ISO/TS 22726-1:2023
(Main)Intelligent transport systems — Dynamic data and map database specification for connected and automated driving system applications — Part 1: Architecture and logical data model for harmonization of static map data
Intelligent transport systems — Dynamic data and map database specification for connected and automated driving system applications — Part 1: Architecture and logical data model for harmonization of static map data
Systèmes de transport intelligents — Spécification de données dynamiques et de bases de données cartographiques pour les applications de système de conduite connectées et automatisées — Partie 1: Architecture et modèle logique de données pour l'harmonisation des données cartographiques statiques
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 22726-1
First edition
2023-06
Intelligent transport systems —
Dynamic data and map database
specification for connected
and automated driving system
applications —
Part 1:
Architecture and logical data model
for harmonization of static map data
Systèmes de transport intelligents — Spécification de données
dynamiques et de bases de données cartographiques pour les
applications de système de conduite connectées et automatisées —
Partie 1: Architecture et modèle logique de données pour
l'harmonisation des données cartographiques statiques
Reference number
© ISO 2023
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms and symbols .3
5 Document structure and conformance . 4
5.1 Document structure . 4
5.2 Conformance . 4
6 Architecture. 4
7 Logical data model of map data . 5
7.1 Overall data model of map data. 5
7.2 Transportation package . 6
7.3 MHAD package . 7
7.3.1 General . 7
7.3.2 RoadBeltNetwork package . 11
7.3.3 LaneBeltNetwork package . 45
7.3.4 RoadStructureAndEquipment package . 62
7.3.5 CommonPropertyClasses package .128
7.4 Relationship to dynamic information .137
7.4.1 General .137
7.4.2 RoadNetworkElement .137
Annex A (normative) Abstract test suite . 138
Annex B (informative) Basic data types and stereotypes — concepts and definitions . 139
Annex C (informative) Resolution and accuracy of the MHAD .141
Annex D (informative) Comparison of the road network models of MHAD and existing map
models . 143
Bibliography . 146
iii
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 of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems.
A list of all parts in the ISO 22726 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
Introduction
In response to emerging automated driving system (ADS) development, a new requirement for an
intelligent transport system (ITS) map database standard has been raised to define a set of models for
highly confident map data.
The data used in ADS are categorized into static data (i.e. map for highly automated driving (MHAD) and
traditional map data) and dynamic data (e.g. traffic and travel information). These data are mutually
related and linked to support ADS. The data model for ADS should have a structure specialized for
automated driving and be presented in a manner useable for ADS.
In the case of static map data used by ITS, ISO 14296 specifies a logical data model applied to vehicle
navigation systems and cooperative ITS (C-ITS). The data model of ISO 14296 is insufficient for ADS
because of limitations to represent detailed or accurate carriageway and road-related features. In
addition, new relationships between new map features and dynamic data are defined.
Even though GDF 5.1 (ISO 20524-2) defines map data used in ADS such as road belts or lane belts as
detailed road map data, it focuses on a data model for exchanging and provisioning map data between
map makers and data centres. The GDF model, which is based on three catalogues (Feature, Attribute,
and Relationship), is inefficient not only for storing ITS map data in a database, but also for being able
to access that data rapidly in vehicles. Therefore, this document defines a database standard to quickly
and directly access detailed road map entities and their related information.
Implementation of this document can potentially lead to cost reductions in maintenance and expansion
of map access libraries, as well as reductions in compilation and maintenance costs of map and map-
related data for data providers for connected and automated driving, and vehicle control applications.
v
TECHNICAL SPECIFICATION ISO/TS 22726-1:2023(E)
Intelligent transport systems — Dynamic data and map
database specification for connected and automated
driving system applications —
Part 1:
Architecture and logical data model for harmonization of
static map data
1 Scope
This document specifies the architecture and the logical data model of static map data for connected
and automated driving system applications.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 19501, Information technology — Open Distributed Processing — Unified Modeling Language
(UML) Version 1.4.2
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
belt
configuration concept for specifying an area bounded by side lines and terminal lines, characterized by
directions and represented as one or more linear axes when skeletonized
Note 1 to entry: The number of skeletonized axes differs depending on the feature class. In the case of a belt
applied to a one-way lane, the number is one. When applied to an intersection, the belt has axes corresponding to
the number of unique allowable traffic directions.
[SOURCE: ISO 20524-2:2020, 3.2]
3.2
direction
signature of belt, determined by an allowed connection between a pair of terminal lines
[SOURCE: ISO 20524-2:2020, 3.3]
3.3
belt feature
two-dimensional Feature bounded by three or more Edges or four or more NET coordinate Tuple
[SOURCE: ISO 20524-2:2020, 3.1.]
3.4
feature
database representation of a real-world object
[SOURCE: ISO 20524-1:2020, 3.4.9]
3.5
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
[SOURCE: ISO/TS 20452:2007, 3.19]
3.6
node
data model entity for a topological junction of two or more links or end bounding a link
Note 1 to entry: A link stores the coordinate value of the corresponding GDF junction.
[SOURCE: ISO/TS 20452:2007, 3.23]
3.7
partition line
transversal line representing the boundary of a segment set to a road belt element and a lane belt
element, and both terminations are set on the side line of road belt element or lane belt element
3.8
probe data
vehicle sensor information formatted as probe data elements and/or probe messages that are processed,
formatted and transmitted to a land-based centre for processing to create a good understanding of the
driving environment
[SOURCE: ISO 24100:2010, 3.14]
3.9
road feature
feature, specified by a belt, that represents an area for vehicle travel
EXAMPLE Carriageways, intersections and lanes are examples of road features.
Note 1 to entry: This is a general term for the roadway, carriageways, intersections and lanes, and does not
contain the sidewalks and paths for pedestrians.
3.10
side line
type of boundary line constituting a belt feature other than a terminal line
[SOURCE: ISO 20524-2:2020, 3.4, modified — The admitted term "side line" has been added.]
3.11
terminal line
type of boundary line constituting a belt feature and designated for determining a direction of a belt
feature in combination with another terminal line
[SOURCE: ISO 20524-2:2020, 3.5]
4 Abbreviated terms and symbols
ADS automated driving system
C-ITS cooperative ITS
CMS changeable message sign
GNSS Global Navigation Satellite System
IAP IntersectionAnchorPosition
IB IntersectionBelt
IBSd IntersectionBeltSideLine
IBTr IntersectionBeltTerminalLine
ICP IntersectionConnectionPoint
ITS intelligent transport system
LAP lane anchor position
LBE LaneBeltElement
LBJ LaneBeltJoint
LBSd LaneBeltSideLine
LBSg LaneBeltSegment
LBSSg LaneBeltSideLineSegment
LBTr LaneBeltTerminalLine
LCP LaneConnectionPoint
MHAD map for highly automated driving
POI point of interest
RAP RoadAnchorPosition
RBE RoadBeltElement
RBS RoadBeltSection
RBSg RoadBeltSegment
RBSd RoadBeltSideLine
RBSSg RoadBeltSideLineSegment
RBTr RoadBeltTerminalLine
RSE RoadStructuresAndEquipment
RTK-GPS real time kinematics - global positioning system
VMS variable message sign
5 Document structure and conformance
5.1 Document structure
This document contains the following main clauses, subclauses and annexes:
— Conformance (5.2)
— Architecture (Clause 6)
— Logical data model of map data (Clause 7)
— Overall data model of map data (7.1)
— Transportation package (7.2)
— MHAD package (7.3)
— Relationship to dynamic information (7.4)
— Annex A (normative) Abstract test suite
— Annex B (normative) Basic data types and stereotypes
— Annex C (informative) Resolution and accuracy of the MHAD
— Annex D (informative) Comparison of the road network models of MHAD and existing map models
5.2 Conformance
Data model structures shall be provided as specified in Clause 7.
Any data structure claiming conformance with this document shall pass the requirements presented in
the abstract test suite in Annex A.
UML expressions for diagrams in this document shall conform to ISO/IEC 19501.
Throughout this document, the data types and stereotypes as defined in Table B.1 apply.
6 Architecture
Automated driving systems (ADSs) and their applications can refer to both static map data and dynamic
information data. In addition, ITS stations in automated driving vehicles, connected vehicles and road
equipment can collect sensing data, such as contradictions between the static map and features of the
real world, traffic data, and travel information, and distribute them as probe data.
Figure 1 depicts the conceptual system architecture of map data in an ITS station for an ADS.
In ITS vehicle stations that correspond to ADSs, the application uses map data (MHAD) and additional
dynamic data. The original data, along with updates of the MHAD data and dynamic data, are intended
to be provided through external transmitted messages received from outside of the station. Automated
driving applications also use data collected from both in-vehicle and roadside mounted sensors and can
also use conventional map data which complements the applications to which the navigation system
and/or C-ITS refer.
Figure 1 — Conceptual system architecture
7 Logical data model of map data
7.1 Overall data model of map data
The overall map data model for ITS is adopted from the model defined in ISO 14296 which consists of
the following packages:
— AddressLocation: location information based on various types of information both on the Earth and
in the map data;
— Cartographic: terrain map information for expressing a visual map;
— Service&POI: information of the services and POI that exist in a fixed location;
— Transportation: information concerning fixed features for transportation; and
— DynamicInformation: external information in association with transportation data for providing
real-time conditions and/or status.
To support ADS, both the Transportation and DynamicInformation packages are expanded.
1)
The DynamicInformation package is specified in ISO/TS 22726-2:—.
The overall map data model is shown in Figure 2.
1) Under preparation. Stage at the time of publication ISO/AWI TS 22726-2:2023.
Key
A ISO/TS 22726-1 (this document)
B ISO/TS 22726-2
Figure 2 — Overall map data model
7.2 Transportation package
Following the addition of the MHAD package to the Transportation package, the updated package
consists of the following:
— MHAD: data for road belt network, lane belt network, and road structures and equipment for
connected and automated driving systems;
— TransferZoneNetwork: information concerning place and connected network for transferring with
the transport network;
— RoadNetwork: static road data using linear network modelling;
— PublicTransportationNetwork: static network data for the public transportation system;
— BicyclePathNetwork: static path network data for bicycle movement; and
— PedestrianPathNetwork: static path network data for pedestrian movement.
The overview of the Transportation package is shown in Figure 3.
The TransferZoneNetwork package and the RoadNetwork package are defined in ISO 14296.
The RoadNetwork package contains features represented by links and nodes, in multiple levels
corresponding to the concept of different map scales. The features in the MHAD package can be related
to road features such as RoadElement, Intersection, IntersectionLink, IntersectionConnectionPoint and
Lane in the RoadNetwork package and are described in Clause D.2.
This document only defines the specifications of features in the MHAD package.
Key
A ISO/TS 22726-1 (this document)
B ISO 14296
C other standards
Figure 3 — Transportation package
7.3 MHAD package
7.3.1 General
7.3.1.1 Configuration of MHAD package
A connected and/or automated driving system requires the road belt network data, the lane belt
network data and the road structures and equipment data related to road features. The MHAD
represents the data model for a static map of the road and consists of the following packages:
— RoadBeltNetwork package — defines belt features and relevant features which compose road-level
networks;
— LaneBeltNetwork package — defines belt features and relevant features which compose lane-level
networks;
— RoadStructureAndEquipment package — defines road structures and road equipment which are
related to road-level and/or lane-level networks;
— CommonPropertyClasses package — defines the data classes commonly used in multiple sub-
packages belonging to the MHAD package.
Figure 4 shows the package configuration of the MHAD package.
The MHAD package contains an MHAD class which is defined as the root class for the entire package.
Figure 4 — MHAD package diagram
Figure 5 shows the classes and relationships for expressing the hierarchical model of the MHAD
package.
Figure 5 — Class diagram of MHAD package
7.3.1.2 Belt concept for roadway, intersection and lane
Roadways and intersections are expressed by lines and points in conventional road network data
models. However, emerging ITS applications (e.g. lane keeping for C-ITS and automated driving systems)
require highly defined information that enables the vehicle to identify where it is driving in a lane, and
in which lane it is allowed to drive in order to overtake other vehicles.
To provide such information, road features, such as the roadway, intersections and lanes need to be
expressed by specific area features which have characteristics implying directions and/or trajectories
of moving vehicles. An instance of this specific area feature is transformed into a directed line that
corresponds to a possible directed trajectory of regular vehicle movement when it is degenerated by
means of a mathematical morphology transformation.
A conventional data model enables a vehicle to identify in which road and/or lane it is driving. However,
an area feature in the conventional data model merely expresses a space for free motion and does not
imply any specific directions. Thus, the area feature in the conventional data model does not meet the
requirements of emerging ITS applications.
The "belt concept" and belt features specified in ISO 20524-2 meet the recommendation that roads,
intersections and lanes should be represented by a specific area feature with the directions defined as
their characteristics. As illustrated in Figure 6, a belt feature is a specific area feature which is bounded
by a combination of side lines and terminal lines.
In the case of a road [Figure 6 a)], a belt has at least one directional characteristic, the “direction”.
Additionally, the belt can have other characteristics which include the widths of the belt that are
calculated as the distance between a pair of side lines for that belt. The value width should be associated
with a measure on the degenerated line representing the belt feature.
The terminal lines define the characteristics of the belt direction. In the case of an intersection
[Figure 6 b)], a belt has at least two directional characteristics. Widths of a belt are calculated as the
distance between a pair of side lines which determine both sides of the belt except in an intersection.
In the belt data model, terminal lines are conceptually represented and assumed to function as
"directional control valves" at both ends of a flow. Side lines are also conceptually represented and can
refer to real road-related objects (e.g. lane markings, flow-markings, kerbs, guardrails, etc.).
a) Road b) Intersection
Key
1 terminal line 3 direction
2 side line 4 belt
Figure 6 — Example of belt structure
In the MHAD package, road features are instantiated as features in a RoadBeltNetwork package and a
LaneBeltNetwork package.
7.3.1.3 Relationship between road feature and road structures and equipment feature
In the real world, there are various features located at or along roads such as road markings, traffic
signals, kerbs, manholes, fences, walls, guardrails and poles. These features are referred to as road
structures or road equipment and are instantiated as features in the RoadStructureAndEquipment
package in MHAD.
As road structures and road equipment are located at or along a road, they can have relationships
with road features such as those defined by the RoadBeltNetwork package and the LaneBeltNetwork
package. When road structures and road equipment are interrelated, it is necessary to define the
specific location on the road feature that relates to the corresponding part of the road structures and
road equipment.
EXAMPLE The outline of a kerb represents the boundary of the kerb itself and at the same time represents a
part of a side line of the road feature where that kerb is located.
In the MHAD data model, road features have anchor positions that are used to associate road structures
or pieces of road equipment to the road and indicate the position where the road structures and/or
road equipment is anchored to the road feature.
A projection point is a point positioned on the geometry of the road structures and road equipment
and associated to the anchor position. A projection line is an outline of the road structures or road
equipment, partly specified by a pair of projection points. Both the projection point and project line
of road structures or road equipment are designed to include traffic restrictions due to the physical
properties of the road structures and road equipment, and they can be used as reference positions for
positioning functions. Anchor positions are defined as RoadAnchorPosition, IntersectionAnchorPosition
and LaneAnchorPosition in either a RoadBeltNetwork or LaneBeltNetwork package.
Figure 7 shows examples of the relationship of anchor positions and projection points between a
RoadBeltElement and a bridge and a guardrail.
Key
1 RoadBeltElement
2 anchor position
3 projection position
4 bridge
5 guardrail
Figure 7 — Example of relationship between a road belt element and a bridge and a guardrail
7.3.1.4 MHAD class
The MHAD class is the root class of the MHAD package and has three composition relationships.
Table 1 defines the details of the MHAD class.
Table 1 — MHAD class
Class<>: MHAD
Dataset representing the static road network map which consists of the datasets of
Definition
the road belt network, the lane belt network, and the road structures and equipment.
Definition
Role/Attribute name
Value type Multiplicity Stereotypes Note/Constraint
Specifies road belt network data.
role: RoadBeltNetwork
RoadBeltNetwork [0.*] Composition relationship
Specifies lane belt network data.
role: LaneBeltNetwork
LaneBeltNetwork [0.*] Composition relationship
Specifies road structures and equipment data.
role: RoadStructureAnd-
RoadStructureAndE-
Equipment
[0.*] Composition relationship
quipment
7.3.2 RoadBeltNetwork package
7.3.2.1 General
7.3.2.1.1 Configuration of RoadBeltNetwork package
The RoadBeltNetwork package defines the road features of carriageways and intersections represented
by the belt concept.
The RoadBeltNetwork package consists of:
— RoadBeltNetwork,
— RoadBeltElement,
— RoadBeltElementLink,
— RoadBeltSideLine,
— RoadBeltSideLineSegment,
— RoadBeltTerminalLine,
— RoadBeltSegment,
— RoadAnchorPosition,
— IntersectionBelt,
— IntersectionBeltLink,
— IntersectionSideLine,
— IntersectionTerminalLine,
— IntersectionConnectionPoint,
— IntersectionAnchorPosition,
— RoadBeltSection, and
— LaneBlock.
Figure 8 shows the classes and relationships of road features in the RoadBeltNetwork package (see
https:// standards .iso .org/ iso/ ts/ 22726/ -1/ ed -1/ en for an enlarged version of this figure).
Additionally, the RoadBeltNetwork package contains a RoadBeltFeatureProperty package which
defines the properties used in the road feature belonging to the RoadBeltNetwork.
Figure 8 — RoadBeltNetwork package
7.3.2.1.2 Modelling policy of RoadBeltNetwork
A RoadBeltNetwork is a class and is specified as the root class of the RoadBeltNetwork package,
supporting a hierarchical model. A RoadBeltNetwork class has composition relationships to:
— IntersectionBelt,
— RoadBeltElement, and
— RoadBeltSection.
The network of RoadBeltNetwork consists of the IntersectionBelts, RoadBeltElements and relationships
between IntersectionBelt and RoadBeltElement. It is also a networking concept in ISO 20524-2.
Additionally, RoadBeltElement has composition relationships to:
— RoadBeltSideLine,
— RoadBeltTerminalLine,
— RoadBeltSegment,
— RoadBeltElementLink,
— LaneBlock, and
— RoadAnchorPosition.
An IntersectionBelt has composition relationships to:
— IntersectionBeltSideLine,
— IntersectionBeltTerminalLine,
— IntersectionBeltLink,
— LaneBlock, and
— IntersectionAnchorPosition.
The composition relationships listed above accommodate the requirements of ADS applications which
are enabled to easily and quickly access properties of the road feature side lines and links as the vehicle
moves.
Figure 9 shows the configurations of RoadBeltElement and IntersectionBelt.
A RoadBeltElement consists of two RoadBeltSideLines, two RoadBeltTerminalLines and a
RoadBeltElementLink. The physical domain of a RoadBeltElement is defined by property data of
RoadBeltSideLines and RoadBeltTerminalLines.
A RoadBeltElementLink is a feature that corresponds to the geometry data of a RoadBeltElement when
it is degenerated by means of mathematical morphology transformations.
The first RoadBeltSideLine represents the right-side line with reference to the forward direction of
RoadBeltElement while the second RoadBeltSideLine represents the left side line. The direction of the
RoadBeltElement is determined by a pair of RoadBeltTerminalLines. The first RoadBeltTerminalLine
represents the origin of the forward direction of RoadBeltElement and the second RoadBeltTerminalLine
represents the destination.
The starting point of a RoadBeltElementLink is referred to as "the first point" and is located on the first
RoadBeltTerminalLine and the ending point of each RoadBeltElementLine is referred to as "the second
point" and is located on the second RoadBeltTerminalLine.
RoadBeltElements and IntersectionBelts are connected by their respective TerminalLines. A
RoadBeltElement should be connected to a pair of IntersectionBelts, but a RoadBeltElement connected
to the same IntersectionBelt, i.e., a circular RoadBeltElement, shall not be permitted.
An IntersectionBelt is distinguished as either a basic belt type or thin belt type according to the area
of an intersection. A configuration example of a thin belt type IntersectionBelt is shown in Figure 9 d).
An IntersectionBelt that is connected to the first RoadBeltTerminalLine of a RoadBeltElement is referred
to as the first IntersectionBelt for that RoadBeltElement. When another IntersectionBelt connected the
RoadBeltElement is referred to as the second IntersectionBelt for that RoadBeltElement. The forward
direction of a RoadBeltElement is specified as the direction from the first RoadBeltTerminalLine
moving toward the second RoadBeltTerminalLine.
The traffic direction in the real world can be defined with reference to the direction of the
RoadBeltElement. The traffic flow direction identified by key element “1”, illustrated in Figure 9 a),
is opposite to the belt direction. The traffic flow direction identified by key element “2” is the same
direction as the belt direction.
a) RoadBeltElement b) IntrsectionBelt (basic type) with Intersec-
tionConnectionPoints defined inside Intersec-
tionBelt
c) IntersectionBelt (basic type) without Inter- d) IntersectionBelt (thin type)
sectionConnectionPoints defined inside Inter-
sectionBelt
Key
1 - 5 traffic flow direction
Figure 9 — RoadBeltElement and IntersectionBelt with relevant features defined in
RoadBeltNetwork package
IntersectionBeltSideLines and IntersectionBeltTerminalLines are connected in a counterclockwise
chain and can be specified by the sequence number.
An IntersectionBeltLink is a feature that represents a linear representation generated by the
degeneration of the Intersection Belt and is equivalent to a link in a linear network model. The
degeneration is carried out by means of a mathematical morphology transformation.
An IntersectionConnectionPoint can be defined inside an IntersectionBelt. Figure 9 b) and Figure 9 c)
illustrate examples of two distinct definitions of an IntersectionBeltLink depending on whether or not
the IntersectionConnectionPoints are defined inside the IntersectionBelt.
The traffic direction inside an IntersectionBelt can be defined by the traffic flow direction (entering/
exiting) with reference to the RoadBeltElementLink located on the IntersectionConnectionPoint on the
terminal lines of the IntersectionBelt. The traffic flow direction identified by key element “3”, illustrated
in Figure 9 b) and Figure 9 c), is entering into the IntersectionBelt. The traffic flow direction identified
by key element “4” is exiting from the IntersectionBelt. The traffic flow direction identified by key “5” is
bidirectional, meaning both entering and exiting flows to the IntersectionBelt.
In implementations of ADS applications, the traffic flow direction of the carriageway should be
specified with reference to the direction of the RoadBeltElement. Figure 10 describes an example of the
configuration of the traffic flow direction and the direction of RoadBeltElement.
In a one-way road, illustrated in Figure 10 a), when the traffic flow direction is in the same direction as
the RoadBeltElement, it should be referred to as "forward direction".
Conversely traffic flow direction opposite to the direction of the RoadBeltElement should be referred to
as "reverse direction".
NOTE 1 Specifically, the traffic flow direction identified by key element “1” illustrated in Figure 10 a) is
defined as the forward direction, key element “A ” with reference to the direction of key element “A”. The traffic
direction key element “1” is specified as the reverse direction, key element “B ” with reference to the direction of
key element “B”.
In a two-way road illustrated in Figure 10 b), the traffic flow direction should be referred to as
bidirectional. Each traffic flow direction is identifiable with reference to the direction of the
RoadBeltElement.
NOTE 2 Specifically, the traffic flow direction in a two-way carriageway, identified by both key element “1”and
key element “2”, Figure 10 b), is specified as bidirectional (key element "C "). The traffic flow direction identified
by key element “1” or key element “2” is identifiable as the forward or reverse direction with reference to the
direction of key “C”.
a) One-way road b) Two-way road
Key
1 and 2 traffic flow direction in the real world
A, B and C RoadBeltElement
A , B , and C description of the traffic flow direction specified with reference to the direction of Road-
1 1 12
BeltElement
Figure 10 — Relation between the traffic flow direction and the direction of RoadBeltElement
When existing on the same vertical level, an IntersectionBelt should not overlap any IntersectionBelts
and any RoadBeltElements. A RoadBeltElement can overlap with adjacent RoadBeltElements for
branching or merging.
7.3.2.2 RoadBeltNetwork
RoadBeltNetwork class is a class that may be instantiated and represents a branch class having only
three composition relationships and used for expressing the hierarchical model.
Table 2 defines the details of the RoadBeltNetwork class.
Table 2 — RoadBeltNetwork class
Class<>: RoadBeltNetwork
Dataset representing the road network which consists of the datasets of the road
Definition
belt element, intersection belt and road belt section.
Definition
Role/Attribute name
Value type Multiplicity Stereotypes Note/Constraint
Specifies data in a road belt element belonging to the road belt network.
role: RoadBeltElement
RoadBeltElement [0.*] Composition relationship
Specifies data in an intersection belt belonging to the road belt network.
role: IntersectionBelt
IntersectionBelt [0.*] Composition relationship
Specifies data in a road belt section belonging to the road belt network.
role: RoadBeltSection
RoadBeltSection [0.*] Composition relationship
7.3.2.3 IntersectionAnchorPosition
IntersectionAnchorPosition is defined on IntersectionBeltSideLines and IntersectionBeltTerminalLines
depending on the position of a projection point of RoadStructureAndEquipment.
Table 3 defines the details of IntersectionAnchorPosition class.
Table 3 — IntersectionAnchorPosition class
Class<>: IntersectionAnchorPosition
Feature that represents the anchor position used to relate road structures and
Definition
road equipment with the intersection belt.
Definition
Role/Attribute name
Value type Multiplicity Stereotypes Note/Constraint
Specifies a road structure or a piece of road equipment data linked with the inter-
section anchor position.
role: RSE
RoadStructureAndE-
[1.*] Association relationship
quipment
Distance from the first point of the intersection belt terminal line or the intersec-
tion belt side line to the intersection anchor position.
distanceToIAP
Length [1]
Coordinates of the intersection anchor position.
coordinateOfIAP
DirectPosition [1]
Anchoring information of the road structure or a piece of road equipment.
anchoringInformation
AnchoringInformation [1.*]
7.3.2.4 IntersectionBelt
IntersectionBelt does not contain geometry data because IntersectionBeltSideLines and
IntersectionBeltTerminalLines contain geometry data.
Table 4 defines the details of the IntersectionBelt class.
Table 4 — IntersectionBelt class
Class<>: IntersectionBelt
Road belt feature which represents the intersecting part of a road where one road is
Definition
split into two or more roads or where roads merge into one road, or a roundabout.
Definition
Role/Attribute name
Value type Multiplicity Stereotypes Note/Constraint
Specifies a road belt element connected to the intersection belt.
role: RBE
RoadBeltElement [1.*] Association relationship
Specifies a road belt section including the intersection belt.
role RBS
RoadBeltSection [0.*] Association relationship
Specifies a lane block located in the intersection belt.
role: LB
Composition relation-
LaneBlock [0.*]
a
ship {ordered}
Specifies an intersection belt link existing in the intersection belt.
role: IBL
IntersectionBeltLink [0.*] Composition relationship
Specifies an intersection belt side line in the intersection belt.
role: IBSd
IntersectionBeltSideLine [0.*] Composition relationship
a
The order of LaneBlock is counted by the sequence of IntersectionBeltTerminalLine for grouping by connected ingress
(or egress) RoadBeltElement.
b
The intersection name can be different for each approach road at the intersection. In such cases, the intersection names
are given in each IntersectionBeltTerminalLine.
TTabablele 4 4 ((ccoonnttiinnueuedd))
Specifies an intersection belt terminal line in the intersection belt.
role: IBTr
IntersectionBeltTreminal-
[0.*] Composition relationship
Line
Specifies an intersection anchor position located in the intersection belt.
role: IAP
IntersectionAnchorPosi-
[0.*] Composition relationship
tion
Type of an intersection.
intersectionType
IntersectionTypeEnum [1]
Class of an intersection based on a national classification.
intersectionNational-
Class
RoadNationalClassList [0.1]
Name of the intersection.
intersectionName
b
CharacterString [0.1]
Central point of the intersection belt.
representativePoint
DirectPosition [0.1]
a
The order of LaneBlock is counted by the sequence of IntersectionBeltTerminalLine for grouping by connected ingress
(or egress) RoadBeltElement.
b
The intersection name can be different for each approach road at the intersection. In such cases, the intersection names
are given in each IntersectionBeltTerminalLine.
7.3.2.5 IntersectionBeltLink
Both ends of an IntersectionBeltLink should be located at the IntersectionConnectionPoint defined on
the IntersectionBeltTerminalLine.
If the IntersectionConnectionPoints are defined within the IntersectionBelt, the IntersectionBeltLink
can be located at these inner IntersectionConnectionPoints.
In the case that an IntersectionBeltLink can be equivalent to an IntersectionLink defined in
RoadNetwork package, an IntersectionBeltLink can be associated with an IntersectionLink.
An IntersectionConnectionPoint located at the starting point of the IntersectionBeltLink is designated
as the first IntersectionConnectionPoint, and an IntersectionConnectionPoint located at the end point
of the IntersectionBeltLink is designated as the second IntersectionConnectionPoint.
Table 5 defines the details of the IntersectionBeltLink class.
Table 5 — IntersectionBeltLink class
Class<>: IntersectionBeltLink
Feature that represents a linear representation generated by the degeneracy of the
Definition
intersection belt equivalent to a link in a linear network model in an intersection.
Definition
Role/Attribute name
Value type Multiplicity Stereotypes Note/Constraint
Specifies the first and the second intersection connection points connected to the
intersection belt link.
role: ICP
IntersectionConnection- Association relationship
[2]
Point {ordered}
Direction of traffic flow of the intersection belt link.
trafficDirection
TrafficDirectionEnum [1]
Length of the intersection belt link shape.
linkLength
Length [0.1]
TTabablele 5 5 ((ccoonnttiinnueuedd))
Estimated travel time for passing through the intersection belt link.
linkTravelTime
TimeMeasure [0.*]
Geometry data of the intersection belt link.
linkShapeData
LineData [1]
7.3.2.6 IntersectionBeltSideLine
IntersectionBeltSideLines and IntersectionBeltTerminalLines are chained in a counterclockwise
direction. Therefore, the start point of an IntersectionBeltSideLine is located at the starting side of the
chain.
Table 6 defines the details of the IntersectionBeltSideLine class.
Table 6 — IntersectionBeltSideLine class
Class<>: IntersectionBeltSideLine
Definition Feature which represents the side line of an intersection belt.
Definition
Role/Attribute name
Value type Multiplicity Stereotypes Note/Constraint
Specifies an intersection anchor position on the int
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...