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.

facilityspaceuml

Figure 15 — FacilitySpace module UML class diagram

6.2.1.  <FacilitySpace>

The FacilitySpace (and FacilitySpaceBoundary) class inherited from CellSpace (and CellSpaceBoundary) represents the facility and furniture features in indoor space. There is no additional attribute nor property. These classes are mainly defined for making their own space layer explicitly. The detailed information is described in section Clause 6.2.2.

Figure 16 shows an XML encoding schema for the FacilitySpace class.



<xs:element name="FacilitySpace" type="FacilitySpaceType" substitutionGroup="IndoorCore:CellSpace"/>
<xs:complexType name="FacilitySpaceType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:CellSpaceType">
            <xs:sequence>
                <xs:element name="duality" type="FacilityStatePropertyType" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="FacilitySpacePropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="FacilitySpace"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="FacilitySpaceBoundary" type="FacilitySpaceBoundaryType" substitutionGroup="IndoorCore:CellSpaceBoundary"/>
<xs:complexType name="FacilitySpaceBoundaryType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:CellSpaceBoundaryType"/>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="FacilitySpaceBoundaryPropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="FacilitySpaceBoundary"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

Figure 16 — Schema 7. FacilitySpace and FacilitySpaceBoundary XML Schema

FacilitySpace consisted of four subclasses by its characteristic:

  • Furniture: Can’t move itself, such as chair or desk.

  • StationaryFacility: Installation facility. Its location rarely changes. Examples are elevators, escalators, or stairs.

  • MobileFacility: Can move itself, such as a robot or pedestrian.

  • SensorFacility: Monitoring or sensing sensor, such as CCTV.

Note that each subclass has several attributes:

  • Each class can have its type code from OmniClass [6] or other references or a user-defined one.

  • The serviceTime attribute indicates the life span of the class instance.

  • StationaryFacility can have optional attributes, such as capacityByCount, capacityByWeight, and fireExit, which can be utilized in service.



<xs:element name="Furniture" type="FurnitureType" substitutionGroup="FacilitySpace"/>
<xs:complexType name="FurnitureType">
    <xs:complexContent>
        <xs:extension base="FacilitySpaceType">
            <xs:sequence>
                <xs:element name="furnitureType" type="gml:CodeType" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:element name="StationaryFacility" type="StationaryFacilityType" substitutionGroup="FacilitySpace"/>
<xs:complexType name="StationaryFacilityType">
    <xs:complexContent>
        <xs:extension base="FacilitySpaceType">
            <xs:sequence>
                <xs:element name="stationaryType" type="gml:CodeType" minOccurs="0"/>
                <xs:element name="capacityByCount" type="gml:Count" minOccurs="0"/>
                <xs:element name="capacityByWeight" type="gml:MeasureType" minOccurs="0"/>
                <xs:element name="fireExit" type="gml:Boolean" minOccurs="0"/>
                <xs:element name="serviceTime" type="gml:validTime" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:element name="MobileFacility" type="MobileFacilityType" substitutionGroup="FacilitySpace"/>
<xs:complexType name="MobileFacilityType">
    <xs:complexContent>
        <xs:extension base="FacilitySpaceType">
            <xs:sequence>
                <xs:element name="mobileType" type="gml:CodeType" minOccurs="0"/>
                <xs:element name="serviceTime" type="gml:validTime" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:element name="SensorFacility" type="SensorFacilityType" substitutionGroup="FacilitySpace"/>
<xs:complexType name="SensorFacilityType">
    <xs:complexContent>
        <xs:extension base="FacilitySpaceType">
            <xs:sequence>
                <xs:element name="sensorType" type="gml:CodeType" minOccurs="0"/>
                <xs:element name="serviceTime" type="gml:validTime" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

Figure 17 — Schema 8. Implemented class of FacilitySpace XML Schema

6.2.2.  <FacilityState> and <FacilitySpaceLayer>

The FacilityState class inherits State, to represent FacilitySpaceLayer explicitly. When FacilitySpace represents 3D (and 2D) models of indoor environments, as shown in Figure 18, the models occupy a certain space. As mentioned in section Clause 5.3, a separate space layer (FacilitySpaceLayer) to define FacilitySpace 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, FacilityState, FacilitySpaceLayer and the necessary classes were separately defined in the FacilitySpace module. This means FacilitySpace can only have duality as FacilityState. Also, FacilitySpaceLayer can only have nodes as FacilityState.

intersectedfacilityspace

Figure 18 — Example of FacilitySpace and StructureSpace

Figure 19 and Figure 20 shows an XML encoding schema for the FacilityState and FacilitySpaceLayer class.



<xs:element name="FacilityState" type="FacilityStateType" substitutionGroup="IndoorCore:State"/>
<xs:complexType name="FacilityStateType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:StateType">
            <xs:sequence>
                <xs:element name="duality" type="FacilitySpacePropertyType" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="FacilityStatePropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="FacilityState"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

Figure 19 — Schema 9. FacilityState XML Schema



<xs:element name="FacilitySpaceLayer" type="FacilitySpaceLayerType" substitutionGroup="IndoorCore:SpaceLayer"/>
<xs:complexType name="FacilitySpaceLayerType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:SpaceLayerType">
            <xs:sequence>
                <xs:element name="nodes" type="FacilityNodesType" minOccurs="1" maxOccurs="unbounded"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="FacilityNodesType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureType">
            <xs:sequence>
                <xs:element name="stateMember" type="FacilityStateMemberType" 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="FacilityStateMemberType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureMemberType">
            <xs:sequence minOccurs="0">
                <xs:element ref="FacilityState"/>
            </xs:sequence>
            <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>

Figure 20 — Schema 10. FacilitySpaceLayer XML Schema


6.3.  ExperienceSpace module

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

experienceuml

Figure 21 — ExperienceSpace module UML class diagram

6.3.1.  <ExperienceSpace>

The ExperienceSpace class inherited from CellSpace contains geometry attributes for the indoor feature space. The geometric representation and semantic structure of an ExperienceSpace is shown in Figure 21. Similar to OGC CityGML 3.0, this model allows for the representation of spatial aspects of indoor feature in three predefined Levels of Detail (LOD1 to LOD3), with attributes of LOD1Solid, LOD2Solid, and LOD3Solid. The definition of different Levels of Detail follows that specified in the OGC CityGML 3.0 Standard. Note that ExperienceSpace class represents only volumetric space; however, the LOD0 of CityGML is a projection of the shape of a space. Therefore, ExperienceSpace class only used LOD1 to LOD3.

Figure 22 shows an XML encoding schema for the ExperienceSpace class.



<xs:element name="ExperienceSpace" type="ExperienceSpaceType" substitutionGroup="IndoorCore:CellSpace"/>
<xs:complexType name="ExperienceSpaceType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:CellSpaceType">
            <xs:sequence>
                <xs:element name="class" type="gml:CodeType"/>
                <xs:element name="function" type="gml:CodeType"/>
                <xs:element name="LOD1Solid" type="gml:SolidPropertyType" minOccurs="0"/>
                <xs:element name="LOD2Solid" type="gml:SolidPropertyType" minOccurs="0"/>
                <xs:element name="LOD3Solid" type="gml:SolidPropertyType" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="ExperienceSpacePropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="ExperienceSpace"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

Figure 22 — Schema 11. ExperienceSpace XML Schema

Geometry and Level of Detail from OGC CityGML 3.0 Part 1:Conceptual Model Standard

The OGC CityGML 3.0 Part 1:Conceptual Model Standard identifies a set of Level of Detail (LOD) definitions. The classification of real-world objects into spaces and space boundaries is solely based on the semantics of these objects and not on their used geometry type, as the CityGML 3.0 CM allows various geometrical representations for objects. A building, for instance, can be spatially represented by a 3D solid (e.g., in LOD1), but at the same time, the real-world geometry can also be abstracted by a single point, footprint or roof print (LOD0), or by a 3D mesh (LOD3). The outer shell of the building may also be semantically decomposed into wall, roof, and ground surfaces. Figure 23 shows different representations of the same real-world building object in different geometric LODs (and appearances).

lodexample

Figure 23 — Representation of the same real-world building in the Levels of Detail 0-3 (OGC 20-010, CityGML)

The biggest changes between CityGML 3.0 and earlier versions are the following.

  • LOD4 was dropped, because now all feature types can have outdoor and indoor elements in LODs 0-3 (for those city objects where it makes sense like buildings, tunnels, or bridges). This means that the outside shell such as of a building, could be spatially represented in LOD2 and the indoor elements like rooms, doors, hallways, stairs etc. in LOD1. CityGML can now be used to represent building floor plans, which are LOD0 representations of building interiors (cf. Konde et al. 2018). It is even possible to model the outside shell of a building in LOD1, while representing the interior structure in LOD2 or 3. Figure 24 shows different indoor/outdoor representations of a building. Details on the changes to the CityGML LOD concept are provided in [8].

  • Levels of Detail are no longer associated with the degree of semantic decomposition of city objects and refer to the spatial representations only. This means that, for example, buildings can have thematic surfaces (like WallSurface, GroundSurface) also in LODs 0 and 1 and windows and doors can be represented in all LODs 0-3. In CityGML 2.0 or earlier thematic surfaces were only allowed starting from LOD2, openings like doors and windows starting from LOD3, and interior rooms and furniture only in LOD4.

lodexample

Figure 24 — Floor plan representation (LOD0) of a building (left), combined LOD2 indoor and outdoor representation (right). Image adopted from [8].

Spaces and all its subclasses like Building, Room, and TrafficSpace can now be spatially represented by single points in LOD0, multi-surfaces in LOD0/2/3, solids in LOD1/2/3, and multi-curves in LOD2/3. Space Boundaries and all its subclasses such as WallSurface, LandUse, or Relief can now be represented by multi-surfaces in LOD0/2/3 and as multi-curves in LOD2/3.

Spaces and space boundaries can have various geometry representations depending on the Levels of Detail (LOD). Spaces can be spatially represented as single points in LOD0, multi-surfaces in LOD0/2/3, solids in LOD1/2/3, and multi-curves in LOD2/3. Space boundaries can be represented as multi-surfaces in LOD0/2/3 and as multi-curves in LOD2/3. All Levels of Detail allow for the representation of the interior of city objects.

The different Levels of Detail are defined in the OGC CityGML 3.0 Part 1:Conceptual Model Standard in the following way.

  • LOD 0: Volumetric real-world objects (Spaces) can be spatially represented by a single point, by a set of curves, or by a set of surfaces. Areal real-world objects (Space Boundaries) can be spatially represented in LOD0 by a set of curves or a set of surfaces. LOD0 surface representations are typically the result of a projection of the shape of a volumetric object onto a plane parallel to the ground, hence, representing a footprint (e.g., a building footprint or a floor plan of the rooms inside a building). LOD0 curve representations are either the result of a projection of the shape of a vertical surface (e.g., a wall surface) onto a grounding plane or the skeleton of a volumetric shape of longitudinal extent such as a road or river segment.

  • LOD 1: Volumetric real-world objects (Spaces) are spatially represented by a vertical extrusion solid, i.e., a solid created from a horizontal footprint by vertical extrusion. Areal real-world objects (Space Boundaries) can be spatially represented in LOD1 by a set of horizontal or vertical surfaces.

  • LOD 2: Volumetric real-world objects (Spaces) can be spatially represented by a set of curves, a set of surfaces, or a single solid geometry. Areal real-world objects (Space Boundaries) can be spatially represented in LOD2 by a set of surfaces. The shape of the real-world object is generalized in LOD2 and smaller details (e.g., bulges, dents, sills, but also structures, like balconies or dormers of buildings) are typically neglected. LOD2 curve representations are skeletons of volumetric shapes of longitudinal extent like an antenna or a chimney.

  • LOD 3: Volumetric real-world objects (Spaces) can be spatially represented by a set of curves, a set of surfaces, or a single solid geometry. Areal real-world objects (Space Boundaries) can be spatially represented in LOD3 by a set of surfaces. LOD3 is the highest level of detail and respective geometries include all available shape details.

6.3.2.  <ExperienceSpaceBoundary>

The ExperienceSpaceBoundary class inherited from CellSpaceBoundary contains common attributes for the indoor feature’s space boundary. Like the ExperienceSpace class, the ExperienceSpaceBoundary class has attributes of LOD1Surface, LOD2Surface, and LOD3Surface. ExperienceSpaceBoundary can represent the boundedBy relationship to ExperienceSpace, with inherited partialBoundedBy property. Lastly, the ExperienceSpaceBoundary class has the overlaying property to represent ExperienceObject which overlays on ExperienceSpaceBoundary, such as a texture, photo, advertisement, and so on.

Figure 25 shows an XML encoding schema for the ExperienceSpaceBoundary class.



<xs:element name="ExperienceSpaceBoundary" type="ExperienceSpaceBoundaryType" substitutionGroup="IndoorCore:CellSpaceBoundary"/>
<xs:complexType name="ExperienceSpaceBoundaryType">
    <xs:complexContent>
        <xs:extension base="IndoorCore:CellSpaceBoundaryType">
            <xs:sequence>
                <xs:element name="overlaying" type="ExperienceObjectPropertyType" minOccurs="0" maxOccurs="unbounded"/>
                <xs:element name="LOD1Surface" type="gml:SurfacePropertyType" minOccurs="0"/>
                <xs:element name="LOD2Surface" type="gml:SurfacePropertyType" minOccurs="0"/>
                <xs:element name="LOD3Surface" type="gml:SurfacePropertyType" minOccurs="0"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="ExperienceSpaceBoundaryPropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="ExperienceSpaceBoundary"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

Figure 25 — Schema 12. ExperienceSpaceBoundary XML Schema

6.3.3.  <ExperienceObject>

The ExperienceObject class represents objects that agents can experience (and interact with) in a space. The experience object has three essential attributes and one optional attribute:

  • The locateAt attribute represents the location of ExperienceObject, on the ExperienceSpaceBoundary, which is overlayed.

  • The resource attribute represents accessible multimedia.

  • The validTime attribute indicates the life span of the ExperienceObject.

  • The name attribute that represents the object’s name is optional.

In this DP, the ExperienceObject class has four subclasses according to perceptual features:

  • VisualObject: visible multimedia, such as texture, photo.

  • SoundObject: audible multimedia, such as guidance audio.

  • TouchObject: touch-enabled object.

  • SmellObject: smelly object such as perfume.

Figure 26 shows an XML encoding schema for the ExperienceObject and its subclasses.



<xs:element name="ExperienceObject" type="ExperienceObjectType" substitutionGroup="gml:AbstractFeature"/>
<xs:complexType name="ExperienceObjectType">
    <xs:complexContent>
        <xs:extension base="gml:AbstractFeatureType">
            <xs:sequence>
                <xs:element name="name" type="xs:string" minOccurs="0"/>
                <xs:element name="locatedAt" type="gml:GeometryPropertyType"/>
                <xs:element name="resource" type="xs:anyURI"/>
                <xs:element name="validTime" type="gml:validTime"/>
            </xs:sequence>
        </xs:extension>
    </xs:complexContent>
</xs:complexType>
<xs:complexType name="ExperienceObjectPropertyType">
    <xs:sequence minOccurs="0">
        <xs:element ref="ExperienceObject"/>
    </xs:sequence>
    <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="VisualObject" type="VisualObjectType" substitutionGroup="ExperienceObject"/>
<xs:complexType name="VisualObjectType">
    <xs:complexContent>
        <xs:extension base="ExperienceObjectType"/>
    </xs:complexContent>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="SoundObject" type="SoundObjectType" substitutionGroup="ExperienceObject"/>
<xs:complexType name="SoundObjectType">
    <xs:complexContent>
        <xs:extension base="ExperienceObjectType"/>
    </xs:complexContent>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="TouchObject" type="TouchObjectType" substitutionGroup="ExperienceObject"/>
<xs:complexType name="TouchObjectType">
<xs:complexContent>
    <xs:extension base="ExperienceObjectType"/>
</xs:complexContent>
</xs:complexType>
<!--  ======================================================================  -->
<xs:element name="SmellObject" type="SmellObjectType" substitutionGroup="ExperienceObject"/>
<xs:complexType name="SmellObjectType">
<xs:complexContent>
    <xs:extension base="ExperienceObjectType"/>
</xs:complexContent>
</xs:complexType>

Figure 26 — Schema 13. ExperienceObject XML Schema


7.  Harmonizing with Building Models

7.1.  Methodology

This section will look at other data models of building interiors and show how the models can map to the proposed affordance space, as shown in Figure 27.

  • To select de facto and de jure standards for building representation: buildingSmart IFC, OGC CityGML, Esri ArcGIS Indoors, and Apple and OGC IMDF models are considered in this document;

  • To investigate definition and properties of model classes to represent buildings: The building interiors are classified into three elements- space representation elements (e.g. building parts, storeys, rooms), physical building feature elements (e.g. walls, floors, doors), and facility elements (e.g. furniture, installations, sensors);

  • To analyze hierarchical representation of space; A building consists of building parts and each part contains storeys and rooms structurally. Each model uses different terms to represent these elements. Based on the definition and properties, this document shows their hierarchical relationships;

  • To map each feature element to an affordance space: The space representation elements and physical building feature elements are assigned to structural affordance spaces. The facility elements are assigned to functional affordance spaces. The special class for visualization is assigned to sensory affordance spaces.

methodology

Figure 27 — Processes of building model analysis


7.2.  buildingSmart Industry Foundation Classes (IFC)

7.2.1.  Purpose

The Industry Foundation Classes (IFC) [7] standard enables the exchange and sharing of the Building Information Model (BIM) data between software applications used by various participants in the construction or facility management industry sector. Among many aspects of the IFC model, manufacturing, supply, creation, or spatial elements and their relationships are selected as the classes of the feature model.

7.2.2.  Relevant feature classes for building modeling

An example of IFC elements covering the three categories of physical, facility, and space is shown in Figure 28.

ifcclassificationsystem

Figure 28 — Example of IFC elements by three categories (physical, facility, and space)

Some of the IFC feature classes that are relevant for building modeling are listed in Table 5.

Table 5 — Class definition from Industry Foundation Classes [7]

NameDescription
IfcRoot

Most abstract and root class for all entity definitions that roots in the kernel or in subsequent layers of the IFC specification.

IfcObject Definition

Contains all the useful objects to fully describe a construction asset. The word ‘object’ refers to an abstract or tangible entity that represents the description of a construction part.

IfcProduct

Base class for all the entities of a project and therefore made up of spatial elements, physical elements, structural analysis elements and other concepts. An abstract representation of any object that relates to a geometric or spatial context. Occurs at a specific location in space if it has a geometric representation assigned.

IfcElement

Physically existent objects, such as walls or doors. These remain permanently in the Architecture, Engineering and Construction product, or only temporarily. Includes IfcBuildingElement, IfcDistributionElement, IfcFurnishingElement, and IfcTransportElement.

IfcBuilding Element

Comprises all elements that are primarily part of the construction of a built facility. i.e., its structural and space separating system. Building elements are all physically existent and tangible things including. All physically existent and tangible things.

IfcDistribution Element

A generalization of all elements that participate in a distribution system. Include building service elements within a heating system or cooling, building service elements within a plumbing system, and electrical elements.

IfcFurnishing Element

A generalization of all furniture related objects. Characterized as being pre-manufactured and assembled on-site, or manufactured on-site (built-in). Thus furnishing elements can either be movable, or not (as the built-ins).

IfcTransport Element

A generalization of all transport related objects that move people, animals or goods within a building or building complex. Defines the occurrence of a transport element, that (if given), is expressed by the IfcTransportElementType. Has the ‘type’ property for the categories of transport, like elevators or escalators.

IfcSpatial Element

The generalization of all spatial elements that might be used to define a spatial structure or to define spatial zones. Includes IfcSpatialZone and IfcSpatialStructureElement.

IfcSpatial Zone

A potentially overlapping decomposition of the project under some functional consideration. Might be used to represent a thermal zone, a construction zone, a lighting zone, a usable area zone.

IfcSpatial Structure Element

The generalization of all spatial elements that might be used to define a spatial structure. Often used to provide a project structure to organize a building project.

IfcSite

A defined area of land, possibly covered with water, on which the project construction is to be completed. May be used to erect, retrofit or tear down building(s), or for other construction related developments.

IfcBuilding

Represents a structure that provides shelter for its occupants or contents and stands in one place. Also used to provide a basic element within the spatial structure hierarchy for the components of a building project (together with Site, Storey, and Space).

IfcBuilding Storey

Has an elevation and typically represents a (nearly) horizontal aggregation of spaces that are vertically bound. (if specified) Associated to a building.

IfcSpace

Represents an area or volume bounded actually or theoretically. Areas or volumes that provide for certain functions within a building. A space is associated to a building storey (or in case of exterior spaces to a site).

7.2.3.  Spatial hierarchy

IfcSpatialElement has a spatial hierarchy relation as below:

  • IfcSite aggregates one or more IfcBuilding.

  • IfcBuilding aggregates one or more IfcBuildingStorey.

  • IfcBuildingStorey aggregates one or more IfcSpaces.

  • IfcSpatialZone is defined as a non-hierarchical spatial element.

ifcspatialhierarchy

Figure 29 — Examples of spatial hierarchy relation of IFC

7.2.4.  Visualization class

The IfcPresentationItem is the abstract supertype of all entities used for presentation appearance definitions in the IFC 4×2. IfcPresentationItem has many inherited entities, including IfcSurfaceTexture and IfcTextureCoordinate. The ExperienceObject in DP can be directly used as information IfcSurfaceTexture (or IfcImageTexture which has an image URI) with IfcTextureCoordinate, to map with the sensory affordance space.

7.2.5.  Summary

The three types of element (physical, facility, and space) of IFC can be summarized as follows:

  • IfcBuildingElement defines physical elements. Those physical elements include Door, Roof, Stair, Wall, and Window.

  • IfcDistributionElement, IfcFurnishingElement, and IfcTransportElement define facility elements. Those facilities are distribution systems, furniture, and transport.

  • IfcSite, IfcBuilding, IfcBuildingStorey, IfcSpace, and IfcSpatialZone define space elements.

The spatial hierarchy of the IFC can be summarized as follows:

  • Space hierarchy consists of IfcSite, IfcBuilding, IfcBuildingStorey, and IfcSpace. The preceding feature contains the following feature.

  • IfcSpatialZone can be defined independently regardless of how space or storey is defined.

As the result, the affordance spaces are mapped as below:

  • The structural affordance space: IfcBuildingElement, IfcSite, IfcBuilding, IfcBuildingStorey, IfcSpace, and IfcSpatialZone

  • The functional affordance space: IfcDistributionElement, IfcFurnishingElement, and IfcTransportElement

  • The sensory affordance space: IfcSurfaceTexture, IfcImageTexture


7.3.  Esri ArcGIS Indoors Information Model (AIIM)

7.3.1.  Purpose

ArcGIS Indoors Information Model (AIIM [4]) supports indoor GIS information management for sharing web maps and mobile map packages suitably configured for use with ArcGIS Indoors Web, the ArcGIS Indoors app for iOS and Android. ArcGIS Indoors consists of two data models: AIIM and Network. AIIM is a data model with a collection of feature classes related to building modeling.

7.3.2.  Relevant feature classes for building modeling

Among the two different kinds of information in the AIIM model, the information related to indoor spaces is chosen for the proposed IndoorGML feature model. The information related to indoor spaces has eight related feature classes, including Sites, Facilities, Levels, Sections, Zones, Units, Details, and PointsOfInterest (POI).

aiimclassificationsystem

Figure 30 — Examples of spatial hierarchy relation of AIIM

Some of the AIIM feature classes that are relevant for building modeling are listed in Table 6.

Table 6 — Class definition from Esri ArcGIS Indoors Information Model

NameDescription
Site

Describes the boundaries of managed sites and is used for visualization.

Facilities

Describes the footprints of managed facilities.

Levels

Describes the footprint of each level contained in managed facilities. Levels footprints must be contained in a Facilities feature.

Zones

Describes the footprints of possibly overlapping areas of organization in a level, such as security, functional, managerial, retail zones, and so on, and used for visualization in mapmaking. Zones footprints must be contained in a Levels feature.

Sections

Describes the footprints of nonoverlapping areas of organization in a level, such as wings, and used for visualization. Sections footprints must be contained in a Levels feature.

Units

Describes the footprints of nonoverlapping individual functional areas such as workspaces, amenities, retail spaces, elevators and stairways, and so on. Unit footprints must be contained in a Levels feature.

Details

Describes linear assets, such as walls, doors, windows, and so on. Details are used to constrain generated network pathways and to support visualization. Details lines must be contained in a Levels feature.

POI

Describes point assets, entries and exits, functional areas, and so on, and used to support the search and explore capabilities, identification, routing, and identification of landmarks in routing.

7.3.3.  Spatial hierarchy

AIIM class has a spatial hierarchy relation as below:

  • Site aggregates one or more Facilities.

  • Facilities aggregates one or more Levels.

  • Levels aggregates one or more Sections and Zones.

  • Sections aggregates one or more Units.

7.3.4.  Visualization class

There is no specific class for appearance and visualization in AIIM.

7.3.5.  Summary

The three types of element (physical, facility, and space) of AIIM can be summarized as follows:

  • Detail defines physical elements. The physical elements include opening, such as door and window.

  • Units defines facility elements. Those facilities include amenities, retail spaces, elevators, stairways, etc.

  • Site, Facilities, Levels, Zones, Sections, and Units define space elements.

The spatial hierarchy of the AIIM can be summarized as follows:

  • Space hierarchy consisting of Site, Facilities, Levels, Sections (and Zones), and Units. The preceding feature contains the following feature.

  • Levels can contain Sections and Zones feature.

  • POI, as point assets, has a relationship with the Space to be located.

As the result, the affordance spaces are mapped as below:

  • The structural affordance space: Site, Facilities, Levels, Zones, Sections, and Units

  • The functional affordance space: Units (especially used for facility space representation)

  • The sensory affordance space: None


7.4.  Apple Indoor Mapping Data Format (IMDF)

7.4.1.  Purpose

IMDF is an OGC® Community Standard. IMDF [5] provides a generic but comprehensive model for indoor locations and provides a basis for navigation and navigation. An IMDF encoding is lightweight, mobile-friendly, and can be displayed on any device, OS, or browser.

7.4.2.  Relevant feature classes for building modeling

Among all the 16 features defined in the IMDF model, 11 features are selected: Spatial feature classes, amenity, furniture, transport, and opening and wall.

imdfclassificationsystem

Figure 31 — Example of IMDF elements by three categories (physical, facility, and space)

Some of the IMDF feature classes that are relevant for building modeling are listed in Table 7.

Table 7 — Class definition from Apple Indoor Mapping Data Format

NameDescription
Venue

A Venue models the presence, location and approximate extent of a place. A Venue is an abstract modeling concept whose only tangible elements are the associated descriptive properties, and the other feature types that lay within it which model physical items such as buildings, floors and rooms.

Building

A Building describes a physical building structure associated with a Venue.

Level

A Level models the presence, location and approximate physical extent of a floor area in: A physical building where the Level’s extent is expected to be analogous to the surface (facade) of the physical building at the height where the floor is positioned

Section

A Section models the presence and approximate extent of a theme.

Unit

Unit models the presence, location and approximate extent of a space. Extent may be characterized by: A barrier, such as a wall

Amenity

An Amenity models the physical presence and approximate point location of a pedestrian amenity that serves a utilitarian purpose or other convenience that serves to enhance the pedestrian “experience.”, like ATM, coin locker.

Detail

A Detail models the presence, location and extent of a physical object. Recognition of the feature in a map is heavily dependent upon the spatial context and cognitive recognition, like stairs.

Fixture

A Fixture models the presence and approximate physical extent of a movable or semi-permanent physical asset, such as desk and furniture.

Kiosk

A Kiosk models the presence and physical extent of furniture that facilitates the distribution of products and/or services. A Kiosk models the extent of the physical object, only. It is not used to describe the business or service that is operating out of the Kiosk. An Occupant (via Anchor) or Amenity would model the operation.

Occupant

An Occupant models the presence and location (via Anchor) of a business entity that trades goods and/or services.

Opening

With few exceptions, an Opening models the presence, location and physical extent (width) of an entrance. An entrance may be a physical presence such as a door that swings, slides or rotates, a gate/turnstile, or threshold.

7.4.3.  Spatial hierarchy

IMDF class has a spatial hierarchy relation as below:

  • Venue aggregates one or more Building instances.

  • Building aggregates one or more Level instances.

  • Level aggregates one or more Section and Unit instances.

7.4.4.  Visualization class

There is no specific class for appearance and visualization in IMDF. However, the Unit can specifically describe the material nature of the physical, vertical barrier, the following Unit category types may be used: “brick”, “concrete”, “drywall”, “glass”, and “wood”

7.4.5.  Summary

The three types of elements (physical, facility, and space) of IMDF can be summarized as follows:

  • Opening defines a physical element. The physical element is a door.

  • Amenity, Detail, Kiosk, Unit, and Fixture define facility. Those facilities include amenities, furniture, and transport elements.

  • Venue, Building, Level, and Section (and Unit) define space elements.

The spatial hierarchy of the IMDF can be summarized as follows:

  • Space hierarchy consists of Venue, Building, Level, and Section (and Unit). The preceding feature contains the following feature.

  • Level can contain Section and Unit feature.

  • Occupant has relationships with space, physical elements, and facility to define a business entity.

As the result, the affordance spaces are mapped as below:

  • The structural affordance space: Venue, Building, Level, Section, Unit, and Opening

  • The functional affordance space: Amenity, Detail, Kiosk, Unit, and Fixture

  • The sensory affordance space: category of Unit


7.5.  OGC CityGML 3.0

7.5.1.  Purpose

CityGML 3.0 is an open data model and XML-based format for the storage and exchange of virtual 3D city models. The CityGML standard specifies an open conceptual model, the extendable international standard for spatial data exchange issued by the OGC. The purpose of the CityGML Conceptual Model is to provide a common definition of the basic entities, attributes, and relations of a 3D city model, to cost-effective sustainable maintenance.

7.5.2.  Relevant feature classes for building modeling

citygml3classificationsystem

Figure 32 — Example of CityGML elements by three categories (physical, facility, and space)

Some of the CityGML 3.0 feature classes that are relevant for building modeling are listed in Table 8.

Table 8 — Class definition from CityGML

NameDescription
Building

A Building is a free-standing, self-supporting construction that is roofed, usually walled, and can be entered by humans

BuildingPart

A BuildingPart is a physical or functional subdivision of a Building. It would be considered a Building, if it were not part of a collection of other BuildingParts.

Storey

A Storey is a horizontal section of a Building.

BuildingUnit

A BuildingUnit is a logical subdivision of a Building. BuildingUnits are formed according to some homogeneous property like management

BuildingRoom

A BuildingRoom is a space within a Building or BuildingPart intended for human occupancy and/or containment of animals or things

BuildingFurniture

A BuildingFurniture is equipment for occupant use, usually not fixed to the building.

BuildingInstallation

A BuildingInstallation is a permanent part of a Building which has not the significance of a BuildingPart. One example is stairs.

Door

A Door is a construction for closing an opening intended primarily for access or egress or both. [cf. ISO 6707-1]

Window

A Window is a construction for closing an opening in a wall or roof, primarily intended to admit light and/or provide ventilation. [cf. ISO 6707-1]

7.5.3.  Spatial hierarchy

CityGML 3.0 class has a spatial hierarchy relation as below:

  • Space hierarchy consists of Building, BuildingPart, Storey, BuildingUnit, and BuildingRoom.

  • Building and BuildingPart inherit AbstractBuilding.

  • BuildingPart is used to model a structural part of a Building.

  • Storey and BuildingUnit inherit AbstractBuildingSubdivision.

  • AbstractBuilding can contain set of AbstractBuildingSubdivision.

  • Both AbstractBuilding and AbstractBuildingSubdivision can have set of BuildingRoom.

7.5.4.  Visualization class

The Appearance module in CityGML provides the representation of surface data such as observable properties for surface geometry objects in the form of textures and material. ExperienceObject in DP can be directly used information ParameterizedTexture, such as imageURI, textureParameterization, and so on.

7.5.5.  Summary

The three types of element (physical, facility, and space) of CityGML can be summarized as follows:

  • WallSurface, InteriorWallSurface, CeilingSurface, OuterCeilingSurface, FloorSurface, OuterFloorSurface, RoofSurface, GroundSurface, Door, DoorSurface, Window, and WindowSurface define physical elements. Those physical elements include boundary entity, door, and window.

  • BuildingFurniture and BuildingInstallation define facility elements. Those facilities include furniture and distribution systems.

  • Building, BuildingPart, Storey, BuildingUnit, and BuildingRoom define space elements.

The spatial hierarchy of the CityGML can be summarized as follows:

  • Building and BuildingPart inherit AbstractBuilding.

  • Storey and BuildingUnit inherit AbstractBuildingSubdivision.

  • AbstractBuilding can contain set of AbstractBuildingSubdivision.

  • Both AbstractBuilding and AbstractBuildingSubdivision can have set of BuildingRoom.

As the result, the affordance spaces are mapped as below:

  • The structural affordance space: Building, BuildingPart, Storey, BuildingUnit, BuildingRoom, WallSurface, InteriorWallSurface, CeilingSurface, OuterCeilingSurface, FloorSurface, OuterFloorSurface, RoofSurface, GroundSurface, Door, DoorSurface, Window, and WindowSurface

  • The functional affordance space: BuildingFurniture and BuildingInstallation

  • The sensory affordance space: Appearance module in CityGML



Annex A
(informative)
XML Schema for IndoorGML IndoorFeature Module (Normative)

This discussion paper proposes the following normative XML schema document for the IndoorGML IndoorFeature Module consisting of three submodules: Experience, FacilitySpace, StructureSpace.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="http://www.opengis.net/indoorgml/1.0/affordance/experiencespace"
           targetNamespace="http://www.opengis.net/indoorgml/1.0/affordance/experiencespace"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:gml="http://www.opengis.net/gml/3.2"
           xmlns:IndoorCore="http://www.opengis.net/indoorgml/1.0/core"
           elementFormDefault="qualified"
           version="1.0.0">
    <xs:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
    <xs:import namespace="http://www.opengis.net/indoorgml/1.0/core" schemaLocation="http://schemas.opengis.net/indoorgml/1.0/indoorgmlcore.xsd"/>
    <!--  ======================================================================  -->
    <xs:element name="ExperienceSpace" type="ExperienceSpaceType" substitutionGroup="IndoorCore:CellSpace"/>
    <xs:complexType name="ExperienceSpaceType">
        <xs:complexContent>
            <xs:extension base="IndoorCore:CellSpaceType">
                <xs:sequence>
                    <xs:element name="class" type="gml:CodeType"/>
                    <xs:element name="function" type="gml:CodeType"/>
                    <xs:element name="LOD1Solid" type="gml:SolidPropertyType" minOccurs="0"/>
                    <xs:element name="LOD2Solid" type="gml:SolidPropertyType" minOccurs="0"/>
                    <xs:element name="LOD3Solid" type="gml:SolidPropertyType" minOccurs="0"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:complexType name="ExperienceSpacePropertyType">
        <xs:sequence minOccurs="0">
            <xs:element ref="ExperienceSpace"/>
        </xs:sequence>
        <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="ExperienceSpaceBoundary" type="ExperienceSpaceBoundaryType" substitutionGroup="IndoorCore:CellSpaceBoundary"/>
    <xs:complexType name="ExperienceSpaceBoundaryType">
        <xs:complexContent>
            <xs:extension base="IndoorCore:CellSpaceBoundaryType">
                <xs:sequence>
                    <xs:element name="overlaying" type="ExperienceObjectPropertyType" minOccurs="0" maxOccurs="unbounded"/>
                    <xs:element name="LOD1Surface" type="gml:SurfacePropertyType" minOccurs="0"/>
                    <xs:element name="LOD2Surface" type="gml:SurfacePropertyType" minOccurs="0"/>
                    <xs:element name="LOD3Surface" type="gml:SurfacePropertyType" minOccurs="0"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:complexType name="ExperienceSpaceBoundaryPropertyType">
        <xs:sequence minOccurs="0">
            <xs:element ref="ExperienceSpaceBoundary"/>
        </xs:sequence>
        <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="ExperienceObject" type="ExperienceObjectType" substitutionGroup="gml:AbstractFeature"/>
    <xs:complexType name="ExperienceObjectType">
        <xs:complexContent>
            <xs:extension base="gml:AbstractFeatureType">
                <xs:sequence>
                    <xs:element name="name" type="xs:string" minOccurs="0"/>
                    <xs:element name="locatedAt" type="gml:GeometryPropertyType"/>
                    <xs:element name="resource" type="xs:anyURI"/>
                    <xs:element name="validTime" type="gml:validTime"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:complexType name="ExperienceObjectPropertyType">
        <xs:sequence minOccurs="0">
            <xs:element ref="ExperienceObject"/>
        </xs:sequence>
        <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="VisualObject" type="VisualObjectType" substitutionGroup="ExperienceObject"/>
    <xs:complexType name="VisualObjectType">
        <xs:complexContent>
            <xs:extension base="ExperienceObjectType"/>
        </xs:complexContent>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="SoundObject" type="SoundObjectType" substitutionGroup="ExperienceObject"/>
    <xs:complexType name="SoundObjectType">
        <xs:complexContent>
            <xs:extension base="ExperienceObjectType"/>
        </xs:complexContent>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="TouchObject" type="TouchObjectType" substitutionGroup="ExperienceObject"/>
    <xs:complexType name="TouchObjectType">
        <xs:complexContent>
            <xs:extension base="ExperienceObjectType"/>
        </xs:complexContent>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="SmellObject" type="SmellObjectType" substitutionGroup="ExperienceObject"/>
    <xs:complexType name="SmellObjectType">
        <xs:complexContent>
            <xs:extension base="ExperienceObjectType"/>
        </xs:complexContent>
    </xs:complexType>
    <!--  ======================================================================  -->
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="http://www.opengis.net/indoorgml/1.0/affordance/facilityspace"
           targetNamespace="http://www.opengis.net/indoorgml/1.0/affordance/facilityspace"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:gml="http://www.opengis.net/gml/3.2"
           xmlns:IndoorCore="http://www.opengis.net/indoorgml/1.0/core"
           elementFormDefault="qualified"
           version="1.0.0">
    <xs:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
    <xs:import namespace="http://www.opengis.net/indoorgml/1.0/core" schemaLocation="http://schemas.opengis.net/indoorgml/1.0/indoorgmlcore.xsd"/>
    <!--  ======================================================================  -->
    <xs:element name="FacilitySpace" type="FacilitySpaceType" substitutionGroup="IndoorCore:CellSpace"/>
    <xs:complexType name="FacilitySpaceType">
        <xs:complexContent>
            <xs:extension base="IndoorCore:CellSpaceType">
                <xs:sequence>
                    <xs:element name="duality" type="FacilityStatePropertyType" minOccurs="0"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:complexType name="FacilitySpacePropertyType">
        <xs:sequence minOccurs="0">
            <xs:element ref="FacilitySpace"/>
        </xs:sequence>
        <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="FacilitySpaceBoundary" type="FacilitySpaceBoundaryType" substitutionGroup="IndoorCore:CellSpaceBoundary"/>
    <xs:complexType name="FacilitySpaceBoundaryType">
        <xs:complexContent>
            <xs:extension base="IndoorCore:CellSpaceBoundaryType"/>
        </xs:complexContent>
    </xs:complexType>
    <xs:complexType name="FacilitySpaceBoundaryPropertyType">
        <xs:sequence minOccurs="0">
            <xs:element ref="FacilitySpaceBoundary"/>
        </xs:sequence>
        <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="Furniture" type="FurnitureType" substitutionGroup="FacilitySpace"/>
    <xs:complexType name="FurnitureType">
        <xs:complexContent>
            <xs:extension base="FacilitySpaceType">
                <xs:sequence>
                    <xs:element name="furnitureType" type="gml:CodeType" minOccurs="0"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:element name="StationaryFacility" type="StationaryFacilityType" substitutionGroup="FacilitySpace"/>
    <xs:complexType name="StationaryFacilityType">
        <xs:complexContent>
            <xs:extension base="FacilitySpaceType">
                <xs:sequence>
                    <xs:element name="stationaryType" type="gml:CodeType" minOccurs="0"/>
                    <xs:element name="capacityByCount" type="gml:Count" minOccurs="0"/>
                    <xs:element name="capacityByWeight" type="gml:MeasureType" minOccurs="0"/>
                    <xs:element name="fireExit" type="gml:Boolean" minOccurs="0"/>
                    <xs:element name="serviceTime" type="gml:validTime" minOccurs="0"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:element name="MobileFacility" type="MobileFacilityType" substitutionGroup="FacilitySpace"/>
    <xs:complexType name="MobileFacilityType">
        <xs:complexContent>
            <xs:extension base="FacilitySpaceType">
                <xs:sequence>
                    <xs:element name="mobileType" type="gml:CodeType" minOccurs="0"/>
                    <xs:element name="serviceTime" type="gml:validTime" minOccurs="0"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:element name="SensorFacility" type="SensorFacilityType" substitutionGroup="FacilitySpace"/>
    <xs:complexType name="SensorFacilityType">
        <xs:complexContent>
            <xs:extension base="FacilitySpaceType">
                <xs:sequence>
                    <xs:element name="sensorType" type="gml:CodeType" minOccurs="0"/>
                    <xs:element name="serviceTime" type="gml:validTime" minOccurs="0"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="FacilityState" type="FacilityStateType" substitutionGroup="IndoorCore:State"/>
    <xs:complexType name="FacilityStateType">
        <xs:complexContent>
            <xs:extension base="IndoorCore:StateType">
                <xs:sequence>
                    <xs:element name="duality" type="FacilitySpacePropertyType" minOccurs="0"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:complexType name="FacilityStatePropertyType">
        <xs:sequence minOccurs="0">
            <xs:element ref="FacilityState"/>
        </xs:sequence>
        <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
    </xs:complexType>
    <!--  ======================================================================  -->
    <xs:element name="FacilitySpaceLayer" type="FacilitySpaceLayerType" substitutionGroup="IndoorCore:SpaceLayer"/>
    <xs:complexType name="FacilitySpaceLayerType">
        <xs:complexContent>
            <xs:extension base="IndoorCore:SpaceLayerType">
                <xs:sequence>
                    <xs:element name="nodes" type="FacilityNodesType" minOccurs="1" maxOccurs="unbounded"/>
                </xs:sequence>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <xs:complexType name="FacilityNodesType">
        <xs:complexContent>
            <xs:extension base="gml:AbstractFeatureType">
                <xs:sequence>
                    <xs:element name="stateMember" type="FacilityStateMemberType" 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="FacilityStateMemberType">
        <xs:complexContent>
            <xs:extension base="gml:AbstractFeatureMemberType">
                <xs:sequence minOccurs="0">
                    <xs:element ref="FacilityState"/>
                </xs:sequence>
                <xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
            </xs:extension>
        </xs:complexContent>
    </xs:complexType>
    <!--  ======================================================================  -->
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns="http://www.opengis.net/indoorgml/1.0/affordance/structurespace"
           targetNamespace="http://www.opengis.net/indoorgml/1.0/affordance/structurespace"
           xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:gml="http://www.opengis.net/gml/3.2"
           xmlns:IndoorCore="http://www.opengis.net/indoorgml/1.0/core"
           elementFormDefault="qualified"
           version="1.0.0">
    <xs:import namespace="http://www.opengis.net/gml/3.2" schemaLocation="http://schemas.opengis.net/gml/3.2.1/gml.xsd"/>
    <xs:import namespace="http://www.opengis.net/indoorgml/1.0/core" schemaLocation="http://schemas.opengis.net/indoorgml/1.0/indoorgmlcore.xsd"/>
    <!--  ======================================================================  -->
    <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>
    <!--  ======================================================================  -->
    <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>
    <!--  ======================================================================  -->
    <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>
    <!--  ======================================================================  -->
    <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>
    <!--  ======================================================================  -->
    <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>
    <!--  ======================================================================  -->
    <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>
    <!--  ======================================================================  -->
</xs:schema>

Figure A.1


Annex B
(informative)
Revision History

Table B.1

Date Release Editor Primary clauses modified Description
2020-09-03 0.1 Kyong-Sook Kim, Taehoon Kim all initial version
2020-12-05 0.2 Kyong-Sook Kim, Taehoon Kim, Jiyeong Lee, In-Hye Lee, Hye-Young Kang all first draft
2021-01-04 1.0 Kyong-Sook Kim, Taehoon Kim, Jiyeong Lee all submission draft
2021-05-20 1.0.1 Kyong-Sook Kim, Taehoon Kim, Jiyeong Lee all minor revision by applying the given comments
2021-12-15 1.1 Kyong-Sook Kim, Taehoon Kim, Ki-Joune Li Title, Section 2, 6, and 7 minor revision by applying the given comments
2022-02-09 1.2 Kyong-Sook Kim, Taehoon Kim, Ki-Joune Li all major revision
2022-04-08 1.2.1 Kyong-Sook Kim, Taehoon Kim, Ki-Joune Li all final version

Bibliography

[1]  Klepeis, N., Nelson, W., Ott, W. et al.: The National Human Activity Pattern Survey (NHAPS): a resource for assessing exposure to environmental pollutants. J Expo Sci Environ Epidemiol 11, 231–252, 2001. https://doi.org/10.1038/sj.jea.7500165

[2]  Gibson, J.J.: The Ecological Approach to Visual Perception: Classic Edition (1st ed.). Psychology Press, 2014. https://doi.org/10.4324/9781315740218

[3]  Zlatanova S, Yan J, Wang Y, Diakité A, Isikdag U, Sithole G, Barton J.: Spaces in Spatial Science and Urban Applications—State of the Art Review. ISPRS International Journal of Geo-Information. 9(1):58, 2020. https://doi.org/10.3390/ijgi9010058

[4]  Esri: ArcGIS Indoors Information Model (ArcGIS Pro 2.7), https://pro.arcgis.com/en/pro-app/latest/help/data/indoors/arcgis-indoors-information-model.htm

[5]  Apple: Indoor Mapping Data Format (1.0.0) OGC Community Standard, https://docs.ogc.org/cs/20-094/index.html

[6]  OmniClass: The OmniClass™ Construction Classification System (Version 2019-07-01), https://www.csiresources.org/standards/omniclass

[7]  buildingSMART International Ltd: Industry Foundation Classes (IFC2x Edition 3), https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/FINAL/HTML/

[8]  Löwner, M.-O., Gröger, G., Benner, J., Biljecki, F., Nagel, C.: Proposal for a new LOD and multi-representation concept for CityGML. In: Proceedings of the 11th 3D Geoinfo Conference 2016, ISPRS Annals of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol. IV-2/W1, 3–12 (2016). https://doi.org/10.5194/isprs-annals-IV-2-W1-3-2016