Open Geospatial Consortium

Submission Date: 2019-02-05

Approval Date:   2019-02-28

Publication Date:   2019-12-11

External identifier of this OGC® document: http://www.opengis.net/doc/dp/indoorgml-anchornode

Internal reference number of this OGC® document:    19-004

Category: OGC® Discussion Paper

Editor:   Kyoung-Sook Kim, Jiyeong Lee

Anchor Node Extension in IndoorGML - Seamless Navigation between Indoor and Outdoor Space

Copyright notice

Copyright © 2019 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.opengeospatial.org/legal/

Warning

This document is not an OGC Standard. This document is an OGC Discussion Paper and is therefore not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, an OGC Discussion Paper should not be referenced as required or mandatory technology in procurements.

Document type:    OGC® Discussion Paper

Document subtype:

Document stage:    Approved

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

i. Abstract

This OGC discussion paper provides an extension module of OGC Indoor Geography Markup Language (IndoorGML) for the seamless navigation between indoor and outdoor spaces. The OGC IndoorGML standard has an issue on the data model that affects the connection of indoor and outdoor spaces via an “Anchor Node,” which is a conceptual part for connecting indoor and outdoor spaces. This discussion paper aims to show use cases of how IndoorGML can connect with other geospatial standards that represent outdoor spaces (and road networks), such as OGC City Geography Markup Language (CityGML) and version 5.0 of the Geographic Data Files (GDF) format.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, OGC, IndoorGML, Indoor space, Outdoor space, Seamless navigation, CityGML

iii. Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

The following organizations submitted this document to the Open Geospatial Consortium (OGC):

Organization name(s)

  • National Institute of Advanced Industrial Science and Technology,

  • The University of Seoul,

  • All for Land Inc.

v. Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name Affiliation

Kyong-Sook Kim

National Institute of Advanced Industrial Science and Technology

Teahoon Kim

National Institute of Advanced Industrial Science and Technology

Jiyeong Lee

University of Seoul

Hye-Young Kang

All for Land Inc.

1. Introduction

This OGC document tries to extend the OGC IndoorGML core and navigation modules for supporting seamless navigation from an indoor to an outdoor space, and vice versa. Although there are many approaches to determine the indoor or outdoor location of a user, few services support both indoor and outdoor space due to the absence of a data model that covers/connects them both. The scope of this discussion paper is to design an extension data model of IndoorGML for linking between two anchor parts of indoor and outdoor space. This paper consists of three parts:

  • The concept of anchor nodes for the connection between indoor and outdoor space,

  • An extension of IndoorGML schema for seamless navigation, and

  • A use case with other geospatial data model standards: CityGML 2.0, Geographic Data Files 5.0, and the specification for a pedestrian network model from the Government of Japan [2]

2. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this Best Practice.

For the purposes of this document, the following additional terms and definitions apply.

2.1. Indoor space

A space within one or multiple buildings consisting of architectural components.

2.2. Cellular Space

A space where location is identified by a cell identifier

2.3. Abbreviated terms

The following abbreviated terms are used in this discussion paper:

  • AIST National Institute of Advanced Industrial Science and Technology

  • CityGML City Geography Markup Language

  • CRS Coordinate Reference System

  • GDF Geographic Data Files

  • GML Geography Markup Language

  • IndoorGML Indoor Geography Markup Language

  • ISO International Organization for Standardization

  • OGC Open Geospatial Consortium

  • OSM OpenStreetMap

  • UML Unified Modeling Language

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

ISO: ISO 14825:2011 ISO Intelligent transport Systems - Geographic Data Files (GDF) - GDF 5.0 (2011)

OGC: OGC 14-005r5, OGC Indoor Geography Markup Language (IndoorGML) - with Corrigendum 1.0.3 (2018)

OGC: OGC 12-019, OGC City Geography Markup Language (CityGML) Encoding Standards 2.0 (2012)

4. The connection between indoor and outdoor spaces

Designing a converged data model to represent indoor and outdoor spaces is one of the typical issues on geographic information systems. In particular, a route navigation service is primarily associated with the network model of connectivity of roads. Compared to many standard formats that represent outdoor networks, only IndoorGML provides a standard model to describe the connectivity of components in indoor space. Since IndoorGML has been published, various studies have been carried out to express indoor and outdoor space connections.

image
Figure 1. Anchor node connecting indoor and outdoor networks (OGC 14-005r5)

As shown in Figure 1, IndoorGML introduces a simple concept of an “anchor node” for representing indoor and outdoor connections. For example, an “entrance” is represented as an anchor node, a topological node to connect an indoor and outdoor element.

However, there is no element in the IndoorGML Core (and Navigation) model to represent anchor node, and specific examples of how to apply IndoorGML for connecting outdoor elements, such as roads, junctions, and pedestrian ways, are excluded in the IndoorGML standard document. In [4], the indoor and outdoor connections are expressed by extending the State and Transition of the core module of IndoorGML to SpecialState (Anchor node) and SpecialTransition (Anchor edge). However, this extension brings cost overruns when constructing and managing all indoor and outdoor data in/for an IndoorGML document.

This discussion paper proposes an IndoorGML extension model to interconnect indoor and outdoor models for seamless navigation by defining anchor node in the model. To this end, this document includes:

  1. Definition of a conversion matrix between indoor and outdoor coordinate systems

  2. Definition of the element of anchor node that extends IndoorGML core and navigation modules

5. Seamless navigation module of IndoorGML using anchor node

This section describes an IndoorGML SeamlessNavigation module for seamless navigation between indoors and outdoors.

image
Figure 2. Structure space model (OGC 14-005r5)

OGC IndoorGML provides a standard data model for indoor space with two spatial models, as shown in Figure 2: Euclidean Space represents the shape of a three-dimensional (3D) cell space; Topology Space represents connectivity between cell spaces. Topology represents a duality transformation of the 3D cell space and is an essential component for indoor navigation and routing system. By applying a duality transformation, the 3D cells in primal space are mapped to nodes (0D) in dual space. The topological adjacency relationships between 3D cells are transformed to edges (1D) linking pairs of nodes in dual space. In the current version of IndoorGML, a gate or entrance of building that connects indoor and outdoor spaces is represented by an AnchorSpace instance and can be represented by a State instance in dual space. However, the connectivity between an outdoor network and an indoor cell of the AnchorSpace class cannot be represented by the elements in IndoorGML.

image
Figure 3. The concept of SeamlessNavigation module

In this discussion paper, a SeamlessNavigation model as an extension of IndoorGML is designed for making connections with other standards that represent outdoor spaces, as shown in Figure 3. Unlike defining a unified integration model, the SeamlessNavigation model defines a new element which has the following attributes to support the seamless traveling between indoor and outdoor spaces:

  • Parameters for the conversion of coordinate reference systems

  • External reference to the outdoor transportation network

5.1. Conversion method of the coordinate reference system

The conversion of the Coordinate Reference System (CRS) is an important process for seamless navigation between indoor and outdoor coordinate systems. In cases where the global CRS is used for indoor space, the conversion parameters are not necessary. However, many building datasets are represented in their own local CRS. In the case of using the local CRS, four parameters are required for Cartesian coordinate system conversion:

  • the origin point of target CRS (or global CRS) \($P_{o}(x_{0},\ y_{0},\ z_{0})$\),

  • rescaling factor \($R(s_{x},\ s_{y},\ s_{z})$\),

  • rotation angles \($A(\alpha,\ \ \beta,\ \ \gamma)$\), along \($x,y,z$\)-axis, and

  • translation vector \($T(t_{x},\ t_{y},\ t_{z})$\)

Firstly, the origin \($P_{o}$\) is required to perform the transformation. Next, a scale value \($R$\), between the local coordinate system and the global coordinate system, is required. Thirdly, the rotation angle of each axis \($A$\) is required for the rotation movement between the coordinate systems. Lastly, a translation vector \($T$\)is given for parallel movement between coordinate systems. Figure 4 shows examples of conversion methods.

image
Figure 4. Example of transform methods (2-dimensional case)

Unlike scaling and translation, the rotation is affected by the order in which the parameters (rotation angles) are applied. Typically, the Euler angle for 3D rotation described in [1,5] can be used. Euler angles are described as a sequence of rotations about three mutually orthogonal coordinate axes fixed in \($\mathbb{R}^{3}$\) Space. This discussion paper uses yaw, pitch, and roll rotation, as shown in Figure 5, one of the sequences of Euler angles.

image
Figure 5. Example of Yaw-Pitch-Roll rotation

Yaw is a counterclockwise rotation of \($\alpha$\) about the \($z$\)-axis, as shown in Figure 5. The rotation matrix is given by:

\[R_{z}\left( \alpha \right) = \ \begin{pmatrix} \cos\alpha & - \sin\alpha & 0 \\ \sin\alpha & \cos\alpha & 0 \\ 0 & 0 & 1 \\ \end{pmatrix}\]

Note that the upper left entries of \($R_{z}\left( \alpha \right)$\) from a 2D rotation applied to the \($x$\) and \($y$\) coordinates, whereas the \($z$\) coordinate remains constant.

Similarly, a pitch is a counterclockwise rotation of \($\text{β}$\) about the \($y$\)-axis, and a roll is a counterclockwise rotation of \($\text{γ}$\) about the \($x$\)-axis, as shown in Figure 5. The rotation matrix of pitch and roll are given by:

\[R_{y}\left( \beta \right) = \ \begin{pmatrix} \cos\beta & 0 & \sin\beta \\ 0 & 1 & 0 \\ - \sin\beta & 0 & \cos\beta \\ \end{pmatrix},\ \ R_{x}\left( \gamma \right) = \ \begin{pmatrix} 1 & 0 & 0 \\ 0 & \cos\gamma & - \sin\gamma \\ 0 & \sin\gamma & \cos\gamma \\ \end{pmatrix}\]

So, a 3D rotation matrix with \($\alpha,\beta,\gamma$\) is defined as follows:

\[R\left( \alpha,\ \beta,\gamma \right) = \ R_{z}\left( \alpha \right)R_{y}\left( \beta \right)R_{x}\left( \gamma \right) = \begin{bmatrix} {\cos\alpha}{\cos\beta} & \cos\alpha\sin\beta\sin\gamma - \sin\alpha\cos\gamma & \cos\alpha\sin\beta\cos\gamma + \sin\alpha\sin\gamma \\ {\sin\alpha}{\cos\beta} & \sin\alpha\sin\beta\sin\gamma + \cos\alpha\cos\gamma & \sin\alpha\sin\beta\cos\gamma - \cos\alpha\sin\gamma \\ - \sin\beta & \cos\beta\sin\gamma & \cos\beta\cos\gamma \\ \end{bmatrix}\]

5.2. UML diagram of the seamless navigation module

IndoorGML has a thick model that represents the wall thickness of a building and a thin model that does not, as shown in Figure 6. The SeamlessNavigation module can be defined by considering both models.