Published

OGC Discussion Paper

•
Extensions of IndoorGML 1.1 - Indoor Affordance Spaces
Taehoon Kim Editor Kyoung-Sook Kim Editor Jiyeong Lee Editor Ki-Joune Li Editor
Submission Date: 2021-03-01 Approval Date: 2022-03-04 Publication Date: 2022-05-06 External identifier of this OGC® document: http://www.opengis.net/doc/DP/IndoorGML1.1-IndoorAffordanceSpaces Internal identifier of this OGC® document: 21-010r2
Additional Formats: PDF
OGC Discussion Paper

Published

Notice

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 number:21-010r2
Document type:OGC Discussion Paper
Document subtype:
Document stage:Published
Document language:English

Copyright notice

Copyright © 2022 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.ogc.org/legal/

Note

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.


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.

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.



I.  Abstract

The OGC IndoorGML standard provides a fundamental data model for representing indoor spaces as spatial, topological, and semantic features. The IndoorGML core module allows applications to extend the model with their semantic considerations. For example, the IndoorGML navigation module classifies the basic class of indoor spaces, cell spaces, into navigable or non-navigable spaces. Navigable spaces, in which users can move freely, are specified in two subclasses: transfer spaces (e.g. doors, entrances, hallways) and general spaces (e.g. rooms, terraces, lobbies), based on indoor navigation requirements. This discussion paper proposes an extension to the OGC IndoorGML core module to support new types of location-based services, such as autonomous driving robots, personal experience augmentation with augmented reality (AR) / virtual reality (VR), and facilities management, to understand activities and needs in indoor spaces. The proposed extension consists of three new indoor spaces to represent affordance spaces with structural, functional, and sensory characteristics by leveraging the multi-layered space representation of IndoorGML.

II.  Keywords

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

ogcdoc, OGC, IndoorGML, indoor spaces, affordances, experience spaces, facility spaces, structure spaces, IFC, CityGML, IMDF, BIM


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.  Security considerations

No security considerations have been made for this document.

V.  Submitting Organizations

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

VI.  Submitters

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

Name Affiliation
Kyong-Sook Kim National Institute of Advanced Industrial Science and Technology
Taehoon Kim National Institute of Advanced Industrial Science and Technology
Jiyeong Lee The University of Seoul
In-Hye Park The University of Seoul
Hye-Young Kang All for Land Inc.
Ki-Joune Li Pusan National University

Extensions of IndoorGML 1.1 - Indoor Affordance Spaces

1.  Scope

The scope of this OGC Discussion Paper is to propose an extended data model of affordance space for supporting human-agent interaction in indoor space. An agent can be any software, device, or system like a robot. Indoor agents are functional units that perform tasks of navigation and other tasks on behalf of human behavior without any intervention or direct interaction in indoor spaces. The indoor agent needs to understand the role and physical setting of each indoor space to carry out a task or provide a service in an indoor space where users can safely and efficiently continue their activities. Also, it can make the user experience more engaging. This document shows how to extend IndoorGML core and navigation modules for this interaction space between indoor agents and humans. In addition, the investigation of indoor features in existing indoor (and building) information models such as buildingSmart IFC, Esri ArcGIS Indoors, OGC CityGML, Apple and OGC IMDF is addressed. This discussion paper covers the following scopes:

scope

Figure 1 — Goal of the discussion paper

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: ISO 16739-1:2018, Industry Foundation Classes (IFC) for data sharing in the construction and facility management industries — Part 1: Data schema. International Organization for Standardization, Geneva (2018). https://www.iso.org/standard/70303.html

OGC® Indoor Geography Markup Language (IndoorGML) 1.1 (2020)

OGC City Geography Markup Language (CityGML) Part 1 : Conceptual Model Standard (2021)

Apple Inc.: OGC 20-094, Indoor Mapping Data Format. Open Geospatial Consortium (2021). https://docs.ogc.org/cs/20-094/index.html

3.  Terms and definitions

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.

3.1. experience space

space for user experience which interacts with the interactive objects

3.2. facility space

space to represent facility that physical installation or physical area that may be accessed and used

3.3. indoor agent

automated software, device, or system that performs a role in an indoor activity

3.4. structure space

space which physically or logically distinguishable and assembles part of a structure

3.5. user experience

person’s perceptions and responses resulting from the use and/or anticipated use of a product, system or service
(Source: ISO 9241-210:2010)

4.  Conventions

This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

4.1.  Abbreviated terms

The following abbreviated terms are used in this discussion paper:

Table 1

CityGMLCity Geographic Markup Language
CSIConstruction Specifications Institute
ESRIEnvironmental Systems Research Institute
GMLGeography Markup Language
IndoorGMLIndoor Geographic Markup Language
IMDFIndoor Mapping Data Format
IFCIndustry Foundation Classes
LBSLocation-Based Service
LODLevel of Detail
OGCOpen Geospatial Consortium
OmniClass or OCCSOmniClass™ Construction Classification System
POIPoints of Interest
UMLUnified Modeling Language

5.  Indoor affordance space module in IndoorGML

5.1.  Space affordance

The technological innovations such as internet of things (IoT), artificial intelligence (AI), and robots have led to the emergence of new types of services and products that collaborate autonomously with humans. Location-based services (LBS) are adapting to the interconnection between the digital and physical worlds with 3D environments and become more ambient to human behavior in indoor as well as outdoor spaces. LBS will support humans as intelligent agents that will be more finely customized to assist or take on a larger share of human activities, such as personal navigation with augmented reality (AR)/ virtual reality (VR), evacuation simulation, remote control for automated facility management, and human-robot collaboration. These LBS require more rich information to describe space to understand the affordance of a space and to explore the interconnection between two spaces. A space is a unit of digital representation of the real world. Indoor space is defined as “space within one or multiple buildings consisting of architectural components such as entrances, corridors, rooms, doors, and stairs” by the OGC IndoorGML standard. Most human activity refers to indoor environments. According to the National Human Activity Pattern Survey (NHAPS) report, about 87% of human activity takes place indoors and about 6% is in enclosed vehicles [1]. The term affordance was initially introduced in Ecology to describe the relational properties between an entity (a human or animal) and its environment [2]. The concept of affordance is applied to the design of human-computer interaction as a possibility for action. This document defines affordance space as space that allows an agent to perceive its environment and take actions for matching its goals. An affordance space is represented by the conjunction space of structural affordance, functional affordance, and sensory affordance, as shown in Figure 2. This document discusses how to extend the OGC IndoorGML core model for representing indoor affordance spaces to support human-agent interaction and improve the usability of indoor spaces.

affordancespace

Figure 2 — Affordance of indoor space

Structural affordance represents properties of forms (e.g. open, closed, semi-closed) and spatial hierarchy of physical (e.g. building, floor, room, door) or logical building parts (e.g. zone). It is a mandatory component of space utility. Functional affordance specifies purposeful action and helps an agent do something in the space. For example, a door can be opened and closed, and a chair can be sat on by a human. Even they can have different meanings depending on where they are located. Finally, sensory affordance plays a supporting role in human-agent interaction in an indoor space. It provides perceptual features that help an indoor agent augment the user’s experience in the space, such as seeing, hearing, feeling, and smelling.

NOTE  OGC CityGML has changed its core model with the concept of space in version 3.0. Even though OGC CityGML and buildingSmart IFC standards define the space bounded by physical or logical elements, OGC IndoorGML provides flexibility to describe the multiple relationships between spaces.

5.2.  IndoorGML core module

As shown in Figure 3, IndoorGML defines a standard data model for indoor space with two spatial models: Euclidean Space, which represents the shape of a three-dimensional (3D) cell space, and Topology Space, which describes the connectivity between cell spaces. Topology represents a duality transformation of the 3D cell space and is essential for indoor navigation and routing systems. The 3D cells in primal space are mapped to nodes (0D) in dual space by applying a duality transformation. The topological adjacency relationships between 3D cells are transformed to edges (1D) linking pairs of nodes in a dual space. Therefore, IndoorGML utilizes a network model for navigation and expresses the connectivity relationships between cell spaces. The nodes of the indoor network represent rooms, corridors, doors, elevators, and staircases. The edges of the indoor network represent the topological relationships among indoor spatial entities and can indicate the paths of pedestrian movement between nodes within a building. The IndoorGML network model is represented by nodes (as called State) and edges (as called Transition) feature, as shown in Figure 4.

indoorgml

Figure 3 — Structured space model (OGC 19-011r4, IndoorGML)

indoorgmlmodel

Figure 4 — Part of IndoorGML Core module UML diagram (OGC 19-011r4, IndoorGML)

5.3.  The conformance requirements of the IndoorGML core module

IndoorGML assumes every indoor feature object occupies a particular space that represents a cell space. Suppose that there are several objects in a bathroom as shown in Figure 5(a). An indoor agent wants to identify each element as shown in Figure 5(b) and to make an action plan. To represent those elements’ spaces in an IndoorGML document, they are assigned as instances of class CellSpace of the IndoorGML core module. However, this may conflict with the conformance requirements of the IndoorGML core module if the CellSpace instance of the bathroom is in the same SpaceLayer as the CellSpace instance of indoor feature objects, such as furnishing objects in the bathroom as shown in Figure 5(b). IndoorGML core requires to avoid the overlap of class CellSpace in the same layer of SpaceLayer as follows:

The following are Conformance Requirements of the IndoorGML Core Module:

  • Requirement 1: The instances of CellSpace belonging to the same instance of SpaceLayer shall not overlap.

  • Requirement 2: When a CellSpace instance is divided into a set of subspaces, the subspace instances shall not belong to the same SpaceLayer instance of the original CellSpace instance but form a new SpaceLayer instance.

  • Requirement 3: Every instance of InterLayerConnection shall connect two State instances, each of which belongs to different space layers.

If the CellSpace instances of furnishing objects and bathroom in the same SpaceLayer, this breaks the rules as specified in the requirements. To satisfy the requirements, the CellSpace of the bathroom has to be assigned with the remaining space, except for the CellSpace of furnishing objects, as shown in Figure 5©. However, the application requires a high cost for calculating the cell geometry with holes where objects are located. As a result, a separate SpaceLayer to define CellSpace of each indoor feature is required to manage indoor features in IndoorGML documents. This document obeys the conformance requirements to define indoor affordance spaces with three characteristics: structural, functional, and sensory affordances.

bathroom

Figure 5 — Example of indoor features (furnishing elements) in a bathroom

6.  UML diagram of Affordance Space Extension Module

Figure 6 illustrates a proposed new affordance space package, called AffordanceSpace. This package comprises thematic extension modules with the dependency relationships between IndoorGML modules. The package consists of three submodules defined by the module’s purpose: StructureSpace, FacilitySpace, ExperienceSpace modules. The AffordanceSpace modules are specified as an XML Schema definition file and are defined within an individual and globally unique XML target namespace as shown in Table 2.

poipackage

Figure 6 — AffordanceSpace UML package diagram

Table 2 — AffordanceSpace modules and namespace identifier

Module Name IndoorGML StructureSpace
XML Namespace Identifier

http://www.opengis.net/indoorgml/1.0/affordance/strcturespace
XML Schema File Name

StructureSpace.xsd
Namespace Prefix

Structure
Module Description

The StructureSpace module defines the IndoorGML core module’s semantic extension to represent the indoor structural information. This module also includes the schema definitions of the classes to handle spatial hierarchy information.

Table 3

Module Name IndoorGML FacilitySpace
XML Namespace Identifier

http://www.opengis.net/indoorgml/1.0/affordance/facilityspace
XML Schema File Name

FacilitySpace.xsd
Namespace Prefix

Facility
Module Description

The FacilitySpace module defines the IndoorGML core module’s semantic extension to represent the indoor facility and furniture information. This module also includes the schema definitions of the classes to handle indoor facility information.

Table 4

Module Name IndoorGML ExperienceSpace
XML Namespace Identifier

http://www.opengis.net/indoorgml/1.0/affordance/experiencespace
XML Schema File Name

ExperienceSpace.xsd
Namespace Prefix

Experience
Module Description

The ExperienceSpace module defines the semantic extension to the IndoorGML core module as to how to represent the indoor feature in a visualization. It also includes the schema definitions of the classes to handle various experience objects.

6.1.  StructureSpace module

The UML diagram depicted in Figure 7 shows the data model of the StructureSpace module based on the IndoorGML core module. The StructureSpace module represents a more detailed hierarchy structure than the IndoorGML core module.

structurespaceuml

Figure 7 — StructureSpace module UML class diagram

The StructureSpace module defines spatial hierarchy as three physical types (Section, Storey, and Unit) and one logical type (Zone), as below:

  • Section is a building part that has a set of its own floors.

  • Storey is a part of the section and consists of a set of Unit that is non-overlapping.

  • Unit is a unit space of the StructureSpace module.

  • Zone is a logical space consisting of a set of Unit.

Figure 8 can show a simple example and relation of each space type of StructureSpace module. Note that PrimalSpaceFeatures is defined in the IndoorGML core module.

structurespacehierarchy

Figure 8 — Hierarchy of SpaceLayers in StructureSpace module

As mentioned in section Clause 5.3, a separate space layer SectionSpaceLayer to define Section is required to satisfy IndoorGML core module requirements. Of course, users can use State and SpaceLayer appropriately to meet these requirements, but to avoid violating the requirements, SectionState, related space layers and the necessary classes were separately defined in the StructureSpace module. Therefore, Section can only have duality as SectionState. Also, SectionSpaceLayer can only have nodes as SectionState. The case of Storey (and Unit) is also similarly defined to Section, to satisfy IndoorGML core module requirements. Note that Zone is not inherited CellSpace which is defined in the IndoorGML core module; therefore, Zone is not affected by IndoorGML core module requirements.


6.1.1.  <StructureSpace>

The StructureSpace class inherited from CellSpace contains common attributes for the structure space. This class has two attributes: capacity and structureForm.

  • capacity means how many people can be in the structure.

  • structureForm means the form of structure code.

Figure 9 shows an XML encoding schema for the StructureSpace class.



<xs:element name="StructureSpace" type="StructureSpaceType" substitutionGroup="IndoorCore:CellSpace"/>
<xs:complexType name="StructureSpaceType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:CellSpaceType">
            <xs:sequence>
                <xs:element name="capacity" type="xs:int" minOccurs="0"/>
                <xs:element name="structureForm" type="gml:CodeType" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="StructureSpacePropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="StructureSpace"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

Figure 9 — Schema 1. StructureSpace XML Schema

6.1.2.  <Section>

The Section class inherited from StructureSpace represents a building part, such as a mall in a complex shopping mall. In a minor view, Section is also a building because it consisted of a set of levels. Section has various attributes to represent its structural properties.

  • elevation is how tall this Section is in relation to the located ground.

  • storeyAboveGround is a number of the floors above the ground level.

  • storeyUnderGround is a number of the floors below the ground level.

  • storeys mean included Storey in this Section.

  • including indicate included Zone in this Section.

In order to satisfy the IndoorGML conformance requirements as mentioned in section Clause 5.3, the Section class has SectionState and SectionSpaceLayer to explicitly represent SpaceLayer for Section.

Figure 10 shows an XML encoding schema for the Section class.



<xs:element name="Section" type="SectionType" substitutionGroup="StructureSpace"/>
<xs:complexType name="SectionType">
    <xs:complexContent>
        <xs:extension base="StructureSpaceType">
            <xs:sequence>
                <xs:element name="elevation" type="xs:double" minOccurs="0"/>
                <xs:element name="storeyAboveGround" type="xs:int" minOccurs="0"/>
                <xs:element name="storeyUnderGround" type="xs:int" minOccurs="0"/>
                <xs:element name="storeys" type="StoreyPropertyType" minOccurs="0" maxOccurs="unbounded"/>
                <xs:element name="including" type="ZonePropertyType" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="SectionPropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="Section"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="SectionState" type="SectionStateType" substitutionGroup="IndoorCore:State"/>
<xs:complexType name="SectionStateType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:StateType">
            <xs:sequence>
                <xs:element name="duality" type="SectionPropertyType" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="SectionStatePropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="SectionState"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="SectionSpaceLayer" type="SectionSpaceLayerType" substitutionGroup="IndoorCore:SpaceLayer"/>
<xs:complexType name="SectionSpaceLayerType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:SpaceLayerType">
            <xs:sequence>
                <xs:element name="nodes" type="SectionNodesType" minOccurs="1" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="SectionNodesType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureType">
            <xs:sequence>
                <xs:element name="stateMember" type="SectionStateMemberType" minOccurs="1" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attributeGroup ref="gml:AggregationAttributeGroup"/>
            <xs:attributeGroup ref="gml:OwnershipAttributeGroup"/>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="SectionStateMemberType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureMemberType">
            <xs:sequence minOccurs="0">
                <xs:element ref="SectionState"/>
            </xs:sequence>
            <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

Figure 10 — Schema 2. Section XML Schema

6.1.3.  <Storey>

The Storey class inherited from StructureSpace represents a certain Storey to be included in a Section. The Storey consists of a set of Unit elements via a units property. In order to satisfy the IndoorGML conformance requirements as mentioned in section Clause 5.3, the Storey class has StoreyState and StoreySpaceLayer elements to explicitly represent a SpaceLayer for a Storey.

Figure 11 shows an XML encoding schema for the Storey class.



<xs:element name="Storey" type="StoreyType" substitutionGroup="StructureSpace"/>
<xs:complexType name="StoreyType">
    <xs:complexContent>
        <xs:annotation>
            <xs:documentation>
                units don't allow intersection between any Units.
            </xs:documentation>
        </xs:annotation>
        <xs:extension base="StructureSpaceType">
            <xs:sequence>
                <xs:element name="units" type="UnitPropertyType" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="StoreyPropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="Storey"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="StoreyState" type="StoreyStateType" substitutionGroup="IndoorCore:State"/>
<xs:complexType name="StoreyStateType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:StateType">
            <xs:sequence>
                <xs:element name="duality" type="StoreyPropertyType" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="StoreyStatePropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="StoreyState"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="StoreySpaceLayer" type="StoreySpaceLayerType" substitutionGroup="IndoorCore:SpaceLayer"/>
<xs:complexType name="StoreySpaceLayerType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:SpaceLayerType">
            <xs:sequence>
                <xs:element name="nodes" type="StoreyNodesType" minOccurs="1" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="StoreyNodesType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureType">
            <xs:sequence>
                <xs:element name="stateMember" type="StoreyStateMemberType" minOccurs="1" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attributeGroup ref="gml:AggregationAttributeGroup"/>
            <xs:attributeGroup ref="gml:OwnershipAttributeGroup"/>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="StoreyStateMemberType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureMemberType">
            <xs:sequence minOccurs="0">
                <xs:element ref="StoreyState"/>
            </xs:sequence>
            <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

Figure 11 — Schema 3. Storey XML Schema

6.1.4.  <Unit>

The Unit class inherited from StructureSpace is a base class of the StructureSpace module, such as a room in a building. All CellSpace instances in the StructureSpace module should consist of one or more Unit elements. The Unit can represent its form of space via the fromOfSpace attribute. It consisted of four types as “Closed Space”, “Covered Space”, “Open Space”, and “Semi-Open Space”. This form of space is referenced from OmniClass Table 14 (Space by Form) [6]. The Door class is one type of Unit class. In order to satisfy the IndoorGML conformance requirements as mentioned in section Clause 5.3, the Unit class has UnitState and UnitSpaceLayer to explicitly represent SpaceLayer for Unit.

Figure 12 shows an XML encoding schema for the Unit class.



<xs:element name="Unit" type="UnitType" substitutionGroup="StructureSpace"/>
<xs:complexType name="UnitType">
    <xs:complexContent>
        <xs:extension base="StructureSpaceType">
            <xs:sequence>
                <xs:element name="formOfSpace" type="FormOfSpaceCodeType" minOccurs="0"/>
                <xs:element name="roomHeight" type="xs:double" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="UnitPropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="Unit"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<xs:simpleType name="FormOfSpaceCodeType">
    <xs:restriction base="xs:string">
        <xs:enumeration value="Closed Space"/>
        <xs:enumeration value="Semi-Open Space"/>
        <xs:enumeration value="Open Space"/>
        <xs:enumeration value="Covered Space"/>
    </xs:restriction>
</xs:simpleType>
<!--  ======================================================================  -->
<xs:element name="UnitState" type="UnitStateType" substitutionGroup="IndoorCore:State"/>
<xs:complexType name="UnitStateType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:StateType">
            <xs:sequence>
                <xs:element name="duality" type="UnitPropertyType" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="UnitStatePropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="UnitState"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="UnitSpaceLayer" type="UnitSpaceLayerType" substitutionGroup="IndoorCore:SpaceLayer"/>
<xs:complexType name="UnitSpaceLayerType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:SpaceLayerType">
            <xs:sequence>
                <xs:element name="nodes" type="UnitNodesType" minOccurs="1" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="UnitNodesType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureType">
            <xs:sequence>
                <xs:element name="stateMember" type="UnitStateMemberType" minOccurs="1" maxOccurs="unbounded"/>
            </xs:sequence>
            <xs:attributeGroup ref="gml:AggregationAttributeGroup"/>
            <xs:attributeGroup ref="gml:OwnershipAttributeGroup"/>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="UnitStateMemberType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureMemberType">
            <xs:sequence minOccurs="0">
                <xs:element ref="UnitState"/>
            </xs:sequence>
            <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="Door" type="DoorType" substitutionGroup="Unit"/>
<xs:complexType name="DoorType">
    <xs:complexContent>
        <xs:extension base="UnitType"/>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="DoorPropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="Door"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

Figure 12 — Schema 4. Unit XML Schema

6.1.5.  <Zone>

The Zone class represents a logical space by a set of Unit classes. It can be used to represent vertical connected space such as elevator space. It can also be used to represent a certain zone with a special meaning, such as a school zone. The Zone class is not a type of CellSpace because the State (and Transition) of Zone is not necessary.

Figure 13 shows an XML encoding schema for the Zone class.



<xs:element name="Zone" type="ZoneType" substitutionGroup="gml:AbstractFeature"/>
<xs:complexType name="ZoneType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureType">
            <xs:sequence>
                <xs:element name="units" type="UnitPropertyType" minOccurs="0" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="ZonePropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="Zone"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

Figure 13 — Schema 5. Zone XML Schema

6.1.6.  <StructureSpaceBoundary>

The StructureSpaceBoundary class inherited from CellSpaceBoundary represents a physical boundary of the StructureSpace class. To represent its physical boundary type, the StructureSpaceBoundary class has a type attribute. This class can be distinguished by physical boundary types such as Ceiling, Exterior Wall , Interior Wall, Floor, Roof, Door, and Window.

Figure 14 shows an XML encoding schema for the StructureSpaceBoundary class.



<xs:element name="StructureSpaceBoundary" type="StructureSpaceBoundaryType" substitutionGroup="IndoorCore:CellSpaceBoundary"/>
<xs:complexType name="StructureSpaceBoundaryType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:CellSpaceBoundaryType">
            <xs:sequence>
                <xs:element name="type" type="PhysicalBoundaryTypeCodeType"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="StructureSpaceBoundaryPropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="StructureSpaceBoundary"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<xs:simpleType name="PhysicalBoundaryTypeCodeType">
    <xs:restriction base="xs:string">
        <xs:enumeration value="Ceiling"/>
        <xs:enumeration value="Exterior Wall"/>
        <xs:enumeration value="Floor"/>
        <xs:enumeration value="Interior Wall"/>
        <xs:enumeration value="Roof"/>
        <xs:enumeration value="Door"/>
        <xs:enumeration value="Window"/>
    </xs:restriction>
</xs:simpleType>

Figure 14 — Schema 6. StructureSpaceBoundary XML Schema


6.2.  FacilitySpace module

The UML diagram depicted in Figure 15 shows the data model of the FacilitySpace module based on the IndoorGML core module.