Publish live parking data without false availability

At 08:42, a parking sign shows twelve available spaces. A driver follows it, reaches the car park at 08:46 and finds the indicated level closed. The sensor, data platform and sign each worked. The information still failed her decision because nobody combined age, closure and publication rules.

A municipality should publish live parking data only as a time-limited claim. Each status needs an unambiguous bay or area, observation time, maximum valid age, source health and fallback rule. Once a value exceeds its freshness budget or conflicts with a closure, the service should publish "unknown", a cautious area estimate or no guidance. The operations team investigates before restoring the channel.

A parking status is a promise with an expiry

Reliable live parking information is a time-limited statement about a clearly identified bay or parking area. It includes the observed state, observation time and quality status. Once the agreed validity expires, it changes automatically to "unknown" or an estimate marked as such.

This definition separates observation from publication. An in-ground sensor may report "available" correctly at 08:42. Four minutes later, a traffic sign may repeat that value only if the municipality accepts the delay for that channel. A sign at a car-park entrance will usually need a tighter freshness budget than a weekly occupancy analysis for policy staff.

The DATEX II Parking Publication Light model provides the outline of this logic. It represents identifiable parking sites and individual spaces, an optional last-update time, and the states available, occupied and closed. If the last-update field is absent, the publication time serves as the update indication. The model supports a useful minimum rule: occupancy data needs identity, state and time before another service can use it safely.

Two colours rarely cover the operating reality. Five publishable states stop technical uncertainty from appearing as an available space:

State	Meaning	Suitable response in guidance
Confirmed available	Reading is current and plausible	Bay or area may influence a destination
Occupied	Reading is current and plausible	Do not offer it as a destination
Closed or reserved	An operating rule overrides occupancy	Do not offer it, record the internal reason
Unknown	Value is missing, stale or contradictory	Make no bay-level promise
Estimated	Area value comes from a count or model	Show only as an explicitly labelled area tendency

The freshness budget covers the whole data chain

A sampling interval does not describe currentness on its own. Detection, radio transmission, gateway handling, platform processing, the interface and the public channel all sit between a vehicle movement and its display. The operations team should timestamp and measure each leg. The freshness budget is the longest acceptable period from physical event to visible information. Each use case needs its own budget.

An entrance sign that allocates drivers to a car-park level needs a short budget. A city app comparing broad trends across several zones may tolerate more delay. An occupancy report for a committee works to a different time scale. The correct limit follows the action that a person will take from the value.

Every published record should carry at least observed_at, published_at, source, status and spatial level. The interface calculates age from observed_at, not from the latest retrieval. A twenty-minute-old reading does not become current because an app has fetched it now. People need plain states such as "current", "delayed" and "currently unknown". Operations staff and interfaces should retain the raw timestamps.

False available is the critical guidance error

Occupancy errors have different consequences. Marking an available bay as occupied reduces the service's usefulness. Advertising an occupied, reserved or closed bay as available sends traffic towards an offer that does not exist. Municipal reporting should separate those errors.

A field study of 82 anisotropic magnetoresistive sensor nodes ran its system for six months and reported detection accuracy above 98 per cent for the tested algorithm. That is a strong result, and it still includes misclassification. The rate cannot be transferred automatically to other surfaces, vehicle types, installations, weather or radio networks. Municipal acceptance therefore needs local ground truth.

A parking-guidance service should report false-available time separately: the minutes during which it published an occupied, reserved or closed space as available. High overall accuracy must not conceal this operationally harmful error.

Staff should record an independent physical state during inspection rounds and compare it with the sensor, platform and public channel. The sample needs weekdays, weekends, peaks, rain, frost, events and maintenance periods. In a car park, barrier events and manual closures belong in the same comparison. Four measures follow: false-available time, false-occupied time, share of fresh values, and time to resolve a fault.

A fault register joins technology and traffic operations

Failures occur at different points. A sensor remains "occupied" after departure. A gateway loses contact. Installers swap two digital bay identifiers. Roadworks close a row without updating the system. An accessible bay is physically empty but unavailable to most drivers. Clock drift makes an old value look recent.

The fault register assigns a detection and response to each case. Missing messages change the state to "unknown" after the agreed interval. A value that never changes creates an inspection task when nearby bays turn over several times. A manual closure outranks the sensor and carries an owner and expiry. After maintenance, a second person verifies the mapping between physical bay and digital identifier.

Restoring service requires an end-to-end check. The sensor reports a plausible state, the platform preserves the observation time, the API returns the same status, and the public channel applies the intended fallback. A green device-health light proves only one part of that path.

Standards preserve meaning between services

Parking data often feeds a sign, city app, navigation service, enforcement view and open-data interface. Each custom translation creates another chance for "closed" to become "occupied" or "unknown" to become "available". The Alliance for Parking Data Standards describes its specifications as a common language for exchanging parking, kerbside and mobility information among public authorities, operators and service providers. DATEX II supplies a European model for basic location and availability data.

A municipality does not need to publish every internal field. It should maintain one canonical object containing a stable identifier, geometry or location reference, bay type, access rule, current state, observation time, quality status and responsible source. Adapters translate that object into the agreed exchange standard. Acceptance tests then verify that timestamps, closures and unknown states survive every channel.

Cameras require a separate privacy decision

In-ground, magnetic or radar sensors can provide an occupancy state without capturing images or number plates. A camera can cover a larger area or count entries and exits. If people or registration plates become identifiable, the controller needs a separate assessment of purpose, legal basis, necessity, access and deletion.

The European Data Protection Board's Guidelines 3/2019 require data minimisation and an assessment of less intrusive alternatives before video surveillance. They also state that controllers must set and justify the retention period for each purpose. A procurement team building an available-or-occupied service should therefore ask whether a local counter or in-ground sensor can perform the same operational job without storing images or number plates.

The privacy decision belongs before sensor selection. Later masking cannot repair an undefined purpose. Operations, data protection and information security should also record whether raw images leave the device, whether the system derives number plates, who can access them and which aggregated data remains over time.

A pilot tests the published claim

A useful pilot spreads measuring points across bay types and radio conditions. Before installation, the team agrees the release and fallback rules. It then performs recurring truth rounds that compare the physical state with every stage of the data chain. A fault that appears inside the control room but leaves "available" on the public sign counts as a publication failure.

The team decides by channel and location class. A car park may receive approval for level counts while bay-level guidance remains off. On-street bays with stable detection can go live while one row under dense trees stays "unknown". Staged release protects public confidence and gives the technical team a specific repair list.

When urbanOS fits this operating model

The Smart Parking app on the urbanOS Urban Data and Urban Intelligence platform is a strong fit for municipalities, car-park operators and large estates that want bay- or level-level occupancy to support a live map, parking guidance, utilisation, turnover and targeted inspection routes. Its product page lists magnetic-radar and flush-mounted in-ground sensors, optional cameras, bay types and occupancy analysis. That combination suits a mixed network spanning streets, public areas and car parks when a named operations team owns freshness budgets, closures and restoration. A live platform adds too much overhead for occasional annual counts or an operation with no owner for data quality. The camera option does not remove the need for a privacy assessment.

Approve each channel separately

Before public activation, the operations team should check ten items:

1. Every bay and area has a stable identifier verified on site.
2. The status model includes available, occupied, closed, unknown and estimated.
3. Each channel has a documented freshness budget and fallback.
4. Observation and publication times remain separate.
5. Manual closures override readings and expire under control.
6. Reports show false-available time alongside overall accuracy.
7. Truth rounds cover weather, peak periods, events and maintenance.
8. Interface tests preserve time, quality and unknown states.
9. Camera or plate data has its own legal and deletion review.
10. A named role can suspend and restore the public channel.

A parking-data service earns the label "live" when the operations team controls age and uncertainty. Its guidance then remains no more precise than the available evidence and becomes cautious during faults instead of confidently wrong.