Decide which municipal sensor data to publish

At 8 a.m., a water-level sensor reports an unusual reading. The public works team needs the individual value and its quality status at once. A public map may be better served by a delayed, checked time series. The exact location of a sensor at critical infrastructure may not belong on the open web at all. One measurement stream can require different outputs for different users and risks.

A municipality should publish sensor data as open data when it holds the necessary rights, no overriding protection interest applies, a concrete public use exists, and a named team can operate the data quality and availability. Live raw data is one release level among several. A delayed, spatially generalised or aggregated dataset often makes the better public product. Data with personal-data implications, security relevance or unresolved contractual rights should remain internal or use controlled access.

A release needs a defined data product

An export button cannot make the release decision. The service department must define what others receive: readings, time reference, spatial resolution, measurement method, unit, quality flag, update pattern, licence and contact. Together, these elements form a public data product with an operating commitment the municipality can sustain.

Four release levels cover most municipal sensor cases:

Level	Typical form	Suitable use	Example
Open and current	API with a short delay, status and timestamp	applications that react to new values	temperature, air quality or parking availability after the protection and quality checks pass
Open and limited	delayed, aggregated or spatially generalised	planning, research, transparency and seasonal comparison	daily soil-moisture class by neighbourhood instead of exact tree locations
Controlled sharing	authenticated access with a purpose and roles	emergency partners, research projects or municipal collaboration	higher-resolution water levels for an agreed warning process
Internal	specialist system and operations view	control, fault diagnosis or sensitive infrastructure	device keys, maintenance diagnostics or precise locations of critical components

A municipal sensor-data release level follows five tests: legal basis and rights, protection needs, utility of the requested resolution, measurement quality and long-term operating capacity. If one test fails, the team should reduce detail, timeliness or audience until all five can be supported.

Teams using this rule avoid exposing people or infrastructure and withholding useful data from residents, researchers, businesses and other public bodies.

Access duties and reuse conditions require separate legal checks

Germany's Data Use Act governs reuse of public-sector data that is already accessible. Section 1(2) does not itself create a duty to provide data or a right of access. Municipal legal counsel must first establish whether the dataset is accessible under the applicable federal or state law. The team can then assess the conditions for reuse. This guide cannot replace advice on the relevant state, municipal, environmental-information or sector law.

The Act excludes data where personal-data protection, trade secrets, public security, confidential critical-infrastructure information or third-party intellectual property rights prevent access. For data within scope, it calls for open, machine-readable, accessible, findable and interoperable formats with metadata where possible and appropriate. Dynamic data should be usable through suitable APIs and, where technically necessary, bulk download.

The EU Open Data Directive also separates access regimes from reuse arrangements. Category names such as environment, meteorology, geospatial data or mobility do not by themselves make a municipal stream a high-value dataset. The Implementing Regulation on high-value datasets identifies specific datasets and publication arrangements. Legal counsel and the data owner should compare the individual dataset with its Annex instead of inferring a duty from the subject alone.

Assess protection needs against the public version

The protection review must examine the version that will reach the public, including plausible links to other sources. GovData excludes personal and security-sensitive data and warns that combining sources may allow de-anonymisation. Municipal sensor data can create that risk without a person's name or user account.

A precise sequence of parking occupancy can expose regular movement patterns. Visitor counters may link devices or routes. Water levels, electricity consumption or door states at critical sites can reveal operating conditions. A tree or climate sensor in public space will often carry less risk, although exact coordinates may still increase theft or vandalism.

The release team should test four safeguards one at a time:

1. Temporal aggregation replaces individual readings with hourly or daily values, including coverage and extremes.
2. Spatial generalisation publishes a grid, neighbourhood or road segment instead of a precise point.
3. Delay separates public release from the current operating state.
4. Field reduction removes device identifiers, diagnostics, access information and internal rule states.

Each safeguard must improve protection while preserving the stated use. A daily mean can support a seasonal comparison but cannot support a flood warning. Spatial generalisation can protect a measuring point while destroying a street-level heat analysis. Data protection, information security, the service department and legal counsel should record this trade-off together.

Public utility sets the resolution and update rate

A released time series needs at least one named decision or reuse. Green-space teams might release daily moisture classes for research and climate adaptation. Economic-development staff could publish anonymised footfall by hour. Mobility services need current availability with a clear freshness marker. Area-level public-bin fill data might support accountability, while precise live levels offer little public value and could encourage dumping beside full bins.

Before technical work starts, the team should hold three short interviews: one with an expected internal user, one with a potential external reuser, and one with the person who will answer questions about the dataset. Each participant states their decision, tolerable delay and required resolution. Where demand remains uncertain, the municipality can publish metadata and a bounded sample first. That tests interest before staff promise a maintained live service.

Measurement quality must travel with the value

Sensor values estimate a property of the observed subject. Weather, installation, calibration, radio gaps and sensor replacement affect the series. An open dataset therefore needs more than a number and timestamp.

A publishable municipal sensor value carries at least the measured property, unit, observation time, spatial reference, quality status and method version. A continuing series also needs its update interval, coverage, latest successful transmission and accountable contact.

The open OGC SensorThings API Standard supplies a unified, geospatial model for observations and metadata from heterogeneous IoT systems. Its observation model links the result with its observation time, observed property, sensor and feature of interest. A standard does not define the municipality's quality thresholds. The service department still decides what “checked”, “provisional”, “incomplete” and “invalid” mean.

The European data portal's Data Quality Guidelines organise publication guidance around findability, accessibility, interoperability and reusability. Stable addresses, documented formats, clear terms, working links and a visible update time belong in a municipal data product. A CSV download can serve a monthly report. Dynamic values also need a documented API, bulk access to history and clear rate limits.

Licences and metadata make release usable

An unclear licence blocks serious reuse. GovData recommends standard open licences, including CC0 and CC BY 4.0; the German Data Licence 2.0 is available where a licence of German origin is needed. Municipal legal counsel should choose the licence after checking whether the sensor supplier, network operator or data partner claims rights in the content, database or derived values.

For discovery, GovData's guidance for data providers identifies DCAT-AP.de as the binding basis for metadata exchange with Germany's national portal. A useful record names the title, description, publisher, spatial and temporal coverage, update frequency, format, licence, contact, quality notes and durable address. Units, sensor changes and calculation methods belong in a data dictionary.

A publication service needs an operator

The service department remains accountable for the meaning of the readings. A technical operations team monitors the API, data flow and access boundary. The open-data coordinator maintains the catalogue and licence. Data protection, information security and legal counsel receive defined review triggers, such as a new sensor, higher spatial resolution or an added data link.

The operating plan should answer seven questions. Who can stop a faulty release? How do users recognise stale values? Which availability does the municipality promise? How are method changes versioned? Where can reusers report faults? Which event triggers another protection and utility review? How will the team retire the dataset?

A six-week release pilot provides enough evidence for a first decision. The team sends a representative subset through the public pipeline, creates radio gaps and a method change, checks the licence and metadata, invites an external reuser, and records the support effort. Before approval, the service department should demonstrate that the public output marks faulty or stale values and can pause without disturbing internal operations.

urbanOS fits separate operational and release paths

The urbanOS Urban Data and Urban Intelligence platform is a strong fit for German municipalities and operators of large estates that want to connect existing and new sensors over LoRaWAN, NB-IoT or LTE, run several service applications on one data foundation, and pass selected data onward through an API or GeoJSON and GPX exports. The platform page documents real-time processing, dashboards, automations, open interfaces and hosting in Germany. This best-fit assumes a municipal team will define public data products from internal streams, with a licence, protection level, metadata and operating commitment. The page does not describe a ready-made municipal open-data portal or an automated release decision. Catalogue integration, public API boundaries and acceptance remain project work.

Seven approvals form the release decision

Data owners can approve a municipal sensor dataset for publication when they can support seven statements:

• The municipality holds the necessary rights and has identified the applicable access and reuse law.
• Data protection, security, critical infrastructure, trade secrets and third-party rights do not prevent the chosen public version.
• A named user and public purpose justify its resolution and timeliness.
• Each value carries the necessary time, location, method and quality information.
• The licence, metadata, durable address and machine-readable format are settled.
• The service department, technical team and open-data coordinator have accepted responsibility, budget and an incident path.
• A pilot has tested gaps, method changes, pausing, recovery and external reuse.

Missing evidence does not force a choice between a fully open live stream and a complete block. The municipality can reduce, delay or aggregate the public version, or share it with a controlled audience. With a suitable release level, staff can explain and maintain the public value for years.