...

• OpenLR White Paper & Toolkit – openlr.org

• ISO 21219-22 – TPEG2-OLR Standard

• TISA Github 

• DATEX II Specifications, see also DATEXII OpenLR™ (Point, linear and area location)

• TN-ITS Specifications:  TN-ITS integration to become EN TS 16157, Part 14: TN-ITS (work-item in CEN TC278 W7, publication expected Q1 2026)

Processed comments meeting August 6

...

Who

...

What

...

Decision

...

In 'detailed explanation' table, why is 'For integration into TN-ITS environments' a limitation?

In 'Decision guide': a 'TN-ITS user' can also use Area features

Reference & Tools: note : replace 'finalisation' with 'publication expected in Q1 2026' 

...

solved

solved

solved

...

Processed comments meeting July 9th

...

Who

...

What

...

Decision

...

Added TN-ITS to use cases for sharing road infrastructure by Public Authorities.

Decision guide: add 'road' to "Traffic data exchange or event messages"

Added OpenLR Binary to decision guide

NOTE: the next publication of the TN-ITS specification will be under the DATEX umbrella:  "CEN TC278 W8 : CEN TS 16157, Part 14: TN-ITS". This revision is expected in Q4

...

Proposal 216 Jun 2025

2. Short Summary Answer

OpenLR is a method for describing locations—like road segments, intersections, or zones—that works across different digital maps. It comes in different forms (like binary or XML) and variations (such as versions used by governments, carmakers, or traffic services). Some are better for speed and compactness, others for compatibility or inspection. The right version depends on what you're trying to do—send fast updates, analyze traffic data, or guide vehicles

3. Why This Matters (For Different Stakeholders)

• Public Authorities
  Need standards like DATEX II or TPEG2 to ensure compatibility across national and EU-wide systems. OpenLR helps exchange traffic and road data across jurisdictions and map providers.

• Service Providers
  Use OpenLR to send traffic events quickly and efficiently, even when different maps are in use. Binary formats are best for performance, while XML makes testing and debugging easier.

• OEMs (Automotive Manufacturers)
  OpenLR supports in-vehicle features like navigation, alerts, and geofencing (especially in ADAS and V2X systems). Compact formats like Binary V3 are ideal for embedded systems.

4. Understanding the Different Versions and Formats

✅ Plain Overview (for non-experts)

🧠 Technical Notes (for experts)

• Binary V3 is the current preferred version for compact location encoding.

• XML formats vary: White Paper XML is widely used; DATEX II XML and TN-ITS XML follow different schemas.

• Logical Format includes:

  • Location Reference Points (LRPs) with road class, orientation, etc.

  • Support for lines, points, areas (polygons, circles, etc.)

• Area location types (e.g., ClosedLine, Polygon) are only supported in OpenLR v1.5+, not in early implementations.

5. Decision Guide – What to Use When

6. Tips for Implementation

• Test compatibility between encoder and decoder—different formats and versions may not work together out of the box.

• Use XML for inspection and integration, binary for real-time or bandwidth-sensitive environments.

• Avoid mixing DATEX II XML with White Paper XML without schema validation.

• Choose a decoder that supports V3 to ensure support for advanced features like area and POI references.

7. Useful Resources

• OpenLR Official Website

• ISO TPEG2-OLR Standard

• DATEX II OpenLR Schema

• TN-ITS OpenLR Profile

• StackOverflow: OpenLR Binary v3 discussion

Comments

...

Who

...

What

...

Decision

...

Proposal 209 May 2025 

Proposal text

1. Question

• Clearly state the issue or decision point.
• Optionally include context (e.g., “in multi-map environments” or “for cross-border traffic data exchange”).

2. Short Summary Answer

• Provide a 2–3 sentence overview that answers the question directly.

3. Stakeholder Relevance / Rationale

• Explain why this matters to each stakeholder group:
  • Public Authorities: Interoperability, compliance, public service delivery.
  • Service Providers: Scalability, integration, data quality.
  • OEMs: In-vehicle systems, ADAS, V2X compatibility.

4. Detailed Explanation

Break down the topic into structured sub-sections:

• Types / Versions / Formats (with strengths and weaknesses)
• Use Cases (real-world examples per stakeholder)
• Technical Considerations (e.g., encoding, decoding, schema)

5. Decision Guide

• Provide a table or flowchart to help stakeholders choose the right approach based on their role and goals.

6. Implementation Notes

• Highlight integration tips, tooling, compatibility issues, or known pitfalls.

7. References & Tools

• Link to standards, documentation, open-source tools, or vendor-specific resources.

Description of changes

<description of the changes>

Comments

Prior revisions of answers

Proposal 101 May 2025 

...

Proposal text ( MS CoPilot generated)

...

OpenLR, developed by TomTom, is a royalty-free open standard for encoding, transmitting, and decoding location data across different maps. There are several versions and adaptations of OpenLR, each with its own strengths and weaknesses:

1. TomTom OpenLR (Original Version)

• Strengths:
  • Compatibility: Works well with TomTom maps and services.
  • Open Standard: Free to use and adapt, with a detailed white paper available.
• Weaknesses:
  • Complexity: Can be complex to implement correctly, especially for those unfamiliar with the format.
  • Limited Interoperability: May not work seamlessly with non-TomTom maps without adjustments.

2. TISA Adaptation (TPEG2)

• Strengths:
  • Standardization: Adopted as ISO 21219-22:2017, ensuring a high level of standardization.
  • Interoperability: Designed to work with TPEG2 standards, making it suitable for a wide range of applications.
• Weaknesses:
  • Differences in XML Structure: The XML structure and some field names differ from the original TomTom specification, which can cause compatibility issues.
  • Binary Format Differences: The binary format is also different, which can complicate integration.

3. Datex2 Adaptation

• Strengths:
  • Flexibility: Supports multiple location referencing methods, including OpenLR.
  • Integration: Well-suited for use in traffic management and information systems.
• Weaknesses:
  • Non-Interoperability: Not interoperable with either the TomTom or TISA/ISO specifications at the XML level.
  • Complexity: Requires understanding of the Datex2 framework, which can be complex.

Choosing the Right Version

• For TomTom Ecosystem: Use the original TomTom OpenLR version for best compatibility and performance.
• For Standardized Applications: The TISA adaptation is ideal for applications requiring ISO standard compliance and interoperability with TPEG2.
• For Traffic Management Systems: The Datex2 adaptation is suitable for integration into broader traffic management and information systems.

Each version has its own use cases and should be chosen based on the specific requirements of your project 

...

2 . OpenLR - Wikipedia
3. Dynamic Location Referencing | INRIX documentation

Is there a specific application or project you're considering for OpenLR?

OpenLR (Open Location Referencing) is an open-source method developed by TomTom for encoding location references in a compact, map-agnostic way, suitable for sending location data between systems using different digital maps. There are different versions and types of OpenLR location references, each with their own strengths and weaknesses, depending on the use case (e.g., navigation, map updates, traffic messages).

Here’s a breakdown of the main types (location reference types) used in OpenLR and what each is good or bad at:

1. Line Location (Standard OpenLR)

Use case: Roads, paths, routes (e.g., traffic updates on a road segment).

• Good at:

  • Representing linear features like roads and routes.

  • Map-agnostic: works well across different map vendors.

  • Compact binary format: suitable for low-bandwidth environments.

• Bad at:

  • Representing very short segments or intersections precisely.

  • Not optimal for very dense urban networks (complex decoding due to many options).

• Version support: Core part of OpenLR since the beginning.

2. Point Along Line Location

Use case: Speed cameras, toll booths, construction zones.

• Good at:

  • Identifying a specific point on a known road segment.

  • Efficient and compact for single-point use cases.

• Bad at:

  • Not suited for off-road or arbitrary point locations.

  • Requires a road segment match—fails if the map lacks the referenced segment.

• Version support: Included in later enhancements to the OpenLR specification.

3. POI with Access Point

Use case: Points of interest (e.g., gas stations, shops) with a known access road.

• Good at:

  • Capturing not just a POI but how to access it from a road.

  • Helps with navigation to real-world locations that aren’t exactly on the road.

• Bad at:

  • More complex encoding and decoding.

  • Still relies on nearby road coverage, so fails if the road is missing or incorrect.

• Version support: Requires enhanced support beyond basic OpenLR implementations.

4. GeoCoordinate Location (Proposed/Extended Type)

Use case: Arbitrary geographic points not necessarily tied to roads (e.g., parks, geofences).

• Good at:

  • Flexibility—works for off-road or remote locations.

  • Not map-dependent.

• Bad at:

  • Not standardized in core OpenLR.

  • Loses the “map-agnostic” advantage if the point must be interpreted differently across maps.

• Version support: Not in official OpenLR; considered in extended or proprietary adaptations.

5. Closed Line Location / Area Location (Extended/OpenLR+ Concepts)

Use case: Regions (e.g., zones under construction, traffic-restricted areas).

• Good at:

  • Describing enclosed areas or loops.

  • Useful in urban traffic control, geofencing.

• Bad at:

  • Complex decoding; can be imprecise across maps.

  • Not part of original OpenLR spec—often requires OpenLR+ or proprietary enhancements.

• Version support: Requires OpenLR+ or extensions beyond version 1.5.

Summary Comparison Table

OpenLR has evolved through different versions and physical formats, each suited for specific use cases. Here's a breakdown of the OpenLR types/versions, their strengths, limitations, and when to use them:

🔄 Logical Format (Common to all)

All OpenLR types are based on the logical location reference format, which includes:

• Location Reference Points (LRPs): Coordinates + attributes (FRC, FOW, Bearing, Distance to next)

• Offsets: Positive/negative distances from edges

• Location types: Line, Point (PointAlongLine, POI with Access), and Area (Circle, Grid, Rectangle, Polygon, ClosedLine)

This logical format is map-agnostic and defines what to encode.

📦 1. Binary Format

✅ Best for:

• Low-bandwidth scenarios (e.g., mobile broadcasts, vehicle-to-infrastructure)

• High-performance environments (quick parsing, compact size)

• Mass distribution of traffic event data

⚠️ Weaknesses:

• Hard to debug or inspect manually

• Inflexible: not human-readable, difficult to extend

• Poor forward/backward compatibility if decoder doesn't support version

🛠️ Versions:

• Version 2: Initial release (deprecated)

• Version 3: Adds area locations, revised offsets and bug fixes

  • Binary V3 is the recommended binary version now

📄 2. XML Format

✅ Best for:

• Interoperability and clarity (e.g., between services, debug tools)

• Human-readable logs and tools integration

• Testing and prototyping location references

⚠️ Weaknesses:

• Larger size (less ideal for real-time transmission)

• Slower to parse than binary

• Requires full XML schema validation for robust use

💡 Use case:

• System integration where visibility of location data is important (e.g., OpenLR exchange between data providers)

🌐 3. Datex II Format (OpenLR extension)

✅ Best for:

• Integration with European traffic standards (e.g., TMC, DATEX II for ITS systems)

• Government and infrastructure-grade systems

⚠️ Weaknesses:

• Complex schema, requires full DATEX II stack

• Less widely supported outside Europe

💡 Use case:

• Encoding OpenLR references inside broader traffic event payloads

🔠 4. Abstract Format

Sometimes OpenLR is referenced abstractly, especially in APIs:

• Used by proprietary or intermediate tools before conversion

• Not a transfer format itself

🔁 Version Evolution Summary

✅ Format & Version: When to Use What

Would you like a decision flow diagram to choose the best format/version based on your use case?

Description of changes

<description of the changes>

Comments

...

Who

...

What

...

Decision

...

Mention all variants:

The different versions/types of OpenLR: What are they each good/bad at? What should be used for a given situation.

• OpenLR binary v3 (OpenLR white paper), 
• OpenLR XML v3 (OpenLR white paper, 
• OpenLR XML (version TN-ITS)
• OpenLR XML( DATEXII), 
• TPEG2-OLR   (TPEG binary, TPEG protobuf, TPEGml)

What are key differences and potential impact

...

• Add main message and why: Map-agnostic, and able to overcome map differences, and no need for look-up tables
• Combine response in proposal 2 as best-of-both
• Add references as in table, primary reference should be OpenLR.org

...

Input materials