Created by Teun Hendriks less than a minute ago

This box suggests the current best answer

Prior revisions of answers

Proposal 4 (Consolidation item before meeting24 Mar 2026 )

Short Summary Answer

Migrating from TMC (Traffic Message Channel) to OpenLR involves a shift from fixed, pre‑coded location tables to a dynamic, map‑agnostic location‑referencing approach. OpenLR enables significantly greater flexibility, supports virtually unlimited coverage of road networks and locations of interest, and improves interoperability across different digital map providers. At the same time, this transition introduces new technical, operational, and performance considerations. Whereas TMC encoding did not require access to a routable digital road network, now OpenLR encoding does depend on the availability of a suitable digital map with a routable road network. Successful adoption therefore requires careful attention to encoding accuracy, as well as verifying cross‑map interoperability of OpenLR encoders.

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 centrally maintained location table. Each identifier refers to a known, pre‑coded location point, linear segment, or area, which guarantees deterministic and lightweight matching on the receiver side. However, this approach inherently restricts flexibility: only locations that have been coded in advance can be referenced, coverage is limited by the size and maintenance of the location table, and extending to new roads or regions requires coordinated updates across the ecosystem.

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 the presence of a suitable routable road network at encoding time.

Encoding/decoding differences to be explained


TMC
OpenLR

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 evolve, older TMC location tables may become outdated. With OpenLR, a larger difference between source and target map versions needs careful matching to ensure correct location referencing, it may reduce 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 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. 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 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. 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.
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. 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 workload	Low	Higher	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.
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. 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.

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:

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 digital 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

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 evolve, older TMC location tables may become outdated. With OpenLR, a larger difference between source and target map versions needs careful matching to ensure correct location referencing, it may reduce 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 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. 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 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. 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.
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. 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 workload	Low	Higher	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.
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. 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.

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:

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. Agreed rewording: Notwithstanding the higher workload, millions of in‑vehicle and backend systems use OpenLR decoding for traffic updates without practical issues.	DS: 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.
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	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.
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)	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.
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)	→ discussion item for the next telco

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

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 anOpenLR requires careful matching between source and target maps
3. Location Identification	Lookup of a pre-defined TMC Location Code (LC) 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 LCs 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	Used in IP-based, broadcast, or hybrid systems	OpenLR suitable for richer digital ecosystems
7. Decoding Method	Match LC 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	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	Notwithstanding the higher workload, millions of in‑vehicle and backend systems use OpenLR decoding for traffic updates without practical issues.
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.

References & Tools

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

Comments

1
2
3

Proposal 1 (discussion item26 Nov 2025 )

Migrating from TMC to OLR: what are typical issues:

CoPilot input

Great question! Migrating from TMC (Traffic Message Channel) location referencing—which uses pre-coded locations—to an on-the-fly method like OpenLR introduces several technical and operational challenges. Here are the key issues:

First present fundamental reasons to migrate:

Benefits

Opposite argument: TMC coverage is limited to pre-coded locations, OpenLR is unlimited

1. Fundamental Differences in Referencing Approach

TMC: Uses a fixed, pre-defined location table (with IDs for road segments, junctions, etc.). This ensures consistency but limits flexibility.
OpenLR: Encodes locations dynamically based on geometry and attributes, making it map-agnostic and more scalable.

Implication: Migration requires rethinking how locations are identified and transmitted—no more reliance on static IDs.

2. Map Provider Variability

Different providers (Google, HERE, TomTom) have different network topologies, segment definitions, and attribute sets.
OpenLR is designed to be map-independent, but accuracy depends on how well the encoding matches the target map.

Challenge: Ensuring interoperability and consistent decoding across providers.

3. Accuracy and Ambiguity

TMC guarantees exact matches because of pre-coded IDs.
OpenLR uses shortest-path algorithms and attribute matching, which can lead to:
- Ambiguity in dense urban areas.
- Errors if road attributes differ between source and target maps.

Mitigation: Fine-tuning encoding parameters and implementing robust fallback strategies.

Opposite argument: TMC coverage is limited to pre-coded locations, OpenLR is unlimited

4. Performance and Bandwidth

TMC: Compact messages (just IDs).
OpenLR: Larger payloads (geometry, attributes), which can impact bandwidth and processing time.

Consideration: Efficient encoding and compression are critical for real-time systems.

Size: Less of an issue now going from ~2-4 bytes to ~20-30 bytes per location reference

Encoding / decoding time and processing impact:

Encoding is more compute-intensive, but most often done on large server
Decoding on user devices is much more compute intensive, and especially in large urban areas with lots of traffic messages (e.g. London, Paris) may strain a CPU and take a long time to process, which is a risk if the next batch of traffic messages.

5. Legacy System Integration

Many traffic systems, navigation devices, and broadcast protocols are built around TMC.
Migration requires:
- Dual support during transition.
- Conversion tools (TMC ↔ OpenLR) for backward compatibility.

6. Quality Assurance

Need to validate that OpenLR-referenced locations match intended real-world positions in a map-agnostic way ( handling multiple map versions from same map vendors, as well as maps from different vendors).
Requires thorough testing and needs SW and data infrastructure for automatic machine-based error detection.
Variations in maps and map updates could impact accuracy, and re-validation is advice.

7. Governance and Standardization

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