ISO/TS 22726-1:2025

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

This document specifies the architecture and the logical data model of static map data for connected and automated driving system applications.

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

• Status: Published
• Publication Date: 06-Nov-2025
• ICS: 03.220.20 - Road transport
• ICS: 35.240.60 - IT applications in transport
• Technical Committee: ISO/TC 204 - Intelligent transport systems
• Drafting Committee: ISO/TC 204/WG 3 - ITS geographic data
• Current Stage: 6060 - International Standard published
• Start Date: 07-Nov-2025
• Due Date: 31-Oct-2026
• Completion Date: 07-Nov-2025

Relations

• Revises: ISO/TS 22726-1:2023 - 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
• Effective Date: 04-Nov-2023

Overview

ISO/TS 22726-1:2025 - "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" - defines the architecture and logical data model for static (non-dynamic) map data tailored to connected and automated driving (CAD) applications. The Technical Specification provides a harmonized information model to support consistent representation, exchange and conformance testing of high‑precision static map content used by AD stacks, simulation and ITS services.

Key topics and technical requirements

• Architecture: overall structural framework and conformance rules for map databases intended for CAD applications.
• Logical data model: comprehensive schema describing map features, relationships and properties for static map elements.
• MHAD package: core package defining configuration, classes and the conceptual modelling used throughout the standard.
• Belt concept: modeling lanes, roadways and intersections using a "belt" abstraction to represent traversable areas and manoeuvre paths.
• RoadBeltNetwork & LaneBeltNetwork: network-level and lane-level models for manoeuvre paths, segments and properties supporting routing and manoeuvre planning.
• RoadStructureAndEquipment: modelling road furniture, markings, structures and equipment with position/geometry policies.
• Traffic regulation modeling: rules, time and vehicle conditions to represent legal and operational traffic attributes.
• Relations to dynamic information: guidance on linking static map definitions to dynamic (real‑time) data.
• Conformance and testability: includes an Annex A abstract test suite and informative annexes on data types, resolution/accuracy and model comparisons to help implementers validate conformance.

Applications

ISO/TS 22726-1:2025 is intended to be used where accurate, harmonized static map data is required for:

• Connected & automated driving systems (localization, path planning, AD perception augmentation).
• HD map production and exchange between map providers, OEMs and Tier‑1 suppliers.
• Simulation and virtual testing of automated driving scenarios.
• Infrastructure and ITS services that integrate map-based rules and traffic regulation data.
• Map validation and certification workflows using the provided abstract test suite.

Who should use this standard

• Map data vendors and HD map engineers
• Automotive OEMs and software integrators working on ADS/CAD stacks
• Tier‑1 suppliers and ADAS developers
• ITS platform providers, municipalities and road authorities involved in digital infrastructure
• Test labs and certification bodies verifying map conformance and interoperability

Related standards

This Technical Specification complements other ITS and HD‑map specifications and industry map models by providing a harmonized, implementation‑focused logical model for static map content and conformance testing. Implementers should consider it alongside regional ITS standards and existing industry map formats when planning interoperability and data exchange.

Standards Content (Sample)

Technical
Specification
ISO/TS 22726-1
Second edition
Intelligent transport systems —
2025-11
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 2025
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vii
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
8 MHAD package . 7
8.1 Configuration of MHAD package .7
8.2 Belt concept for roadway, intersection and lane .10
8.3 Relationship between road feature and road structures and equipment feature .11
8.4 MHAD class .11
9 MHADCommonProperty package .12
9.1 General . 12
9.2 GeneralCommonProperty package . 13
9.2.1 General . 13
9.2.2 Class definitions .14
9.3 CommonPhysicalCharacteristics package . 20
9.3.1 General . 20
9.3.2 Class definitions . 22
9.4 TrafficRegulation package . 36
9.4.1 Modelling policy of Traffic regulations . 36
9.4.2 General description .37
9.4.3 TrafficRegulation(Main) sub-package . 38
9.4.4 TimeCondition sub-package. 48
9.4.5 VehicleCondition sub-package .59
10 RoadBeltNetwork package .81
10.1 General . 81
10.2 RoadBeltNetworkFeature sub-package . 81
10.2.1 General . 81
10.2.2 Modelling policy of RoadBeltNetwork . 84
10.2.3 Modelling policy of Manoeuvre Path . 87
10.2.4 Class definitions . 88
10.3 RoadBeltFeatureProperty sub-package .114
10.3.1 General .114
10.3.2 Class definitions .116
10.4 RoadBeltSegmentProperty sub-package . 123
10.4.1 General . 123
10.4.2 Class definitions . 124
11 LaneBeltNetwork package .137
11.1 General . 137
11.2 LaneBeltNetworkFeature sub-package . 138
11.2.1 General .138
11.2.2 Modelling policy of the LaneBeltNetwork . 140

iii
11.2.3 Modelling policy of Manoeuvre Lane Path .141
11.2.4 Class definitions .142
11.3 LaneBeltFeatureProperty sub-package classes . 160
11.3.1 General . 160
11.3.2 Class definitions . 160
11.4 LaneBeltSegmentProperty sub-package . 164
11.4.1 General . 164
11.4.2 Class definitions . 166
12 RoadStructureAndEquipment package . .171
12.1 General description .171
12.1.1 Configuration of RoadStructureAndEquipment package .171
12.1.2 Position and geometry policy for the road structures and pieces of road
equipment features . 172
12.1.3 RoadStructureAndEquipment class . 173
12.2 RoadEquipment sub-package . 175
12.2.1 General description . . 175
12.2.2 RoadEquipmentFeature sub-package . 175
12.2.3 RoadEquipmentProperty sub-package . 201
12.3 RoadMarking sub-package .208
12.3.1 General description . .208
12.3.2 RoadMarkingFeature sub-package .208
12.3.3 RoadMarkingProperty sub-package . 221
12.4 RoadStructure sub-package . 229
12.4.1 General description . . 229
12.4.2 RoadStructureFeature sub-package . 229
12.4.3 RoadStructureProperty sub-package . 250
12.5 RSECommonProperty package . 255
12.5.1 General description . . 255
12.5.2 Class definitions . 256
13 Relation between the MHAD and the dynamic information .261
Annex A (normative) Abstract test suite .262
Annex B (informative) Basic data types and stereotypes — concepts and definitions . 263
Annex C (informative) Resolution and accuracy of the MHAD .265
Annex D (informative) Comparison of the road network models of MHAD and existing map
models . 266
Bibliography .269

iv
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 document 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).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
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.
This second edition cancels and replaces the first edition (ISO/TS 22726-1:2023), which has been technically
revised.
The main changes are as follows:
— addition of a traffic regulation model consisting of traffic regulations, time conditions, and vehicle
conditions;
— addition of traffic regulation attributes in the carriageway and lane data sets;
— addition of "carriageway manoeuvre path" and "lane manoeuvre path" classes in the carriageway and
lane datasets;
— addition of the "crossfall" class as one of the physical characteristics for carriageways and lane data sets;
— integration of both major and minor road structures packages into the road structure sub-package;
— addition of an upper space feature attribute in the carriageway data set;
— addition of properties which define the features in the space under the vehicle bridge or the objects of
the super- or sub-structures;
— addition of a parking lot marking class in the road marking sub-package;
— change of "island nose" to "shock absorption device" class name;
— change of "speed bump" to "traffic calming device" class name;
— change of "bus stop board" to "public transport stop point board" class name;
— change of "inaccessible sloped zone" to "inaccessible zone" class name;
— integration of both "bridge" and "viaduct" into the "vehicle bridge" class;

v
— additional techncial and editorial revisions.
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.

vi
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.

vii
Technical Specification ISO/TS 22726-1:2025(en)
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 terminology 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 addmitted term "side line" has been used as the
preferred term.]
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
MLP manoeuvre lane path
MP manoeuvre path
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 (Clause 8)
— MHADCommonProperty package (Clause 9)
— RoadBeltNetwork package (Clause 10)
— LaneBeltNetwork package (Clause 11)
— RoadBeltStructureAndEquipment package (Clause 12)
— Relationship to dynamic information (Clause 13)
— Annex A (normative) Abstract test suite
— Annex B (informative) 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.

The DynamicInformation package is specified in ISO/TS 22726-2:2025.
The overall map data model is shown in Figure 2.
Key
A ISO/TS 22726-1 (this document)
B Extended package for DynamicInformation defined in 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 — Overview of the Transportation package
8 MHAD package
8.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, and
— CommonPropertyClasses package — defines the data classes commonly used in multiple sub-packages
belonging to the MHAD package.
Figure 4 shows the package diagram 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 the MHAD package

8.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
2 side line
3 direction
4 belt
Figure 6 — Example of belt structure
In the MHAD package, road features are instantiated as features in the RoadBeltNetwork package and the
LaneBeltNetwork package.
8.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 defined 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 part of the outline of the road structures or road
equipment, specified by a pair of projection points. Both the projection point, and project line of road
structures and road equipment are designed to indicate traffic limitations due to the physical characteristics
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.
If a road structure and equipment feature crosses or are set up along continuous roads, the road structure
and equipment feature have intermediate projection points at continuous road boundaries to identify an
anchor position of each road feature.
Figure 7 shows examples of the positional relationships of anchor positions, projection lines, and projection
points between a RoadBeltElement and a bridge and a guardrail.
Key
A RoadBeltElement
B bridge
C guardrail
1 anchor position
2 projection point
3 projection line
Figure 7 — Example of relationship between a road belt element, a bridge, and a guardrail
8.4 MHAD class
The MHAD class is the root class of the MHAD data model and has three composition relationships to the
contained classes.
Table 1 defines the details of the MHAD class.
Table 1 — MHAD class
Class: MHAD
Definition: Dataset representing the static road network map which consists of the datasets of the road belt net-
work, the lane belt network, and the road structures and equipment.
Abstract:
Subtype of:
Stereotypes: «FeatureType»
Relationship role name: laneBeltNetwork
Definition: Specifies lane belt network data sets.
Relationship type: Composition
Value type: LaneBeltNetwork
Multiplicity: 0.*
Stereotypes: «FeatureType»
Relationship role name: roadStructureAndEquipment
Definition: Specifies road structures and equipment data sets.
Relationship type: Composition
Value type: RoadStructuresAndEquipment
Multiplicity: 0.*
Stereotypes: «FeatureType»
Relationship role name: roadBeltNetwork
Definition: Specifies road belt network data sets.
Relationship type: Composition
Value type: RoadBeltNetwork
Multiplicity: 0.*
Stereotypes: «FeatureType»
9 MHADCommonProperty package
9.1 General
The MHADCommonProperty package represents the data packages commonly used in the MHAD data
model, and consists of the following sub-packages:
— GeneralCommonProperty sub-package — defines data classes and their relationships used as general
common data,
— CommonPhysicalCharacteristics sub-package — defines common data classes and their relationships
used as belt segment common data, and
— TrafficRegulation sub-package — defines data classes and their relationships for the traffic regulation
model used as commonly in MHAD.
Figure 8 shows the package diagram of the MHAD CommonProperty package.

Figure 8 — MHAD CommonProperty package
9.2 GeneralCommonProperty package
9.2.1 General
The GeneralCommonProperty package defines common data classes and relationships other than the
RoadPhysicalCharacteristics and TrafficRegulation packages.
Figure 9 shows the class diagram of the GeneralCommonProperty package.

Figure 9 — Class diagram of the GeneralCommonProperty package
9.2.2 Class definitions
9.2.2.1 General
The GeneralCommonProperty package consists of the following classes.
9.2.2.2 AnchoringInformation class
The AnchoringInformation class represents a common property used in an association class between
anchor positions of roads, intersection, or lanes and a roadside feature. Since a related roadside feature may
have some projection points and projection lines, it needs an identifier to specify projection line and point
corresponding to the anchor position.
Table 2 defines the details of AnchoringInformation class.
Table 2 — AnchoringInformation class
Class: AnchoringInformation
Definition: Information about projection point and/or projection line of a roadside feature that is attached to an
association from an anchor position class to a roadside feature class.
Subtype of:
Stereotypes: «DataType»
Attribute: projectionLineSeqNo

TTabablele 2 2 ((ccoonnttiinnueuedd))
A unique sequence number within the road structure or equipment to specify the
Definition:
corresponding projection line.
Value type: Integer
Multiplicity: 0.1
Stereotypes: «PrimitiveType»
Attribute: projectionPointSeqNo
A unique sequence number within the road structure or equipment to specify the
D
...