• Created by Teun Hendriks less than a minute ago  

Prior revisions of answers

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