ISO 14296:2016

DRAFT INTERNATIONAL STANDARD
ISO/DIS 14296
ISO/TC 204 Secretariat: ANSI
Voting begins on: Voting terminates on:
2014-11-12 2015-02-12
Intelligent transport systems — Extension of map database
specifications for applications of cooperative ITS
Systèmes intelligents de transport — Extension des spécifications de base de données cartographiques aux
applications collaboratives des SIT
ICS: 35.240.60;03.220.01
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/DIS 14296:2014(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
©
PROVIDE SUPPORTING DOCUMENTATION. ISO 2014

ISO/DIS 14296:2014(E)
Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as
permitted under the applicable laws of the user’s country, neither this ISO draft nor any extract
from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means,
electronic, photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to 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
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO 2014 – All rights reserved

ISO/DIS 14296:2014(E)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Conformance . 1
4 Terms and definitions . 1
5 Symbols (and abbreviated terms) . 5
6 Requirements . 5
6.1 Introduction . 5
6.2 Application requirements. 5
6.3 Functional requirements . 5
7 Logical data model .16
7.1 Overall model .16
7.2 Transportation package .17
7.3 Cartographic package .46
7.4 Service and POI package .52
7.5 Address location package .53
7.6 Dynamic information package .55
7.7 Relationship of the road data between levels .56
Annex A (normative) Abstract test suite .59
Annex B (informative) Description of UML expression elements .60
Annex C (normative) Basic set of applications definition .62
Annex D (informative) Overview of the target example services (Japanese examples) for
Driving support .64
Annex E (normative) Relationship between Basic set of applications and Driving support services
(Japanese example) .82
Annex F (informative) Use case of Multi-Modal Travel Support service.83
Bibliography .91
ISO/DIS 14296:2014(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.
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 meaning of ISO specific terms and expressions related to conformity
assessment, as well as information about ISO’s adherence to the WTO principles in the Technical Barriers
to Trade (TBT) (see Foreword — Supplementary information).
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
iv © ISO 2014 – All rights reserved

ISO/DIS 14296:2014(E)
Introduction
The purpose of this proposal is to extend the existing specifications for map databases in order to
provide greater support for applications and/or application developments of cooperative ITS that may
use Local Dynamic Map.
The functional requirements and data model for in-vehicle navigation are already defined in TS 20452.
However, the map-related functional requirements, data model, and data elements needed for Local
Dynamic Map for Cooperative ITS have not yet been defined.
This proposal can help developers of applications for Cooperative ITS by broadening its applicability.
Such applications will benefit by the availability of a standardized data model and data elements. The
resulting work will shorten developers’ time-to-market for new products and services.
The scope of ISO/TS 17931 is within the scope of NP14296 which was approved in April, 2011. However,
in order to meet the schedule requirement of Mandate M/453 issued by European Commission, TS 17931
was published as the Local Dynamic Map component of this International Standard. This International
Standard fully supports the ISO/TS 17931.
This International Standard defines the Logical Data Model for Multi-Modal navigation system, however
does not define the data model for individual navigation service except for in-vehicle navigation.
This International Standard uses UML to express specific circumstances; the graphical elements are
used to express specific constraints and structural relationships. A full definition can be found in
ISO/IEC 19501:2005. However, a short introduction of elements is given in Annex B.
DRAFT INTERNATIONAL STANDARD ISO/DIS 14296:2014(E)
Intelligent transport systems — Extension of map database
specifications for applications of cooperative ITS
1 Scope
This International Standard provides the map-related functional requirements, data model (logical
data model/logical data organization), and data elements for those applications of cooperative ITS that
require information derived from map databases.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 14825:2011, Intelligent transport systems — Geographic Data Files (GDF) — GDF5.0
ISO/IEC 19501:2005, Information technology — Open Distributed Processing — Unified Modelling Language
(UML) Version 1.4.2
ISO/TS 20452:2007, 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
3 Conformance
Data structures are provided as specified in Clause 7.
Any data structure claiming conformance with this International Standard shall pass the requirements
presented in the abstract test suite in Annex A.
UML Expressions for diagrams in this International Standard shall be compliant with ISO/IEC 19501:2005.
4 Terms and definitions
For the purposes of this document, the terms and definitions in ISO 14825 and ISO/TS 20452 and the
following apply.
4.1
Address Location
application category that deals with the task of expressing a real-world position in terms of the PSF data
representation
4.2
application category
basic sub-function within the set of functionality for cooperative ITS support
Note 1 to entry: This International Standard identifies eight application categories: Positioning, Route Planning,
Route Guidance, Map Display, Address Location, Services and POI Information Access, cooperative ITS including
Driving support, Multi-Modal Travel.
4.3
display point
0-dimensional type of cartographic feature
ISO/DIS 14296:2014(E)
4.4
geocoding
determination of a link or node based on address information describing and/or naming a location
4.5
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
4.6
itinerary
plan of a journey, including the route and the places visited
4.7
junction
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
4.8
landmark
point, line or area feature that can be used to clarify the directions generated to describe a route
Note 1 to entry: It can be associated to a node or a link.
Note 2 to entry: 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.
4.9
layer
sub-set of map data resulting from a subdivision of data of the same coverage area based on contents
(similar to IS 14825 GDF layer) and which is typically related to one or only a few of the application
categories
EXAMPLE District name, which is one of the data items for Route Guidance applications, is included in a layer.
4.10
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 1 to entry: 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.
4.11
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
4.12
Local Dynamic Map
conceptual data store which is embedded in an ITS station and which contains topographical, positional
and status information
4.13
Map Display
application category that deals with graphical information presentation
2 © ISO 2014 – All rights reserved

ISO/DIS 14296:2014(E)
4.14
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
4.15
Multi-Modal Travel Service
application category that provides information on a trip from an origin to a destination using alternative
modes of transportation or a combination of transport modes for one trip
Note 1 to entry: This service may include navigation.
4.16
Multi-Modal Travel Support
software application for Multi-Modal Travel Service
4.17
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 to entry: 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 to entry: It can be partitioned such that the amount of data of one parcel is nearly the same as that of
another.
4.18
place
named area which can be used as part of Address Location
4.19
Point of Interest
POI
destination and/or site of interest to travellers, usually non-commercial by nature
4.20
polygon
2-dimensional type of cartographic feature
4.21
polyline
1-dimensional type of cartographic feature
4.22
positioning
application category that deals with the determination of vehicle location and map-matching
4.23
position-on-the-link
position on the road or road side used to identify the access point between the road network and entrance
or exit of facilities such as station, bus stop and building
4.24
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
ISO/DIS 14296:2014(E)
4.25
regular parcel
parcel shaped like a rectangle
Note 1 to entry: Regular parcels on the same generalization level are not intended to overlap.
4.26
reverse geocoding
determination of the address description of a link or node (i.e. determination of an upwards path across
the place tree)
4.27
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
4.28
route
ordered list of route Links, or of stop points respectively, defining a single path through the transport
network, with a direction
4.29
Route Guidance
application category that deals with the generation of graphical, textual, and/or audio instructions for
following a planned route
4.30
route link
oriented link between two route Points defining a unique path through the transport network
4.31
Route Planning
application category that deals with the determination of routes between specified points
4.32
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
4.33
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) or place(s), by which it can be accessed
Note 1 to entry: 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 to entry: Service is used synonymously with POI within the logical data model.
4.34
Service and POI Information Access
application category that deals with the provision of POI information to the navigation application
Note 1 to entry: Services and POI Information Access is one of the eight application categories.
4.35
shape point
position along a link used to more accurately represent its geometric course, bounded by exactly two
segments
4 © ISO 2014 – All rights reserved

ISO/DIS 14296:2014(E)
4.36
stop point
position where passengers gets in or off a (public transport) vehicles
4.37
symbol
icon associated with a cartographic feature
5 Symbols (and abbreviated terms)
ADAS Advanced Driver Assistance System
BSA Basic set of applications
DB Database
GDF Geographic Data File
ITS Intelligent Transport System
ITS-RSU Intelligent Transport System — Road Side Unit
LDM Local Dynamic Map
LDO Logical Data Organization
POI Point Of Interest
PSF Physical Storage Format
6 Requirements
6.1 Introduction
This clause defines application requirements and functional requirements.
6.2 Application requirements
This International Standard supports BSA of cooperative ITS systems, Driving support services, and
navigation services for in-vehicle and Multi-Modal Travel.
BSA of cooperative ITS systems are defined in Annex C. Driving support services are defined in Annex D.
Relationship between BSA of cooperative ITS systems and Driving support services are defined in
Annex E and Multi-Modal Travel services are defined in Annex F.
6.3 Functional requirements
6.3.1 Overview
Six application categories (Map Display, Positioning, route Planning, route Guidance, Service/POI
Information Access and Address Location) for navigation functionality are the same as those defined
in ISO/TS 20452:2007. Cooperative ITS (including driving support) and Multi-Modal Travel Support
functions are newly defined by this International Standard.
ISO/DIS 14296:2014(E)
6.3.2 Map Display
6.3.2.1 General description
The Map Display function is used to display a map of a specified geographic area. An application may
display maps to the end-user. The application may also accept end-user input that references the Map
Display (such as from a point and click device).
6.3.2.2 Functional description
An application may display points, features, lines features, areas features, cartographic text and symbols
for a specified geographic area. This may include roads, physical features, administrative boundaries,
and names for all of these. Text and symbols can be positioned on a display to annotate this map.
The Map Display function provides cartographic data that can be used to display a map of any application
specified arbitrarily-oriented rectangle in the database. The data consist of the following database
entities to support a variety of map drawing styles: Cartographic Features, Cartographic Text and
Symbols.
The application may allow the map to be zoomed in or out. The application may display different levels
of detail on a Map Display based on the zoom level. The application may allow the map to be rotated and
scrolled. When scrolling, if detailed data are not available, the application may automatically zoom the
map out to a level where data are available. The application may allow the end-user to access additional
information by selecting objects on the display. The application may display multiple windows.
Generating map images and managing displays are beyond the scope of this function.
To facilitate data access speed, this application groups cartographic data into levels. The higher levels
contain only the more significant cartographic features. The set of cartographic data are also selectable
by level.
6.3.2.3 Requirements for data model
Map Display provides the following methods of accessing data:
R-1. via the Cartographic Features, Cartographic Text and Symbols for an application-specified
rectangle, level and feature type;
R-2. via the coordinates for application-specified Cartographic Features;
R-3. via attributes for Cartographic Features, such as: feature type, name, and functional
classification;
R-4. via the complete or partial Cartographic Features associated with application-specified
Transportation Elements;
R-5. via the area (size) of an application-specified Area Feature;
R-6. via the ability to retrieve additional information for Point, Line and Area Features which are
associated with Cartographic Features which may have been selected from the displayed map;
R-7. via the Cartographic Text associated with a Cartographic Feature;
R-8. via the Symbol associated with a Cartographic Feature;
R-9. via returning the Cartographic Features and Cartographic Text in “draw-order”. For example, if
water is drawn before bridges, water features should be returned before bridge features.
R-10. When no map data are available for an area requested by a function, the function may
distinguish between the case of “off the map” and the case of “no data at this location at this level”.
6 © ISO 2014 – All rights reserved

ISO/DIS 14296:2014(E)
R-11. The API shall allow a pre-fetch area of interest to be specified by a rectangle and application
specified level for retrieving Map Display data.
R-12. displays a map at the current location of the navigation system;
R-13. displays a marker on the map indicating the navigation system’s current location;
R-14. scrolls the displayed map as the navigation system moves, maintaining the position of the
marker indicating the navigation system’s current location;
R-15. displays a map at any location selected by the end-user. The end-user may specify the location
as an Address, an Intersection, a service, or by cursor position on the display;
R-16. provides latitude and longitude, street address, and other information for a point indicated by
the cursor on the display;
R-17. highlights a route on the display;
R-18. highlights the point on a displayed map of a particular routing manoeuvre.
R-19. Several levels of data are required for cartographic data, corresponding to different map scale
ranges. At the higher levels, the drawing detail for line features and area features is generalized.
R-20. Access is required for data from all GDF Feature Themes, as well as attributes and conditions.
R-21. Map Display data shall be organized into parcels.
R-22. In order to allow easy identification of parcels, parcels shall be rectangular.
R-23. Links crossing parcel boundaries shall be cut at the parcel boundary.
R-24. 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.
6.3.3 Positioning
6.3.3.1 General description
The Positioning function is used to determine vehicle 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. It corrects the geo-localization on
the routes.
6.3.3.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”, with an accuracy depending on the map-matching. Map
Matching algorithms are beyond the scope of this document.
6.3.3.3 Requirements for data model
For the purpose of Positioning, the following functions shall be provided:
R-25. a single set of coordinates for an application-specified Point Feature in the Roads and Ferries
theme;
ISO/DIS 14296:2014(E)
R-26. 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;
R-27. the set of topologically connected Features in the Roads and Ferries Theme connected to an
application specified Feature in the Roads and Ferries theme;
R-28. 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;
R-29. the set of Features, Edges, Nodes and/or Intermediate Points in the Roads and Ferries theme
within an application-specified rectangle;
R-30. Positioning related Attributes, Conditions and Relationships (i.e. Prohibited Manoeuvres,
Direction of Traffic Flow) for an application-specified Feature in the Roads and Ferries theme;
R-31. the entry and exit angles for the set of Transportation Elements connected to an application-
specified Intersection or junction;
R-32. this International Standard 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;
R-33. only one coordinate system can be used in a single piece of storage media;
R-34. when an application tracks progress along the route and provides manoeuvre instructions at
appropriate points to the end-user;
R-35. when an application determines whether the navigation system has left the planned route;
R-36. when an application calculates a route to the requested destination from the navigation
system’s current position;
R-37. when an application scrolls the displayed map;
R-38. when an application selects services by geographic proximity;
R-39. when an application is displaying the navigation system’s position on a map;
R-40. when an application displays a map around a location relative to the navigation system’s
current position;
R-41. Positioning may receive planned route information from the route Planning application for
use in Map Matching.
R-42. Only access to the lowest level of data are required.
R-43. Only access to the data represented in the Roads and Ferries theme is required.
R-44. Positioning data shall be organized into parcels.
R-45. 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.
R-46. 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.
6.3.4 Route Planning
6.3.4.1 General description
The Route Planning function is used to determine routes from one user-specified location to another.
8 © ISO 2014 – All rights reserved

ISO/DIS 14296:2014(E)
6.3.4.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. Route Planning 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.
6.3.4.3 Requirements for data model
The Route Planning application provides the following methods of accessing data that can be used for
routing:
R-47. via the set of topologically connected Links for an application-specified Link at an application-
specified level;
R-48. 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;
R-49. via navigation attributes for roads and intersections;
R-50. via corresponding link for an application-specified link at an application-specified different
level;
R-51. 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;
R-52. via a set of GDF road elements and GDF junctions, which comprise a GDF road or GDF
intersection;
R-53. via the GDF road or GDF intersection for an application-specified GDF road element or GDF
junction;
R-54. 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;
R-55. via effective time or date periods for turn, travel, or other conditions;
R-56. via location references which are stored in the database for an application-specified set of
transportation elements;
R-57. via a set of transportation elements for an application-specified location reference which is
stored in the database;
R-58. via the entry and exit angles for the set of links connected to an application-specified
Intersection or junction;
R-59. via historic and forecast traffic conditions, incidents, and events information for a specified
transportation element or set of transportation elements;
ISO/DIS 14296:2014(E)
R-60. 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;
R-61. 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.
R-62. 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.
R-63. 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.
R-64. the Route Planning application provides information about the planned route to the route
Guidance application for generating driving instructions.
R-65. 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.
R-66. 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.
R-67. 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.
R-68. Only access to the data represented in the roads and ferries theme is required. Enclosed traffic
areas shall be represented by links and nodes.
R-69. 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.
R-70. For Route Planning data, references to parcels on the same level and on the level(s) above and
below are required.
R-71. In order to have optimally filled parcels, parcels may have different coverage sizes.
R-72. 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.
R-73. There is no requirement to create an additional node where a link crosses a parcel boundary.
R-74. 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.
R-75. In order to have fast access to parcels, parcels shall be accessed by their bounding rectangles.
R-76. 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 the nodes or links are found is
outside the scope of this International Standard.
6.3.5 Route Guidance
6.3.5.1 General description
The Route Guidance function is used to generate instructions for following a route.
6.3.5.2 Functional description
The Route Guidance function generates step-by-step instructions for following a route. These instructions
may include compass heading, distance, road names, sign text, landmarks, and still or motion images.
10 © ISO 2014 – All rights reserved

ISO/DIS 14296:2014(E)
These instructions may also include manoeuvre details such as turn angle, merges, and road name
changes. Route Guidance may be given using text, voice or graphics.
6.3.5.3 Requirements for data model
Route Guidance provides the following methods of accessing data used for guidance of a route:
R-77. via guidance-relevant features and relationships related to an application-specified
transportation element, or set of transportation elements, such as: intersecting road elements,
signpost Information, conditions and landmarks along the transportation element;
R-78. via guidance attributes for an application-specified transportation element, or set of
transportation elements, such as: road names, length, direction of traffic flow, and form of way;
R-79. via indicating whether an application-specified junction is a part or all of an Intersection;
R-80. via indicating whether an application-specified link is a regular link, a super link or part of a
super link;
R-81. via connected transportation elements for an application-specified junction;
R-82. via connected transportation elements for an application-specified Intersection which are not
part of that Intersection, such as the set of road elements connected to a roundabout;
R-83. via component transportation elements of an application-specified Intersection, such as the
set of road elements and junctions which make up a roundabout;
R-84. via data about the transition from an application-specified link to an application-specified
series of connected links, such as: the existence of a tollbooth or gate;
R-85. via node and intermediate point positions for line features to support displaying manoeuvre
“arrows” for Route Guidance;
R-86. via cartographic data for the line features comprising an Intersection for the derivation of
intersection schematics;
R-87. via entry and exit angles for the set of transportation elements connected to an application-
specified intersection or junction;
R-88. via phonetic strings in an application-specified language for pronunciation of any named
entity in the database;
R-89. via phonetic strings in an application-specified language for commonly used guidance words;
R-90. via digitized pronunciation data in an application-specified language for commonly used
guidance words;
R-91. via API allowing a prefect area of interest specified by a rectangle for retrieving Route Guidance
data;
R-92. via image data for optional picture guidance.
R-93. provides guidance while the navigation system is in motion, based on a calculated route and
map matching;
R-94. tracks progress along the route and provide manoeuvre instructions at appropriate points to
the end-user.
R-95. Route Guidance data shall be organized into parcels.
R-96. In order to allow fast access to parcels, parcels shall be accessed by their bounding rectangles.
R-97. In order to have optimally filled parcels, parcels may have different coverage area sizes.
ISO/DIS 14296:2014(E)
6.3.6 Service and POI Information Access
6.3.6.1 General description
The Service and Points-of-Interest (POI) Information Access function provides access to data which are
commonly used as origins or destinations for a route and which contain information useful to travellers.
Services are single point or area locations that are typically known by name rather than address.
Services include traveller-related commercial services such as hotels, restaurants, and gas stations.
Services also include locations or points of interest to travellers, such as national parks, monuments,
and tourist attractions. Services can be categorized by type (e.g. airport, city centre, and hotel) and may
carry a variety of other attribute information (e.g. rating, cuisine type, credit cards accepted).
Typically, third party organizations, such as tourist or motoring organizations, can offer a rich content
of traveller information which may be of interest to the user. This type of service information is called
Third Party Data (TPD). The amount of service information supplied by Third Parties may vary and may
consist of comprehensive service data, including locational aspects and a linkage to the road network.
Some TPD may originate from a party which has imposed proprietary restrictions on the use of the data.
This is a subset referred to as Branded Third Party Data (BTPD) which imposes additional requirements.
6.3.6.2 Functional description
An application may provide service data to the end-user. Also, an application may allow the use of
services in Address Location, Route Planning, and Map Display. An application may provide information
about services, including Third Party Data. The services may be selectable by types, geographic areas
(e.g. within a rectangle or within distance of a point), places (e.g. Administrative areas, Districts, Postal
areas), service attributes, or whether the service is associated with Third Party Data. Services may
be associated with Road Elements or other components of the Transportation Network based on their
location. This provides a location on a Road Element which gives access to a service.
Additionally, searches for services may be qualified by an application-specified partial or full spelling
match to the beginning of the service type, attribute, name, or to any individual word within the type,
attribute or name.
Services may be associated with each other. A primary service is called a parent. A parent service
may have many secondary services called child services. A child service may also have many parent
services. One example of how this relationship is used is in the definition of an airport service that has
multiple parking lots. In this case, the airport is designated as the parent service and the parking lots
are designated as children of that parent.
A Service may be associated with multiple places. For example, the Dallas/Fort Worth Airport is
physically located in Arlington and Grapevine. It is also logically associated with Dallas and Fort Worth.
Service and POI Information Access shall support different entry orders by means of appropriate data
structures. Typically, a hierarchical top-down entry order may be used. However, permutations thereof
shall also be supported, e.g. POI brand name first.
Service and POI Information Access shall support extensions to the search criteria when no match is
found. The user may demand an expanded search area, i.e. areas close to the specified place(s) or spelling
tolerance for similarly pronounced/written names.
6.3.6.3 Requirements for data model
Service data may be accessed by the following methods:
R-98. via service attribute data for an application-specified service (to the extent they exist in the
database) for example: name, address, phone number, chain, facility type, and days and times the
service is open;
R-99. via the coordinates of an application-specified service;
12 © ISO 2014 – All rights reserved

ISO/DIS 14296:2014(E)
R-100. via the related Road Elements and position along the Road Elements for the entry to an
application-specified service;
R-101. via the related services of an application
...