Q2 has been finalised during the telco of |
OpenLR is a map-agnostic, open-source location referencing method optimized for cross-platform data exchange. Its compact format and royalty-free licensing make it especially attractive for use cases involving real-time traffic information and embedded systems. OpenLR provides a robust and cost-effective solution for many ITS and mobility scenarios.
Maps from different suppliers are not exactly the same.
Differences in geometry, topology, and attributes—such as street names— do occur due to variations in data sources and modeling approaches.
To illustrate such map differences, the figure below shows a small section of 2025 maps of two vendors near the Sophie Vitringastraat in Hoorn, The Netherlands.
A possible location of interest is indicated with an orange highlight.
This example illustrates that real-world maps must be expected to have differences in geometry, topology, and further attributes such as road names.
![Location Referencing FAQ > [TISA-LR-OpenLR-FAQ1] - Why is OpenLR the right location referencing method for us? > image-2025-8-6_10-35-21-1.png](/download/attachments/411533942/image-2025-8-6_10-35-21-1.png?version=1&modificationDate=1754469321726&api=v2)
Accurately matching locations across maps from different providers requires a method that can handle these differences between maps — such a method is termed a "map-agnostic location referencing method".
Any map-agnostic location referencing must ensure that the intended location can be correctly identified, no matter which map is used to create the location reference and which map is used to match the location reference.
Public Authorities: Ensures interoperability of (open) data on National Access Points towards data consumers and platforms in traffic management and navigation services; cost-effective and aligns with open standards.
Content Providers: Facilitates scalable data aggregation across different maps; encoding efficiency supports dynamic updates.
Service Providers: Enables consistent service delivery in bandwidth-constrained or multi-map environments; standards with royalty-free licensing avoids vendor lock-in.
OEMs: Well-suited for in-vehicle use due to its compact format; supports navigation services and also dynamic updates for ADAS and connected services.
Types / Versions / Formats
Use Cases
Traffic Management Systems: Dynamic updates like congestion alerts can be reliably encoded.
Navigation and Routing: Works well in systems where map providers vary or change.
Cross-border Applications: Supports consistent interpretation regardless of underlying map data.
Connected Vehicles: Efficient data usage is ideal for bandwidth-sensitive environments.
Technical Considerations
Encoding/Decoding Logic: Requires correct implementation on both sender and receiver sides.
Resilience to Map Changes: Uses road topology rather than fixed coordinates, reducing errors when maps differ.
Open Tools: Available libraries and encoders/decoders simplify integration.
| Need | OpenLR Fit |
|---|---|
| Cross-map compatibility | Excellent in all versions |
| Real-time traffic/event messaging | Excellent in all versions |
| Compact transmission format | Excellent in all versions |
| Royalty-free, open-source integration | Excellent in all versions |
| High-resolution polygons or zones | Use ISO TPEG2-OLR, TomTom format has limited support |
| Off-road or free-form location support | Use ISO TPEG2-OLR, TomTom format has limited support |
Ensure team familiarity with the topology-based referencing model.
For more complex POIs or areas, use ISO TPEG2-OLR, or evaluate extensions or hybrid approaches (e.g., OpenLR+).
Who | What | Decision | |
|---|---|---|---|
| 1 | TH | Add proposed visual example of map differences and need for map-agnostic LR | approved |
| 2 | Aziya | Add bits and bytes explainer OpenLR (TH most appropriate in Q3, implementation documentation?!) | approved |
| 3 | Stephen T'Siobbel | What about a section 'Known limitations'? From TN-ITS we observe a (significant?) number of decoding mismatches when topology is (substantially) different, i.e outside major roads | to be handled in Q6 |
Who | What | Decision | |
|---|---|---|---|
| 1 | LB | FRC and form-of-way need to be present | Added in implementation notes |
| 2 | LB | Some countries have different coordinate reference systems | WGS-84 added implementation notes. |
| 3 | TH | Link to DATEXII OpenLR model | added |
Proposal text (MS Copilot generated) | ChatGPT | ChatGPT Plus - OpenLR Guru | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
OpenLR offers several advantages that make it a strong choice for location referencing: 1. Map-AgnosticOpenLR is designed to work across different maps, making it highly versatile. This means you can use it with various map providers without worrying about compatibility issues [1]. 2. Open Source and Royalty-FreeOpenLR is available as an open-source standard under the Apache license v2.0, which means there are no licensing costs involved [1]. This can significantly reduce expenses and simplify integration. 3. Compact and EfficientThe encoding method used by OpenLR is compact, requiring minimal bandwidth for data communication [1]. This is particularly beneficial for applications where data transmission efficiency is crucial. 4. Dynamic Location ReferencingOpenLR supports dynamic location referencing, allowing for real-time updates and adjustments [2]. This is ideal for applications like traffic management, navigation, and real-time routing. 5. Broad ApplicabilityOpenLR can be used for various types of location data, including point locations, road stretches, and areas [1]. This flexibility makes it suitable for a wide range of applications, from traffic information systems to advanced driver assistance systems (ADAS). 6. Industry StandardAs an open industry standard, OpenLR is widely adopted and supported, ensuring robust community and industry backing [1]. 7. Integration ToolsOpenLR provides implementation tools, including encoders and decoders, which can simplify the integration process [2]. Given these advantages, OpenLR is a strong choice for applications requiring reliable, efficient, and versatile location referencing.
| 1. Map-Agnostic & Vendor-Neutral
2. Compact & Efficient
3. Open Standard
4. Good for Dynamic Data (e.g., Traffic, Routing)
5. Resilient to Map Changes
⚠️ Potential Limitations to Consider1. Not Designed for All Use Cases
2. Encoding/Decoding Complexity
3. Limited Support for Area/POI Use Cases
✅ OpenLR is a Good Fit If You Need:
| To determine if OpenLR is the right location referencing method for your organization, here’s a structured answer based on its strengths, limitations, and the types of problems it solves better than alternatives like TMC, GeoJSON, or vendor-specific IDs. ✅ Why OpenLR Is Likely Right for You1. Map-Agnostic Location ExchangeIf you work across multiple map providers (e.g., TomTom, HERE, OSM), OpenLR excels:
2. Compact Yet Expressive Encoding
3. Open Standard, Royalty-Free
4. Designed for ITS and Automotive
5. Field-Proven
🚫 When OpenLR Might Not Be Ideal
|
<description of the changes>
Who | What | Decision | |
|---|---|---|---|
| 1 | 6/11 meeting | Add numbers of usage, hundreds of millions systems etc Needs public references → can TomTom suggest these? | |
| 2 | 6/11 meeting | Distill the main message, a tag line to be used as summary ("map-agnostic, industry proven, global deployment"... " .... Overcoming real-world map differences (the problem / issue it solves) | |
| 3 |