ISO/TS 20452:2007

TECHNICAL ISO/TS
SPECIFICATION 20452
First edition
2007-06-15
Requirements and Logical Data Model for
a Physical Storage Format (PSF) and an
Application Program Interface (API) and
Logical Data Organization for PSF used in
Intelligent Transport Systems (ITS)
Database Technology
Exigences et modèle de données logiques pour un format de stockage
physique (PSF), une interface de programme d'application (API) et une
organisation de données logiques pour un PSF utilisé dans la
technologie de base de données des systèmes de transport intelligents
(ITS)
Reference number
©
ISO 2007
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2007
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2007 – All rights reserved

Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions. 1
4 Symbols and abbreviated terms . 7
4.1 Abbreviations . 7
4.2 Syntax notation used in data model diagrams . 8
5 Application categories . 9
5.1 Positioning . 9
5.2 Route Planning. 11
5.3 Route Guidance . 15
5.4 Map Display . 17
5.5 Address Location. 21
5.6 Service and POI Information Access. 32
6 Logical Data Model . 37
6.1 Overall model . 37
6.2 Transportation Entities. 39
6.3 Address Location entities. 42
6.4 Service/POI entities . 43
6.5 Cartographic entities. 44
6.6 Dynamic Traffic Information entities . 46
7 Logical Data Organization . 47
7.1 Global architecture . 47
7.2 Detailed Road Data . 51
7.3 Detailed Background Data . 51
7.4 Map Display Data . 51
7.5 Route Planning data . 52
7.6 Address Location data . 52
7.7 Service Data . 52
7.8 Traffic Information . 53
7.9 Metadata . 53
Bibliography . 54

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a
technical committee may decide to publish other types of normative document:
⎯ an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
⎯ an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a
further three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is
confirmed, it is reviewed again after a further three years, at which time it must either be transformed into an
International Standard or be withdrawn.
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.
ISO/TS 20452 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.

iv © ISO 2007 – All rights reserved

Introduction
ISO/NP 14826, Physical Storage for TICS Database Technology, was introduced into ISO/TC 204 with the
objective of standardizing a physical storage format (PSF) for navigation map data and related information
stored on physical media used by in-vehicle navigation systems. The intent was to facilitate an interoperable
in-vehicle navigation market environment by developing a standard PSF that would enable navigation media
offered by different providers to be used by any navigation system and navigation systems made by any
developer to be able to read the same media.
There was widespread international participation in this effort. Many of the different companies within the
1)
different participating national delegations possessed their own respective formats that were commercially
available. It was decided early on that since none of these existing formats would be adopted wholesale as
the standard physical storage format, the functional requirements of these existing systems would be
submitted and consolidated into a universal set and organized into the major categories of application
functionality predominantly used by in-vehicle navigation systems.
This gathering of market-driven requirements was the first step of an agreed development process that would
proceed according to a top-down development approach. A sequential work plan was defined which included
a logical data model based on the requirements, followed by the development of a logical organization of the
data types used in the model. This logical data organization (LDO) would be used as a basis for the definition
of a physical data organization (PDO), which would be defined to a sufficient level of granularity to specify a
single standard PSF.
It took several years to develop and gain consensus on the requirements, the logical data model, and the
logical data organization. During the development there were several input documents submitted by various
national delegations. At the beginning of the development of the PDO it was decided to use a Japanese PDO
2)
input document as a framework for the PDO discussion.
Shortly after the PDO discussion began, the project ISO/NP 14826 expired and there was not sufficient
international support for resubmitting a new work item proposal to continue the work, nor was there consensus
that the PDO work could be finished within an acceptable time frame. Consequently, a standard PSF as
envisioned within the scope of the work item would not be realized.
However, the requirements, logical data model, and logical data organization documents developed in this
process reflect international consensus and still provide value for the navigation system market and other
emerging products and services which use navigation map data. Thus it was agreed to convert these
documents into a Technical Specification which could be used for future developments.
This Technical Specification can help developers of applications that use map databases to realize
efficiencies by providing guidelines on setting up an appropriate architecture for navigation systems. This
provides a potential benefit to the developer's ability to develop systems in a shorter timeframe, thereby
shortening time-to-market for products. Although this Technical Specification was originally developed for
navigation system applications, it may also facilitate other market development activities by providing insight
into solving common data modelling and organization issues in the fields of telematics and location-based
services.
1) These formats are identified in the Bibliography of this Technical Specification.
2) Kiwi Format Specification version 1.2.2 (see Bibliography).
TECHNICAL SPECIFICATION ISO/TS 20452:2007(E)

Requirements and Logical Data Model for a Physical Storage
Format (PSF) and an Application Program Interface (API) and
Logical Data Organization for PSF used in Intelligent Transport
Systems (ITS) Database Technology
1 Scope
This Technical Specification describes the functional requirements and Logical Data Model for PSF and API
and the Logical Data Organization for PSF that were completed under ISO/NP 14826. It does not specify a
Physical Data Organization.
2 Normative references
The following referenced documents are indispensable for the application 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 14825, Intelligent transport systems — Geographic Data Files (GDF) — Overall data specification
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
Address Location
application category that deals with the task of expressing a real-world position in terms of the PSF data
representation
NOTE Address Location is one of the six application categories supported by the PSF and the API.
3.2
address type
attribute of road section entity, specifying the type of house number ranges
EXAMPLE distinction between base address, county address, commercial address, etc., or no address.
3.3
application category
basic sub-function within the set of functionality for vehicle navigation and traveller information system
applications
NOTE This Technical Specification identifies six application categories: Positioning, Route Planning, Route Guidance,
Map Display, Address Location, Services and POI Information Access.
3.4
Application Program Interface
API
〈ISO context〉 specification interface and set of function calls between application software and data access
libraries of vehicle navigation systems
3.5
base map
the whole of all transportation elements and all services, including their relationships to transportation
elements
3.6
Branded Third Party Data
BTPD
information about services which is supplied by third party data providers (e.g. tourist or motoring
organizations) who may impose proprietary restrictions on the use and presentation of the data
NOTE 1 Access to BTPD is subject to authorization and licensing.
NOTE 2 BTPD is a sub-set of Third Party Data (TPD).
3.7
cartographic feature
data model entity that represents geometrical information for display purposes, having non-explicit topology
and 0-, 1- and 2-dimensional types
EXAMPLES Display Point, Polyline and Polygon.
3.8
cartographic text
data model entity that stores name text that is associated with all or part of a cartographic feature
NOTE It is language-dependent and can contain a suggested display location, orientation, language code, priority (or
importance), suggested scale range, and bounding box.
3.9
condition
information related to link(s) which is composed of condition type, condition modifiers and condition scope
3.10
crossroad
data model entity that represents the single instance of the crossing of two named navigable features; it
relates to the set of links and nodes which comprise the crossing, and to the crossing of the navigable
features to a place
3.11
display point
0-dimensional type of cartographic feature
3.12
dummy point
non-required entity that represents a position along a link where the link crosses a parcel boundary and does
not necessarily coincide with a shape point or node
3.13
geocoding
determination of a link or node based on address information describing and/or naming a location
2 © ISO 2007 – All rights reserved

3.14
intersection
GDF level 2 representation of a crossing which bounds a road or a ferry as a complex feature composed of
one or more GDF level 1 junctions, road elements and enclosed traffic areas
3.15
junction
data model entity that represents a navigable feature which is either a named GDF junction or named GDF
intersection, and that relates a named navigable feature to a set of links and nodes and a place
3.16
landmark
point, line or area feature that can be used to clarify the directions generated to describe a route
NOTE 1 It can be associated to a node or a link.
NOTE 2 A landmark cannot be in the Services, Administrative Areas, or Public Transportation Feature themes of the
GDF; however a facility in which a service is located can be a landmark.
3.17
layer
sub-set of map data resulting from a subdivision of data of the same coverage area based on contents (similar
to ISO-GDF layer) and which is typically related to one or only a few of the application categories
EXAMPLE Route guidance data can be considered as one layer.
3.18
level
sub-set of map data resulting from classification of data of the same semantically contents based on the level
of details/density, related to the concept of different map scales
NOTE Level 0 is considered the lowest level (greatest detail); higher levels are numbered level 1, level 2, etc.
EXAMPLE Map display data can be organized into 6 levels representing different zoom scales.
3.19
link
directed topological connection between two nodes, composed of an ordered sequence of one or more
segments and represented by an ordered sequence of zero or more shape points
3.20
Map Display
application category that deals with graphical information presentation
NOTE Map Display is one of the six application categories supported by the PSF and the API.
3.21
multilink
ordered aggregation of links which are at the same level, connected in sequence, share the same functional
classification, form of way, direction of travel, and perhaps additional PSF-builder-specified characteristics,
such that each link is contained in exactly one multilink
3.22
navigable feature name
data model entity that represents the name for the transportation element, including GDF road element, GDF
ferry connection, GDF junction, GDF intersection
NOTE It is related to places, crossroads, junctions and road sections.
3.23
node
data model entity for a topological junction of two or more links or end bounding a link
NOTE A link stores the coordinate value of the corresponding GDF junction.
3.24
parcel
database partitioning unit, corresponding to a certain coverage area and associated with one level and
containing data of one or more layers
NOTE 1 A parcel contains (at least) all nodes with positions enclosed by or located on the outline of its coverage area
plus (parts of) all links attached to these nodes.
NOTE 2 It can be partitioned such that the amount of data of one parcel is nearly the same as that of another.
3.25
place
named area which can be used as part of address location
3.26
place class
attribute of place entity, classifying data into highest administrative or geographic division, administrative
sub-division, postal, or colloquial (such as regions or neighbourhoods)
NOTE It is partially ordered as “place class A is below place class B” (does not imply strict or complete containment).
3.27
place level
level associated with places of place classification “administrative sub-division”
NOTE Higher/lower level situations are constituted by the occurrence of a parent/child place relationship between
places.
3.28
place relationship
bivalent relationship between place entities, constituting the place tree, linking parent and child places
(“place A is in place B”)
NOTE 1 It does not imply strict or complete containment.
NOTE 2 It is attributed as: address significant, official, postal, or useful for reverse geocoding.
3.29
Point of Interest
POI
destination and/or site of interest to travellers, usually non-commercial by nature
3.30
polygon
2-dimensional type of cartographic feature
3.31
polyline
1-dimensional type of cartographic feature
3.32
Positioning
application category that deals with the determination of vehicle location and map-matching
NOTE Positioning is one of the six application categories supported by the PSF and the API.
4 © ISO 2007 – All rights reserved

3.33
postal code
data model entity for a government-designated code used for specified regions for addressing
NOTE It is related to link, navigable feature name, place, and POI.
3.34
rectangle
unit of geographic space, defined by two parallels of min/max latitude and by two meridians of min/max
longitude, that represents the coverage area of the map data enclosed by or located on the outline of the
rectangle
3.35
regular parcel
parcel shaped like a rectangle
NOTE Regular parcels on the same generalization level are not intended to overlap.
3.36
reverse geocoding
determination of the address description of a link or node (i.e. determination of an upwards path across the
place tree)
3.37
road
GDF level 2 feature composed of one, many or no road elements and joining two intersections, serving as the
smallest independent unit of a road network at GDF level 2
3.38
Road Element Side
RES
basic component of the road section entity that represents the left or right side of a link, and corresponds to
one or more unique combinations of a navigable feature and a house number range
3.39
road section
data model entity that represents the house number ranges of both sides of a street that carries a navigable
feature name
NOTE It corresponds to a link (ID).
3.40
Route Guidance
application category that deals with the generation of graphical, textual, and/or audio instructions for following
a planned route
NOTE Route Guidance is one of the six application categories supported by the PSF and the API.
3.41
Route Planning
application category that deals with the determination of routes between specified points
NOTE Route Planning is one of the six application categories supported by the PSF and the API.
3.42
segment
straight section of a link connecting either two successive shape points, or a shape point and a node, or two
nodes in case the link does not contain shape points
3.43
service
data model entity for a commercial activity of interest to travellers as a destination and/or orientation that is
associated with road element(s), by which it can be accessed, and place(s)
NOTE 1 Service is further described by attributes including (at least) name and type; it can be associated with other
services by parent/child relationships (many to many).
NOTE 2 Service is used synonymously with POI within the logical data model.
3.44
service attribute
descriptive information of a service
3.45
Services and POI Information Access
application category that deals with the provision of POI information to the navigation application
NOTE Services and POI Information Access is one of the six application categories supported by the PSF and the
API.
3.46
shape point
position along a link used to more accurately represent its geometric course, bounded by exactly two
segments
3.47
signpost
data model entity for a directional sign that represents a logical relationship between signpost information and
two associated links where the first link (mandatory) represents the road element along which the signpost is
located, and the second link (optional) is the first road element which directs exclusively to the destination
indicated on the signpost
NOTE The position of the signpost along the link and the link direction the signpost is facing are also stored.
3.48
SuperLink
aggregation of linearly connected regular links present in the lowest level as a simplified representation of the
road network in higher levels
3.49
symbol
data model entity that represents an icon associated with a cartographic feature
3.50
Third Party Data
TPD
additional descriptive and editorial information about services which is typically supplied by third party data
providers (e.g. tourist or motoring organizations)
3.51
traffic location
data model entity that contains an external reference (e.g. VICS or RDS-TMC) and is linked to either place or
transportation entities
3.52
transportation element
any feature from the Roads and Ferries feature theme of the GDF
6 © ISO 2007 – All rights reserved

4 Symbols and abbreviated terms
4.1 Abbreviations
AL Address Location
API Application Program Interface
BTPD Branded Third Party Data (subset of Third Party Data – TPD)
DAL Data Access Libraries
DBD Detailed Background Data
DRD Detailed Road Data
GDF Geographic Data Files
ITRF International Terrestrial Reference Frame
LDO Logical Data Organization
LDM Logical Data Model
LiQ Location in Question
MD Map Display
MI Metadata Information
PDO Physical Data Organization
POI Point(s) of Interest
PSF Physical Storage Format (the ISO entity defined by this Technical Specification)
RDS-TMC Radio Data System-Traffic Message Channel
RES Road Element Side
RP Route Planning
TI Traffic Information
TPD Third Party Data
VICS Vehicle Information and Communication System
WGS84 World Geodetic System 1984
4.2 Syntax notation used in data model diagrams

Figure 1 — Example for Data Model Notation
There are six components:
⎯ Entity (any logical data entity);
⎯ Binary Relationship (any relation between two entities);
⎯ Ternary Relationship (any relation between three entities);
⎯ Connector (notation component to connect entities with a relationship valence qualified by a number);
⎯ Relationship Attribute (qualifies a relationship in more detail);
⎯ Data Model Part (a conceptual sub-unit of the whole model).
In the example in Figure 1, there is an N-to-M binary relationship involving A and B, and qualified by
relationship attribute X. Valences (the N and M in an N-to-M relationship, or the 1 and N in a one-to-N
relationship) are interpreted as follows: An N-to-M binary relationship is always an abbreviation for two parallel
relationships, as shown in Figure 1. This means that an A can correspond to multiple B’s (hence the “M” on B),
and in addition that a B can correspond to multiple A’s (hence the “N” on A). When a variable like “N” or “M” is
used, there is no implication that every A corresponds to the same number of B’s or that every B corresponds
8 © ISO 2007 – All rights reserved

to the same number of A’s. Two different variables, N and M, are used to further imply that there is no
correspondence between the number of B’s per A and the number of A’s per B. The existence of an N-to-M
relationship in the Logical Data Model also does not imply that functionality will be supplied to follow the
relationship in both directions. That is, it is not necessarily true that there need be both a function to find the
B’s corresponding to a given A and the A’s corresponding to a given B. If there is a function to find the B’s that
correspond to a given A, then the 1-to-M relationship from A to B indicates that the function, given an A, might
return multiple B’s, and the N-to-1 relationship from A to B indicates that a given B might be in the lists
returned for multiple distinct A’s in separate calls.
Whether a relationship is characterised as 1-to-1, 1-to-N, or N-to-M, it is possible that a given individual entity
may not participate in the relationship, or may participate in the relationship with fewer than the maximum
possible number of corresponding entities. For example, there is a 1-to-N relationship between Links and
Shape Points. This indicates that one Link can have multiple Shape Points, but that a given Shape Point can
correspond to only one Link. However, a given Link might have no Shape Points, despite the multiplicity
implied by “N”. In order to keep the notation simple, we will consider this to be implicit, rather than writing
expressions like “{0, 1}-to-{0, 1, …, N}”.
The interpretation of ternary relationships and their valences is similar. A ternary relationship is a relationship
among three entities. An example is shown as an M-to-1-to-N relationship among B, C, and D. This is
interpreted as follows: There are correspondences between triples (b, c, d) of individual B’s, C’s, and D’s. The
valence M on B indicates that, if one selects a particular c0 from among the C’s and a particular d0 from
among the D’s, there can be multiple B’s that correspond to c0 and d0. There is no implication that different
choices of c0 and d0 will correspond to the same number of B’s. Similarly, the valence N on D indicates that, if
one selects a particular b0 from among the B’s and a particular c0 from among the C’s, there can be multiple
D’s that correspond to b0 and c0. Again, there is no implication that different choices of b0 and c0 will
correspond to the same number of D’s. Different variables N and M are used for B and D in order to further
imply that there is no correspondence between the number of B’s corresponding to a fixed C and a fixed D
and the number of D’s corresponding to a fixed B and a fixed C. Finally, the valence 1 on C indicates that, if
one selects a particular b0 from among the B’s and a particular d0 from among the D’s, there can be at most
one C that corresponds to b0 and d0.
As in the case of binary relationships, the existence of a ternary relationship, regardless of its valences, does
not imply that functionality will be supplied to follow the relationship in all three possible directions. Of the
three possible functions in this example (given a B and a C, return the corresponding D’s; given a B and a D,
return the corresponding C; given a C and a D, return the corresponding B’s), one, two, or all three functions
may be defined. Suppose, for example, that only the first of those functions is defined. Then the correct
interpretation of the valences is as follows: The “N” on D means that for a given B and a given C, the function
might return multiple D’s. The “M” on B means that, for a fixed c0 among the C’s and a fixed d0 among the D’s,
there might be multiple B’s such that the function, called with them and with c0, will return d0 among its list of
D’s. Finally, the “1” on C means that, for a fixed b0 among the B’s and a fixed d0 among the D’s, there is at
most one C such that calling the function with b0 and with that C will return d0 among its list of D’s.
Binary relationships shall be drawn in solid lines, while ternary relationships shall be drawn in dashed lines.
5 Application categories
5.1 Positioning
5.1.1 General
The Positioning function is used to determine location, for example latitude and longitude of a road network
entity and for Map Matching. Map Matching is the method of determining where the navigation system has
moved in the road network based on the navigation system’s previous location and data about the navigation
system’s motion from external inputs.
5.1.2 Functional description
“Positioning” seeks a position and orientation of a navigation system relative to the transportation network with
respect to the map data representing the real world. An application may dynamically determine the navigation
system’s current position while the navigation system is in motion. Map Matching can continue “in the
background” even while other functions are being performed so the navigation system always “knows where it
is”. Map Matching algorithms are beyond the scope of this document.
For the purpose of positioning, the following functions shall be provided:
a) a single set of coordinates for an application-specified Point Feature in the Roads and Ferries theme;
b) the set of Edges, Nodes and/or Intermediate Points for an application-specified Feature or set of
connected Features in the Roads and Ferries theme;
c) the set of topologically connected Features in the Roads and Ferries Theme connected to an application-
specified Feature in the Roads and Ferries theme;
d) a single set of coordinates for an application-specified Line Feature in the Roads and Ferries theme and
application-specified percentage of the distance along the Feature;
e) the set of Features, Edges, Nodes and/or Intermediate Points in the Roads and Ferries theme within an
application-specified rectangle;
f) positioning related Attributes, Conditions and Relationships (i.e. Prohibited Maneuvers, Direction of Traffic
Flow) for an application-specified Feature in the Roads and Ferries theme;
g) the entry and exit angles for the set of Transportation Elements connected to an application-specified
Intersection or Junction;
Additionally,
h) the API shall allow a pre-fetch area of interest to be specified by a rectangle for retrieving Positioning
data;
i) the specification shall support a single, world-wide, latitude/longitude-based coordinate reference system.
The International Terrestrial Reference Frame (ITRF) is chosen because it is maintained by an
international body. It is considered equivalent to WGS84 because the two systems currently have less
than 1 m difference;
j) in datasets of Japan and Korea the Tokyo datum shall also be allowed because of the prevalent use of
the Tokyo datum in existing navigation applications in Japan and Korea;
k) only one coordinate system can be used in a single piece of storage media;
l) identification of the coordinate system used in the PSF shall be by means of a meta-data identifier;
m) the API shall allow retrieval of the coordinate system identifier;
n) the API shall allow retrieval of coordinates in the coordinate system which is stored in the media.
5.1.3 Interaction of Positioning and other Application Categories
Positioning may provide position information to other applications which perform the following tasks:
a) when an application tracks progress along the route and provides manoeuver instructions at appropriate
points to the end-user;
b) when an application determines whether the navigation system has left the planned route;
10 © ISO 2007 – All rights reserved

c) when an application calculates a route to the requested destination from the navigation system’s current
position;
d) when an application scrolls the displayed map;
e) when an application selects services by geographic proximity;
f) when an application is displaying the navigation system’s position on a map;
g) when an application displays a map around a location relative to the navigation system’s current position;
h) positioning may receive planned route information from the Route Planning application for use in Map
Matching.
5.1.4 Requirements for Logical Data Model
The Logical Data Model is required to support at least the data identified in the Function Description. Other
requirements for the Logical Data Model are defined below.
a) Only access to the lowest level of data is required.
b) Only access to the data represented in the Roads and Ferries theme is required.
c) Positioning data shall be organized into parcels.
d) In order to minimize the number of parcels accessed, any link crossing into a parcel, with or without a
node or intermediate point in that parcel, shall be represented in that parcel.
e) In order to allow fast spatial access to parcels, parcels shall be accessed by their bounding rectangles.
The shapes of parcels on the lowest level shall not overlap.
5.1.5 Metadata
Access to metadata is required in order to identify the geodetic system of the coordinate data in the database.
5.1.6 Extended Parcel Exposing Functions
For the requirements of this subclause, see 5.2.7.
5.2 Route Planning
5.2.1 General
The Route Planning function is used to determine routes from one user-specified location to another.
5.2.2 Functional description
Navigation applications may calculate routes based on attributes of the transportation network. Applications
may allow end-users to specify criteria for the route such as “shortest distance”, “no highways”, etc. As a basic
operation, a user indicates a departure position, which could be the navigation system’s current position, and
selects a destination (place to go) and possibly one or more waypoints. A suitable route is then calculated.
Routing is not limited to automobile transportation only. This function supports routing via any mode
represented in the database. This may include rail and water ferries, taxis, and routes only accessible by
bicycle or foot. Other forms of public transportation may be considered in the future.
The route calculation algorithms are outside the scope of this functional description.
To improve data access speed, the Logical Data Organization groups transportation features into levels. The
higher levels contain only the more significant features (e.g. highways and main roads). These may be
aggregated. Correspondences between features at different levels shall be made available to the application.
The functions specified in the requirements below allow selection by level.
The Route Planning application provides the following methods of accessing data that can be used for routing:
a) via the set of topologically connected Links for an application-specified Link at an application-specified
level;
b) via routing-related Attributes for an application-specified Transportation Element or set of connected
Transportation Elements, such as: Node Coordinates (of the bounding Nodes of a Link), Measured
Length, Functional Road Class, Number Of Lanes, Average Speed, Divided Road Element, Form Of Way,
as well as access characteristics, Conditions, and other Relationships;
c) via navigation attributes for Roads and Intersections;
d) via corresponding Link for an application-specified Link at an application-specified different level;
e) via a set of topologically connected GDF Roads for an application specified GDF Road at an application
specified level at certain levels to be determined;
f) via a set of GDF Road Elements and GDF Junctions, which comprise a GDF Road or GDF Intersection;
g) via the GDF Road or GDF Intersection for an application-specified GDF Road Element or GDF Junction;
h) via the corresponding entity representing a GDF Junction or Intersection for an application-specified entity
representing a GDF Junction or Intersection at an application-specified different level;
i) via effective time or date periods for turn, travel, or other Conditions;
j) via location references which are stored in the database for an application-specified set of Transportation
Elements;
k) via a set of Transportation Elements for an application-specified location reference, which is stored in the
database;
l) via the entry and exit angles for the set of Links connected to an application-specified Intersection or
Junction;
m) via historic and forecast traffic conditions, incidents, and events information for a specified Transportation
Element or set of Transportation Elements;
n) via a DAL capable of providing transparent access to static and dynamic traffic information. It shall not
preclude or require the integration of dynamic traffic information from external systems;
o) via an API allowing a pre-fetch area of interest specified by feature ID or rectangle for retrieving Route
Planning data at an application-specified level.
5.2.3 Interaction of Route Planning and other application categories
The Route Planning application can interact with other application categories as follows.
a) The Route Planning application accepts other information from the Positioning application when
calculating a route to the requested destination from the navigation system’s current position.
b) The Route Planning application provides information about the planned route to the Positioning
application when determining whether the navigation system has left the planned route.
12 © ISO 2007 – All rights reserved

c) The Route Planning application provides information about the planned route to the Route Guidance
application for generating driving instructions.
d) The Route Planning application provides information about the planned route to the Services and POI
Information Access application for geographic selection of services with proximity to the planned route.
e) The Route Planning application accepts input from the Services and POI Information Access and Address
Location application when determining end-points or way-points for a route.
f) The Route Planning application provides information about the planned route to the Map Display
Application when indicating the course of the planned route on the graphical map display.
5.2.4 Requirements for Logical Data Model
The logical data model is required to support at least the data identified in the function description. Other
requirements for the logical data model are defined below.
a) Only access to the data represented in the Roads and Ferries theme is required. Enclosed traffic areas
shall be represented by links and nodes.
b) The shape of a parcel on a given level shall be contained in the shape of exactly one parcel at a higher
level. The shapes of parcels on the same level shall not overlap.
c) For route planning data, references to parcels on the same level and on the level(s) above and below are
required.
d) In order to have optimally filled parcels, parcels may have different coverage sizes.
e) For route planning data, no intermediate points are required for the representation of links. A
representation of turn angles, link length and the link cost are required.
f) There is no requirement to create an additional node where a link crosses a parcel boundary.
g) For route planning data, links crossing a parcel boundary should be stored as a whole in those parcels
where they are connected to other links in the same parcel.
h) In order to have fast access to parcels, parcels shall be accessed by their bounding rectangles.
i) A separate computation is required to find nodes or links in the network data corresponding to origin,
intermediate and destination points. The manner in which t
...