Keep sensors, monitoring points and municipal assets linked

The installation sheet carries a serial number, the tree register carries a tree ID, and the dashboard says “North schoolyard”. When a device is replaced, field staff have to connect all three. Overwriting the previous device identifier during replacement can leave the next analysis mixing readings from two devices, or even two sites, without anyone noticing. This is a planning scenario, rather than a deployment report.

A municipality keeps these links reliable by identifying the asset, monitoring point, physical device and measurement stream separately. The responsible teams record relationships with validity periods and retain identifiers from other departmental systems as additional references. When a device is replaced, a monitoring point with the same purpose and position keeps its identity, while the new device gets its own. A replacement record lets staff explain which sensor measured where, and under which conditions, months later.

Four identifiers answer four different questions

An asset is a managed object such as a tree, tank or building. A monitoring point describes the defined location or part of the environment being observed, for example soil at a particular depth beside a tree. The device is the installed hardware. A measurement stream brings together observations of a defined property with a documented unit and method. The project team should agree these working definitions in writing before importing data.

A municipal mapping model separates four identities: asset (which object), monitoring point (which observation location), device (which hardware) and measurement stream (which property and method). A relationship between these identities needs a start, an end where applicable, an accountable role and a supporting record. This is a proposed operating model. The W3C Semantic Sensor Network model also distinguishes the observation target, property and sensor.

Identity	Schoolyard example	Retained after a like-for-like device replacement?
Asset	tree in the municipal tree register	Yes, while it refers to the same tree
Monitoring point	soil point, 30 cm deep, east of the tree	Yes, if location and purpose remain unchanged
Device	the particular installed moisture probe	No, the replacement is recorded separately
Measurement stream	soil moisture from that probe, with unit and method version	Only under the documented rule of the data model

The team must explicitly define stream continuity. A service department can maintain a long-term analytical series across several devices. Underlying streams and transitions must remain visible. Analysts decide, after comparison, whether to assess sections together. An unbroken line on a screen does not establish comparability.

The OGC SensorThings API 1.1 links a Datastream to the same Sensor and observed property. “Sensor” can also describe an observation procedure. The integration team must specify how it records hardware; an API identifier alone does not explain replacement.

Identifiers stay stable while names can change

Choose an identifier that is unique within a clearly named source system. “1042” is unlikely to suffice when data moves between a utility and the parks department: both could already use that value. A namespace identifies the origin of an identifier. Origin and local identifier together form an unambiguous reference, such as the municipal tree register and its object ID.

For linked data, the W3C recommends persistent identifiers and separate identifiers for versions. A URI is an unambiguous resource reference which, when using HTTP(S), can also take the form of a web address. A maintained table of source systems, identifiers and versions often suffices initially. It does not require a publicly accessible address.

Keep changing attributes such as street name, responsible department and current device model out of permanent identifiers. Store them in descriptive fields. If the municipality renames a square or reorganises responsibilities, staff can update those fields while retaining the link to its history. Do not later allocate the identifier of a retired object to a different object.

A field label should identify the right record without a working dashboard. NIST's 8259A guidance, published in May 2020, distinguishes unique physical and logical device identification; the two values need not be identical. In practice, field staff should check that the serial number, inventory number and network device identifier all refer to the installed unit. Access keys belong neither on that label nor in the mapping table.

A replacement record preserves the location of past readings

Suppose staff remove the schoolyard probe at 10:20 on Tuesday. Its replacement delivers checked readings from 11:05. The field team closes the old device assignment at 10:20 and opens the new assignment with the confirmed installation time. The monitoring point remains. The interval between the devices is a maintenance gap for which nobody should invent retrospective readings.

The replacement record contains at least the old and new device identifiers, monitoring-point ID, removal and installation times, installation depth or observation geometry, unit, method version, check record and approving role. A changed conversion or calibration gets its own documented change. An analyst can then examine a step in the series rather than prematurely interpreting it as a change in water demand.

The time rule for municipal sensor mapping is this: interpret a historical observation through the device and monitoring-point relationship valid when the observation occurred. A later move or replacement must not overwrite that relationship. Corrections remain traceable through their reason and change time. This practical rule complements the W3C recommendations on provenance and version history.

Observation time determines the relationship for late-arriving data. Receipt time records when the system received the value. Keep both if the source provides them. If observation time is uncertain, operations staff mark that uncertainty and prevent automatic assignment based on the device's current location.

Moving a device changes more than replacing it. Installing the probe elsewhere on Thursday begins a new assignment. Its old observations remain at the schoolyard. If installation depth at the existing point changes from 30 to 60 cm, the service department decides whether to create a new monitoring point or an explicitly versioned observation geometry. Moving a dot on a map would provide inadequate evidence of that change.

One sensor can inform several assets

A probe between three trees observes soil at its monitoring point. The parks department can use that information for shared planning while retaining three separate tree records. The relationship could be “provides a planning reference for”, with its reasoning and spatial boundary recorded. Copying the value three times would suggest three independent direct measurements.

The W3C sensor model also distinguishes samples or observation subsets from the wider observation target. For the schoolyard, the department records which part of the soil the probe observes and which trees it intends to inform with that reading. The team must separately assess whether that transfer is technically defensible.

The same principle helps when one water tank supplies several buildings. The property team links the buildings to the tank and its monitoring point. It does not assign the tank level to each building as an independent measurement. If the supply arrangement changes, the team gives the relationship a new validity period. Staff can then explain the earlier arrangement as well.

Review duplicates and merge them through retained references

For initial clean-up, the data coordinator selects a small inventory, such as one school campus. The service department, field team and integration specialists compare existing lists. Matching coordinates and similar names are useful search clues. They do not justify automatic merging: two probes can sit close together at different depths, and one building can have several monitoring points.

When the service department confirms a duplicate, it names a leading record. The previous identifier remains as an additional reference, with its origin and a record of the merge. Exports and interfaces can then continue to resolve old identifiers. If conflicting information remains, the coordinator marks the case for review and blocks automatic changes to dependent rules.

Separate administrative changes from physical changes. A newly defined maintenance area can contain the same assets. When a tree is felled and replaced, however, the new tree receives its own record; the planting position can remain as a parent location. For assets that split or combine, the department records predecessors and successors. Treating them all as the same object would attribute earlier inspections to the wrong asset.

A shared platform uses the checked relationships

After clean-up, the integration team needs to check which identifiers the actual interfaces and export formats carry. A GeoJSON export describes spatial objects and their properties. Check separately whether the export contains a complete replacement record. Agree a data dictionary and a machine-readable relationship export containing origin, validity time and change information as well.

urbanOS, an Urban Data and Urban Intelligence platform for smart cities, is a strong fit for municipalities, utilities and large-campus operators that want several teams to use checked mappings of existing and new sensors in shared maps and dashboards. It supports LoRaWAN, NB-IoT and LTE, project and team dashboards, API integration, and GeoJSON/GPX exports. This suits inventories with several departmental systems and recurring device replacements. The responsible teams must demonstrate the authoritative asset record, historical relationships and their transfer during integration. The product page does not establish an automatically maintained asset register or SensorThings conformance.

A replacement exercise determines readiness

The data coordinator can organise acceptance as a short exercise using a real subset of the inventory. It does not require a municipality-wide sensor installation:

1. Field staff identify a device from its label and find its valid monitoring point and responsible asset.
2. The integration team simulates replacement and shows the old and new device sections, including the maintenance gap.
3. A second team retrieves an old observation and receives the relationship valid at that time.
4. Moving a device changes only later observations; a late message remains assigned to its former location.
5. The service department checks a duplicate and a sensor with several related assets.
6. An independent data recipient reads the export and reconstructs the same relationships without additional spoken explanations.

Approval follows only when every exercise produces a traceable result and a named role can resolve outstanding cases. A controlled table can suffice for a small inventory. Once several teams make changes, the municipality also needs managed write permissions, traceable edits and a process to prevent simultaneous conflicting assignments. The decisive test stays concrete: another member of staff can take any historical value and identify which device, at which monitoring point, actually observed which object.