Page History
| Info |
|---|
Prior revisions of answers
...
[TISA-LR-OpenLR-FAQ1] 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 |
...
Short Summary Answer
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.
Why the need for map agnostic location referencing ?
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.
...
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.
Stakeholder Relevance / Rationale
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.
Detailed Explanation
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.
...
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.
Decision Guide
| 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 |
Implementation Notes
- OpenLR is based on the WGS-84 coordinate reference system and requires maps to have two attributes: Functional Road Class (FRC, importance of road), Form-of-Way (FoW, type of road).
- A mapping may be needed from source map attribute conventions to OpenLR conventions.
- Use official encoders/decoders to ensure format compliance.
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+).
References & Tools
- TISA Github
- DATEXII OpenLR™ (Point, linear and area location)
- Dynamic Location Referencing (INRIX)
- OpenLR GitHub Tools and Libraries
Comments
...
Who
...
What
...
Decision
...
Add proposed visual example of map differences and need for map-agnostic LR
Source material in this PPTX: LR_WG_FAQ_Q2_MapDifferences.pptx
...
Processed comments meeting 9 July
...
Who
...
What
...
Decision
...
Proposal 1
...
Proposal text (MS Copilot generated)
...
OpenLR offers several advantages that make it a strong choice for location referencing:
1. Map-Agnostic
OpenLR 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-Free
OpenLR 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 Efficient
The 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 Referencing
OpenLR 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 Applicability
OpenLR 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 Standard
As an open industry standard, OpenLR is widely adopted and supported, ensuring robust community and industry backing [1].
7. Integration Tools
OpenLR 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
Strength: OpenLR does not depend on a specific map provider.
Why it matters: If you’re sharing data across systems that use different map vendors (e.g., TomTom, HERE, OpenStreetMap), OpenLR allows locations to be understood and decoded consistently.
2. Compact & Efficient
...
Strength: It encodes locations in a compact binary format.
...
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 You
1. Map-Agnostic Location Exchange
If you work across multiple map providers (e.g., TomTom, HERE, OSM), OpenLR excels:
It enables interoperable location sharing, even when the maps differ structurally.
This is crucial for traffic event exchange, navigation providers, and ADAS applications.
📌 Use Case: A road segment encoded on a TomTom map can be decoded on OSM—even if segments or attributes differ—because OpenLR describes how to find a path, not just what it is called.
2. Compact Yet Expressive Encoding
OpenLR binary is extremely compact, suitable for real-time traffic data transmission or vehicle-to-cloud messaging.
It supports multiple location types: lines, points, areas—covering 99% of real-world use cases from navigation to traffic alerts.
3. Open Standard, Royalty-Free
You avoid vendor lock-in. OpenLR is free to use, modify, and implement.
Supported by an active community (TomTom, DLR, and contributors) with source code on GitHub.
4. Designed for ITS and Automotive
Native support for ADAS concepts (side of road, orientation, circular zones)
Good fit for electronic horizon systems, traffic control centers, and routing APIs
5. Field-Proven
Used in real-world applications for over a decade
Successfully powers systems like TomTom Traffic, TISA messages, OpenStreetMap-based navigation tools
🚫 When OpenLR Might Not Be Ideal
| Scenario | Reason to consider other formats |
|---|---|
| You only use one map provider | Vendor-specific IDs may be faster |
| You need freehand polygons or arbitrary shapes | GeoJSON is better for complex geometry |
| You need rich semantic metadata (e.g., road closures, speed limits) | DATEX II or WFS formats offer more extensibility |
| Your use case is indoor navigation or floorplans | OpenLR is not designed for indoor geometry |
Description of changes
<description of the changes>
Comments
...
Who
...
What
...
Decision
...
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. Open Standard
Strength: OpenLR is open-source with no licensing fees.
Why it matters: You can integrate it freely into your products without vendor lock-in or commercial licensing costs.
4. Good for Dynamic Data (e.g., Traffic, Routing)
Strength: Line-based referencing makes it excellent for real-time traffic updates, navigation instructions, or map updates.
Why it matters: You can encode and decode live event locations across different systems quickly and accurately.
5. Resilient to Map Changes
Strength: OpenLR uses topology (road shape, connectivity) rather than strict coordinates.
Why it matters: This makes it more robust across maps with slightly different geometry or coverage, unlike coordinate-based systems that can fail if roads don’t align perfectly.
⚠️ Potential Limitations to Consider
1. Not Designed for All Use Cases
Weakness: OpenLR isn’t ideal for:
Free-form shapes (e.g., detailed polygons).
Precise off-road points.
High-resolution spatial queries.
2. Encoding/Decoding Complexity
Requires both sender and receiver to implement proper encoding/decoding logic, which can be non-trivial to set up.
3. Limited Support for Area/POI Use Cases
Basic OpenLR doesn’t natively support area locations or standalone POIs without access roads—these require custom or extended formats (e.g., OpenLR+).
