You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »




This box suggests the current best answer




Prior revisions of answers

Proposal 1 (discussion item )

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