...

Prior revisions of answers

Proposal 3 (Consolidation item after meeting21 Jan 2026 )

Short Summary Answer

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 map providers, decoder performance on end devices, and the integration of legacy systems.

Why the Need for Migrating from TMC to OpenLR?

TMC relies on static, pre-coded location tables that limit coverage to predetermined road segments and require frequent maintenance. As digital mobility ecosystems evolve and more stakeholders use diverse maps (e.g. from Google, HERE, TomTom, OSM), a map‑agnostic approach becomes essential. OpenLR supports unlimited coverage, map independence, and dynamic location encoding, enabling consistent interpretation of locations across different maps and versions. Its flexibility is better suited for modern traffic services, dynamic updates, and large-scale multi-map environments.

Stakeholder Relevance / Rationale

Relevance and rationale for migrating to OpenLR for various stakeholders can be summarized as follows:

• Public Authorities:  Supports interoperability across national access points and data platforms. Scales to new road networks, and eliminates dependency on pre-coded tables with limited coverage and associated maintenance costs.
• Content Providers: Enables consistent location exchange across different map providers. Simplifies data aggregation from heterogeneous sources. Reduces constraints caused by limited TMC location coverage.
• Service Providers: Facilitates real-time, high-volume traffic message handling. Supports dynamic updates that work across multiple map ecosystems. Avoids reliance on static TMC tables that may lag behind map updates.
• OEMs: Offers a flexible method for in‑vehicle systems where map providers vary. Allows dynamic encoding for real-time routing and ADAS services. Reduces the need for large, pre-installed TMC tables and updates thereof.

Detailed Explanation

Migration means adopting a fundamental change in referencing approach

TMC relies on fixed identifiers that point to pre‑defined entries in a location table. This approach guarantees deterministic matching, but it also restricts flexibility and limits coverage to only those locations that have been coded in advance.

OpenLR works fundamentally differently. Instead of static IDs, it generates dynamic encodings based on the actual geometry and attributes of the road network. Because it does not depend on a specific map version or vendor, it functions as a fully map‑agnostic method that can be used consistently across different maps and updates.

Migrating from TMC to OpenLR: impact on Location Referencing Workflows

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

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.

References & Tools

For understanding OpenLR as a method the following references are useful:

• OpenLR White Paper (PDF) 

• OpenLR_Decoding_bits_and_bytes v1.0,1 (PDF)

• ISO 21219-22 – TPEG2-OLR Standard

• TISA Github 

• GitHub Reference Implementation

• HOWTO.md Guide

• OpenLR Python Documentation

Comments

Proposal 2 (discussion item21 Jan 2026 )

Short Summary Answer

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 map providers, decoder performance on end devices, and the integration of legacy systems.

Why the Need for Migrating from TMC to OpenLR?

TMC relies on static, pre-coded location tables that limit coverage to predetermined road segments and require frequent maintenance. As digital mobility ecosystems evolve and more stakeholders use diverse maps (e.g. from Google, HERE, TomTom, OSM), a map‑agnostic approach becomes essential. OpenLR supports unlimited coverage, map independence, and dynamic location encoding, enabling consistent interpretation of locations across different maps and versions. Its flexibility is better suited for modern traffic services, dynamic updates, and large-scale multi-map environments.

Stakeholder Relevance / Rationale

Relevance and rationale for migrating to OpenLR for various stakeholders can be summarized as follows:

• Public Authorities:  Supports interoperability across national access points and data platforms. Scales to new road networks, and eliminates dependency on pre-coded tables with limited coverage and associated maintenance costs.
• Content Providers: Enables consistent location exchange across different map providers. Simplifies data aggregation from heterogeneous sources. Reduces constraints caused by limited TMC location coverage.
• Service Providers: Facilitates real-time, high-volume traffic message handling. Supports dynamic updates that work across multiple map ecosystems. Avoids reliance on static TMC tables that may lag behind map updates.
• OEMs: Offers a flexible method for in‑vehicle systems where map providers vary. Allows dynamic encoding for real-time routing and ADAS services. Reduces the need for large, pre-installed TMC tables and updates thereof.

Detailed Explanation

Migration means adopting a fundamental change in referencing approach

TMC relies on fixed identifiers that point to pre‑defined entries in a location table. This approach guarantees deterministic matching, but it also restricts flexibility and limits coverage to only those locations that have been coded in advance.

OpenLR works fundamentally differently. Instead of static IDs, it generates dynamic encodings based on the actual geometry and attributes of the road network. Because it does not depend on a specific map version or vendor, it functions as a fully map‑agnostic method that can be used consistently across different maps and updates.

Migrating from TMC to OpenLR: impact on Location Referencing Workflows

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

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.

References & Tools

For understanding OpenLR as a method the following references are useful:

• OpenLR White Paper (PDF) 

• OpenLR_Decoding_bits_and_bytes v1.0,1 (PDF)

• ISO 21219-22 – TPEG2-OLR Standard

• TISA Github 

• GitHub Reference Implementation

• HOWTO.md Guide

• OpenLR Python Documentation

Comments

Proposal 1 (discussion item26 Nov 2025 )

...

• 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