Page History
...
Migrating from TMC to OpenLR: impact on Location Referencing Workflows
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 IDs | Dynamic encoding based on geometry, topology, and attributes | OpenLR 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 elements | Map‑agnostic and designed to work across multiple maps and versions | As road networks change, TMC location definitions may become outdated. Older versions of TMC location tables and OpenLR requires careful matching between source and target maps |
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 geometry | TMC is instant lookup; OpenLR requires computation |
4. Encoding Process | Encoding = selecting the right TMC Location Codes from the table | Encoding = generating a reference path via attributes + geometry | OpenLR 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. | 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 algorithms | OpenLR decoding is more CPU-intensive compared to TMC decoding |
Further migration considerations
- Performance and Bandwidth Considerations: The shift from TMC to OpenLR also introduces changes in message size and computational workload. TMC messages are extremely compact—typically only a few bytes—because they reference predefined IDs. OpenLR messages are larger, although size is rarely a limiting factor today. More important is the computational load: while encoding can be handled efficiently on central servers, decoding is significantly more demanding and must be performed on the end-user device. This is especially evident in major metropolitan areas such as London or Paris, where devices may need to decode large volumes of traffic messages within short timeframes. In such environments, CPU load may increase noticeably, potentially delaying the processing of subsequent message batches
- Legacy System Integration: TMC has been deeply embedded in navigation devices, broadcast protocols, and traffic‑management workflows for many years. As a result, migration to OpenLR typically requires transitional measures. These often include dual support for both formats, bidirectional conversion between TMC and OpenLR, and updates to broadcast or distribution systems. Maintaining continuity for existing services is an important operational requirement, making careful planning and phased migration essential.
- Quality Assurance: The transition to OpenLR requires thorough verification to ensure that encoded locations correspond correctly to their intended positions. This includes validating accuracy across different map versions, detecting mismatches caused by attribute or topology differences, and ensuring resilience as underlying maps evolve. Achieving this level of reliability requires automated QA infrastructure, consistent regression testing, and ongoing monitoring to verify that references continue to behave correctly as maps are updated.
Governance and Standardization: TMC benefits from a long-standing standardized framework, although maintaining location tables is resource‑intensive. OpenLR is open and broadly adopted, but the ecosystem includes several variants—such as the TomTom formats, the ISO TPEG2‑OLR standard, and the XML‑based adaptations used in DATEX II and TN‑ITS. This diversity provides flexibility but introduces complexity when interoperability across stakeholders is required. Ensuring encoder–decoder compatibility across these variants is therefore an important aspect of system design and governance.
Decision Guide
| Requirement /consideration | TMC | OpenLR | Notes |
|---|---|---|---|
| Cross-map compatibility | Limited | Excellent | TMC location referencing requires pre‑use agreement between parties and explicit processing to insert location codes into digital maps. |
| Coverage | Fixed, limited | Unlimited | OpenLR 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 updates | Moderate | Excellent | With TMC, locations must be pre‑identified, agreed, and entered into both location tables and digital maps before they can be referenced, limiting responsiveness. |
| Decoder workload | Low | Higher | TMC decoding is computationally efficient, as it relies primarily on table look‑ups. |
| Interoperability | Table-dependent | Map-agnostic | TMC 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 systems | Strong | Requires 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. |
Implementation Notes
- Provide dual TMC/OpenLR output during transition to ensure backward compatibility.
- Pre-deployment testing must account for all major map vendors used by end users.
- Measure decoder performance under realistic, high‑volume scenarios.
- Establish automated QA and monitoring for geometric mismatches.
...
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. | I did not receive any confirmation from the car industry that this is the case | |
| 2 | Maybe we can convert one specific TMC-segment (a segment of 3 TMC-points) to an OpenLR-segment as an example how to proceed | ||
| 3 | It 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) | ||
| 4 | A 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) |
Proposal 2 (discussion item )
...
- Performance and Bandwidth Considerations: The shift from TMC to OpenLR also introduces changes in message size and computational workload. TMC messages are extremely compact—typically only a few bytes—because they reference predefined IDs. OpenLR messages are larger, although size is rarely a limiting factor today. More important is the computational load: while encoding can be handled efficiently on central servers, decoding is significantly more demanding and must be performed on the end-user device. This is especially evident in major metropolitan areas such as London or Paris, where devices may need to decode large volumes of traffic messages within short timeframes. In such environments, CPU load may increase noticeably, potentially delaying the processing of subsequent message batches
- Legacy System Integration: TMC has been deeply embedded in navigation devices, broadcast protocols, and traffic‑management workflows for many years. As a result, migration to OpenLR typically requires transitional measures. These often include dual support for both formats, bidirectional conversion between TMC and OpenLR, and updates to broadcast or distribution systems. Maintaining continuity for existing services is an important operational requirement, making careful planning and phased migration essential.
- Quality Assurance: The transition to OpenLR requires thorough verification to ensure that encoded locations correspond correctly to their intended positions. This includes validating accuracy across different map versions, detecting mismatches caused by attribute or topology differences, and ensuring resilience as underlying maps evolve. Achieving this level of reliability requires automated QA infrastructure, consistent regression testing, and ongoing monitoring to verify that references continue to behave correctly as maps are updated.
Governance and Standardization: TMC benefits from a long-standing standardized framework, although maintaining location tables is resource‑intensive. OpenLR is open and broadly adopted, but the ecosystem includes several variants—such as the TomTom formats, the ISO TPEG2‑OLR standard, and the XML‑based adaptations used in DATEX II and TN‑ITS. This diversity provides flexibility but introduces complexity when interoperability across stakeholders is required. Ensuring encoder–decoder compatibility across these variants is therefore an important aspect of system design and governance.
Decision Guide
| Requirement /consideration | TMC | OpenLR | Notes |
|---|---|---|---|
| Cross-map compatibility | Limited | Excellent | OpenLR best for heterogeneous ecosystems |
| Coverage | Fixed, limited | Unlimited | No need for location tables |
| Real-time dynamic updates | Moderate | Excellent | OpenLR more flexible |
| Decoder workload | Low | Higher | The large majority of in-vehicle devices handle / decode OpenLR reference for traffic updates |
| Interoperability | Table-dependent | Map-agnostic | Better for multi-provider environments |
| Legacy embedded systems | Strong | Requires migration | Transitional dual support recommended |
Implementation Notes
- Provide dual TMC/OpenLR output during transition to ensure backward compatibility.
- Pre-deployment testing must account for all major map vendors used by end users.
- Measure decoder performance under realistic, high‑volume scenarios.
- Establish automated QA and monitoring for geometric mismatches.
...
Comments
| 1 | |||
| 2 | |||
| 3 |
Proposal 1 (discussion item )
...
- TMC is standardized and widely adopted, but supporting various versions of TMC location tables presents large overhead at the server side/encoding side.
- OpenLR is open source, also widely adopted, but less regulated, so encoder/decoder compatibility may require attention.
...
Comments
| 1 | |||
| 2 | |||
| 3 |
