ISO/TS 21219-22:2017

TECHNICAL ISO/TS
SPECIFICATION 21219-22
First edition
2017-06
Intelligent transport systems —
Traffic and travel information (TTI)
via transport protocol experts group,
generation 2 (TPEG2) —
Part 22:
OpenLR location referencing
(TPEG2-OLR)
Systèmes intelligents de transport — Informations sur le trafic et le
tourisme via le groupe expert du protocole de transport, génération 2
(TPEG2) —
Partie 22: Référencement d’Emplacement OpenLR (TPEG2-OLR)
Reference number
©
ISO 2017
© ISO 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2017 – All rights reserved

Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 3
5 Toolkit specific constraints . 4
5.1 Version number signalling . 4
5.2 Extension . 4
6 OLR structure . 4
6.1 Location types. 4
6.1.1 Supported location types . 4
6.1.2 Linear locations . 5
6.1.3 Point locations . 6
6.1.4 Area locations . 8
6.2 Requirements .11
6.2.1 General.11
6.2.2 Map requirements .11
6.2.3 Location properties .12
6.3 Logical data format specification .13
6.3.1 General.13
6.3.2 Building blocks .14
6.3.3 Additional data .18
6.3.4 Location reference point .20
6.4 Data format rules .26
6.4.1 OpenLR™ rules .26
6.4.2 Overview of the data format rules .27
6.5 Physical representations of geo-coordinates .28
6.5.1 General.28
6.5.2 Absolute geo-coordinates .28
6.5.3 Relative geo-coordinates.28
7 OLR message components .29
7.1 OpenLRLocationReference .29
7.2 AbstractLocationReference .29
7.3 LinearLocationReference .30
7.4 GeoCoordinateLocationReference.30
7.5 PointAlongLineLocationReference .31
7.6 POIWithAccessPointLocationReference .32
7.7 CircleLocationReference .33
7.8 PolygonLocationReference .34
7.9 RectangleLocationReference.35
7.10 GridLocationReference .35
7.11 ClosedLinearLocationReference .36
7.12 LineProperties .37
7.13 PathProperties .38
7.14 LocationDescription .38
7.15 AbstractShape .38
7.16 Shape .38
7.17 Path .39
8 OLR datatypes.39
8.1 AbsoluteGeoCoordinate .39
8.2 RelativeGeoCoordinate .39
8.3 Bearing .39
8.4 DistanceMetresMax15000 .40
8.5 FirstLocationReferencePoint .40
8.6 IntermediateLocationReferencePoint .40
8.7 LastLocationReferencePoint .40
8.8 PointLocationLineReferenceData .41
8.9 Rectangle .41
9 OLR tables .41
9.1 olr001:F unctionalRoadClass .41
9.2 olr002:F ormOfWay .42
9.3 olr003:Orientation .42
9.4 olr004:SideOfR oad .42
Annex A (normative) TPEG application, TPEG-Binary Representation .43
Annex B (normative) TPEG application, TPEG-ML Representation .51
Bibliography .59
iv © ISO 2017 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation on the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO’s adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see the following
URL: w w w . i s o .org/ iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
A list of all parts in the ISO 21219 series can be found on the ISO website.
Introduction
History
TPEG technology was originally proposed by the European Broadcasting Union (EBU) Broadcast
Management Committee, who established the B/TPEG project group in the autumn of 1997 with a brief
to develop, as soon as possible, a new protocol for broadcasting traffic and travel-related information
in the multimedia environment. TPEG technology, its applications and service features were designed
to enable travel-related messages to be coded, decoded, filtered and understood by humans (visually
and/or audibly in the user’s language) and by agent systems. Originally, a byte-oriented data stream
format, which may be carried on almost any digital bearer with an appropriate adaptation layer,
was developed. Hierarchically structured TPEG messages from service providers to end-users were
designed to transfer information from the service provider database to an end-user’s equipment.
One year later, in December 1998, the B/TPEG group produced its first EBU specifications. Two
documents were released. Part 2 (TPEG-SSF, which became ISO/TS 18234-2) described the syntax,
semantics and framing structure, which was used for all TPEG applications. Meanwhile, Part 4 (TPEG-
RTM, which became ISO/TS 18234-4) described the first application for road traffic messages.
Subsequently, in March 1999, CEN/TC 278, in conjunction with ISO/TC 204, established a group
comprising members of the former EBU B/TPEG and this working group continued development work.
Further parts were developed to make the initial set of four parts, enabling the implementation of a
consistent service. Part 3 (TPEG-SNI, ISO/TS 18234-3) described the service and network information
application used by all service implementations to ensure appropriate referencing from one service
source to another.
Part 1 (TPEG-INV, ISO/TS 18234-1) completed the series by describing the other parts and their
relationship; it also contained the application IDs used within the other parts. Additionally, Part 5, the
public transport information application (TPEG-PTI, ISO/TS 18234-5), was developed. The so-called
TPEG-LOC location referencing method, which enabled both map-based TPEG-decoders and non-map-
based ones to deliver either map-based location referencing or human readable text information, was
issued as ISO/TS 18234-6 to be used in association with the other applications parts of the ISO/TS 18234
series to provide location referencing.
The ISO/TS 18234 series has become known as TPEG Generation 1.
TPEG Generation 2
When the Traveller Information Services Association (TISA), derived from former forums, was
inaugurated in December 2007, TPEG development was taken over by TISA and continued in the TPEG
applications working group.
It was about this time that the (then) new Unified Modelling Language (UML) was seen as having major
advantages for the development of new TPEG applications in communities who would not necessarily
have binary physical format skills required to extend the original TPEG TS work. It was also realized
that the XML format for TPEG described within the ISO/TS 24530 series (now superseded) had a greater
significance than previously foreseen, especially in the content-generation segment and that keeping
two physical formats in synchronism, in different standards series, would be rather difficult.
As a result, TISA set about the development of a new TPEG structure that would be UML based. This has
subsequently become known as TPEG Generation 2.
TPEG2 is embodied in the ISO/TS 21219 series and it comprises many parts that cover introduction,
rules, toolkit and application components. TPEG2 is built around UML modelling and has a core of rules
that contain the modelling strategy covered in ISO/TS 21219-2, ISO/TS 21219-3 and ISO/TS 21219-
4 and the conversion to two current physical formats: binary and XML; others could be added in the
future. TISA uses an automated tool to convert from the agreed UML model XMI file directly into an MS
Word document file, to minimize drafting errors, that forms the annex for each physical format.
vi © ISO 2017 – All rights reserved

TPEG2 has a three container conceptual structure: message management (ISO/TS 21219-6), application
(several parts) and location referencing (ISO/TS 21219-7). This structure has flexible capability and
can accommodate many differing use cases that have been proposed within the TTI sector and wider
for hierarchical message content.
TPEG2 also has many location referencing options as required by the service provider community, any
of which may be delivered by vectoring data included in the location referencing container.
The following classification provides a helpful grouping of the different TPEG2 parts according to their
intended purpose.
— Toolkit parts: TPEG2-INV (ISO/TS 21219-1), TPEG2-UML (ISO/TS 21219-2), TPEG2-UBCR
(ISO/TS 21219-3), TPEG2-UXCR (ISO/TS 21219-4), TPEG2-SFW (ISO/TS 21219-5), TPEG2-MMC
(ISO/TS 21219-6), TPEG2-LRC (ISO/TS 21219-7), TPEG2-LTE (ISO/TS 21219-24).
— Special applications: TPEG2-SNI (ISO/TS 21219-9), TPEG2-CAI (ISO/TS 21219-10).
1)
1)
— Location referencing: TPEG2-ULR (ISO/TS 21219-11 ), TPEG2-GLR (ISO/TS 21219-21 ), TPEG2-
OLR (ISO/TS 21219-22).
— Applications: TPEG2-PKI (ISO/TS 21219-14), TPEG2-TEC (ISO/TS 21219-15), TPEG2-FPI
(ISO/TS 21219-16), TPEG2-TFP (ISO/TS 21219-18), TPEG2-WEA (ISO/TS 21219-19), TPEG2-RMR
(ISO/TS 21219-23), TPEG2-EMI (ISO/TS 21219-25).
TPEG2 has been developed to be broadly (but not totally) backward compatible with TPEG1 to assist
in transitions from earlier implementations, while not hindering the TPEG2 innovative approach and
being able to support many new features, such as dealing with applications having both long-term,
unchanging content and highly dynamic content, such as parking information.
This document is based on the TISA specification technical/editorial version reference:
SP14006/1.0/002.
1) Under development.
TECHNICAL SPECIFICATION ISO/TS 21219-22:2017(E)
Intelligent transport systems — Traffic and travel
information (TTI) via transport protocol experts group,
generation 2 (TPEG2) —
Part 22:
OpenLR location referencing (TPEG2-OLR)
1 Scope
TM
This document specifies the logical data format of OpenLR location references and general
requirements of the method in Clause 6 and defines the structure of the TPEG toolkit for OpenLR
location referencing (OLR) in Clauses 7, 8 and 9. The toolkit is intended to be used in the TPEG location
referencing container (TPEG-LRC).
OpenLR™ has been designed for the use case of transferring traffic information from a centre to in-
vehicle systems, built-in or used as an add-on (PND, smart phone). The information transferred can
consist of the current traffic situation at a certain location, a traffic forecast or special alerts. The
corresponding locations are roads, a list of connected roads, points of interest, or areas.
TM
In order to transmit location information from a sending to a receiving side, the OpenLR method
defines rules for generating map-independent location references, that is, the actual location references
are generated dynamically not requiring use of pre-defined location references.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/TS 21219-1, Intelligent transport systems — Traffic and travel information (TTI) via transport protocol
experts group, generation 2 (TPEG2) — Part 1: Introduction, numbering and versions (TPEG2-INV)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http:// www .electropedia .org/
— ISO Online browsing platform: available at http:// www .iso .org/ obp
3.1
area
two-dimensional part of the surface of the earth which is bounded by a closed curve
Note 1 to entry: An area may cover parts of the road network, covering several roads or parts of roads.
3.2
decoder
software component which decodes a location code and finds the corresponding location back in a map
3.3
encoder
software component which generates a location code for a location in a map
3.4
intermediate/intermediate location reference point
internal location reference point (LRP) which is neither the start LRP nor the end LRP
3.5
line
one-dimensional representation of a road or part of road in a road network
Note 1 to entry: A line starts and ends at a node. It is directed. This means two-way traffic flows are represented
by two (directed) lines, one per direction.
3.6
location
specification of the position on the earth surface of an object in a digital map
3.7
location reference
location code, created according to a specific set of rules, used to reference a location
3.8
location reference path
route in a road network in a digital map which is referenced by the location reference
Note 1 to entry: Note1 to entry: This path might be longer than the location itself.
3.9
location reference point
point representing a real-world point location
Note 1 to entry: Besides the position or line information, additional data may be used to further specify the
character of a location.
3.10
map
geospatial representation of an area on the earth surface
3.11
node
zero-dimensional object in the road network acting as start and end for lines
3.12
offset
specification of a position along a referenced path to indicate the start or the end of a location
3.13
orientation
describes the relationship between a point of interest and the direction of a referenced line
Note 1 to entry: The point may be directed in the same direction as the line, against that direction, in both
directions, or the direction of the point might be unknown.
3.14
point
zero-dimensional element that specifies a spatial location by a coordinate pair
2 © ISO 2017 – All rights reserved

3.15
route
collection of line objects in a digital map connecting a departure location and a destination location,
defined according to certain criteria which might include time distance or cost
3.16
side of road
relationship between a point of interest and a referenced line
Note 1 to entry: The point can be on the right side of the reference line, on the left side of the reference line, on
both sides of the reference line or directly on the reference line, in the position direction of the reference line.
4 Abbreviated terms
ADD against driving direction
BEAR bearing
CEN Comité Européen de Normalisation
COORD coordinates
DESC location description
DNP distance to next point
FOW form of way
FRC functional road class
FUZ fuzzy area
lat latitude
LFRCNP lowest functional road class to next point
lon longitude
LRP location reference point
LRC location reference container
n.a. not available
NCOLS number of columns
NOFF negative offset
NROWS number of rows
ORI orientation
POFF positive offset
POI point of interest
RAD radius
SFW TPEG service framework: modelling and conversion rules
SHP shape
SOR side of road
SRBL side road bearing left
SRBR side road bearing right
TISA Traveller Information Services Association
TPEG Transport Protocol Expert Group
TTI traffic and travel information
UML Unified Modelling Language
XML eXtensible Markup Language
5 Toolkit specific constraints
5.1 Version number signalling
Version numbering is used to track the separate versions of a toolkit through its development and
deployment. The differences between these versions may have an impact on client devices.
The version numbering principle is defined in ISO/TS 21219-1.
Table 1 shows the current version numbers for signalling the OLR version in use within this toolkit’s
top level component (see 7.1) and within TPEG-ML.
Table 1 — Current version number for signalling of OLR
Major version number 1
Minor version number 0
5.2 Extension
Future toolkit extensions may insert new components without losing backward compatibility. That
means an OLR decoder shall be able to detect and skip unknown components.
6 OLR structure
6.1 Location types
6.1.1 Supported location types
OpenLR™ supports several types of locations. Table 2 lists the supported types and also provides a link
to the clause where the specific type is explained in detail.
Table 2 — Supported location types
Name Category Details
Linear location Linear location See 6.1.2
Geo-Coordinate Point location See 6.1.3.2
PointAlongLine Point location See 6.1.3.3
4 © ISO 2017 – All rights reserved

Table 2 (continued)
Name Category Details
PoiWithAccessPoint Point location See 6.1.3.4
Circle Area location See 6.1.4.2
Rectangle Area location See 6.1.4.3
Grid Area location See 6.1.4.4
Polygon Area location See 6.1.4.5
ClosedLinear Area location See 6.1.4.6
6.1.2 Linear locations
A linear location is a one-dimensional singular continuous path through a road network, from one start
point location to one end point location. Offsets may be used to identify locations which do not start or
end exactly at a network node.
NOTE Examples of linear locations are jams, (temporary) speed limits and (calculated) routes. Figure 1 and
Figure 2 show different types of linear locations where the location is marked and the position of the offsets are
shown as dots.
Figure 1 — Linear location without offsets
Figure 2 — Linear location with offsets
6.1.3 Point locations
6.1.3.1 General
A point location is a zero-dimensional element that specifies a spatial location by a coordinate pair. One
coordinate pair specifies the point location. The following clauses outline different point location types
when seen in combination with a (road) network and their real-world examples. The types differ in how
the coordinate pair is related to the (road) network.
6.1.3.2 Geo-coordinate
A geo-coordinate pair is a position in a map defined by its longitude and latitude coordinate values.
This type of point location may or may not be bound to the network and can be everywhere on the
surface. Figure 3 shows an example of such a point location (filled circle).
Figure 3 — Example — Geo-coordinate
6 © ISO 2017 – All rights reserved

Real-world examples for a geo-coordinate as a point location are all coordinate pairs on the surface.
This is the general type of a point location. All other types can also be expressed by only using the geo-
coordinate pair.
6.1.3.3 Point along line
The next point location type is a location along a line. Such a line shall be bounded by two nodes. This
point location is dependent on the road network and Figure 4 shows such an example (filled circle). The
point may be on the right side of the line, on the left side of the line, on both sides of the line, or directly
on the line. Additionally, the point may have an orientation to indicate in which direction of the line the
information referenced at that point is useful.
Real-world examples of this point location type are points of interests closely or directly being related
to the road network such as petrol stations, shopping malls and restaurants and also property locations
and address points. But it can also be used to reference the location of speed cameras or induction loops.
Figure 4 — Example — Point along line
6.1.3.4 Point of interest (POI) with access point (on a line)
Another point location type combines a point on a line with a geo-coordinate. The point on a line
functions as an access point from the road network to a POI location represented by the geo-coordinate
part. The access point may be on the right side of the line, on the left side of the line, on both sides of
the line, or directly on the line. Additionally, the point may have an orientation to indicate in which
direction of the line the information referenced at that point is useful.
Figure 5 shows an example of this point location type. The filled circle not related to the road network
(coloured red in Figure 5) indicates the point location to be referenced. In combination with this point
location, there is an access point (filled circle related to the road network) (coloured green in Figure 5).
The access point identifies the location within the network used to access the point of interest. An
application may use the network related point to navigate the user to the desired point location.
Examples for such point locations may be address points but also all point of interests (POI) not being
closely related to the road network. Alternatively, the POI location may be used to reference other
interesting locations such as access to petrol stations or parking garages.
Figure 5 — Example — POI with access point
6.1.4 Area locations
6.1.4.1 General
An area location is a two-dimensional part of the surface of the earth which is bounded by a closed curve.
An area location may cover parts of the road network but does not necessarily need to. Examples for
area locations not covering the network are areas describing an area of woodland, a sea or agricultural
land. In OpenLR™, area locations are defined by their boundary.
6.1.4.2 Circle
A circle location shall be given by the position of the centre and the radius. The centre position shall
be a geo-coordinate pair of longitude and latitude coordinate values that may be everywhere on the
surface. The radius shall be integer-valued and given in metres. Figure 6 shows an example of such an
area location.
Figure 6 — Example — Circle
A real-world example for a circle location is a Wi-Fi hotspot with an approximation of its signal range.
8 © ISO 2017 – All rights reserved

6.1.4.3 Rectangle
A rectangle location references to a rectangular shape. It shall be given by two geo-coordinate pairs
which may be everywhere on the surface. The geo-coordinate pairs shall define the lower left (A) and
the upper right (B) corner of the rectangular shape (see Figure 7).
Figure 7 — Example — Rectangle location
Real-world examples are weather information or any area where the shape is not exactly specified and
the location references shall be light-weighted.
6.1.4.4 Grid
A grid location is a special instance of a rectangle location. It shall be given by a base rectangular shape
as described in 6.1.4.3. This base rectangle shall be the lower left cell of the grid and shall be multiplied
to the north (by defining the number of rows) and to the East (by defining the number of columns).
Figure 8 shows an example of such an area location.
Figure 8 — Example — Grid location
Real-world examples are weather reports about, for example, average rainfall for every cell of the grid.
6.1.4.5 Polygon
A polygon location is a non-intersecting shape defined by a sequence of geo-coordinate pairs. The
coordinate pairs may be everywhere on the surface. They shall define the vertices of the underlying
geometrical polygon. The boundary of this polygon shall be constituted by straight lines between every
pair of consecutive geo-coordinates pairs in the sequence, plus the straight line between the last and
the first geo-coordinate pairs. The order of the geo-coordinates pairs may be clockwise or counter-
clockwise.
Figure 9 shows an example of such an area location, defined by the interior of the polygon.
Figure 9 — Example — Polygon
Real-world examples for such area locations include low emission zones, areas affected by weather or
environmental conditions (bad weather, smog), flood areas, areas that are congested (due to any cause,
e.g. traffic overload, public event, or disaster), administrative areas, pedestrian areas, large crowds of
people, areas that are blocked for traffic, and areas subject to city toll.
6.1.4.6 Closed linear location
A closed linear location references the area defined by a closed path (i.e. a circuit) in the road network.
The boundary shall always consist of road segments. The path of a closed linear location may contain
self-intersections if courses (e.g. marathon course) are referenced. Otherwise, for referencing areas,
self-intersections should not appear. Figure 10 shows an example of such an area location.
Figure 10 — Example — Closed linear location
10 © ISO 2017 – All rights reserved

Real-world examples include low emission zones, congestion areas, areas that are blocked for traffic.
6.2 Requirements
6.2.1 General
The OpenLR™ approach focuses on creating map agnostic references for line, point and area locations.
The digital map used for encoding and decoding and the location itself shall fulfil some requirements
in order to guarantee acceptable results for the OpenLR™ method. Furthermore, the different location
types may also define requirements in order to transmit meaningful locations.
6.2.2 Map requirements
A digital map consists of nodes and lines. Lines represent real-world roads or parts of a road. Nodes
represent crossings of roads or parts of roads. Nodes are the connecting points between the lines.
The encoder and decoder map might differ but nevertheless, the OpenLR™ approach provides a method
to reference to the same location represented in both maps.
To be able to generate a map-independent location reference and also able to resolve locations properly,
a map should contain information about the following data:
— Coordinates in WGS84
— Every node in the network should have coordinates in the WGS84 format.
— The preferable accuracy is decamicrodegrees for each value.
— Length in metres
— Every line should have a length value in metres indicating its real dimension along the geometry.
— Geometry
— Every line should know about its real geometry in the real world.
— Lines shall not be abstracted by the airline.
— Functional road class (FRC)
— Every line in the network should have a functional road class value indicating its importance in
the network.
— Form of way (FOW)
— Every line in the network should have a form of way value indicating its physical properties.
If the coordinates are not in the WGS84 format, they shall be transformed into WGS84. The same applies
if length values are not available in metres.
Different digital maps may have different classifications for the functional road class and the form of
way values. It may also happen there exist more or less values. Therefore, OpenLR™ defines its own
ranges for FRC and FOW. There shall be a mapping between the FRC values in the digital map and the
FRC values as defined in the logical data format (see 6.3.2.3). The same applies for the FOW values (see
6.3.2.4). If no such functional road class values or form of way values are provided by the digital map
data, then these shall be derived from other information available in the digital map.
If a digital map provides less information than required, the encoding and decoding processes do
generally still succeed but the error rate can increase considerably. At least two out of the following
three information types shall be available in the map data: geometry [for the calculation of bearing
values (angle to the true north)], functional road class, form of way. The order geometry, FRC and FOW
also indicate the importance of the information for a location reference point to be unique.
6.2.3 Location properties
6.2.3.1 General
The location types may also define additional requirements in order to deal with a meaningful location.
Locations which do not fulfil the location type requirements cannot be encoded with OpenLR™. The
OpenLR™ encoder shall check each location if the requirements are met and shall report on any error.
6.2.3.2 Linear location
Linear locations shall fulfil the following requirements:
— A linear location shall be connected.
— Two subsequent lines in the location shall also be connected and adjacent in the underlying network.
A linear location is represented by an ordered list of line elements.
— The list of line elements shall be ordered from the start of a location to the end of a location.
— Offsets are always indicated by positive values and the total length of the offsets shall not exceed
the length of the complete location.
6.2.3.3 Point locations
6.2.3.3.1 Geo-coordinate
Geo-coordinate locations do not have further requirements.
6.2.3.3.2 Point along line
Point along line locations shall fulfil the following requirements:
— The referenced line shall be a single line in the road network.
— The offset value defining the position of the location on the referenced line shall not exceed the
length of the line.
6.2.3.3.3 POI with access point
POI with access point locations shall fulfil the following requirements:
— The referenced line shall be a single line in the road network.
— The offset value defining the position of the location on the referenced line shall not exceed the
length of the line.
— The distance between the start node of the referenced line and the position of the POI shall not
exceed the maximum distance between two location reference points as defined in Rule 1 in 6.4.
6.2.3.4 Area locations
6.2.3.4.1 General
Area locations should focus on simple (geometric) shapes. Mathematical operations like union or
intersection of shapes are not supported and may be implemented by the application using OpenLR™
area locations.
12 © ISO 2017 – All rights reserved

6.2.3.4.2 Circle
Circle locations shall fulfil the following requirements:
— The radius value shall be positive.
6.2.3.4.3 Rectangle
Rectangle locations shall fulfil the following requirements:
— The lower left coordinate and the upper right coordinate shall differ in both components (longitude
and latitude values).
— The lower left coordinate shall be southwestern of the upper right coordinate.
6.2.3.4.4 Grid
Grid locations shall fulfil the following requirements:
— The lower left coordinate and the upper right coordinate shall differ in both components (longitude
and latitude values).
— The lower left coordinate shall be southwestern of the upper right coordinate.
— The number of rows and the number of columns of a grid location shall be greater than 1.
— The number of cells forming a grid shall be exactly the product of the number of rows and the
number of columns (number of cells = number of rows × number of columns).
6.2.3.4.5 Polygon
Polygon locations shall fulfil the following requirements:
— The boundary of an area defined by a polygon shall not cross itself.
— The sequence of geo-coordinates of a polygon location shall be ordered.
6.2.3.4.6 Closed linear location
Closed linear locations shall fulfil the following requirements:
— The lines shall be connected.
— Two subsequent lines in the location shall also be connected and adjacent in the underlying
network.
— If a driving direction is available, then the location shall be traversable from its start to its end.
— The lines shall form a closed circuit.
— The las
...