ISO 17438-2:2024

International
Standard
ISO 17438-2
First edition
Intelligent transport systems —
2024-09
Indoor navigation for personal and
vehicle ITS stations —
Part 2:
Requirements and specification for
indoor maps
Systèmes de transport intelligents — Navigation interne pour
station personnelle et véhicules ITS —
Partie 2: Exigences et spécifications pour les cartes d'intérieure
Reference number
© ISO 2024
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, definitions, symbols and abbreviated terms . 2
3.1 Terms and definitions .2
3.2 Abbreviated terms .4
4 Requirement and conformance. 4
4.1 Requirements .4
4.2 Conformance .4
5 Conventions . 4
6 Indoor map for indoor navigation functionality . 4
6.1 Overview .4
6.2 Scope of indoor maps .5
6.3 Use cases of indoor maps.5
7 Definition of indoor map . 5
Annex A (normative) ASN.1 Schema .25
Bibliography .29

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 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.
A list of all parts in the ISO 17438 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
With the spread of nomadic and mobile devices such as smart phones and the rapid expansion of indoor
spaces, many of the services and facilities related to the transport system have become accessible to indoor
spaces. Consequently, navigation in indoor space is considered a new killer application in the transport
industry.
The objective of this document is to provide a basic data model and encoding format for indoor positioning
reference data required for indoor navigation functionality for ITS applications. This document is intended
to be used by designers, developers and providers of indoor navigation services. When implemented, this
document is intended to:
1) provide developers and designers with concepts and appropriate information to implement indoor
navigation services;
2) provide developers and designers with interoperable ways to use indoor navigation data from various
sources for indoor navigation;
3) enable the provision of indoor navigation services to users;
4) provide developers and designers with an extendable base for indoor navigation.

v
International Standard ISO 17438-2:2024(en)
Intelligent transport systems — Indoor navigation for
personal and vehicle ITS stations —
Part 2:
Requirements and specification for indoor maps
1 Scope
This document defines requirements and specifications of indoor positioning references, which can be
referenced for positioning in indoor space, for supporting indoor navigation functionality of a personal/
vehicle (P/V) ITS station.
NOTE Specific structure and contents of indoor positioning references depend on types of indoor positioning
technologies.
This document defines:
a) the composition of an indoor map for indoor navigation of P/V ITS stations;
b) the schema and encoding format of the indoor map for indoor navigation at the P/V ITS stations.
This document focuses on the specification and format of the indoor map. The following issues which are
adjunctive but essential for commercial navigation services are beyond the scope of this document:
— authorized and authenticated access of users and services, including security;
— payment;
— preparation of indoor data which are necessary for indoor navigation;
— low-level communication protocols required to transfer and share data from and to a roadside ITS station
or a central ITS station;
— other issues dependent on implementation of an instance of indoor navigation.
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 13184-2, Intelligent transport systems (ITS) — Guidance protocol via personal ITS station for advisory
safety systems — Part 2: Road guidance protocol (RGP) requirements and specification
ISO 17438-1, Intelligent transport systems — Indoor navigation for personal and vehicle ITS station — Part 1:
General information and use case definition

3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 13184-2 and ISO 17438-1 and the
following 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.1
nomadic device
ND
implementation of a personal ITS station which provides communication connectivity via portable
equipment such as cellular telephones, wireless communication network (3G, 4G and 5G), mobile wireless
broadband (WIMAX, HC-SDMA, etc.), etc. and includes short range links, such as IEEE 802.11x, etc. to connect
portable devices to the motor vehicle communications system network
Note 1 to entry: In detail, nomadic devices that have hardware security modules and have been certified to be ITS
trusted are called a personal ITS station.
[SOURCE: ISO 23795-2:2024, 3.1.1, modified — Note 1 to entry has been added.]
3.1.2
indoor navigation
navigation provided in indoor space
[SOURCE: ISO 17438-4:2019, 3.1.2]
3.1.3
indoor space
space within artificial structures such as buildings and facilities connected with transport corridors or roads
EXAMPLE A building or indoor parking lot.
[SOURCE: ISO 17438-1:2016, 3.1.2]
3.1.4
ITS station
ITS-S
entity in a communication network, comprised of application, facilities, networking and access layer
components specified in ISO 21217 that operate within a bounded secure management domain
[SOURCE: ISO 13184-2:2016, 3.5]
3.1.5
personal/vehicle ITS station
P/V-ITS-S
ITS station implemented in a vehicle or nomadic device
[SOURCE: ISO 13184-2:2016, modified — "personal mobile device" has been replaced by "nomadic device" in
the definition.]
3.1.6
well-known binary
WKB
binary equivalent used to transfer and store the same information in a more compact form, which is
convenient for computer processing but which is not human-readable

3.1.7
well-known text
WKT
text markup language for representing vector geometry objects
3.1.8
roadside ITS station
R-ITS-S
system that receives and processes vehicular and pedestrian information within a certain zone
Note 1 to entry: The system is installed at the roadside.
[SOURCE: ISO 13184-2:2016, 3.9, modified — "and determines the situation, in order to provide the safety
warning and parking guide service to vehicles and pedestrians" has been removed from the definition.]
3.1.9
central ITS station
central ITS-S
C-ITS-S
implementation of an ITS-S in a central ITS subsystem
[SOURCE: ISO 13184-4:2019, 3.1.6]
3.1.10
indoor positioning
determination of a location in an indoor space
[SOURCE: ISO 17438-4:2019, 3.1.7]
3.1.11
indoor positioning infrastructure
infrastructure used to determine locations of personal/vehicle ITS stations (P/V-ITS-S) in an indoor space
EXAMPLE WiFi, Bluetooth, etc.
[SOURCE: ISO 17438-4:2019, 3.1.11]
3.1.12
indoor positioning reference
information to support indoor positioning
Note 1 to entry: Detailed specifications and contents of indoor positioning references depend on the specific indoor
positioning technologies.
EXAMPLE A good example of an indoor positioning reference is information about indoor positioning
infrastructure. For Wi-Fi based positioning, the indoor positioning infrastructure information includes the Wi-Fi APs
information, such as location, SSID, and RSSI values of APs.
[SOURCE: ISO 17438-4:2019, 3.1.12, modified — Example 1 and Example 2 have been combined into a single
Example.]
3.1.13
indoor navigation data
data needed for indoor navigation, which includes indoor maps and indoor positioning infrastructure
information
[SOURCE: ISO 17438-4:2019, 3.1.13]

3.2 Abbreviated terms
ASN abstract syntax notation
C-ITS-S central ITS station
CRS coordinate reference system
EPSG European Petroleum Survey Group
ITS intelligent transport systems
ITS-S ITS station
M/O/C mandatory/optional/conditional
MO maximum occurrence
POI point of interest
P/V-ITS-S personal/vehicle ITS station
R-ITS-S roadside ITS station
WKB well-known binary
WKT well-known text
4 Requirement and conformance
4.1 Requirements
This document defines use cases and data specifications between a P/V-ITS-S and a C-ITS-S for using indoor
maps. In the definitions of data types for supporting the indoor maps, there are mandatory, optional or
conditional fields. Mandatory fields shall be provided and conditions for conditional fields shall be satisfied.
These are the requirements embedded in the definition of data types for supporting client-based positioning.
Specific encoding of each data types can be adapted for implementation. There can be additional
requirements for specific encoding.
4.2 Conformance
For the purpose of conformance to the indoor maps of which specifications are defined in Clause 7,
multiplicity of the elements in an indoor map should be observed through their implementations.
5 Conventions
This document is based on the conventions of ASN.1 (Abstract Syntax Notation One) formats.
6 Indoor map for indoor navigation functionality
6.1 Overview
Indoor maps for indoor navigation consist of the following components.
a) Background map — The background map in an indoor mapping system serves as the base layer,
providing the fundamental visual guide for users. The background map can be a form of vector and
raster maps, which is aligned with a geographic indoor space. By displaying the background map, the

indoor space can be visualized on the user’s device. The background map helps ensure that the map
provides an effective and accurate representation of the physical environment for users navigating
through it.
b) Route network map — The route network map serves as a comprehensive guide for navigation through
interconnected pathways within indoor spaces. It outlines the paths, providing information on how
different areas of the indoor space are linked together, and how they can be navigated. It details specific
points of interest, their types, and the routes connecting them. The map incorporates dynamic features,
such as permissible directions of movement, the timings during which specific routes are accessible,
and the periodicity of these access times.
c) Space map — The space map provides a representation of the semantic structure of an indoor
environment. The semantic structure represents the organization and interrelation of spaces such as
rooms, corridors and stairs within one or more buildings, emphasizing the navigable and functional
areas rather than the architectural elements that define these spaces. It highlights the relationships
between these spaces, facilitating a clear spatial understanding and navigation.
d) Set of POIs — The set of points of interest (POIs) is a collection of notable locations or features that have
been marked for special consideration within the indoor maps. These can include specific rooms, areas,
individual objects or facilities. Each point in this set is linked to a specific location of indoor nodes or
indoor semantic space. It can be highlighted or prioritized for users to navigate the indoor space or find
specific locations.
In addition to these components, other types of positioning resources can also be considered according to
the configuration of systems and services to be implemented and the type of indoor positioning to be used.
6.2 Scope of indoor maps
This document focuses specifically on requirements and specifications of indoor navigation maps for P/V-
ITS stations. It includes the data types and formats for features, network, POIs and base map within indoor
maps. Annex A provides the ASN.1 schema encoding.
6.3 Use cases of indoor maps
This document refers to and uses the use cases UC 2.1 – Searching for indoor maps, and UC 2.2 – Retrieving
indoor maps, defined in ISO 17438-4:2019, 7.2.2.1 and 7.2.2.2. UC 2.1 is the use case for searching for
candidates of indoor maps that satisfy given conditions, and UC 2.2 is the use case for downloading the
searched indoor maps. This document defines the contents of indoor maps which are transferred to a P/V-
ITS-S, as described in UC 2.2.
7 Definition of indoor map
As described in Table 1, the indoor maps for indoor navigation at a P/V-ITS-S are transferred to a P/V-ITS-S
from a C-ITS-S using the “map” attribute of “indoor-map” message defined in ISO 17438-4:2019, 8.9.
The whole ASN.1 schema for indoor positioning references shall be as defined in Annex A of this document.
Table 1 defines the “IndoorMap” data type, describing an indoor map, which consists of indoor features,
indoor networks with relevant indoor cell spaces, indoor POIs and base maps.

Table 1 — Definition of IndoorMap
Name IndoorMap
Type
Describes the indoor map, including indoor features, networks in the form of
Description
nodes and edges, indoor POIs and some base maps.
Attributes
Name Type M/O MO Description
info IndoorMapInfo M 1 The information explaining the indoor map, i.e. a kind of
a
metadata.
b c
features IndoorFeatures O N A set of features included in the indoor map.
d,e
network IndoorNetwork O N Networks and cell spaces defined in the indoor space.
The networks consist of indoor nodes and indoor edges
describing a semantic network, such as accessibility, and cell
spaces representing a semantic space in the indoor space. An
indoor node can be a representative point of an indoor cell. An
indoor POI can be related to an indoor node or an indoor cell.
a
pois POIs O N A set of POIs, included in the indoor map.
bgImages BackgroundImage O N The set of background images, which serves as a visible base
f
map. One background image is set for one floor.
note IA5String O 1 Additional description about the indoor map.
Notes
a
See ISO 17438-4:2019, Annex A for the definition.
b
Examples of indoor features are gate, door, etc. The specific list of indoor features for indoor navigation functionality is de-
pendent on implementation. The “features” attribute can be considered as a set of layers, each of which includes specific features
of one type.
c
See Table 5 for the definition.
d
See Table 8 for the definition.
e
Most of “network” can be substituted with IndoorCore module classes, described in OGC IndoorGML v1.1, section 7.3, Mul-
ti-Layered Space Model.
f
See Table 2 for the definition.
ASN.1 Schema
-- Definition of Indoor map of an indoor space for indoor navigation functionality
IndoorMap ::= SEQUENCE {
info       IndoorMapInfo,
features     SEQUENCE OF IndoorFeatures    OPTIONAL,
network     SEQUENCE OF IndoorNetwork    OPTIONAL,
pois       SEQUENCE OF POIs         OPTIONAL,
bgImages     SEQUENCE OF BackgroundImage   OPTIONAL,
note       IA5String  OPTIONAL,
...
}
Example
{
Info { identifier    “MAP001”,
spaceIdentiier  “SPACE001”,
type       “Background2DVector”
boundary {points  {{x-coordinate 36.383165, y-coordinate 127.369725},
{x-coordinate 36.383302, y-coordinate 127.370632},
{x-coordinate 36.384083, y-coordinate 127.370427},
{x-coordinate 36.383951, y-coordinate 127.369543}}},
horizontalCRS  “EPSG:4326”
format      “png”
size       117760
},
features   {.},  -- refer to the example of Table 5

TTaabblle 1 e 1 ((ccoonnttiinnueuedd))
network   {.},  -- refer to the example of Table 8
pois { name     “Gate01”
identifier  “pois001”
location {  x-coordinate   36.38408770533706,
y-coordinate   127.370260537845}},
bgImages   {.},  -- refer to the example of Table 2
note   “an example of Indoor map of an indoor space”
}
Table 2 defines the “BackgroundImage” data type, describing a visible image which is used for visible
background in an indoor navigation device, i.e. P/V-ITS-S.
Table 2 — Definition of BackgroundImage
Name BackgroundImage
Type
Describes a background image which is displayed as background on the screen
Description
of a nomadic device acting as a P/V-ITS-S.
Attributes
Name Type M/O MO Description
a
id BackgroundImageID M 1 An identifier of a background image.
name IA5String O 1 Name of the background image.
floorNo INTEGER M 1 Floor number which is presented by the background image.
For example, 1, 2, etc. for the first floor, the second floor, etc.
For underground floors, the negative number is used.
boundary ImageMappingArea M 1 The maximum bounding rectangle which represents where
this background image is mapped. It is used when the indoor
b
map is displayed with the outdoor map.
size INTEGER M 1 The size of a background image in bytes.
format IA5String M 1 The format of a background image. It can be a filename exten-
sion, such as, “jpg”, “png”, etc.
resolution Resolution M 1 The resolution of a background image, which consists of num-
ber of pixels, in the form of (width, height).
c
For example, (128x128) .
img OCTET STRING M 1 The binary string of a background image itself.
note IA5String O 1 Additional description about the background image.
Notes
a
How to construct an identifier of a background image is out of the scope of this document and more consensus is needed for its
standardization.
b
See Table 3 for the definition.
c
See Table 4 for the definition.
ASN.1 Schema
-- Identifier type of an image used as a background
BackgroundImageID ::= IA5String
-- Definition of Image used a background of a display of indoor navigation device
BackgroundImage ::= SEQUENCE {
id        BackgroundImageID,
name       IA5String      OPTIONAL,
floorNo     INTEGER,
boundary     ImageMappingArea,
size       INTEGER,
format      IA5String,
resolution    Resolution,
img       OCTET STRING,

TTaabblle 2 e 2 ((ccoonnttiinnueuedd))
note       IA5String  OPTIONAL,
...
}
Example
{
id      “001”,
name     “Lobby”,
floorNo    1,
boundary  {points  {{x-coordinate 36.383165, y-coordinate 127.369725},
{x-coordinate 36.383302, y-coordinate 127.370632},
{x-coordinate 36.384083, y-coordinate 127.370427},
{x-coordinate 36.383951, y-coordinate 127.369543}}},
size     117760,
format    “png”,
resolution  {width 80, height 60},
img      "0110010101100101011.” -- this is a binary representation,
note     “This sample image shows the lobby floor in the ETRI Convergence
Commercialization Centre”
}
Table 3 defines the “ImageMappingArea” data type, describing an area where a background image is mapped.
Table 3 — Definition of ImageMappingArea
Type Name ImageMappingArea
Description Describes a geographic area where a background image is mapped.
Attributes
Name Type M/O MO Description
points Location M 4 The minimum bounding box which describes a mapping re-
a
gion (area) where a background image is displayed.
note IA5String O 1 Additional description about the mapping area.
Notes
a
The left and upper corner of the minimum bounding box is mapped to left and upper pixel of the image.
ASN.1 Schema
-- Area where a background image is mapped on (map of) outdoor space
ImageMappingArea ::= SEQUENCE {
points      SEQUENCE (SIZE(4)) OF Location,
note       IA5String  OPTIONAL,
...
}
Example
-- refer the example of ‘boundary’ attribute in Table 2
Table 4 defines the “Resolution” data type, describing a resolution of a background image.
Table 4 — Definition of Resolution
Name Resolution
Type
Description Describes the resolution of an image, consisting of number of pixels.
Attributes
Name Type M/O MO Description
width INTEGER M 1 Number of pixels of an image in width.

TTaabblle 4 e 4 ((ccoonnttiinnueuedd))
height INTEGER M 1 Number of pixels of an image in height.
Notes
(none)
ASN.1 Schema
-- Resolution of a background image
Resolution ::= SEQUENCE {
width   INTEGER,
height  INTEGER
}
Example
-- refer the example of ‘resolution’ attribute in Table 2
Table 5 defines the “IndoorFeatures” data type, describing a set of indoor features existing in indoor spaces
where indoor navigation is provided.
Table 5 — Definition of IndoorFeatures
Name IndoorFeatures
Type
a
Description Describes a set of indoor features, of which types are same.
Attributes
Name Type M/O MO Description
b
id IndoorFeaturesID M 1 An identifier of a set of indoor features.
featureName IA5String M 1 Name of “IndoorFeatures”, e.g. Gate.
c
featureType IndoorFeatureType M 1 Type of “IndoorFeatures”.
d
geometryType GeometryType M 1 Type of geometry of the “IndoorFeatures”.
e
features IndoorFeature M N Indoor Features.
note IA5String O 1 Additional description about the indoor features.
Notes
a
“IndoorFeatures” can be considered as a layer of indoor features, of which the type is the same. For example, Gate, Door etc. can
be indoor features.
b
How to construct an identifier of the indoor features is out of the scope of this document and more consensus is needed for its
standardization.
c
For the definition of indoor feature types, i.e. a kind of code list or enumeration, a pre-defined code list, such as IFC OmniClass
code, can be applied.
d
For the type of geometry, OGC Simple Feature Code is applied.
e
See Table 6 for the definition.
ASN.1 Schema
-- Identifier type of a set of indoor features
IndoorFeaturesID ::= IA5String
-- Type of an indoor feature
IndoorFeatureType ::= INTEGER
-- Type of geometries
GeometryType ::= INTEGER
-- A set of indoor features, which can be a layer of the indoor features
IndoorFeatures ::= SEQUENCE {
id      IndoorFeaturesID,
featureName  IA5String,
featureType  IndoorFeatureType,
geometryType GeometryType,
features   SEQUENCE OF IndoorFeature,
note     IA5String  OPTIONAL,

TTaabblle 5 e 5 ((ccoonnttiinnueuedd))
...
}
Example
{
id      “001”,
featureName  “Entrance Doors”,
featureType  “AnchorSpace”,
geometryType “POLYGON”,
features {  { id   "001-1",
name  “Main Entrance Door”,
geometry {wkb “01D7A370.”,
wkt "POINT(36.383302, 127.370632)”}},
{ id   "001-2",
name  “Side Entrance Door”,
geometry {wkb “01D7A370.”,
wkt "POINT(36.384083, 127.370427)”}},
{ id   "001-3",
name  “Back Entrance Door”,
geometry {wkb “01D7A370.”,
wkt "POINT(36.383951, 127.369543)”}}
},
note     “This is a set of indoor features representing entrance doors in the ETRI
Convergence Commercialization Centre”
}
Table 6 defines the “IndoorFeature” data type, describing an indoor feature existing in indoor spaces.
Table 6 — Definition of IndoorFeature
Name IndoorFeature
Type
Description Describes an indoor feature.
Attributes
Name Type M/O MO Description
a
id IndoorFeatureID M 1 An identifier of an indoor feature object.
name IA5String O 1 Name of an indoor feature.
b
geometry IndoorFeatureGeom- M 1 WKB or WKT encoding of the geometry of an indoor feature.
etry
note IA5String O 1 Additional description about the indoor feature.
Notes
a
How to construct an identifier of the indoor feature objects is out of the scope of this document and more consensus is needed
for its standardization.
b
See Table 7 for the definition. See also ISO 19125-1.
ASN.1 Schema
-- Identifier type of an indoor feature
IndoorFeatureID ::= IA5String
-- Definition of Indoor feature
IndoorFeature ::= SEQUENCE {
id      IndoorFeatureID,
name     IA5String  OPTIONAL,
geometry   IndoorFeatureGeometry,

TTaabblle 6 e 6 ((ccoonnttiinnueuedd))
note     IA5String  OPTIONAL,
...
}
Example
-- refer the example of ‘features’ attribute in Table 5
Table 7 defines the “IndoorFeatureGeometry” data type, including WKB or WKT encoding of the geometry of
an indoor feature.
Table 7 — Definition of IndoorFeatureGeometry
Name IndoorFeatureGeometry
Type
Description Describes the geometry of an indoor feature.
Attributes
Name Type M/O MO Description
b a
wkb WKBGeometry C 1 WKB encoding of the geometry of an indoor feature.
c a
wkt WKTGeometry C 1 WKT encoding of the geometry of an indoor feature.
Notes
a
A single geometry encoding, either WKB or WKT, should be provided.
b
WKBGeometry is defined as “OCTET STRING”.
c
WKTGeometry id defined as “VisibleString”.
ASN.1 Schema
-- WKB encoding of the geometry of an indoor feature
WKBGeometry ::= OCTET STRING
-- WKT encoding of the geometry of an indoor feature
WKTGeometry ::= VisibleString
-- Definition of the geometry of an indoor feature
IndoorFeatureGeometry ::= CHOICE {
wkb    WKBGeometry,
wkt    WKTGeometry
}
Example
-- refer the example of features’ geometry in Table 5
Table 8 defines the “IndoorNetwork” data type, describing an indoor network which can be used for searching
an indoor route. An indoor network can be defined by using OGC IndoorGML or represented by a set of indoor
nodes, indoor links and indoor cells.
Table 8 — Definition of IndoorNetwork
Name IndoorNetwork
Type
Description Describes an indoor network, representing accessible networks.
Attributes
Name Type M/O/C MO Description
a
id IndoorNetworkID M 1 An identifier of an indoor network, with cell spaces.
title IA5String O 1 Name of an indoor network, with cell spaces.
c
uri OCTET STRING C 1 URI reference representing indoor networks represented by
other format, such as OGC IndoorGML.
c
nodelinks IndoorNodeEdge Net- C N Indoor networks, representing accessible spaces and paths
b
workWithCells with semantic cell spaces.

TTaabblle 8 e 8 ((ccoonnttiinnueuedd))
note IA5String O 1 Additional description about the indoor network.
Notes
a
How to construct an identifier of the indoor network is out of the scope of this document and more consensus is needed for its
standardization.
b
See Table 9 for the definition.
c
Only one option can be selected: either 'uri' or 'nodelinks'. If 'uri' is chosen, 'nodelinks' shall not be used, and vice versa. If
“nodelinks” is provided, “indoorgml” shall not be specified.
ASN.1 Schema
-- Identifier type of an indoor network
IndoorNetworkID ::= IA5String
-- Definition of Indoor network
IndoorNetwork ::= SEQEUNCE {
id      IndoorNetworkID,
title     IA5String    OPTIONAL,
network CHOICE {
uri      OCTET STRING,
nodelinks   IndoorNodeEdgeNetworkWithCells
},
note     IA5String    OPTIONAL,
...
}
Example
{
id “Network001”,
title “Indoor networks of the ETRI Convergence Commercialization Centre”,
network CHOICE {
uri “3C 49 6E 64 .” -- OCTET STRING representation of OGC IndoorGML,
nodelinks{
nodes  { id     “Node001”,
type    0,
geometry  {36.3839773184394, 127.3698993563252},
edges   {“edge001”, “edge002”},
cell    “GRD001”,
poi    “POI001”},
edges  { id     “Edge001”,
geometry {  points {{36.3839773184394, 127.3698993563252},
{36.3839265739698, 127.3699127673703},
{36.3838801481496, 127.3699275195198}}},
width   3,
weight  1,
allowedMovements { objectType 1,
allowedTime  {From “2023-09-01T09:00:00”,
to “2023-09-30T18:00:00”,
periodic 3},
TTaabblle 8 e 8 ((ccoonnttiinnueuedd))
direction  2,
speedLimit  20}},
cells { id     “GRD001”,
name    “indoor cell space”,
boundary { polygon  {{233195.8787983209,420702.3822559568},
{233196.6726935889,420698.7940314255},
{233196.1112707766,420698.6698165359},
{233195.8787983209,420702.3822559568},
{233191.2781518695,420697.6004881824},
{233190.3505836227,420697.3952635551},
{233189.4230154499,420697.1900389443},
{233191.2781518695,420697.6004881824}}},
category 1,
representative “Node001”,
poi “POI001”}
}
Table 9 defines the “IndoorNodeEdgeNetworkWithCells” data type, describing an indoor network, which
consists of indoor nodes, indoor links and indoor cells which represent semantic spaces.
Table 9 — Definition of IndoorNodeEdgeNetworkWithCells
Name IndoorNodeEdgeNetworkWithCells
Type
Description Describes an indoor network, organized with cell spaces.
Attributes
Name Type M/O MO Description
a b
nodes IndoorNode M N Nodes in an indoor network.
c d
edges IndoorEdge O N Edges in an indoor network.
e
cells IndoorCell O N Cell spaces in an indoor space. A cell space can be connected to
f
an indoor node.
note IA5String O 1 Additional description about the indoor network.
Notes
a
When compared with OGC IndoorGML, this can be mapped to “IndoorCore::State”.
b
See Table 10 for the definition.
c
When compared with OGC IndoorGML, this can be mapped to “IndoorCore::Transition”.
d
See Table 12 in this document for the definition.
e
When compared with OGC IndoorGML, this can be mapped to “IndoorCore::CellSpace”.
f
See Table 18 in this document for the definition.
ASN.1 Schema
-- Definition of Indoor network, consisting of indoor nodes, indoor edges, and indoor cells
IndoorNodeEdgeNetworkWithCells ::= SEQEUNCE {
nodes     SEQUENCE OF IndoorNode,
edges     SEQUENCE OF IndoorEdge  OPTIONAL,
cells     SEQUENCE OF IndoorCell  OPTIONAL,
note     IA5String  OPTIONAL,
...
}
Example
{
nodes  {  id     “Node001”,
type    0,
TTaabblle 9 e 9 ((ccoonnttiinnueuedd))
geometry  {36.3839773184394, 127.3698993563252},
edges   {“edge001”, “edge002”},
cell    “GRD001”,
poi    “POI001”
},
edges  {  id     “Edge001”,
geometry  {  points  {{36.3839773184394, 127.3698993563252},
{36.3839265739698, 127.3699127673703},
{36.3838801481496, 127.3699275195198}}},
width   3,
weight   1,
allowedMovements  {  objectType 1,
allowedTime  {From “2023-09-01T09:00:00”,
to “2023-09-30T18:00:00”,
periodic 3},
direction  2,
speedLimit  20},
},
cells  {  id     “GRD001”,
name    “indoor cell space”,
boundary  { polygon  {{233195.8787983209,420702.3822559568},
{233196.6726935889,420698.7940314255},
{233196.1112707766,420698.6698165359},
{233195.8787983209,420702.3822559568},
{233191.2781518695,420697.6004881824},
{233190.3505836227,420697.3952635551},
{233189.4230154499,420697.1900389443},
{233191.2781518695,420697.6004881824}}},
category 1,
representative “Node001”,
poi “POI001”}
}
Table 10 defines the “IndoorNode” data type, describing an indoor node.
Table 10 — Definition of IndoorNode
Name IndoorNode
Type
Description Describes an indoor node represented as a point.
Attributes
Name Type M/O MO Description
a,b,c
id IndoorNodeID M 1 An identifier of an indoor node.
d
type IndoorNodeType M 1 Type of an indoor node.
e
geometry Location M 1 Geometry (Point) of an indoor node.
f,g
edges IndoorEdgeID O N Indoor edges connected to the indoor node.
h,i
cell IndoorCellID O 1 Indoor cell representing a semantic space of an indoor node.
j
poi IndoorPOIID O 1 POI relevant to an indoor node.

TTaabblle 1e 10 0 ((ccoonnttiinnueuedd))
note IA5String O 1 Additional description about an indoor node.
Notes
a
How to construct an identifier of the indoor node is out of the scope of this document and more consensus is needed for its
standardization.
b
When compared with OGC IndoorGML, an “IndoorNode” can be mapped to “IndoorCore::State”.
c
The “id” should be a valid identifier of an “IndoorNode” included in “IndoorNodeEdgeNetworkWithCells::nodes”.
d
See Table 11 for the definition.
e
See ISO 17438-4:2019, Annex A for the definition.
f
When compared with OGC IndoorGML, an “IndoorEdge” can be mapped to “IndoorCore::Transition”.
g
The “edges” should be valid identifiers of an “IndoorEdge” included in “IndoorNodeEdgeNetworkWithCells::edges”.
h
When compared with OGC IndoorGML, an “IndoorCellSpace” can be mapped to “IndoorCore::CellSpace”.
i
The “cells” should be valid identifiers of an “IndoorCellSpace” included in “IndoorNodeEdgeNetworkWithCells::cells”.
j
See ISO 17438-4:2019, Annex A for the definition.
ASN.1 Schema
-- Identifier type of an indoor node
IndoorNodeID ::= IA5String
-- Identifier type of an indoor edge
IndooeEdgeID ::= IA5String
-- Identifier type of an indoor cell
IndoorCellID ::= IA5String
-- Identifier type of an indoor POI
IndoorPOIID ::= IA5String
-- Definition of Indoor node
IndoorNode ::= SEQUENCE {
id    IndoorNodeID,
type   IndoorNodeType,
geometry Location,
edges   SEQUENCE OF IndoorEdgeID  OPTIONAL,
cell   IndoorCellID        OPTIONAL,
poi    IndoorPOIID        OPTIONAL,
note   IA5String         OPTIONAL,
...}
Example
{
id     “Node001”,
type    0,
geometry  {36.3839773184394, 127.3698993563252},
edges   {“edge001”, “edge002”},
cell    “GRD001”,
poi    “POI001”
}
Table 11 defines the “IndoorNodeType” code list, enumerating types of the indoor nodes.
Table 11 — Definition of IndoorNodeType
Name IndoorNodeType
Code list
Description Enumerates types of an indoor node.
Code values
Name Bit Description
Anchor-in Indoor node representing an entry.
Anchor-out 1 Indoor node representing an exit.

TTaabblle 1e 11 1 ((ccoonnttiinnueuedd))
Connection 2 Indoor node connecting two indoor semantic networks.
Merge-point 3 Indoor node of a merge-point.
Diverge-point 4 Indoor node of a diverge-point.
… (More codes can be added depending on an extension)
Notes
(none)
ASN.1 Schema
-- Type of an indoor node
IndoorNodeType ::= BIT STRING {
Anchor-in    (0),
Anchor-out    (1),
Connection    (2),
Merge-point   (3),
Diverge-point  (4),
...
}
Example
-- refer the example of ‘type’ attribute in Table 10
Table 12 defines the “IndoorEdge” data type, describing an indoor edge.
Table 12 — Definition of IndoorEdge
Name IndoorEdge
Type
Description Describes an indoor edge, represented by a curve.
Attributes
Name Type M/O MO Description
a
id IndoorEdgeID M 1 An identifier of an indoor edge.
b
geometry IndoorCurve M 1 Geometry (Curve) of an indoor edge.
width REAL O 1 Width of the access path, represented by an indoor edge, in
metres.
weight REAL O 1 A weight which can be used for route calculation. The meaning
of the weight is dependent on implementations.
allowedMovements AllowedMovement M N Information regarding allowed movements, which consist of
c
allowed moving object type, accessible date-time.
note IA5String O 1 Additional description about an indoor edge.
Notes
a
How to construct an identifier of the indoor edge is out of the scope of this document and more consens
...