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.
Copyright
© 2022 Open Geospatial Consortium
To obtain additional rights of use, visit
http://www.ogc.org/legal/
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.
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.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
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.
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.
No security considerations have been made for this document.
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. |
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]
This document uses the terms defined in OGC Policy Directive 49, 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 document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
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.
A space within one or multiple buildings consisting of architectural components.
A space where location is identified by a cell identifier
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
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.
As shown in
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:
Definition of a conversion matrix between indoor and outdoor coordinate systems
Definition of the element of anchor node that extends IndoorGML core and navigation modules
This section describes an IndoorGML SeamlessNavigation module for seamless navigation between indoors and outdoors.
OGC IndoorGML provides a standard data model for indoor space with two spatial models, as shown in
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
Parameters for the conversion of coordinate reference systems
External reference to the outdoor transportation network
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)
rescaling factor
rotation angles
translation vector
Firstly, the origin
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
Yaw is a counterclockwise rotation of
Note that the upper left entries of
Similarly, a pitch is a counterclockwise rotation of
So, a 3D rotation matrix with
IndoorGML has a thick model that represents the wall thickness of a building and a thin model that does not, as shown in
However, when expressing an entrance with a thin model, a State is required in the outdoor space according to the definition of transition. However, since State has a duality relation with CellSpace, it is necessary to express the outdoor space as CellSpace to create a State in outdoor space. However, this is not semantically equivalent to CellSpace defined in IndoorGML. In conclusion, the entrance should be expressed, as is the State, in the door of the thick model.
The proposed SeamlessNavigation module is shown in
AnchorState represents a node that provides the connection between indoor space and outdoor space. It refers to entrance doors. It can be used as a control point for indoor-outdoor integrations. It contains conversion parameters for transforming the local CRS coordinates of indoor geometry. In cases where the global CRS is used for indoor space, the conversion parameters are not necessary. The transformReferencePoint element describes a reference point that is used for the conversion. TransformReferencePoint is a point in the global CRS. TransformReferencePoint is represented geometrically as a Point in Geography Markup Language (GML). TransformReferencePoint must have an attribute crsName to represent the used CRS of the outdoor network. The duality element represents an association with the corresponding AnchorSpace class, which represents a special opening space. AnchorState has a geometry that is derived from State class, and it is one of the endpoints of the curve geometry of AnchorLink.
All AnchorState elements are used for conversion, except the duality and connects elements: transformReferencePoint
ExternalAnchorState represents a node that represents the position on the outdoor network. It is represented geometrically as a Point in GML and it is one of the endpoints of the curve geometry of AnchorLink. It also has references to outdoor networks in other standards;
e.g., CityGML, GDF, etc.
In the case of (a) in
AnchorLink represents an edge between the indoor network and outdoor networks. AnchorLink always connects AnchorState and ExternalAnchorState. For the geometrical representation of an AnchorLink, a Curve geometric primitive object from the GML is used.
For better understanding, this document provides a use case of the SeamlessNavigation module for the Transportation model of CityGML 2.0. This section briefly introduces the CityGML Transportation model and suggests some guidelines for using the sample data to create the SeamlessNavigation module data.
CityGML is an OGC standard data model and exchange format for storing digital 3D models of cities and landscapes. CityGML supports a transportation model that focuses on thematic as well as on geometrical/topological aspects, as shown in
The main class is TransportationComplex, which is composed of the parts TrafficArea and AuxiliaryTrafficArea. In the ‘LOD 0’ level of detail, the transportation complexes are modeled by line objects establishing a linear network. On this level, pathfinding algorithms or similar analyses can execute.
Therefore, the geometry of ExternalAnchorState should be created as a point on the lod0Network and must have the source data information of the TransportationComplex using the GML ID or URL information, as shown in
The sample data for the use case have been conducted at a real site: AIST Tokyo Waterfront Annex in Japan, as shown in
For simplicity, the detailed structure inside the AIST building is not represented, and the data are constructed using only 2D geometry. All geometric data in the sample data are derived from the Open Street Map (OSM[3]) data and have the same CRS; EPSG:4326 (WGS 84). The IndoorGML data consists of two spaces: one CellSpace and one AnchorSpace. The CityGML data has only one TransportationComplex instance.
The detailed contents of sample data for the AnchorState class are as shown in
AnchorLink sample data is shown in
This section briefly introduces the “Development Specification for Spatial Network Model for Pedestrians (for short, PNspec) [2]” and suggests guidelines for conversion of the SeamlessNavigation module data using the specific cases.
PNspec includes both indoor and outdoor network information. To use the SeamlessNavigation module, we need to convert the indoors content of the PNspec into IndoorGML.
This chapter describes how to convert PNspec to IndoorGML. Because both IndoorGML and PNspec have node and link-based network models, they can easily convert between each schema. However, some special cases have different parts. In the case of a staircase, the PNspec places nodes at the beginning and end of the staircase, then links the two nodes. However, in IndoorGML, a staircase is expressed as a single space, so it is expressed as a single State. To resolve these conflicts, we need the mapping rules shown in
Similarly, for gradients, PNspec places nodes at the beginning and end of the sloped space, then links the two nodes. However, in IndoorGML, the space with slope is expressed as a single space, so it is expressed as a single State. To resolve these conflicts, we need the mapping rules shown in
Finally, in the case of a step, PNspec places nodes before and after a step. In the case of IndoorGML, we can divide space around a step. However, we do not create a state around the step. Depending on the concept of cellular space of IndoorGML, multiple nodes will be mapped to a single State, as shown in
In addition, PNspec expresses a node having the same concept as an anchor node of this document as ‘the in/out boundary of the facility.’ However, in PNspec, an entrance is supposed to be a link. Depending on the characteristics of the AnchorState defined in this discussion paper, the entrance should be represented as a State. Therefore, the nodes and links representing the entrance in the PNspec should be represented by classes of IndoorGML Core and SeamlessNavigation module as shown in
The sample data for the use case have been conducted at a real site: Tokyo station, as shown in
For simplicity, we used a part of Tokyo station data, as shown in
The detailed contents of sample data for the nodes is shown in
This section briefly introduces the Geographic Data Files (GDF) 5.0 format and suggests guidelines for the conversion of SeamlessNavigation module data using the specific cases.
GDF is an ISO international standard that specifies the conceptual and logical data models and physical encoding formats for geographic databases for Intelligent Transportation Systems (ITS) applications and services. It has the reference number ISO 14825:2011.
In this discussion paper, we focused on how to connect the outdoor network and indoor network using the IndoorGML SeamlessNavigation module. Therefore, we have to make a connection between ExternalAnchorState and a specific feature of GDF 5.0; i.e., the entrance of the building, the element of pedestrian network, etc. Firstly, the entrance of the building element can be expressed in two ways: Using Relationship, Using Feature.
As shown in
As shown in
It coincides with the address of the selected Service;
It is provided with a reception/lobby for the visitor;
It is the entrance which attracts the most attention;
It is the entrance to which road signs (if present) point.And at least one of the EntryPoint instances of a service shall be attributed as “Main.”
In the case of using EntryPoint, for connecting to ExternalAnchorState, we have to make an externalReference based on the EntryPoint ID.
The geometry of all Features in GDF 5.0 shall be expressed by Node, Edge, and Face.
The sample data for the use case have been conducted at a real site: AIST Tokyo Waterfront Annex in Japan, as shown in
Point Feature instances must have point_feat_ID, feature_code, and coord properties: point_feat_ID means identifier of Point Feature, feature_code means the four-digit code of the Feature__Class to which the Feature in issue belongs, and coord means a position of Feature.
Relationship must have rel_ID and rel_code: rel_ID means identifier of Relationship and rel_code means (pre-defined or user-defined) relationship type code. And Relationship can have num_feat and rel_feature: num_feat means the number of features that belong to Relationship and rel_feature means the feature information belong to Relationship.
The mapped ExternalAnchorState result is shown in
This annex provides the normative XML schema document for the SeamlessNavigation Module.
The following are examples of the SeamlessNavigation module documents generated as described in
Date | Release | Editor | Primary clauses modified | Description |
---|---|---|---|---|
2018-11-01 | 0.1 | Kyong-Sook Kim |
all | Initial version |
2018-12-03 | 0.5 | Kyong-Sook Kim |
5, 6, Annex B | complemented |
2019-02-04 | 1.0 | Kyong-Sook Kim |
all | final version |
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.