Page History

Encoding TMC location references

TMC location codes (also known as Problem Locations or PLOCs) are defined in a TMC location table. Point Locations are most commonly used for TMC location referencing. A point location typically refers to an intersection in e.g. along a Highway. In a TMC location table, a TMC point location has as attributes the following (and more):

• a WGS84 coordinate pair
• relevant location names, including the road number and/or road name and the name of the exit or cross-road
• two links to the previous and next TMC point locations (e.g. in the picture above for PLOC 4187 the next PLOC
  would be 4188 and the previous one 4186).

Thus based on the WGS84 coordinate pairs, these TMC problem locations can be overlaid on a satellite image (as above) or overlaid on a scanned map for defining TMC location references. No digital map with routable roadsegments is needed!

Encoding TMC location references entails first identifying which TMC location codes straddle the location of the event of interest. In the picture above assume these are PLOC 4185 and PLOC 4188. PLOC 4188 is referred to as the Head Location (the location point where a driver exits the event), and PLOC 4185 as the Tail Location (the location point after which a driver would enter the event)

Given this information and the previous/next links in the TMC location table then a TMC location reference is constructed as:

• Head location: PLOC 4188 
• Extent: -3 (the number of steps in the TMC location table from the Head location (4188) to the Tail Location (4185) following the next (in case of positive extent) or previous links (negative extent).

Decoding TMC location references

Decoding TMC location references in a receiver first involves expanding the Head Location (4188) and Extent (-3) again into the set of TMC locations, i.e. 4185, 4186, 4187, 4188, using the TMC location table and the previous linkage.

Given this set of locations and the driving direction (positive, or using the next linkage), then in a digital roadmap, the set of relevant road segments can be retrieved.  In TMC enabled digital maps, individual road segments have an attribute indicating to which TMC point location they are leading to, and whether that is external to the TMC problem location or internal, e.g. in case of a large highway intersection with separate exit and entry link roads. Then the road segments after the first intersection exit until the last intersection entry road are considered to be location internal road segments. 

For the positive driving direction these segments are labeled as '+' for location external segments and 'P' for location internal segments. 
For the negative driving direction these segments are labeled as '-' for location external segments and 'N' for  location internal segments.

Thus for the given location reference, this involves identifying road segments with attributes

• (4186, '+' or 'P'): red in the figure above
• (4187, '+' or 'P'), yellow in the figure above, and 
• (4188, '+' or 'P'), green in the figure above. 

Stringing together these road segments provides then for the location of interest in the receiver. 
These road segments then can be colored to mark abnormal traffic flow, or given a special color with an Icon at the tail location to indicate e.g. a roadworks event or other relevant incident.

Encoding OpenLR location references

Encoding OpenLR location references relies directly on a digital road map and its routable road segments. To create an OpenLR location reference, a digital map with routable road segments is therefore required.

The intended location reference represents a routable path. This path is described by selecting at least two Location Referencing Points (LRPs), which together define the location.

Each LRP has the following attributes:

• A WGS‑84 coordinate pair, specifying the geographic position of the LRP.
• Line attributes that further characterize the road segment at the LRP and support robust matching at the receiver side of LRPs, including:
  • Bearing: indicates the direction of travel along the road at the LRP.
  • Functional Road Class (FRC): indicates the relative importance of the road at the LRP.
  • Form of Way (FoW): indicates the type of road (for example, single carriageway or dual carriageway) at the LRP.

In addition, for the path between two successive LRPs, the following attributes are defined:

• Lowest Functional Road Class to Next Point (LFRCNP): indicates the lowest FRC encountered along the path from the current LRP to the next.
• Distance to Next Point: (DNP): indicates the length of the route between two successive LRPs.

Note: For simplicity, only two LRPs are shown here. In practice, an OpenLR location reference may include multiple intermediate LRPs to ensure that each routing path between successive LRPs is unique.

Decoding OpenLR location references

Decoding an OpenLR location reference also relies on a digital road map with routable road segments. A digital map that supports routing is therefore required to decode an OpenLR location reference.

The decoding process starts by matching the Location Referencing Points (LRPs) onto the receiver’s digital map. This matching is based on the WGS‑84 coordinate pairs in combination with the associated line attributes.

These line attributes help identify the correct road segment and travel direction. The Bearing attribute is used to determine the direction of travel at the LRP. In situations where multiple nearby or parallel road segments exist, the FRC and FoW attributes help distinguish between roads of different importance and type, enabling selection of the most appropriate candidate.

In a second step, the route between successive LRPs is reconstructed using a routing algorithm on the receiver’s map. The validity of this reconstructed route (and thus of the decoded location reference) is verified using the provided path attributes. These attributes indicate the expected length of the route (DNP attribute) and whether the route remains on roads with the expected functional road classes (LFRCNP attribure), rather than diverging onto lower‑importance roads.

Together, the line attributes and path attributes provide for a highly robust decoding mechanism by enabling cross-checks for matching and routing correctness. This robustness makes OpenLR highly interoperable across digital maps from different vendors and across different map vintages, for example, when decoding is performed on an older map than the one used during encoding.