Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

OpenLR works fundamentally differently. Instead of static identifiers, it generates dynamic location references derived from the actual geometry, topology, and attributes of the road network. Encoding a location therefore requires access to a routable digital map, as the encoder must understand how road segments connect, how paths are formed, and where decision points such as junctions and merges occur. While OpenLR is map‑agnostic in the sense that it is not tied to a specific vendor or map version, it nevertheless requires access to a suitable routable road network at encoding time. OpenLR requires source and target maps to meet "navigable map" standards.

Encoding/decoding TMC location references versus OpenLR location references

...

Workflow Step

TMC (Traffic Message Channel)

OpenLR (Dynamic Location Referencing)

Key Differences / Notes

1. Location Model

Pre-coded locations stored in a Location Table with static IDsDynamic encoding based on geometry, topology, and attributesOpenLR does not rely on static tables; supports unlimited locations.

2. Map Dependency

Relatively dependent on the specific map version/revision used to build and link the TMC table codes to the road network map elementsMap‑agnostic and designed to work across multiple maps and versions

As road networks evolve, older TMC location tables may become outdated. 
OpenLR tolerates map differences, but maps should meet "navigable map" standards. Reliable decoding depends on both geometric alignment and similarity in road attribution (e.g., FRC/FoW). With OpenLR, overcoming a larger difference between source and target map versions needs careful matching to ensure correct location referencing. Larger discrepancies can reduce the decoding success rate. 

3. Location Identification

Lookup of a pre-defined TMC Location Code based on table or attributed map elements.On‑the‑fly encoding of point/line based on actual map geometryTMC is instant lookup; OpenLR requires computation.

4. Encoding Process

Encoding = selecting the right TMC Location Codes from the tableEncoding = generating a reference path via attributes + geometryOpenLR encoding is computationally heavier but flexible.

5. Message Construction

Very compact messages (a few bytes)Larger messages (~20–30 bytes for a line location)Size is rarely an issue today, but OpenLR uses more bandwidth.

6. Transmission

Typically  used in broadcast (RDS, DAB), and low‑bandwidth IP environments

Typically used in wider bandwidth IP-based environments.
TPEG enables hybrid TMC and OpenLR use in digital Broadcast transmission and IP environments.

OpenLR is suitable for richer digital ecosystems.

7. Decoding Method

Match Location Codes to same TMC table on receiver side, and look up associated map elements in map.Decoder reconstructs location using map matching + shortest-path algorithmsOpenLR decoding is more CPU-intensive compared to TMC decoding.

...

Requirement /considerationTMCOpenLRNotes
Cross-map compatibilityLimitedExcellent

TMC location referencing requires pre‑use agreement between parties and explicit processing to insert location codes into digital maps.
OpenLR does not require prior agreement on location codes, and can be decoded against different map databases, making it source and target maps meet "navigable map" standards. This makes OpenLR significantly better suited for heterogeneous, multi‑map ecosystems.

CoverageFixed, limitedUnlimitedOpenLR does not rely on predefined location tables; any location that exists in a digital map can be encoded and transmitted.
TMC location tables are limited in size (typically around 60,000 locations per table).
In Europe, countries typically maintain a single national table, while larger markets such as the USA and China deploy multiple tables (often on the order of 30).
Real-time dynamic updatesModerateExcellent

With TMC, locations must be pre‑identified, agreed, and entered into both location tables and digital maps before they can be referenced, limiting responsiveness. 
OpenLR allows previously unidentified or newly relevant locations to be referenced immediately, for example when an unexpected incident occurs or temporary traffic management is introduced..

Decoder workloadLowHigher

TMC decoding is computationally efficient, as it relies primarily on table look‑ups.
OpenLR decoding requires on‑the‑fly map matching and routing, which increases processing demand on the receiving device.
Notwithstanding the higher workload, millions of in‑vehicle and backend systems use OpenLR decoding for traffic updates without practical issues.

InteroperabilityTable-dependentMap-agnosticTMC interoperability depends on consistent implementation of the same location tables across all parties, which complicates cross‑vendor, or multi‑provider deployments. 
OpenLR enables interoperability without shared tables, facilitating data exchange across different maps, map suppliers, service providers, and system architectures.
However, interoperability still depends on consistent encoder–decoder behavior and alignment on OpenLR formats.
Legacy embedded systemsStrongRequires migration

TMC is in very widespread use in the intelligent transportation ecosystem, with long-life expectations for e.g. in-vehicle traffic information and navigation systems.
Transitional strategies such as dual TMC/OpenLR support and phased migration are recommended to ensure service continuity while gradually increasing the scale of OpenLR adoption across a user base.

...

...