- Home
- Infrastructure and government
- Case study, linear asset register
Specifying a linear asset register: referencing and time
A public-sector company ran a project worth tens of millions of euros with a major geospatial content. We helped write the geospatial part of the specification, and then assured the quality of the execution.

Two roles in a project worth tens of millions of euros
The client is a public-sector company that manages linear infrastructure. Its large information system project had substantial geospatial content: the register of its linear facilities and everything connected to them. MaptIQ supported it in two ways.
- Specification: we helped write the geospatial part of the specification: the linear facility register, the linear referencing of related objects and phenomena, and the handling of change over time
- Quality assurance: we assured the quality of the project's execution: we reviewed the system designs and checked that the delivered documentation was complete

Four ideas this project is built on
- 1
Linear facility
A road, a railway, a pipeline or a power line is long and thin. It has an identity, a start and an end, connections to other lines, and many properties that change along its length. A register records what exists, where, in what state and who is responsible. Budgets, maintenance, safety and legal responsibility all start from it.
- 2
Linear referencing
Locating something by its position along a line instead of by map coordinates: on route X, at kilometre 12+350, 4 metres to the right. That position along the route is the measure (chainage, in Hungarian practice the szelvényszám). Engineers, crews and legacy data speak in kilometres, and a measure stays meaningful when coordinates change with a new survey or projection.
- 3
Objects and phenomena
Things that exist on the line, such as bridges, signs and culverts, are objects. Things that happen or hold along it, such as a speed limit, a pavement condition, roadworks or an incident, are phenomena (events). Both attach to the line by linear reference, as a point or a range. Dozens of independent layers can then be stored once and overlaid on the same route.
- 4
Temporal change management
The register must answer not only what is true now, but what was true on a given date and what is planned. Facilities are built, rebuilt, realigned and closed, and facts are also corrected afterwards. Reporting, investment planning, audits and incident investigation all need the state on a specific date.
Position along the route, not only on the map
A route has a measure: the distance from its start, shown on the ground as kilometre markers, where 12+350 means 12 km and 350 m. A point object is stored with one measure, a range event with a start and an end measure, and either can have an offset to the left or right of the route.
The same route can carry any number of such layers, each with its own breaks, and none has to cut the others into pieces. This is often called dynamic segmentation: the pieces are computed when needed, not stored as fixed segments. One attribute can change without touching the others, data from different sources and years can be overlaid, and field data collected in kilometres is usable as it is.
The concept is described in the international standard ISO 19148.
What makes linear referencing hard
- 1
Routes change
A realignment or rebuild shortens or lengthens a route, so the measures after the change shift. Every object and event referenced to that route must be re-referenced, or it points to the wrong place.
- 2
More than one measure system
The official chainage, the kilometre markers on the ground, rarely equals the real geometric length. Both are needed, linked by calibration points.
- 3
Direction, lanes and carriageways
A route can have two directions, separate carriageways and several lanes. Events can apply to one side or both, and left and right are defined relative to the direction.
- 4
Branches, overlaps and gaps
Junctions, ramps, one road carrying two route numbers, and stretches where no data exists. The rules for what is valid must be explicit.
- 5
Coordinates and measures must agree
A point at measure 350 must lie 350 m along the geometry, within a stated tolerance. Positions from GNSS or survey have to be snapped to the route.
- 6
Several networks, one reference
Roads, railways and pipelines each have routes, and an object such as a pipeline crossing a road relates to both. The reference model must allow more than one route per object.
Time: what was true on a given date
Two kinds of time matter. Valid time is when something was true in the real world: the speed limit was 70 from March 2021. Recording time is when the system learned about it: a correction entered in 2025 may say that the limit was already 70 in 2021.
A register that keeps both can answer "what was true on 1 June 2022" and also "what did we believe on 1 June 2022". Facilities also pass through states over their life: planned, under construction, in operation, under reconstruction, out of service, decommissioned. Planned future states must be stored without being mistaken for the present.
This matters for legal reporting, investigations, audits and investment decisions: a number in a report must be explainable, for a date, years later.
What makes change management complex
- 1
Geometry and referencing change together
When a route is realigned, its geometry gets a new version and every object and event on it must follow, keeping its meaning in both the old and the new version.
- 2
Stable identity
A facility keeps its identity through rebuilds, splits and merges, or its history breaks. The rules for when something is the same thing must be written down.
- 3
Real change or correction?
A rebuild is a change in the world, a correction fixes a mistake in the data. They are recorded differently and answer different questions.
- 4
Planned, approved, actual
Future states, approval workflows and the moment a plan becomes reality need clear rules and roles.
- 5
Queries at any date
Every report, map and interface must accept an as-of date, and stay fast over years of history.
- 6
Migrating history
Existing data rarely has a clean history. Deciding what to carry over, and how to mark uncertain dates, is part of the specification.
How we approached writing it
One language for everyone
A glossary and a conceptual model that the client, the users and the suppliers read the same way.
Testable requirements
Each requirement can be checked, with examples that include the hard cases such as a realignment, so a supplier cannot read it two ways.
Open standards as the base
ISO 19148 for linear referencing and the wider ISO 19100 geographic information family for modelling, so the data can be exchanged and the design is not tied to one product.
Data quality defined up front
What counts as complete and correct data, how it is measured, and how exceptions are handled.
Detail where it is hard
The most detail went to where suppliers most often go wrong: referencing, time and migration.
An independent eye during execution
While the project was executed we assured quality on the client's behalf.
- Design review: we reviewed the suppliers' system designs against the specification. Do the designs implement the specified referencing and time model, including the hard cases? Are interfaces, performance, security and data migration covered?
- Documentation check: we checked the delivered documentation for completeness. Is everything promised delivered, is it consistent with the design, and can the client run and maintain the system with it?
- Traceability: each requirement can be followed through design, test and documentation
Findings were reported clearly, so the client could decide and the supplier could fix.
None of this is exotic, and open source handles it
Linear referencing and time are well understood problems. PostGIS has functions for locating points along lines, extracting the part of a line between two measures and interpolating positions, and PostgreSQL has range types and exclusion constraints that can guarantee validity periods never overlap.
A specification can therefore be written product-neutral and implemented on proven open components, with no licence lock-in. The expensive mistakes are made earlier, in the requirements, which is why getting them right before the tender is the cheapest moment. See also our work on infrastructure and government and asset data for a utility.
Planning a large geospatial system?
Before the tender is the cheapest time to get the geospatial requirements right. The first consultation is free.