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/TS 20452:2007(E)
©
ISO 2007

---------------------- Page: 1 ----------------------
ISO/TS 20452:2007(E)
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.


COPYRIGHT PROTECTED DOCUMENT


©  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

---------------------- Page: 2 ----------------------
ISO/TS 20452:2007(E)
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

© ISO 2007 – All rights reserved iii

---------------------- Page: 3 ----------------------
ISO/TS 20452:2007(E)
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

---------------------- Page: 4 ----------------------
ISO/TS 20452:2007(E)
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).
© ISO 2007 – All rights reserved v

---------------------- Page: 5 ----------------------
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.
© ISO 2007 – All rights reserved 1

---------------------- Page: 6 ----------------------
ISO/TS 20452:2007(E)
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

---------------------- Page: 7 ----------------------
ISO/TS 20452:2007(E)
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.
© ISO 2007 – All rights reserved 3

---------------------- Page: 8 ----------------------
ISO/TS 20452:2007(E)
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

---------------------- Page: 9 ----------------------
ISO/TS 20452:2007(E)
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
© ISO 2007 – All rights reserved 5

---------------------- Page: 10 ----------------------
ISO/TS 20452:2007(E)
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

---------------------- Page: 11 ----------------------
ISO/TS 20452:2007(E)
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
© ISO 2007 – All rights reserved 7

---------------------- Page: 12 ----------------------
ISO/TS 20452:2007(E)
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

---------------------- Page: 13 ----------------------
ISO/TS 20452:2007(E)
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 maxim
...