5.1.  Symbols (and abbreviated terms)

The following symbols and abbreviated are used in this standard.

5.2.  UML Notation

The diagrams that appear in this standard are presented using the Unified Modeling Language (UML) static structure diagram. The UML notations used in this standard are described in the diagram below.

Figure 1 — UML notation

In this standard, the following three stereotypes of UML classes are used.

1. <<Interface>> A definition of a set of operations that is supported by objects having this interface. An Interface class cannot contain any attributes.

2. <<DataType>> A descriptor of a set of values that lack identity (independent existence and the possibility of side effects). A DataType is a class with no operations whose primary purpose is to hold the information.

3. <<CodeList>> is a flexible enumeration that uses string values for expressing a list of potential values.

In this standard, the following standard data types are used:

1. CharacterString – A sequence of characters;

2. Integer – An integer number;

3. Double – A double precision floating point number; and

4. Float – A single precision floating point number.

6.1.  Motivation for defining IndoorGML

Indoor space differs from outdoor space in many aspects. Therefore, basic concepts, data models, and standards need to be redefined to meet the requirements of indoor spatial applications. The requirements of indoor spatial information are specified according to the types of applications. In general, the applications of indoor spatial information are classified into two categories as follows:

• Management of building components and indoor facilities, and

• Usage of indoor space.

Building construction and management and facility management belong to the first category. While the main focus of the first category is on building components such as roofs and walls, the second category is focused on usage and localization of features (stationary or mobile) in indoor space. The indoor spatial information of the second category includes requirements for representing spatial components such as rooms and corridors, and constraints such as doors. Indoor location-based services, indoor route analysis, or indoor geo-tagging services belong to the second category.

Instead of representing building architectural components, the goal of the IndoorGML standard is to define a framework of indoor spatial information to locate stationary or mobile features in indoor space and to provide spatial information services utilizing their positions in indoor space. IndoorGML is intended to provide the following functions:

• Representing the properties of indoor space, and

• Providing spatial reference of features in indoor space.

In summary, IndoorGML version 1 is based on the requirements from indoor navigation due to strong and urgent standardization demands, such as indoor LBS, routing services, and emergency control in indoor space. We expect that other requirements such as facilities management will be handled by future versions of IndoorGML.

7.1.  Representation of Indoor Objects in IndoorGML

An important difference of indoor space from outdoor space is that an indoor space is composed of complicated constraints such as corridors, doors, stairs, elevators, etc., like a road network space is composed of road constraints. This means that proper representations of indoor constraints are key issues for indoor spatial information modelling and standards. In IndoorGML, indoor constraints are considered from the following aspects:

• Cellular space (defined below)

• Semantic representation

• Geometric representation

• Topological representation

• Multi-Layered Representation

7.1.4.  Geometric Representation of Indoor Space

Every cell defining indoor space, such as a room or a corridor, owns a form, extension and position that can be collected and modelled. Geometric information can be included in IndoorGML in several ways. In order to represent geometry of cell, we assume 3D or 2D Euclidean spaces. Using the concepts of Euclidean space, the geometry provides the means for the quantitative description of the spatial characteristics of cell, where a metric space is defined as [18].

ISO19107 (Spatial Schema) [1] provides conceptual schemas to describe and model real world objects as features, where cells in indoor space are a type of feature. The geometry package contains various classes for coordinate geometry used in IndoorGML. The mathematical functions which are used for describing the geometry of a cell depend on the type of coordinate reference system (CRS) which is used to define a spatial position.

The geometric representation of 2D or 3D features in indoor space is not a major focus of IndoorGML, since they are clearly defined by ISO 19107, CityGML, and IFC. However, for the sake of self-completeness, the geometry of 2D or 3D object may be optionally defined within IndoorGML according to the data model defined by ISO 19107. As illustrated in Figure 2 there are three options for representing geometry of a cell in indoor space.

1. External Reference (Option 1): Instead of explicit representation of geometry in IndoorGML, an IndoorGML document only contains external links (namely c.xlink, where c is a cell in IndoorGML) to objects defined in other data sets such as CityGML, where the referenced objects in external data set include geometric information. Then there must be 1:1 or n:1 mappings from cells in IndoorGML to corresponding objects in other dataset.

2. Geometry in IndoorGML (Option 2): Geometric representation of cell (namely c.geom, where c is a cell in IndoorGML) may be included within an IndoorGML document. It is GM_Solid in 3D space and GM_Surface in 2D space as defined in ISO 19107. Note that solid with holes or surface with holes are allowed in this standard.

3. No Geometry (Option 3): No geometric information is included in IndoorGML document.

Figure 2 — Three options to represent geometry in IndoorGML

When IndoorGML is independently used without referencing CityGML or IFC, it may contain the full 3D geometry of feature as defined in ISO 19107 but can also include only a 2D footprint. When IndoorGML is used with CityGML or IFC, we recommend making reference to the geometry defined in CityGML or IFC. Note that these options are not exclusive. For example, while IndoorGML document contain external references to the corresponding objects in CityGML, it also contains geometries of features by either the second or the third option. However, the second and third options are apparently exclusive.

7.1.5.  Network Representation of Cellular Space

Topology is an essential component of cellular space and IndoorGML. A natural topology such as “neighbourhood, interior, disjoint and boundary” may be induced from geometry in Euclidean space. However, topological properties are not implicitly included in cellular space. Therefore, we need to explicitly describe the topological relationship in IndoorGML.

The Node-Relation Graph (NRG) [25] represents topological relationships, e.g., adjacency and connectivity, among indoor objects. The NRG allows abstracting, simplifying, and representing topological relationships among 3D spaces in indoor environments, such as rooms within a building. It can be implemented as a graph representing the adjacency, connectivity relationships without geometrical properties. It enables the efficient implementation of complex computational problems within indoor navigation and routing systems.

The Poincaré duality [8] provides a theoretical background for mapping indoor space to NRG representing topological relationships. A given indoor space can be transformed into a NRG in topology space using the Poincaré duality. This approach simplifies the complex spatial relationships between 3D by a combinatorial (or logical) topological network model [25]. According to Poincaré duality, a k-dimensional object in N-dimensional primal space is mapped to (N-k) dimensional object in dual space. Thus, solid 3D objects in 3D primal space, e.g., rooms within a building, are mapped to nodes (0D object) in dual space. 2D surfaces shared by two solid objects is transformed into an edge (1D) linking two nodes in dual space. The nodes and edges in dual space form an adjacency graph, where the nodes and the edges of dual space represent cells and adjacency relationships between cells in primal space, respectively. Figure 3-a and Figure 3-b illustrate this duality transformation for the case where the primal space is 3D and 2D respectively. Note that the transformations from 1D object (curve) or 0D object (point) in 3D primal space are not included in IndoorGML since they are not considered as cells in most applications. But the transformation may be applied to 1D or 0D objects of 3D primal space in a similar way if it is required.

Then the adjacency graph G_adj is defined as follows:

G_adj = (V, E_adj), where V and E_adj are sets of nodes and edges in dual space mapped from cells and surfaces in 3D primal space, respectively.

Once adjacency relationships between cells are determined by Poincaré duality, other topological relationships can be defined from adjacency relationships based semantic information. An example of adjacency relationships in dual space is depicted by Figure 4. Figure 4-a shows a primal space with three cells including exterior cell (EXT), and boundaries between cells and the corresponding adjacency graph in dual space is given in Figure 4-b. Adjacency graph of dual space serves as a basic topological graph, since other topological graphs can be derived from the adjacency graph.

While no semantic information is used to generate adjacency graph in Figure 4, a different graph can be derived from adjacency graph by using semantic information. In Figure 5, boundaries are classified into walls and doors, then the graph in Figure 4-b becomes a different graph, called connectivity graph, which represents connectivity between cells as shown in Figure 5. Among adjacency relationships between cells in Figure 4-b, the edges of doors are included in the graph, while walls are removed from the graph since walls are not navigable. In a similar way, we may derive accessibility graph from adjacency graph by using constraint information as shown in Figure 6. If there is a constraint that the width of door D1 is 1.2 meters, then cell R1 is not accessible to tables bigger than 1.2 meters via door D1 and the accessibility graph becomes as Figure 8.

Figure 3 — Principles of Poincaré duality as shown by Lee [21] (mathematical definition of Poincaré duality in [8])

Figure 4

Figure 5 — Derivation of connectivity graph from adjacency graph

Figure 6 — Derivation of accessibility graph

Connectivity graph G_con and accessibility graph G_acc are defined in similar ways as follows:

G_con = (V, E_con), where V is a set of nodes in dual space mapped from cells in 3D primal space and E~con ~is a set of edges representing connectivity between cells in primal space. Note that E_con ⊂ E_adj.

G_acc = (V, E_acc), where V is a set of nodes in dual space mapped from cells in 3D primal space and E~acc ~is a set of edges representing accessibility between cells in primal space. Note that E_acc ⊂ E_adj.

The walls and doors in the primal space are represented as boundaries in Figure 4-a, and they are accordingly mapped to edges in dual space as depicted in Figure 4-b. However, walls and doors may be also represented as cells with certain thickness depending on applications as shown in Figure 7. We call this representation thick wall model and the representation in Figure 4 is called thin (or paper) wall model. Then the NRG in dual space should be differently constructed as shown in Figure 7, where walls and doors are mapped to nodes of dual space.

Figure 7 — Adjacency graph for thick wall model

While the nodes and edges in NRG for the previous examples have no geometric properties, we may embed basic geometric data with nodes and edges such that each node has point coordinates and each edge has the coordinates of the starting, ending, and intermediate vertices. We call this geometrically embedded graph geometric NRG, while NRG without any geometric properties is called logical NRG. In geometric NRG, the geometries of node and edges are defined as GM_Point and GM_Curve of ISO 19107.

7.1.6.  Multi-Layered Space Representation

A single indoor space is often semantically interpreted into different cellular spaces. For example, an indoor space is represented as a topographic cellular space composed of rooms, corridors, and stairs, while also being represented as different cellular spaces such as WiFi coverage cells and RFID sensor coverage cells respectively as shown in Figure 8. For this reason, IndoorGML supports multiple representation layers with different cellular spaces for an indoor space. Each semantic interpretation layer results in a different decomposition of the same indoor space where each decomposition forms a separate layer of cellular space as shown in Figure 8.

Figure 8 — Example — Multiple Layered Space Representation

As shown in Figure 8, an indoor space is interpreted by three semantic representations – Topographic space layer, WiFi sensor space layer, and RFID sensor space. Since they are semantically different in terms of wheelchair movement, each layer forms a different cellular space and derived NRG for dual space.

This representation method with multiple cellular space layers is called Multiple Layered Space Representation (MLS Representation). The MLS representation is useful for many purposes. For example, we can represent the hierarchical structure of indoor space by MLS representation, where each level is represented as a single space layer and the relationships between two hierarchical levels are represented by inter-layer edges. Interlayer edges are explained in section 7.3. Another application example of MLS representation is indoor tracking with presence sensors such as RFID. Given an indoor space represented as topographic cellular space layer and RFID sensor coverage layer respectively, we can deduce the movement of a mobile object with a RFID tag by the sequence of RFID coverage cells and corresponding inter-layer space edges.

7.2.  Structured Space Model

IndoorGML is based on two conceptual frameworks: the Structured Space Model and the Multi-Layered Space Model (MLSM). The Structured Space Model defines the general layout of each space layer independent from the specific space model which it represents. Each layer is systematically subdivided into four segments as shown in see Figure 9.

Figure 9 — Structure Space Model

Figure 9 illustrates the structured space model that allows for the distinct separation of primal space from dual space on the one hand, and geometry and pure topology on the other hand. This structure forms the basis for the framework proposed indoor space model.

The upper and the lower parts of Figure 9 are consistent with the rules of ISO 19107 for modeling geometrical features of real-world phenomena. However, the transition from primal to dual space cannot be modeled or described via the ISO standard. Further, the topological relationships in IndoorGML such as adjacency and connectivity are not defined by means of the topology in ISO 19107 but by explicit associations within the IndoorGML data model.

In the Structured Space Model, topological relationships between 3D (or 2D) spatial objects are represented within topology space (i.e., the right part of Figure 9). By applying a duality transformation, the 3D cells in primal space are mapped to nodes (0D) in dual space. The topological adjacency relationships between 3D cells are transformed to edges (1D) linking pairs of nodes in dual space. Furthermore, the node of NRG is called state and the edge of NRG is called transition. The active state is represented by a node within the NRG and denotes the spatial area where the guided object is currently located. Once the object moves into a topologically connected area, another node within the NRG and thus a new active state is reached. The edge connecting both nodes represents the event of this state transition. The NRG representing topological relationships among 3D spatial objects in topological space is a logical NRG, while the NRG embedded to Euclidean IR³ space is a geometric NRG as seen Figure 9.

The UML diagram depicted in Figure 10 shows the data model for the Structured Space Model perspective. A SpaceLayer represents a separate interpretation and a decomposition layer explained in section 7.1.6 and it is composed of State and Transition which represent nodes and edges of NRG for dual space, respectively. The NRG and state-transition diagram for each layer are realized by SpaceLayer. Note that the current version of IndoorGML supports logical NRG and geometric NRG for dual space.

As mentioned above, NRG as a part of the Structured Space Model is implemented in IndoorGML model. In dual space, the logical NRG in the lower right part of structured space model as seen in Figure 9 represents topological relationships among spaces in topological space, which is described as the cardinality of State and Transition to Geometry classes is 0 in Figure 10. When the cardinality is 1 in Figure 10, the topological model is implemented by coordinate space embedding of NRG (Geometric NRG), which is in the lower left part of structured space model as seen in Figure 9.

Figure 10 — Implementation of Structure Space Model in IndoorGML

7.3.  Multi-Layered Space Model

The concept of Structure Space model is further extended to Multi-Layered Space Model (MLSM). Multi-Layered Space Model provides an approach for combining multiple space structures for different interpretations and decomposition layers to support full indoor information services.

7.3.1.  Multi-Layered Space Model – Key Concepts

A same indoor space is often differently interpreted depending on the application requirements as discussed in section 7.1.6. This results in different decompositions of a same indoor space, and each decomposition results in a specific NRG. For example, the layers for topographic space layer, WiFi sensor space layer, and RFID sensor space in Figure 8 form independent structured spaces and each layer results in three separate NRGs as depicted in Figure 11.

Figure 11 — Multi-Layer combination of alternative space concepts

There may be several interpretations of a same indoor space. In most cases, the topographic space layer composed of geospatial features in indoor space such as rooms, corridors, staircases, and lift shafts are of the most important layer. For indoor positioning purposes, the sensor space layer is also fundamental, where the notion of sensor space substantially differs from topographic space. The sensor space is rather decomposed according to signal characteristics such as propagation and signal coverage areas depending on different localization techniques such as WiFi or RFID which differ in signal propagation and signal coverage. There are other possible interpretations, and the number of layers is generally unbounded and any definition for space (e.g., security space, movement space, activity space, visual space etc.) can be given for a semantic modelling of indoor space, where each of them is defined in its own layer.

7.3.2.  Inter-Layer Relations

Layers of multi-layered space model can be connected by inter-layer relations. As illustrated in Figure 11, there are three space layers, where each layer constitutes a NRG. In a topographic layer, the nodes represent the possible states of a navigating object and correspond to cells with volumetric extent in primal space (e.g., rooms) while the edges represent state transitions, i.e., the movement of an object from one space to another. They correspond to connectivity relations between the cells in primal space (e.g., neighboured rooms connected with a door). In the sensor space, NRG has a slightly different structure. The nodes represent again the cells with volumetric extend (e.g., the entire coverage space of a WiFi transmitter), while the edges represent the transition from one space to another based on the neighbouring WiFi coverage spaces. Since the layers cover the same real-world space, the separated dual graphs can be combined into a multi-layered graph. Figure 12 illustrates overlaid space layers.

Figure 12 — Overlaid space layers in dual space

If we assume that each space model, whether it is for topographic or sensor space, is based upon a non-overlapping partitioning of space, a navigating object can only belong to one cell at a time and thus always only one state may be active. Therefore, an object is at any given time exactly in one cell (named state) in each layer simultaneously. This overall state is thereby denoted by the combination of active states from all space layers.

However, only specific combinations of states from different layers are valid and can be active at the same time. The combinations are expressed by additional edges linking the nodes between different layers. These so-called joint edges are derived by pairwise intersecting the cell geometries from different layers. A joint edge between two such nodes is inserted if the intersection of the interior of the two corresponding cells is non-empty. Therefore, the joint edges represent all relationships according to the eight relation model except “disjoint” and “touch” between two cells from different space layers defined in [14] and thus denote inter-layer relationships. Figure 13 illustrates the dual graphs of three space layers together with their inter-layer relationships.

Figure 13 — Implementation of Multi-Layer Space Model in IndoorGML

In IndoorGML, the space model for multi-layered space representation, called multi-layered space model, is implemented using the MultiSpaceLayer class. MultiLayeredGraph consists of SpaceLayers and InterLayerConnections as shown in Figure 13, while SpaceLayer represents each space layer (e.g., topographic space layer, sensor space layer, etc.) and it forms a NRG composed of objects from State and Transition. The inter-layer relationships are implemented by InterLayerConnection class. In Figure 12, \{(1,A,Within), (4,A,Within), (3,A,Overlaps), (3,AB,Overlaps), (3,B,Overlaps), (2,B,Within), (1,AB,Overlaps), (3,AB,Overlaps), (A,R1,Contains), (B,R2,Contains), (3,R1,Contains), (3,R2,Contains)} are the set of instances from InterLayerConnection class, where each instance represents the relationship between two cells of different space layers of Figure 8. The MultiSpaceLayer is an aggregation of SpaceLayer and InterLayerConnection.

7.4.  External reference

Since a main focus of IndoorGML is on the notion of cellular space and topological representation, an IndoorGML encoding may not contain geometries and detailed semantic information for indoor features. Instead, IndoorGML provides a method to reference an object in external dataset such as CityGML or an IFC. Depending on application areas, indoor features may have different geometric and semantic representation models. For example, indoor spaces are often represented by a grid model in the robotic navigation domain. By separating domain specific representation models from IndoorGML and providing external reference, a high level of flexibility can be achieved.

Figure 14 — External References in IndoorGML

CellSpace and CellSpaceBoundary of IndoorGML core module depicted in Figure 18 may have external references to corresponding objects in external data sets. Note that the external reference is optional and can have at most one target object as shown by the cardinality in Figure 14.

Figure 15-(a) and Figure 15-(b) provide examples of external references to CityGML LoD 4 and SensorML respectively. For example, regarding the topography space layer, the subclasses of NavigableSpace can have an external reference to CityGML objects. The GeneralSpace has an external reference to bldg::Room of CityGML and the AnchorSpace and ConnectionSpace refer to bldg::Door in CityGML. bldg::BoundarySurface in CityGML is also referred by NavigableBoundary. Regarding the sensor space layer, all of subclasses of the NavigableSpace class also can have an external reference to sml::Component as shown in Figure 15-(b) which includes all the location and interface properties of any physical process. Note that NavigableSpace, AnchorSpace, and ConnectionSpace belong to IndoorGML navigation module, which will be explained in section 8.

Figure 15

7.5.  Connection between Indoor and Outdoor Spaces

Connecting indoor and outdoor spaces is an important requirement for navigation and other applications. IndoorGML provides a concept to connect indoor and outdoor spaces by defining additional topology elements between indoor and outdoor spaces. Every indoor space contains at least one entrance, and it can be used to connect indoor and outdoor spaces. In IndoorGML, “entrance” is represented as a special node of the topological graph in indoor space, connecting indoor and outdoor as shown in Figure 16. We call this element anchor node, which differs from other node in the topological graph, since it may include additional information for converting a relative indoor CRS to an outdoorCRS.

Figure 16 — Anchor Node Connecting Indoor and Outdoor Networks [27]

The anchor node element contains attributes to support the seamless conversion between indoor and outdoor spaces.

1. External reference to outdoor transportation network: The anchor node includes an external reference to a node in a ground transportation network, that is connected to the anchor node as shown in Figure 16. Note that the relationship between anchor node and nodes in outdoor ground transportation is bidirectional. The anchor nodes are not only defined within IndoorGML document but also accessible from external data set such as the outdoor ground transportation network. For example, when a vehicle is entering to a building, we can get the IndoorGML document of the building via the external reference from the node in the ground transportation network.

2. Conversion parameters: In many cases, a relative CRS is applied to an indoor space and it is necessary to convert the coordinates of each point of indoor geometry according to the outdoor CRS. Anchor node therefore contains the parameters for transformation:

   • rotation origin point (x₀, y₀, z₀)

   • rotation angles (α, β, γ, along x, y, and z-axis),

   • rescaling factor (s_x, s_y, s_z), and

   • translation vector (t_x, t_y, t_z).

In cases where an absolute CRS is used for indoor space, the conversion parameters are not necessary. However, anchor nodes are still useful not only for representing the connectivity between indoor and outdoor spaces but also facilitating seamless services for example by including the URI of radio map of the building for WiFi indoor positioning.

7.6.  Subspacing

Indoor space often has hierarchical structures and a careful decomposition of an indoor space is required in many cases to reflect these hierarchical structures. A feature such as corridor or hall may be divided to accurately represent the geometric properties of indoor space based on the connectivity relationships among space objects. IndoorGML supports hierarchical subspacing by Multi-Layered Space Model explained in section 7.3.

The subspacing by the first option is shown in Figure 17. In the case of a corridor in Figure 17-(a), node n₆ in the NRG representing a corridor within the indoor space (Figure 17-(a), Figure 17-(b)) is considered as a consolidated Master Node, which is transformed to a sub-graph preserving connectivity relationship among the compartmentalized spaces of the corridor (Figure 17-©). It means that node n₆ in the original NRG is converted into n_6-1 and n_6-2 and edge e₁ in Figure 17-©) in the transformed NRG, which is a sub-graph representing a two-dimensional shape such as a hallway.

Figure 17 — Example of subspacing — Connectivity NRG

IndoorGML supports the subspacing by means of multi-layered space model to reflect the hierarchical structure of indoor space as shown in Figure 18. The NRG G₁ is the original graph layer with node n_6, while G₂ is a transformed graph layer with partitioned nodes n_6-1 and n_6-2. Then the hierarchical structure is represented by means of inter-layer connection of the multi-layered space model. Note that there are default one-to-one inter-layer connection between G₁.n_k, G₂.n_k except n₆ as shown in Figure 18.

Figure 18 — Multi-layered space model for subspacing

In the case where hierarchical subspacing is not required, we may simply replace a space with subdivided spaces and describe the adjacency or connectivity relationships between subdivided spaces. For example in Figure 17, we just replace n₆ with n_6-1, and n_6-2 and append edges connecting them.

7.7.  Modularization

Following the guidance in the OGC’s policy “The Specification Model — A Standard for Modular specifications [15].” IndoorGML is split into a core module and extensions that have a mandatory dependency on the core. Therefore, the IndoorGML data model is thematically decomposed into a Core module and Thematic extension modules (see Figure 19). The core module comprises the basic concept and each extension module covers a specific thematic field such as navigation applications (e.g., pedestrians, wheelchair, and robot). Each IndoorGML module is specified by an XML Schema definition file and is defined within an individual and globally unique XML target namespace as shown in Table 1. According to dependency relationships among modules, each module may, in addition, import namespaces associated to such related IndoorGML modules.

Figure 19 — UML Package diagram

Table 1 — IndoorGML Modules and Namespace Identifiers

The IndoorGML core module defines the basic concepts and component of the IndoorGML data model. Except semantic modelling, the aspects explained in section 7.1 are reflected into the core module. The extension modules contain the semantic modelling aspect (see section 7.1.3) of IndoorGML. Based on the IndoorGML core module, the extension module contains a logically separate thematic component of the IndoorGML data model. This version of IndoorGML introduces the first thematic extension module: IndoorNavigation module.

The dependency relationships among IndoorGML’s modules are illustrated in Figure 19. Each module is represented by a package. The package name corresponds to the module name. A dash arrow in the figure indicates that the schema at the tail of the arrow depends upon the schema at the head of the arrow. For IndoorGML modules, a dependency occurs where one schema <import>s other schema and accordingly the corresponding XML namespace. In the following sections the modules are described in detail.

8.1.  <State>

State represents a node in dual space of MLSM. State may be an isolated node, i.e., not connected to another State. Within the topographic space layer, a space can be associated with a room, corridor, door, etc. within a building of the primal space. It is represented geometrically as Point in IndoorGML. It also has association with the corresponding CellSpace class which represents a space in primal space (or referred to a geometry object in primal space). The attribute duality – which can only occur once – represents an association with the CellSpace. The connects element describes the relation of a Transition and two State object associated with the Transition itself on one layer (the same layer). The attribute connects can occur from zero to many times. For the geometrical representation of a State, a Point geometric primitive object defined in the GML is used.

<xs:element name="State" type="StateType" substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="StateType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="duality" type="CellSpacePropertyType" minOccurs="0" maxOccurs="1"/>
				<xs:element name="connects" type="TransitionPropertyType" minOccurs="0"
                                         maxOccurs="unbounded"/>
				<xs:element name="geometry" type="gml:PointPropertyType" minOccurs="0" maxOccurs="1"/>
			</xs:sequence>
			<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="StatePropertyType">
	<xs:sequence minOccurs="0">
		<xs:element ref="State"/>
	</xs:sequence>
	<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

8.2.  <Transition>

Within a dual graph structure of one layer, Transition is an edge that represents the adjacency or connectivity relationships among nodes representing space objects in primal space. Transition always connects two States. In the topographic space layer, a Transition can be associated with a boundary of a room in the primary space. The attribute connects represents States that are boundary objects of Transition. The attribute duality represents an association relation with CellSpaceBoundary class. The attribute weight can be used for applications in order to deal with the impedance representing absolute barriers in transportation problems. For the geometrical representation of a Transition, a Curve geometric primitive object from the GML is used.

<xs:element name="Transition" type="TransitionType" substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="TransitionType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="weight" type="xs:double"/>
				<xs:element name="connects" type="StatePropertyType"  minOccurs="2"  maxOccurs="2"/>
				<xs:element name="duality" type="CellSpaceBoundaryPropertyType"  minOccurs="0"
                                         maxOccurs="1"/>
				<xs:element name="geometry" type="gml:CurvePropertyType"  minOccurs="0" maxOccurs="1"/>
			</xs:sequence>
			<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="TransitionPropertyType">
	<xs:sequence minOccurs="0">
		<xs:element ref="Transition"/>
	</xs:sequence>
	<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

8.3.  <CellSpace>

CellSpace is a base class for representing the indoor space. The class CellSpace contains properties for space attributes and purely geometric representations of space. CellSpace also has references to thematic objects in external data sources; the geometrical representation in primal Euclidean space is referenced by xlink. The attribute externalReference is used for the reference of an object to its corresponding object in an external data set. Each CellSpace is associated with a geometry object, which can be represented as several geometry primitive types such as 2D and 3D. CellSpace has also information of level. Each CellSpace has normally one level but can have no level information when it cannot be clearly identified. Multiple stories can be also included to a single instance of CellSpace. The value of level is given as a xs:string rather than a xs:integer because it is sometime given as “M” for mezzanine floor and “RC” for ground floor.

<xs:element name="CellSpace" type="CellSpaceType" substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="CellSpaceType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="cellSpaceGeometry" type="CellSpaceGeometryType" minOccurs="0"
 maxOccurs="1"/>
				<xs:element name="duality" type="StatePropertyType"  minOccurs="0" maxOccurs="1"/>
				<xs:element name="externalReference" type="ExternalReferenceType" minOccurs="0"
                                         maxOccurs="unbounded"/>
				<xs:element name="partialboundedBy" type="CellSpaceBoundaryPropertyType"
                                          minOccurs="0" maxOccurs="unbounded"/>
				<xs:element name="level" type="xs:string" minOccurs="0"
maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="CellSpacePropertyType">
	<xs:sequence minOccurs="0">
		<xs:element ref="CellSpace"/>
	</xs:sequence>
	<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="CellSpaceGeometryType">
	<xs:choice>
		<xs:element name="Geometry3D" type="gml:SolidPropertyType"/>
		<xs:element name="Geometry2D" type="gml:SurfacePropertyType"/>
	</xs:choice>
</xs:complexType >
<!-- ====================================================================== -->
<xs:complexType name="ExternalReferenceType">
	<xs:sequence>
		<xs:element name="informationSystem" type="xs:anyURI" minOccurs="0" maxOccurs="1"/>
		<xs:element name="externalObject" type="externalObjectReferenceType"/>
	</xs:sequence>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="externalObjectReferenceType">
	<xs:choice>
		<xs:element name="name" type="xs:string" minOccurs="0" maxOccurs="1"/>
		<xs:element name="uri" type="xs:anyURI"/>
	</xs:choice>
</xs:complexType>

8.4.  <CellSpaceBoundary>

CellSpaceBoundary is used to semantically describe the boundary of each geographical feature in space. The geometry of the CellSpaceBoundary normally will be described by a Surface geometric object in 3D Models. The attribute externalReference is used for the reference of a geometric object to its corresponding object in an external data set. Each CellSpaceBoundary is associated with a geometry primitive object which can be represented as gml:Surface or gml:Curve.

<xs:element name="CellSpaceBoundary" type="CellSpaceBoundaryType"
                    substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="CellSpaceBoundaryType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="duality" type="TransitionPropertyType" minOccurs="0" maxOccurs="1"/>
				<xs:element name="cellSpaceBoundaryGeometry"
type="CellSpaceBoundaryGeometryType" minOccurs="0"  maxOccurs="1"/>
				<xs:element name="externalReference" type="ExternalReferenceType" minOccurs="0"
                                         maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="CellSpaceBoundaryGeometryType">
	<xs:choice>
		<xs:element name="geometry3D" type="gml:SurfacePropertyType"/>
		<xs:element name="geometry2D" type="gml:CurvePropertyType"/>
	</xs:choice>
</xs:complexType >
<!-- ====================================================================== -->
<xs:complexType name="CellSpaceBoundaryGeometryPropertyType">
	<xs:sequence minOccurs="0">
		<xs:group ref="CellSpaceBoundaryGeometry"/>
	</xs:sequence>
	<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="CellSpaceBoundaryPropertyType">
	<xs:sequence minOccurs="0">>
		<xs:element ref="CellSpaceBoundary"/>
	</xs:sequence>
	<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

8.5.  <SpaceLayer>

SpaceLayer class is a top class used to represent a structured space model. A SpaceLayer represents each space layers such as topography, sensor, security space, etc. A SpaceLayer aggregates State and Transition which are directly associated with the corresponding geometry classes to represent dual space. To represent spatial objects in primal space, a SpaceLayer also aggregates CellSpace and CellSpaceBoundary which are directly associated with the corresponding geometry classes. The SpaceLayer class has attributes which are class, function, usage, creationDate and terminationDate. The attribute class – which can only occur once — represents a general classification of the layer. With the function and usage attributes, nominal and real functions of a space layer can be described.

The creationDate and terminationDate attributes can be used to describe the chronology of the layer. The points of time refer to real world times.

The SpaceLayer class has nodes and edges which represent a set of States and Transitions on the layer.

Figure 22 depicted an example of topographic space layer. Each space in real world mapping to State and the relationship between spatial objects is represented by Transition in a dual space of topographic space layer.

Figure 22 — Example of SpaceLayer (Topographic space layer)

<xs:element name="SpaceLayer" type="SpaceLayerType" substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="SpaceLayerType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/>
				<xs:element name="terminationDate" type="xs:dateTime"  minOccurs="0" maxOccurs="1"/>
				<xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/>
				<xs:element name="creationDate" type="xs:dateTime"  minOccurs="0" maxOccurs="1"/>
				<xs:element name="class" type="SpaceLayerClassTypeType"  minOccurs="0" maxOccurs="1"/>
				<xs:element name="nodes" type="NodesType" minOccurs="1" maxOccurs="unbounded"/>
				<xs:element name="edges" type="EdgesType" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
	<xs:complexType name="SpaceLayerPropertyType">
		<xs:sequence minOccurs="0">
			<xs:element ref="SpaceLayer"/>
		</xs:sequence>
		<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
	</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="NodesType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="stateMember" type="StateMemberType" 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="StateMemberType">
  	<xs:complexContent>
  		<xs:extension base="gml:AbstractFeatureMemberType">
  			<xs:sequence minOccurs="0">
  				<xs:element ref="State"/>
  			</xs:sequence>
  			<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
  		</xs:extension>
  	</xs:complexContent>
  </xs:complexType>
  <!-- ====================================================================== -->
  <xs:complexType name="EdgesType">
  	<xs:complexContent>
  		<xs:extension base="gml:AbstractFeatureType">
  			<xs:sequence>
  				<xs:element name="transitionMember" type="TransitionMemberType" minOccurs="0"
                                           maxOccurs="unbounded"/>
  			</xs:sequence>
  			<xs:attributeGroup ref="gml:AggregationAttributeGroup"/>
  			<xs:attributeGroup ref="gml:OwnershipAttributeGroup"/>
  		</xs:extension>
  	</xs:complexContent>
  </xs:complexType>
  <!-- ====================================================================== -->
  <xs:complexType name="TransitionMemberType">
  	<xs:complexContent>
  		<xs:extension base="gml:AbstractFeatureMemberType">
  			<xs:sequence minOccurs="0">
  				<xs:element ref="Transition"/>
  			</xs:sequence>
  			<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
  		</xs:extension>
  	</xs:complexContent>
  </xs:complexType>
  <!-- ====================================================================== -->
  <xs:simpleType name="SpaceLayerClassTypeType">
  	<xs:restriction base="xs:string">
  		<xs:enumeration value="TOPOGRAPHIC"/>
  		<xs:enumeration value="SENSOR"/>
  		<xs:enumeration value="LOGICAL"/>
  		<xs:enumeration value="TAGS"/>
  		<xs:enumeration value="UNKNOWN"/>
  	</xs:restriction>
  </xs:simpleType>

8.6.  <InterLayerConnection>

InterLayerConnection class has two States. Each State is defined in different SpaceLayers. Intersecting the geometries of the layer combinations provides an edge if the intersection of their interior geometries is non-empty; the edge, called InterLayerConnection, may express one of following spatial relationships: contains, overlaps, or equals. InterLayerConnection is denoted relationships between States in different SpaceLayers. The interConnects attribute represents the States belonged into the InterLayerConnection object. The ConnectedLayers attribute represents the SpaceLayers which include each State of InterConnects. The typeOfTopoExpression attribute represents a relationship between two layers. The comment attribute can contain an additional description for the InterLayerConnection.

<xs:element name="InterLayerConnection" type="InterLayerConnectionType" substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="InterLayerConnectionType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="typeOfTopoExpression" type="typeOfTopoExpressionCodeType"
                                         minOccurs="0" maxOccurs="1"/>
				<xs:element name="comment" type="xs:string" minOccurs="0" maxOccurs="1"/>
				<xs:element name="interConnects" type="StatePropertyType" minOccurs="2" maxOccurs="2"/>
				<xs:element name="ConnectedLayers" type="SpaceLayerPropertyType" minOccurs="2"
maxOccurs="2"/>

			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:simpleType name="typeOfTopoExpressionCodeType">
	<xs:union memberTypes="typeOfTopoExpressionCodeEnumerationType
                                                 typeOfTopoExpressionCodeOtherType"/>
</xs:simpleType>
<!-- ====================================================================== -->
<xs:simpleType name="typeOfTopoExpressionCodeEnumerationType">
	<xs:restriction base="xs:string">
		<xs:enumeration value="CONTAINS"/>
		<xs:enumeration value="OVERLAPS"/>
		<xs:enumeration value="EQUALS"/>
		<xs:enumeration value="WITHIN"/>
		<xs:enumeration value="CROSSES"/>
		<xs:enumeration value="INTERSECTS"/>
	</xs:restriction>
</xs:simpleType>
<!-- ====================================================================== -->
<xs:simpleType name="typeOfTopoExpressionCodeOtherType">
	<xs:restriction base="xs:string">
		<xs:pattern value="other. \w{2,}"/>
	</xs:restriction>
</xs:simpleType>

8.7.  <MultilayeredGraph>

MutliLayeredGraph is a key element of IndoorGML Core Module and is used to represent the Multi-layered Space Model. It aggregates SpaceLayers and InterLayerConnections. MutliLayeredGraph class consists of SpaceLayers and InterLayerConnections. MutliLayeredGraph has all the nodes (States) from all n layers (SpaceLayers) are included but they are separated into n partitions which are connected by the Transition. Furthermore, the graph also contains the state-transition edge (InterLayerConnection). The MultiLayeredGraph contains a set of SpaceLayer as spaceLayers and a set of InterLayerConnection as interEdges.

<xs:element name="MultiLayeredGraph" type="MultiLayeredGraphType" substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="MultiLayeredGraphType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="spaceLayers" type="SpaceLayersType" minOccurs="1" maxOccurs="unbounded"/>
				<xs:element name="interEdges" type="InterEdgesType" minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="SpaceLayersType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="spaceLayerMember" type="SpaceLayerMemberType" minOccurs="1"
                                         maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attributeGroup ref="gml:AggregationAttributeGroup"/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="SpaceLayerMemberType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureMemberType">
			<xs:sequence minOccurs="1">
				<xs:element ref="SpaceLayer"/>
			</xs:sequence>
			<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="InterEdgesType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="interLayerConnectionMember" type="InterLayerConnectionMemberType"
                                         minOccurs="1" maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attributeGroup ref="gml:AggregationAttributeGroup"/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="InterLayerConnectionMemberType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureMemberType">
			<xs:sequence minOccurs="0">
				<xs:element ref="InterLayerConnection"/>
			</xs:sequence>
			<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>

8.8.  <PrimalSpaceFeatures>

PrimalSpaceFeatures is a feature class for representing primal space features such as rooms. It consists of CellSpaces as cellSpaceMember and CellSpaceBoundary as cellSpaceBoundaryMember.

<xs:element name="PrimalSpaceFeatures" type="PrimalSpaceFeaturesType"
                    substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="PrimalSpaceFeaturesType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="cellSpaceMember" type="CellSpaceMemberType " minOccurs="0"
                                         maxOccurs="unbounded"/>
				<xs:element name="cellSpaceBoundaryMember" type="CellSpaceBoundaryMemberType " minOccurs="0"
                                         maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attributeGroup ref="gml:AggregationAttributeGroup"/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>

8.9.  < IndoorFeatures>

IndoorFeatures is a root element of IndoorGML Core Module to represent the indoor space. It is an aggregated element with PrimalSpaceFeatures and MultiLayeredGraph. The IndoorFeatures contains both a set of CellSpace and CellSpaceBoundary as PrimalSpaceFeatures and a set of SpaceLayer as MultiLayeredGraph.

<xs:element name="IndoorFeatures" type="IndoorFeaturesType" substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="IndoorFeaturesType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="primalSpaceFeatures" type="PrimalSpaceFeaturesPropertyType" minOccurs="0"
                                         maxOccurs="1"/>
<xs:element name="multiLayeredGraph" type=" MultiLayeredGraphPropertyType" minOccurs="0"
                                         maxOccurs="1"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>

8.10.  Requirements for conformance

This clause specifies the conformance requirements for the IndoorGML Core Module. Although most of conformance requirements are already presented in the model and XML schema of the IndoorGML Core Module, and certain complementary conformance requirements are explicitly given in this clause.

9.1.  <NavigableSpace>

The NavigableSpace class denotes a space that users can move freely in. It has two subclasses GeneralSpace and TransferSpace. The subclasses are classified depending on the purpose of the space. The compartmentalized spaces such as corridor, lobby, hallway, big room are represented as NavigableSpace. Especially, on 3D data mode, door is represented as NavigableSpace as shown as Figure 26-b).

A geometry of NavigableSpace is represented as gml:Solid on 3D data model or gml: Surface on 2D data model as shown as Figure 26 and Figure 27.

The class attribute represents the classification of the NavigableSpace. The different functions and usage of NavigableSpace can be represented as function and usage.

<xs:element name="NavigableSpace" type="NavigableSpaceType" substitutionGroup="IndoorCore:CellSpace"/>
<!-- ====================================================================== -->
<xs:complexType name="NavigableSpaceType">
	<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="usage" type="gml:CodeType"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>

9.2.  <NonNavigableSpace>

The NonNavigableSpace class represents the space that is occupied by obstacles. On 3D data model, a wall is typical NonNavigablespace as shown as Figure 26-b). It is not implemented on XML schema.

9.3.  <GeneralSpace>

The GeneralSpace class is one of the two subclasses of NavigableSpace. GeneralSpace is idenfied as any navigable spaces except Transferspace such as rooms, terraces, lobbies, etc as shown as Figure 28.

<xs:element name="GeneralSpace" type="GeneralSpaceType" substitutionGroup="NavigableSpace"/>
<!-- ====================================================================== -->
<xs:complexType name="GeneralSpaceType">
	<xs:complexContent>
		<xs:extension base="NavigableSpaceType"/>
	</xs:complexContent>
</xs:complexType>

9.4.  <TransferSpace>

The class TransferSpace is derived from NavigableSpace. It is used to model a space for providing passages between GeneralSpaces. It has three subclasses as ConnectionSpace, AnchorSpace, and TransitionSpace. Figure 28 shows ConnectionSpace and AnchorSpace in 2D or 3D space Model. Especially, a door (Door in CityGML or IfcDoor in IFC) is refered to ConnectionSpace or AnchorSpace in 3D Thick Door Model. A hallway and stairs also are represented as TransitionSpace. These subclasses of TransferSpace are mapped to State of IndoorGML core module.

Figure 28 — Examples of GeneralSpace, ConnectionSpace and AnchorSpace

<xs:element name="TransferSpace" type="TransferSpaceType" substitutionGroup="NavigableSpace"/>
	<!-- ====================================================================== -->
	<xs:complexType name="TransferSpaceType">
		<xs:complexContent>
			<xs:extension base="NavigableSpaceType"/>
		</xs:complexContent>
	</xs:complexType>

9.5.  <ConnectionSpace>

ConnectionSpace represents an opening space that provides passages between two indoor spaces as shown as Figure 28. It refers to Door features in the Thick Door Model. As mentioned before, ConnectionSpace is mapped to State in the IndoorGML core module.

<xs:element name="ConnectionSpace" type="ConnectionSpaceType" substitutionGroup="TransferSpace"/>
<!-- ====================================================================== -->
<xs:complexType name="ConnectionSpaceType">
	<xs:complexContent>
		<xs:extension base="TransferSpaceType"/>
	</xs:complexContent>
</xs:complexType>

9.6.  <AnchorSpace>

AnchorSpace represents a special opening space that provides connection between an indoor space and an outdoor space. It refers to Entrance Doors. It can be used as an AnchorNode, which is used as a control point for indoor-outdoor integrations.

<xs:element name="AnchorSpace" type="AnchorSpaceType" substitutionGroup="TransferSpace"/>
<!-- ====================================================================== -->
<xs:complexType name="AnchorSpaceType">
	<xs:complexContent>
		<xs:extension base="TransferSpaceType"/>
	</xs:complexContent>
</xs:complexType>

9.7.  <TransitionSpace>

TransitionSpace represents a real-world space that provides passage between two indoor spaces. It refers to corridors, stair and subspaces of hallway or corridor.

<xs:element name="TransitionSpace" type="TransitionSpaceType" substitutionGroup="TransferSpace"/>
<!-- ====================================================================== -->
<xs:complexType name="TransitionSpaceType">
	<xs:complexContent>
		<xs:extension base="TransferSpaceType"/>
	</xs:complexContent>
</xs:complexType>

9.8.  <NavigableBoundary>

NavigableBoudary is defined as the boundary of NavigableSpace including the boundary of ConnectionSpace and AnchoreSpace.

As shown as Figure 29, a door is mapped to a NavigableBoundary in Thin Door Model. Meanwhile in Thick Door Model, a door has two NavigableBoundary elements and two NonNavigableBoundary elements as shown as Figure 29. The boundary shared with other NavigableSpace is a NavigableBoundary and the others are mapped to NonNavigableBoundary class. The NavigableBoundary class has a subclass, called TransferBoundary.

<xs:element name="NavigableBoundary" type="NavigableBoundaryType"
                    substitutionGroup="IndoorCore:CellSpaceBoundary"/>
<!-- ====================================================================== -->
<xs:complexType name="NavigableBoundaryType">
	<xs:complexContent>
		<xs:extension base="IndoorCore:CellSpaceBoundaryType"/>
	</xs:complexContent>
</xs:complexType>

image::figures/29.png[align=”center”] 

9.9.  <TransferBoundary>

The class TransferBoundary is derived from NavigableBoundary. It is used to model a boundary for providing passages between NavigableSpace. NavigableBoundary has two subclasses, ConnectionBoundary and AnchorBoundary. As shown as Figure 29, in the Thin Door Model a door is mapped to ConnectionBoundary or to AnchorBoundary. In the Thick Door Model, some part of boundaries of door is mapped to ConnectionBoundary or AnchorBoundary. These subclasses of TransferSpace are mapped to Transition in the IndoorGML core module.

<xs:element name="TransferBoundary" type="TransferBoundaryType" substitutionGroup="NavigableBoundary"/>
<!-- ====================================================================== -->
<xs:complexType name="TransferBoundaryType">
	<xs:complexContent>
		<xs:extension base="NavigableBoundaryType">
			<xs:sequence/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>

9.10.  <ConnectionBoundary>

ConnectionBoundary represents a boundary which is connected with two adjacent NavigableSpaces. In a 2D space model, the ConnectionBoundary is represented as a gml:Curve. It is represented as a gml:Surface in 3D space model. As mentioned before, ConnectionBoundary is mapped to Transition in the IndoorGML core module.

<xs:element name="ConnectionBoundary" type="ConnectionBoundaryType"
                    substitutionGroup="TransferBoundary"/>
<!-- ====================================================================== -->
<xs:complexType name="ConnectionBoundaryType">
	<xs:complexContent>
		<xs:extension base="TransferBoundaryType"/>
	</xs:complexContent>
</xs:complexType>

9.11.  <AnchorBoundary>

AnchorBoundary represents a boundary which is the common boundary between a NavigableSpace and Outdoor space. It is represented as a part of boundary of AnchorSpace in Thick Door Model. In 2D space model, the AnchorBoundary is represented as a gml:Curve. It is represented as a gml:Surface in 3D space model. As mentioned before, AnchorBoundary is mapped to Transition in the IndoorGML core module.

<xs:element name="AnchorBoundary" type="AnchorBoundaryType" substitutionGroup="TransferBoundary"/>
<!-- ====================================================================== -->
<xs:complexType name="AnchorBoundaryType">
	<xs:complexContent>
		<xs:extension base="TransferBoundaryType"/>
	</xs:complexContent>
</xs:complexType>

9.12.  <RouteNode>

RouteNode class represents a node associated with a routing path. It has an association relation with a State to get more information from the State. RouteNode also has the attribute of geometric location data for providing this information to application services on the client side.

<xs:element name="RouteNode" type="RouteNodeType"/>
<!-- ====================================================================== -->
<xs:complexType name="RouteNodeType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="referencedState" type="IndoorCore:StatePropertyType"/>
				<xs:element name="geometry" type="gml:PointPropertyType"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="RouteNodePropertyType">
	<xs:sequence minOccurs="0">
		<xs:element ref="RouteNode"/>
	</xs:sequence>
	<xs:attributeGroup ref="gml:AssociationAttributeGroup"/>
</xs:complexType>

9.13.  <RouteSegment>

RouteSegment represents connectivity relationships between spaces (e.g., a room within a building, door). RouteSegments are directed edges between RoutesNodes. Each edge will have at least two nodes. The RouteSegment contains two RouteNodes for representing start position and end position, which called as connects element. It also has association relation with Transition class in the Indoor Core Module, which named to referencedTrasition element.

<xs:element name="RouteSegment" type="RouteSegmentType"/>
<!-- ====================================================================== -->
<xs:complexType name="RouteSegmentType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="weight" type="xs:double"/>
				<xs:element name="connects" type="RouteNodePropertyType"  minOccurs="2" maxOccurs="2" />
				<xs:element name="referencedTransition" type="IndoorCore:TransitionPropertyType" />
				<xs:element name="geometry" type="gml:CurvePropertyType"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>

9.14.  <Route>

Route represents a possible path to navigate indoor space. It is usually defined as a result of path find queries. The Route has a sequence of RouteNodes. The startRouteNode and endRouteNode represent a start position and end position of the path for indoor navigation. The attribute path contains RouteNode and RouteSegment of a possible path in indoor space and is represented as a sequence of RouteNodes and RouteSegments.

<xs:element name="Route" type="RouteType" substitutionGroup="gml:AbstractFeature"/>
<!-- ====================================================================== -->
<xs:complexType name="RouteType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="startRouteNode" type="RouteNodePropertyType" />
				<xs:element name="endRouteNode" type="RouteNodePropertyType" />
				<xs:element name="routeNodes" type="RouteNodesType" />
				<xs:element name="path" type="PathType" />
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="RouteNodesType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="nodeMember" type="RouteNodeMemberType" minOccurs="2"
                                         maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attributeGroup ref="gml:AggregationAttributeGroup"/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="RouteNodeMemberType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureMemberType">
			<xs:sequence minOccurs="1">
				<xs:element ref="RouteNode"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="PathType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureType">
			<xs:sequence>
				<xs:element name="routeMember" type="RouteSegmentMemberType" minOccurs="0"
                                         maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attributeGroup ref="gml:AggregationAttributeGroup"/>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>
<!-- ====================================================================== -->
<xs:complexType name="RouteSegmentMemberType">
	<xs:complexContent>
		<xs:extension base="gml:AbstractFeatureMemberType">
			<xs:sequence>
				<xs:element ref="RouteSegment"/>
			</xs:sequence>
		</xs:extension>
	</xs:complexContent>
</xs:complexType>

9.15.  Constraints

NavigableSpaceConstaints and NavigableBoundaryConstraint are linked to the topographic space semantic models through the relations. For providing indoor navigation, different categories of constraints can be identified: PassRestriction, WalkTypeRestriction, UserRestriction, TimeRestriction, and OneWayRestriction, as shown in Figure 30. Additional constraints can be defined as properties of the constraint elements.

The hierarchical conceptual constraint model could be used to create single or combined constraints for single or a series of semantic topographic space entities.

9.16.  Requirements for conformance

This clause specifies the conformance requirements for the IndoorGML Indoor Navigation Module. Although most of conformance requirements are already presented in the model and XML schema of the IndoorGML Indoor Navigation Module, and certain complementary conformance requirements are explicitly given in this clause.

Figure 29 — Conceptual model of indoor navigation constraints