An Introduction to OpenLR
Table of Contents
- What is Dynamic Location Referencing?
- History of DLR
- INRIX XD and OpenLR
- OpenLR Reference: Basic Structure
1. What is Dynamic Location Referencing?
Dynamic Location Referencing (DLR) provides a way to describe a stretch of road, independent of TMC data, for the purpose of displaying traffic information, routes, incident data, and other driver services.
One of the key advantages of DLR over TMC based solutions is that it supports ‘on-the-fly’ location referencing. The sender and receiver do not need to agree on a set of codes beforehand, as they do with TMCs, and they don’t need to be using the same map data. Everything needed to interpret the location is self-contained in the DLR reference, supplemented by the clients own map data. The sender encodes a message using one of the DLR protocols referencing their map data and the receiver decodes it to their own map.
DLR enables service providers a way to break free from TMC tables and the entities that control them and allows for coverage in countries where there are no TMC tables.
The “Dynamic” part of DLR is precarious. While interpreting locations on-the-fly may be one of the key advantages over TMCs, location referencing doesn’t need to be dynamic. Agreeing on codes ahead of time and using DLR to interpret location content from different map versions and vendors in a more static way is also very useful and may be preferable for many clients. At INRIX, this is known as the “Dictionary” approach and is discussed further in this document.
1.1. DYNAMIC LOCATION REFERENCING: A VISUAL
2. INTRODUCTION TO OPENLR
OpenLR is a specific implementation of Dynamic Location Referencing. OpenLR is Open Source, there are no licensing costs and they provide implementation tools, including:
- Encoder/Decoder: Java based and fully functional.
- Map Access Layer: a set of operations needed to access the map db.
- Map Database: physical representation, raw map data: Utrecht, TomTom maps 2008
You’ll find these tools at OpenLR.org along with fairly extensive documentation. With this material, clients should be able to create a working version of TomTom’s OpenLR DLR.
Of course, ultimately clients will need to have their own map data and accompanying map access layer, but the OpenLR.org encoder/decoder can be utilized ‘as is’ which does alleviate some of the impediments of implementation.
NOTE: INRIX’s current OpenLR solution is slightly different than Tom Tom’s version. For this reason, the OpenLR.org documentation is not sufficient, more on this in the next section.
3. INRIX XD and OpenLR
INRIX XD: Traffic Everywhere with “Extreme Definition”. XD segments are roughly coded to all FRC 1-3 roads, as well as many FRC 4 roads, all ramps for limited access roads, any road that has a TMC. TMCs are roughly coded to FRC 1-3 roads.
INRIX currently has speed information available in over 45 countries and over 10 additional territories across North and South America, EMEA, and APAC.
INRIX Connected Services now delivers speed data on these XD segments in the same way we’ve been doing it on TMC segments. Speeds on XD segments are delivered via “GetSegmentSpeed” APIs. You can receive speeds in a box, in a radius or in geography.
See the INRIX Documentation Center to learn more about these APIs: https://docs.inrix.com/traffic/segmentspeed/
Clients using INRIX map tiles (traffic image overlays) can easily be upgraded to XD coverage via an INRIX backend configuration. All other implementations of INRIX XD require utilizing DLR to translate INRIX XD segments to the client’s map.
Clients can choose to do OpenLR decoding on-the-fly, or they can choose the “Dictionary” approach.
3.1. The INRIX DLR Dictionary approach:
The Dictionary is a pre-coded location reference for all INRIX XD Segments in a particular flavor of DLR. Currently, INRIX is offering an OpenLR based dictionary only.
Instead of decoding XD segments dynamically, as you would in a TPEG implementation where the OLR references are embedded in the LRC, the dictionary is pre-coded. The sender and receiver agree ahead of time on what a certain code means. This is the same approach as TMCs, the difference is that the receiver does not have INRIX XD segments embedded in their map. Hence, the receiver needs a reference so they can translate INRIX XD segments to the client map; the Dictionary provides this reference.
Clients are expected to periodically download the dictionary and perform the OpenLR mapping of XD segments to their own map. Currently INRIX updates the dictionary 2 times per year during Map Updates.
In Connected Services the API call for the Dictionary is:
The GeoID parameter is used to download the dictionary in various geographies. The geographies conform to the standard areas defined in the GetGeography call.
3.2. What’s in the Dictionary?
It’s a set of IDs with relationships that tells previous / next segment so you know how the segments are chained together, and some additional information that allows you to figure out what stretch of road the ID is referencing. This reference could be in any flavor of DLR, currently, INRIX provides it in OpenLR.
3.3. TISA & Open LR Specification:
INRIX is a member of TISA and supports a number of services in TPEG format. For consistency, INRIX chose to align its DLR offerings with the specification offered by TISA.
TISA has a few different specifications for TPEG DLR.
“TPEG DLR” – Basically Agora C “TPEG ULR” – New and unstable. “TPEG OPEN LR” – Based on Tom Tom’s OLR but slightly different.
TomTom submitted the OpenLR specification to TISA and it was accepted, but TISA modified it to be in-line with the conventions and rules used in TPEG. The concepts are the same, the references are the same, but TISA uses some different field names and the binary and XML representations are slightly different than those found in Tom Tom’s OpenLR version.
INRIX chose to use the TISA OLR XML definition for the OLR Dictionary. This differs from the XML defined by TomTom and documented in the whitepaper available on OpenLR.org.
The TISA specification can be obtained on the TISA website for TISA members, or it can be purchased here - TISA Reference: SP14006. You will need the TISA specification to interpret the INRIX Dictionary.
4. OpenLR Reference: Basic Structure
OpenLR is a series of lat/long coordinates with some annotation. The minimum required to describe a segment is 2 points; first and last.
4.1 Line Properties: Each Point as them
- Latitude/longitude
- Bearing
- FRC (as it comes out of the point in the direction of the bearing)
- Form of way (what kind of road: ramps, highways, surface roads, etc.)
Lat/long expressed as an integer value to save space in the binary format, but this also the version returned in our XML. Its’ derived from a conversion algorithm. There is a spreadsheet tool you can use to convert this value into ‘normal’ WGS Lat Long decimal values. The actual lat/long is used only for the first point, after that, OpenLR uses the delta between points. The difference between original lat/long * 10,000.
Bearing – Walk downstream (or upstream if you’re at the last point) from your point 25 meters, connect the 2 points with a straight line and calculate bearing. The bearing of the last point for a road goes in the opposite direction (because the road ends).
Bearing can be expressed several ways: Easiest way is degrees 0-359 (standard) TPEG wants to fit in one byte, so use 0..255 in binary, which is also used in XML (TISA Spec) OpenLR - TomTom wanted in one byte, but uses a different format 0..31 (OpenLR spec)
FRCs: Functional Road Classes (from the TISA spec)
FRC Description FRC 0 Main road FRC 1 First class road FRC 2 Second class road FRC 3 Third class road FRC 4 Fourth class road FRC 5 Fifth class road FOW: Form of Way (from TISA spec)
FOW Description UNDEFINED The physical road type is unknown. MOTORWAY A Motorway is defined as a road permitted for motorized vehicles only in combination with a prescribed minimum speed. It has two or more physically separated carriageways and no single level-crossings. MULTIPLE_CARRIAGEWAY A multiple carriageway is defined as a road with physically separated carriageways regardless of the number of lanes. If a road is also a motorway, it should be coded as such and not as a multiple carriageway. SINGLE_CARRIAGEWAY All roads without separate carriageways are considered as roads with a single carriageway. ROUNDABOUT A Roundabout is a road which forms a ring on which traffic traveling in only one direction is allowed. TRAFFICSQUARE A Traffic Square is an open area (partly) enclosed by roads which is used for non-traffic purposes and which is not a Roundabout. SLIPROAD A Slip Road is a road especially designed to enter or leave a line. OTHER The physical road type is known but does not fit into one of the other categories. BIKE_PATH A bike path is defined as a path only allowed for bikes. FOOTPATH A footpath is defined as a path only allowed for pedestrians. TISA © 2012 – all rights reserved
4.2 Path Properties
Additional information used to describe a connection between two points; additional information that helps with decoding. All points have Path Properties except the last point in a chain. If there are only 2 points, then only the first point has Path Properties.
1) DNP - Distance to the next point on the traveled route (not straight line distance) 2) LFRCNP - lowest FRC to the next point - least important road, so highest numerical FRC
Note: the term “Path Properties” was introduced by TISA as a way to group some attributes in the XML response. In Tom Tom’s Open LR they are all included in same line properties group. So, this is an example how the TISA and Tom Tom specifications differ. The attribution is the same, it’s just structured differently.
Most of the time, two points (start and end) are sufficient to describe a segment of road. However, there are times two points are not “good enough” to describe a segment. OpenLR has 4 rules for adding intermediate points when two points are not deemed sufficient to describe a segment of road.
4.3 When are 2 points not good enough? Open LR Rules for describing additional points:
- No DNP (Distance to Next Point) > 15 km. If longer than 15km you need to introduce a third, intermediate point. There is a non-specific selection criterion for doing this. Although where possible, try to put points on nodes, cause it reduces search space and increases snap accuracy - but if one of the maps is missing roads (cross streets), this can cause problems in the encode/decode).
- Advisory Rule: Put at nodes (junctions) whenever possible.
- Between two successive points, the intended route must equal the shortest route.
- If start/end are not on nodes, use the nodes to describe the location, but then add positive/negative offsets to specify actual endpoints Therefore, the whole package for a segment is a “location reference” which is made up of a series of points and (potentially) a positive/negative offset.
- First Point (always)
- Last Point (always)
- Intermediate Points (optional)
- Positive/Negative offset (optional)
4.5 REFERENCE SAMPLE
Thus a complete reference for an XD segment looks like this from our API:
<Inrix docType="GetReferenceSchemaInGeography" copyright="Copyright INRIX Inc." versionNumber="7.8" createdDate="2016-02-28T08:26:12Z" statusId="0" statusText=""responseId="d09099c6-880d-48c0-b361-1214d8b38945">
<Dictionary xmlns="http://www.INRIX.com/LocDictionary" xmlns:tdt="http://www.tisa.org/TPEG/TPEGDataTypes_2_0" xmlns:olr="http://www.tisa.org/TPEG/OLR_0_1">
<Report dictionaryUpdateDateTime="2015-09-01T18:43:07" dictionaryVersion="1.0">
<reportSegments>
<ReportSegmentID>2089728</ReportSegmentID>
<ReportSegmentLRC>
<method>
<olr:version>0.1</olr:version>
<olr:locationReference>
<olr:optionLinearLocationReference>
<olr:first>
<olr:coordinate>
<olr:longitude>119530</olr:longitude>
<olr:latitude>1842409</olr:latitude>
</olr:coordinate>
<olr:lineProperties>
<olr:frc olr:table="olr001_FunctionalRoadClass" olr:code="3"/>
<olr:fow olr:table="olr002_FormOfWay" olr:code="4"/>
<olr:bearing>
<olr:value>22</olr:value>
</olr:bearing>
</olr:lineProperties>
<olr:pathProperties>
<olr:lfrcnp olr:table="olr001_FunctionalRoadClass" olr:code="3"/>
<olr:dnp>
<olr:value>55</olr:value>
</olr:dnp>
<olr:againstDrivingDirection>false</olr:againstDrivingDirection>
</olr:pathProperties>
</olr:first>
<olr:last>
<olr:coordinate>
<olr:longitude>-26</olr:longitude>
<olr:latitude>-34</olr:latitude>
</olr:coordinate>
<olr:lineProperties>
<olr:frc olr:table="olr001_FunctionalRoadClass" olr:code="3"/>
<olr:fow olr:table="olr002_FormOfWay" olr:code="4"/>
<olr:bearing>
<olr:value>30</olr:value>
</olr:bearing>
</olr:lineProperties>
</olr:last>
</olr:optionLinearLocationReference>
</olr:locationReference>
</method>
</ReportSegmentLRC>
<LinearConnectivity>
<posLink>
<ReportSegmentID>2096368</ReportSegmentID>
</posLink>
</LinearConnectivity>
<SegmentNames>
<Name>Ma-1C</Name>
</SegmentNames>
<segmentLength>53</segmentLength>
<segmentRefSpeed>0</segmentRefSpeed>
</reportSegments>
</Report>
</Dictionary>
</Inrix>
4.6 Map Matching Results:
Our internal tests show that the best “matching” of information is obtained when both sender/receiver are using the same underlying map data. However, it will work across map versions/providers as well; there likely will not be a 100% match (ability to match an XD segment to a road segment). It is expected that there will not be 100% match in using OpenLR to place XD segments on a map.