Versions Compared

Key

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

...

Migrating from TMC (Traffic Message Channel) to OpenLR means shifting from fixed, pre‑coded location tables to a dynamic, map‑agnostic referencing method. OpenLR offers greater flexibility, unlimited road network coverage of locations of interest, and cross-map interoperability.
Nonetheless, the migration introduces technical, operational, and performance considerations. Successful adoption requires careful planning around encoding accuracy, interoperability across digital map providers, decoder performance on end devices, and the integration of legacy systems.

...

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 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.
Nevertheless, the large majority of modern Notwithstanding the higher workload, millions of in‑vehicle and backend systems are capable of handling 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.

...

Comments

1

Nevertheless, the large majority of modern in‑vehicle and backend systems are capable of handling OpenLR decoding for traffic updates without practical issues.

Rewording: Nevertheless, millions of in‑vehicle and backend systems use OpenLR decoding for traffic updates without practical issues.

I did not receive any confirmation from the car industry that this is the case

VW does not use OpenLR

Mercedes Audi, Stellantis, BMW, Kia use it. 


2Maybe we can convert one specific TMC-segment (a segment of 3 TMC-points) to an OpenLR-segment as an example how to proceed

Need a example, TMC location codes, TMC labeling of road segments, and a generated OpenLR code.

TH: Let's see whether an example on USA maps can be generated. 


3It may be 3It may be worth to also mention, that it requires a model of the road network (i.e., not only a map in the sense of a picture/drawing) to encode and decode OpenLR. This is an obstacle (and is often misunderstood) for a public authority who is not also the creator of maps/digial road networks. (TMDL)


(green star) Explain this. Make workflow recommendation, with migration start from digital map, and parallel generate both TMC and OpenLR location reference, not first TMC LR then TMC decoding on map, then OpenLR encoding.  


4A question, maybe for discussion in the WG: Should a road authority without a TMC or TPEG service continue to maintain a TMC location code set for their road network after a transition to OpenLR? What are arguments for and against? (TMDL)→ discussion item for the next telco 

Proposal 2 (discussion item )

...

Requirement /considerationTMCOpenLRNotes
Cross-map compatibilityLimitedExcellentOpenLR best for heterogeneous ecosystems
CoverageFixed, limitedUnlimitedNo need for location tables
Real-time dynamic updatesModerateExcellentOpenLR more flexible
Decoder workloadLowHigherThe large majority of in-vehicle devices handle / decode OpenLR reference Notwithstanding the higher workload, millions of in‑vehicle and backend systems use OpenLR decoding for traffic updates without practical issues.
InteroperabilityTable-dependentMap-agnosticBetter for multi-provider environments
Legacy embedded systemsStrongRequires migrationTransitional dual support recommended

...