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

Compare with Current View Page History

« Previous Version 29 Next »

This box suggests the current best answer


Prior revisions of answers

Proposal 2/3, updated 

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.

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.

  • In the map of vendor A, this road section has a sharp turn, and has a single road name "Sophie Vitringastraat". 
    In the map of vendor B, this road section has a more gradual turn, and halfway the road name changes to "Mathilde Wibautstraat".
  • In the map of Vendor B, an extra side road is present near the top of the location, which is missing in the map of vendor A.

This example illustrates that real-world maps must be expected to have differences in geometry, topology, and further attributes such as road names.

Accurately matching locations across maps from different providers requires a method that can handle such 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.

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.

Decision Guide

NeedOpenLR Fit
Cross-map compatibilityExcellent in all versions
Real-time traffic/event messagingExcellent in all versions
Compact transmission formatExcellent in all versions
Royalty-free, open-source integrationExcellent in all versions
High-resolution polygons or zonesUse ISO TPEG2-OLR, TomTom format has limited support
Off-road or free-form location supportUse 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 form the source map 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

Comments


Who

What

Decision

1THAdd proposed visual example of map differences and need for map-agnostic LRapproved
2AziyaAdd bits and bytes explainer OpenLR (TH most appropriate in Q3, implementation documentation?!)approved
3Stephen T'SiobbelWhat 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

Processed comments meeting 9 July


Who

What

Decision

1LBFRC and form-of-way need to be presentAdded in implementation notes
2LBSome countries have different coordinate reference systems WGS-84 added implementation notes. 
3THLink to DATEXII OpenLR modeladded

Proposal 1 

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-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.



References
[1] OpenLR™ location referencing
[2] Dynamic Location Referencing - INRIX documentation


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.

  • Why it matters: Ideal for bandwidth-limited systems (e.g., embedded devices, mobile apps, or connected vehicles).

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+).

✅ OpenLR is a Good Fit If You Need:

NeedOpenLR Fit
Cross-map compatibility✅ Excellent
Real-time traffic/event messaging✅ Excellent
Compact transmission format✅ Excellent
Open source with no licensing✅ Excellent
Geofences, zones, high-res areas❌ Limited
Simple point/area representation❌ Limited without extensions

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


ScenarioReason to consider other formats
You only use one map providerVendor-specific IDs may be faster
You need freehand polygons or arbitrary shapesGeoJSON 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 floorplansOpenLR is not designed for indoor geometry

Description of changes

<description of the changes>

Comments


Who

What

Decision

16/11 meetingAdd numbers of usage, hundreds of millions systems etc
Needs public references → can TomTom suggest these? 
26/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



Input materials