Page History
...
Encoding | Decoding | |
|---|---|---|
| TMC |
TMC location codes (also known as Problem Locations or PLOCs) are defined in a TMC location table. Point Locations are most commonly used for TMC location referencing. A point location typically refers to an intersection in e.g. along a Highway. In a TMC location table, a TMC point location has as attributes the following (and more):
Thus based on the WGS84 coordinate pairs, these TMC problem locations can be overlaid on a satellite image (as above) or overlaid on a scanned map for defining TMC location references. No digital map with routable roadsegments is needed! Encoding TMC location references entails first identifying which TMC location codes straddle the location of the event of interest. In the picture above assume these are PLOC 4185 and PLOC 4188. PLOC 4188 is referred to as the Head Location (the location point where a driver exits the event), and PLOC 4185 as the Tail Location (the location point after which a driver would enter the event) Given this information and the previous/next links in the TMC location table then a TMC location reference is constructed as:
|
Decoding TMC location references in a receiver first involves expanding the Head Location (4188) and Extent (-3) again into the set of TMC locations, i.e. 4185, 4186, 4187, 4188, using the TMC location table and the previous linkage. Given this set of locations and the driving direction (positive, or using the next linkage), then in a digital roadmap, the set of relevant road segments can be retrieved. In TMC enabled digital maps, individual road segments have an attribute indicating to which TMC point location they are leading to, and whether that is external to the TMC problem location or internal, e.g. in case of a large highway intersection with separate exit and entry link roads. Then the road segments after the first intersection exit until the last intersection entry road are considered to be location internal road segments. For the positive driving direction these segments are labeled as '+' for location external segments and 'P' for location internal segments. Thus for the given location reference, this involves identifying road segments with attributes
Stringing together these road segments provides then for the location of interest in the receiver. |
| OpenLR |
Encoding OpenLR location references relies directly on a digital road map and its routable road segments. To create an OpenLR location reference, a digital map with routable road segments is therefore required. The intended location reference represents a routable path. This path is described by selecting at least two Location Referencing Points (LRPs), which together with the shortest route in between them define the location. Each LRP has the following attributes:
In addition, for the path between two successive LRPs, the following attributes are defined:
Note: For simplicity, only two LRPs are shown here. In practice, an OpenLR location reference may include multiple intermediate LRPs to ensure that each routing path between successive LRPs is unique. |
Decoding an OpenLR location reference also relies on a digital road map with routable road segments. A digital map that supports routing is therefore required to decode an OpenLR location reference. The decoding process starts by matching the Location Referencing Points (LRPs) onto the receiver’s digital map. This matching is based on the WGS‑84 coordinate pairs in combination with the associated line attributes. These line attributes help identify the correct road segment and travel direction. The Bearing attribute is used to determine the direction of travel at the LRP. In situations where multiple nearby or parallel road segments exist, the FRC and FoW attributes help distinguish between roads of different importance and type, enabling selection of the most appropriate candidate. In a second step, the route between successive LRPs is reconstructed using a routing algorithm on the receiver’s map. The validity of this reconstructed route (and thus of the decoded location reference) is verified using the provided path attributes. These attributes indicate the expected length of the route (DNP attribute) and whether the route remains on roads with the expected functional road classes (LFRCNP attribure), rather than diverging onto lower‑importance roads. Together, the line attributes and path attributes provide for a highly robust decoding mechanism by enabling cross-checks for matching and routing correctness. This robustness makes OpenLR highly interoperable across digital maps from different vendors and across different map vintages, for example, when decoding is performed on an older map than the one used during encoding. |
...
- 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
Requisite skills and investment: Migrating from TMC to OpenLR is not merely a change in location referencing format, but a transition that requires dedicated development effort and specialized expertise. Implementing a functional OpenLR encoder/decoder typically involves knowledge in geographic information systems (GIS), routing algorithms, and map-matching techniques. Available reference implementations should not be considered “plug‑and‑play” solutions. Integrating OpenLR into a specific deployment context could require substantial customization, performance optimization, and validation effort.
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. |
| 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
the scale of OpenLR adoption across a user base. |
Implementation Notes
- OpenLR supports various encoding formats: see [TISA-LR-OpenLR-FAQ2] - Different versions/types of OpenLR: What are they each good/bad at? What should be used for a given situation..
- Provide dual TMC/OpenLR output during transition to ensure backward compatibility.
In TPEG feeds, using the TPEG2-LRC (Location Referencing Container) allows simultaneous transmission of both TMC and OpenLR location referenceswithin a single TPEG message. - 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.
...
