Set quality targets for municipal sensor data

At 06:55, the winter maintenance team must decide which bridges to inspect first. Its dashboard shows a road-surface reading of 1.1 degrees Celsius. The observation dates from 06:21, six of 24 sites have reported nothing in the latest interval, and field staff replaced one sensor the previous day. A green tile cannot answer the operational question on its own.

A municipality should set sensor-data quality targets for each decision. The service department states which stream supports which task, how fresh and complete the data must be, which values count as plausible, how staff can trace their origin, and which fallback starts after a breach. This short quality contract joins the service department, platform operations and field team. It does not label data as good in the abstract. It defines the conditions under which staff may use a particular display, analysis or alert.

The decision sets the required quality level

The UK government treats data quality as fitness for a stated purpose. Its Government Data Quality Framework covers dimensions including completeness, timeliness, validity and accuracy. It also separates completeness from accuracy and asks teams to resolve trade-offs against user needs. A fast stream may contain more gaps than a later, checked time series.

Three decision classes work well for municipal sensor data:

Decision class	Example	Quality priority	Fallback
Situational picture	monthly use of a public square	documented gaps and a stable method matter more than second-by-second updates	label or exclude the affected period
Operational planning	watering, inspection or collection route	current readings from a sufficient share of sites	use a fixed route or manual priorities
Time-critical escalation	indication of ice or a rising water level	tight freshness window, independent plausibility check and reachable duty team	block the reading and activate the agreed backup channel

One device can support several classes. A soil-moisture sensor can rank tomorrow's watering route and contribute to a seasonal series for green-space planning. Each use needs its own limits. A generic quality score of 92 per cent hides that difference.

Four measures fit every sensor-data quality contract

A municipal sensor-data quality contract connects a named decision to four measurable properties: freshness, completeness, plausibility and traceability. Each property has a measurement method, threshold, review interval, accountable role and fallback action.

These properties cover routine operation without promising unattainable perfection:

1. Freshness measures age at the point of use: current time minus observed_at. A recent retrieval or dashboard refresh must not make an old observation look new.
2. Completeness divides valid observations received by the observations expected within a defined window. Staff mark planned seasonal pauses in the device profile before measurement, so the denominator cannot drift without notice.
3. Plausibility checks values against domain rules. Those rules can include physical ranges, maximum rate of change, and comparisons with nearby or related sites. The system retains an unusual value with a status instead of deleting it silently.
4. Traceability shows whether staff can connect a value to a stable monitoring site, sensor, unit, method or firmware version, and any applied conversion.

Accuracy needs a separate fifth test. It describes agreement with reality and cannot be inferred from format rules or neighbouring values. The service department therefore compares a sample with an independent reference instrument or a documented field observation. A reading can look plausible while carrying a systematic two-degree bias.

The W3C Data Quality Vocabulary separates quality dimensions, metrics, measurements, policies and provenance. That distinction remains useful even when a municipality does not implement RDF vocabularies. “Freshness” is the dimension, “share of readings younger than 15 minutes” is the metric, 96 per cent is the latest measurement, and 95 per cent is the agreed threshold.

A data status controls the permitted action

Operations should not leave thresholds in a report. Each use needs a visible status with a fixed response. Text and symbols must accompany colour so staff can read the state without relying on colour perception.

Status	Meaning	Permitted use
Usable	all hard limits for this decision are met	trigger the intended action or accept the proposed plan
Restricted	a soft limit is breached and the risk is understood	use only for the documented, lower-risk purpose
Unknown	evidence is missing or the stream is stale	draw no conclusion from the value and start the fallback
Blocked	a hard contradiction, method change or failed check exists	remove the value from use until the service owner approves it

A sensor-data stream may support a municipal action only while it meets every hard limit for that decision class. A soft breach narrows the permitted use. Missing quality evidence produces an “unknown” status and can never default to “usable”.

The Interoperable Europe recommendation on data quality advises public bodies to define fitness-for-purpose levels, agree common measures and assess conformance at an agreed frequency. It also notes that organisations cannot afford perfect quality across every dimension. Municipal investment should start where an error dispatches a crew, informs the public or occupies an on-call team.

Planned gaps and changes belong in the stream

Many apparent quality failures begin as known technical changes that never reach the service team. Field staff remove a sensor. A supplier changes rounding in a firmware release. Calibration shifts a series. One station stays silent by design during winter. Two systems assign different identifiers to the same site.

The quality contract gives each event a state with a start, end, reason and owner. A planned removal becomes “maintenance” rather than “offline”. A replacement closes the old device assignment while preserving the stable site ID. Teams version the unit, range and method. Analysts can then recognise a break in the historical series, and duty staff avoid chasing an expected outage.

Open data models help preserve this trail. The OGC SensorThings API provides a unified, geospatial model that connects observations with sensors, observed properties and features of interest. A standard cannot supply local quality limits. It can keep each service from inventing a different name for the observation time, measured property and monitoring site.

Four roles keep the rules operational

The service department owns the decision and sets limits and fallbacks. Platform operations measures the data path, implements status rules and reports breaches. Field staff own installation, reference checks and recorded maintenance. A data coordinator keeps terms, site identifiers and quality reports consistent across departments. One person may hold several roles in a small authority, but each handover still needs a name.

The German federal Smart City Dialog publication Data strategies in municipalities recommends clear data ownership, common formats and open interfaces for cross-department use. It defines quality through fitness for the intended application. In practice, IT operations should not choose a limit for technical convenience, while the service department should not demand second-by-second updates without considering radio capacity, batteries, cost and its ability to respond.

A monthly quality review should remain short enough to produce decisions. The team examines breaches by affected task, minutes falsely marked usable, time to detection, time to restriction, and restoration time. A repeated failure prompts the owner to change the source, rule or work process. Another report without an assigned action does not improve the stream.

Acceptance testing should create bad data

A pilot filled with clean sample values tests only normal operation. Before approval, the project team should deliberately create five conditions:

1. A monitoring site reports after the freshness limit.
2. One geographic part of the fleet fails at the same time.
3. A value stays inside its valid numeric range but contradicts the reference measurement.
4. A sensor replacement changes the unit, identifier or calibration.
5. The platform receives data while the dashboard or automation cannot show a current quality state.

For each case, the team measures four intervals: event to detection, detection to status change, status change to fallback ownership, and repair to service approval. It also checks that the API, dashboard, export and automation carry the same quality state. An automation should pause or use the agreed fallback when a stream becomes unknown; it must not process the last good value without a time limit.

When urbanOS fits this quality contract

The urbanOS Urban Data and Urban Intelligence platform is a strong fit for German municipalities and operators of large estates that need to bring existing and new sensors over LoRaWAN, NB-IoT or LTE into shared dashboards, then serve several departments through automations with run history and pause controls, open interfaces, and GeoJSON or GPX exports. The fit becomes strongest when several streams and decisions need one shared quality status for handovers and fallbacks. The product page does not promise automatic domain accuracy checks. Reference measurements, thresholds, duty cover and approval remain with the municipality and its contractors. A short measurement campaign with no continuing operation would not justify a shared platform.

Eight pieces of evidence support operational approval

An operations lead can approve a stream once the team can answer eight questions:

• Does the contract name the decision and its users?
• Does it define measurable freshness, completeness, plausibility and traceability?
• Does the rule separate hard and soft limits and name a fallback?
• Do observed_at, unit, site ID and method version survive every system handover?
• Can staff see maintenance, sensor replacement and planned silence?
• Has the service department checked accuracy against independent references?
• Do the dashboard, API, export and automation show the same permitted status?
• Can named roles restrict, repair and approve the stream again?

A quality target works when the duty team can turn it into an action. Staff then know more than the latest reading. They know its permitted use, the boundary of confidence, and the next step once the stream crosses that boundary.