7.2.1.  Geometry

Every cell defining an item in indoor space owns a shape, size, and location that can be collected and modeled. Cell can represent physical features such a room, door, wall, or virtual spaces such as legal rights and access or sensors coverages. Depending on the application, the geometry of a cell can be simplified and generalized into a polygon or rectangle. Such an approach can be applied when considering highly irregular shapes such as furniture. Geometric information can be included in an IndoorGML implementation instance either directly or via an external link. Geometry of cells can be omitted as well.

Cell geometry is defined in 2-dimensional or 3-dimensional Euclidean space and provides the means for the quantitative description of the spatial characteristics of cell. Metrics are defined as in (Morris, 2019). In the IndoorGML Conceptual Model, cells are modeled as features and conform with requirements as specified in ISO 19107 (Spatial Schema) (ISO, 2019). ISO 19107 provides conceptual schemas to describe and model real world objects as features.

Figure 6 — Three options to represent geometry in IndoorGML

As illustrated in Figure 6, there are three options for representing geometry of a cell in indoor space.

Note that Option 2 can always be used in combination with the other options. When Option 1 is used, three fundamental operations can be applied to cell spaces: subdivision, aggregation, and selection.

7.2.2.  Topology

Beside the geometry of a cellular space, cells can be represented in a topological model, which specifies the relationships between points, lines, polygons, and solids constructing the geometry (Gröger and George, 2012). Such topological models are dedicated to representing spatial relationships. As such, their shape and size are not described (Egenhofer et al., 1989). This is to say, geometric predicates such as volumes, areas, distances cannot be computed. As mentioned above, IndoorGML deals only with cells in 3D and 2D space, which are defined as solids or polygons. Consequently, the topological model contains only 3D and 2D objects in 3D cellular space and 2D and 1D objects in 2D cellular space. More information about topology of cells can be found in Clause 8.1.3.

7.2.3.  Subdivision, aggregation, and selection

The indoor environment is complex and indoor spaces often have hierarchical structures. For several indoor applications, a careful decomposition of an indoor space is required to reflect these hierarchical structures. To support the representation of such configurations, the subdivision, aggregation, and selection processes on the CellSpaces can be applied.

Figure 7 — (a) A furnished indoor space. (b) Subdivision of the indoor space into two separate rooms with exclusion of furnishing elements’ spaces. (c) Selection of specific CellSpaces (green) suitable for walking and rolling. (d) CellSpaces (green) suitable for flying.

As illustrated in Figure 7, the subdivision is performed by splitting the original cells into several subspaces, according to the function of cell. For example, in Figure 7(b), the indoor space is subdivided into several cells according to their functions (e.g., as in Figure 7(a)) into a kitchen and a living room, as well as discriminating the spaces physically occupied by items. The subdivision process could be based on any application-based criteria and all resulting subspaces are CellSpaces of a cellular space. For navigation applications, subdivisions may be required due to:

The aggregation process is the reverse of the subdivision process. An aggregation process results in subspaces being merged instead of being split. Therefore, the merging of all subspaces shown in Figure 7(a) allows retrieving the original cell spaces. Similarly, any new cell resulting from this process is a CellSpace of a cellular space. For the purpose of indoor navigation, aggregation may be required when:

Finally, it is possible to discriminate CellSpaces of interest from the rest. Figure 7© and (d) illustrate a scenario where only CellSpaces that can support certain type of locomotion modes are considered in the cellular space (see the green CellSpaces). The selection of spaces for indoor navigation applications can take place for many different reasons:

7.6.1.  Multiple-Layered Space representation

The IndoorGML model provides mechanisms for maintaining and linking multiple Thematic layers for the same indoor environment. Figure 13 represents the three thematic layers discussed above.

Figure 13 — Corresponding Primal and Dual spaces of different thematic layers.

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, representing the hierarchical structure of indoor space, where each floor level is a single space layer. Another application example is indoor tracking using presence sensors, such as RFID, as shown in Figure 12. Given an indoor space represented as a Topographic layer and RFID sensor coverage layer respectively, the movement of a mobile object can be deduced using a RFID tag by the sequence of RFID coverage cells and corresponding inter-layer space edges.

7.6.2.  Inter-Layer Relations

To handle the interaction between several layers, it is necessary to represent the relationships between them. IndoorGML does this through the Inter-Layer connection which describes the spatial relationships (topology) between two layers. Unlike the topological relationships between cells of a same layer which are ruled by the Poincaré Duality (adjacency only), the inter-layer relations are ruled by the 9-intersection model (Egenhofer, 1989). IndoorGML 2.0 concentrates on six relationships: contains, within, covers, coveredBy, overlaps and equals between cells in the Primal space and nodes in Dual space.

As illustrated in Figure 13, there are three space layers. Each layer has its own Primal and Dual space representation. Following the same indoor tracking example, Figure 14 illustrates the inter-layer relations between the dual spaces of the layers in Figure 12. 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). 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., adjacent rooms connected by a door). In the sensor space, the graph has a slightly different structure. The nodes represent again the cells (e.g., the entire coverage space of a Wi-Fi transmitter); the edges represent the transition from one space to another based on the neighboring Wi-Fi coverage spaces. Since the layers cover the same real-world space, the separated dual graphs can be combined into a multi-layered graph.

Figure 14 — Inter-Layer relations between three different layers of a same environment.

Figure 14 illustrates relationships in the Dual space between the three Primal spaces given in Figure 13: Topographic and two sensors’ spaces Wi-Fi and RFID. A novelty in the IndoorGML 2.0 model is the possibility of representing an inter-layer connection between two primal spaces. This is illustrated in Figure 15 where the inter-layer mechanism is used to represent a furnished room with a combination of two layers: One describing solely the cells of the room and openings (Figure 15(b)) and one describing the furniture CellSpaces (Figure 15©). The relationship between the two layers can be qualified as a containment (layer 1 contains layer 2, or layer 2 is within layer 1). This supports describing complex scenes while respecting the non-overlapping constraint of Poincare duality.

Figure 15 — Inter-layer connection between two primal spaces. (a) furnished room. (b) cells of the room and door only. (c) cells of furnishing elements only represented by minmax boxes.

8.1.1.  CellSpace

CellSpace is a core module class for representing the indoor environment in terms of cellular space. CellSpace is a mandatory class to have a valid IndoorGML2.0 encoding. It contains the following properties (Figure 17):

Figure 17 — CellSpace and its related classes: PrimalSpaceLayer, CellBoundary, Node and InterLayerConnection

The cellSpaceGeom property carries an instance of type CellSpaceGeometryType for the description of geometric representations of space. A CellSpaceGeometryType is a geometry class type with two possible properties: Geometry3D or Geometry2D. They provide the 3D and 2D description of a CellSpace instance. The Geometry3D property describes a representation of type solid, similar to the GM_Solid (ISO 19107) type. It is the default type for describing a 3D CellSpace as one single valid entity. The Geometry2D property describes a representation of type surface, similar to the GM_Surface type. This property describes a CellSpace in 2D as one single surface (in the case of a 2D IndoorGML model). The geometry should be valid according to the ISO 19107 Standard terms. If a CellSpace cannot meet those requirements, e.g., be valid 2D or 3D geometry, the option to describe its geometry as a set of CellBoundary entities can be considered. The CellSpace can be defined without geometry as well.

The property externalReference is used for the reference of an object to its corresponding object in an external data set. A CellSpace also carries a level information, which can be left empty when it cannot be clearly identified. For example, this is the case for a CellSpace that aggregates several cells spanning across multiple stories. The value of level is given as a string rather than an integer because it is sometime given as plain text “M” for mezzanine floor and “RC” for ground floor. A newly introduced property in IndoorGML 2 is cellSpaceName. The purpose is to record the name given to a space according to any internal convention (e.g., MR.403 for meeting room 3 at level 4, or coverage of Wi-Fi 234). This is a common practice for large buildings and this property helps simplify space queries for applications. Another new property PoI is introduced to allow CellSpace elements to be flagged as Point of Interest for LBS applications. The property is a simple Boolean allowing the implementation of special considerations for flagged cells.

Note that apart from the PoI property, all applicable properties of a CellSpace can be null. For example, a network only IndoorGML model would not need a cellular space with explicit geometric description. However, CellSpace instances should always be described in an IndoorGML model (even without geometry property) as they may carry all the important information related to the primal space that other features from the dual space or other layers may need. For example, a node can be identified as a PoI or associated with a cellSpaceName thanks to the property of its primal space.

In terms of relationships, a CellSpace instance can describe relationship with multiple CellBoundary entities, which represent its surrounding boundaries partially or fully through the boundedBy association. For example, the choice can be made to store only boundaries which are important for the Dual Graph (e.g., boundaries that reflect adjacency between CellSpaces). In the case where a CellSpace does not carry the geometry of type Solid and uses a boundary-based representation instead, then all boundaries might be needed (to derive the geometry of the nodes or for visualization). Finally, with the duality association, a CellSpace can describe a reference to one Node instance corresponding to its representation in the dual space.

CellSpace instances are aggregated in a PrimalSpaceLayer according to a specific theme as explained in Clause 7.6. For the case of multiple PrimalSpaceLayers, the class InterLayerConnection establishes the link between the depended CellSpace instances.

8.1.2.  CellBoundary

CellBoundary is a core module class that describes the boundary of each cell in a cellular space (Figure 18). Unlike CellSpace, CellBoundary is not a compulsory class. It is only required when Edge instances exist in the model. CellBoundary contains the following properties:

Figure 18 — CellBoundary and its related classed: PrimalSpaceLayer, CellSpace and Edge

The cellBoundaryGeom geometry property of the CellBoundary carries the geometry (of type CellBoundaryGeometryType) which is generally described by a surface in 3D or a curve in 2D. A CellBoundaryGeometryType is a geometry class type similar to the CellSpaceGeometryType, with two possible properties: Geometry2D and Geometry1D. The Geometry2D property is the same as that of CellSpaceGeometryType. Note, in this context, cellBoundaryGeom is embedded in 3D, i.e., has 3D coordinates and represents a part of the boundary of a CellSpace. The Geometry1D property describes a representation of type curve, GM_Curve type. Note, this property is intended for describing a CellBoundary in 2D as one single line/curve and has 2D coordinates. This is an adequate representation of cellBoundaryGeom based on 2D floor plans. cellBoundaryGeom is not required (e.g., when CellBoundary simply indicates a virtual boundary).

The property externalReference is used for the reference of a geometric object to its corresponding object in an external data set and can be given by the url of the file containing the geometry. The isVirtual property is a Boolean value used to indicate whether a CellBoundary corresponds to a virtual surface (true) or a physical one (false), which should be the default value. Virtual boundaries are common in 3D indoor models, mainly when a space subdivision is applied.

Additionally, a CellBoundary can be linked to one Edge instance via the duality association, which corresponds to its dual representation. Unlike CellSpace, CellBoundary is not a mandatory instance in an IndoorGML data. In the case where there are CellSpace entities but no CellBoundary, the network may be derived from the cells using geometric operations.

In the case where there are CellBoundary entities provided without geometric properties in the model, only logical networks can be safely derived between two CellSpace entities sharing any of those CellBoundary. Therefore, providing geometric networks involves similar issues described previously. A final scenario may see an IndoorGML data with geometry information only with CellBoundary instances but not for CellSpace. That case is likely to happen if a solid geometry cannot be provided for a CellSpace, and a set of surface boundaries are provided with no guarantee of closure. In that case the generation of a Node for a CellSpace should be completed from CellBoundary instances, while guaranteeing its position inside the described space.

8.1.3.  PrimalSpaceLayer

PrimalSpaceLayer is a core module class representing the primal cellular spaces of a given thematic layer (Figure 19). It aggregates CellSpace and CellBoundary (which are directly associated with their corresponding geometry properties) to represent spatial objects in primal space. The PrimalSpaceLayer class has the following properties:

Figure 19 — PrimalSpaceLayer and its related classes: CellSpace, CellBoundary and Thematic Layer

Both creationDate and terminationDate properties can be used to describe the chronology of the layer. A PrimalSpaceLayer instance also provides references to its CellSpace and CellBoundary entities through the cellSpaceMember and cellBoundaryMember elements.

8.1.4.  Node

Node is a core module class for representing a node in dual space (Figure 20). It has one property:

Figure 20 — Node and its related classes: CellSpace, Edge, DualSpaceLayer and InterLayerConnection

The value of geometry corresponds to a 2D or 3D Point in the IndoorGML model, but its cardinality can be 0 (no geometry provided) or 1. Because a Node is always the dual space abstraction of a primal space cell, a Node always has an association with its corresponding CellSpace (e.g., room, door, sensor coverage, etc.) through the duality association. This way, a Node can always access the information related to the cell it is representing (e.g., geometry, semantic, etc.). Note that the associated CellSpace may not carry any information as well, except the functional information for the specific cellular space. Additionally, a Node is also associated with at least one Edge instance that is linked to it via the connects association.

8.1.5.  Edge

Edge is a core module class that represents the adjacency or connectivity relationships among Node elements representing space cells in primal space (Figure 21). The Edge class has the following properties:

Figure 21 — Edge and its related classes: CellBoundary, Node and DualSpaceLayer

The property geometry provides the description of a 2D or 3D curve, but similar to Node entities its cardinality can be 0 or 1 as well. The property weight can be used for graph-based applications such as dealing with the impedance representing absolute barriers in transportation problems.

An Edge may be associated with a CellBoundary instance of the primary space via its duality association. This association can be skipped in situations where a CellBoundary is not necessary to represent the link between two CellSpace entities. For example, logical networks or visibility graphs where two CellSpaces connected by visibility may not share a CellBoundary. Finally, an Edge always connects two Nodes.

8.1.6.  DualSpaceLayer

DualSpaceLayer is a feature class for representing the dual space features (e.g., room network) of a given thematic layer. The DualSpaceLayer class is composed of Nodes and Edges for representing the topology of objects from the primal space. The DualSpaceLayer class has the following properties:

Figure 22 — DualSpaceLayer and its related classes: Node, Edge and Thematic Layer

While creationDate and terminationDate are similar to those of PrimalSpaceLayer, the isLogical property allows differentiating whether the provided network is a geometric or a logical network. This difference may matter for certain applications such as navigation, where a logical network would not be sufficient to evaluate travel distances between cells. Similarly, the isDirected property allows to specify if the graph associated with the DualSpaceLayer is directed or not. A directed graph implies that the node directions should be considered in the applications. Currently, the order of the nodes in the implementation formats determines their direction. Additionally, a DualSpace provides references to all its related Node and Edge entities through its nodeMember and edgeMember compositions.

8.1.7.  InterLayerConnection

The InterLayerConnection class describes the connection between two layers in IndoorGML, either of type PrimalSpaceLayer or DualSpaceLayer (Figure 23). The InterLayerConnection class contains the following properties:

Figure 23 — InterLayerConnection and its related classes: CellSpace, Node, ThematicLayer and IndoorFeatures

The typeOfTopoExpression property represents the topological relationship between two layers. typeOfTopoExpression is a code list with the following values: contains, within, crosses, overlaps and equals. Those topological values are in the form of verbs for which the subject is the first instance of the connectedLayers property. In other words, for two layers successively described by the connectedLayers association, such as Layer 1 and Layer 2, one should read Layer 1 typeOfTopoExpression Layer 2 (e.g., Layer Room contains Layer Furniture).

An InterLayerConnection also describes the cells or nodes that are connected between two layers, using the connectedCells and/or connectedNodes associations. The former is used when the connection is between two primal spaces and the latter is used otherwise. Finally, the comment property can contain an additional description for the InterLayerConnection.

8.1.8.  ThematicLayer

The ThematicLayer is a core module class introduced in IndoorGML2.0. ThematicLayer is an aggregation of PrimalSpaceLayer and DualSpaceLayer instances to allow definition of Thematic layers separately (Figure 24). Note, IndoorGML 1.1 enables the multi-layer mechanism only for the dual space (the networks). The ThematicLayer class is composed of the following properties:

Figure 24 — ThematicLayer and its related classes: PrimalSpaceLayer, DualSpaceLayer, InterLayerConnection and IndoorFeatures

The semanticExtension property is a Boolean that indicates whether there is Extension module with additional semantic information associated to the PrimalSpaceLayer. The IndoorGML 2.0 Standard only specifies the Navigation extension module (see Clause 8.2). The use of a Boolean is considered enough to indicate the presence of the Navigation extension. However, this is expected to evolve in the future (into a codeList). The theme property determines what type of representation of the model can be expected in the corresponding layer (e.g., topographic). The theme property comes in the form of a code list which tells whether the layer is of type Physical, Virtual, Tags or Unknown.

A Physical layer is a layer that describes the indoor space on the basis of its physical constraints (e.g., the topographic cellular space in Figure 12) (Nagel et al., 2009). It is the most common type of layer for applications such as indoor navigation, where the physical elements highly constrain the use of the space. Similarly, a layer is qualified as Virtual when its description of the space relies exclusively on virtual, or a combination of physical and virtual extents. For example, the case for functional spaces that can represent spaces necessary for some indoor objects to operate or to be used properly (Diakité, 2018). This is also the case for sensor spaces such as the Wi-Fi spaces represented in Figure 12. Finally, the Tags type is useful for describing layers that use symbols or tags to represent the cellular space. The Tags type is a useful representation when the real geometry of the CellSpaces of a given layer are not relevant for a given application. PoI are often represented in a separate layer with their locations only (e.g., in Dual Space). Finally, any layer the does not fall in those previous categories will take the Unknown type.

8.2.1.  NavigableSpace

The NavigableSpace class denotes a space in which users can move freely. It has two subclasses GeneralSpace and TransferSpace (Figure 27). The subclasses are classified depending on the purpose of the space. The compartmentalized spaces such as corridor, door, lobby, hallway, big room are represented as NavigableSpace. Note, door is represented as NavigableSpace as shown in Figure 26, especially in the 3D case. In 2D, doors are commonly represented as boundaries of rooms and must be considered NavigableBoundaries (see Clause 8.2.4).

Figure 27 — NavigableSpace and its related class: CellSpace

NavigableSpace entities can carry information about the type of locomotion, which is the allowed transportation mode in indoor space. The locomotionType property has one of the following values: Walking, Flying, Rolling and Unspecified. A Navigable space may handle one or several of the locomotion types listed. Note, the class instances inherit the geometry of its parent CellSpace entity and can therefore be represented as GM_Solid on 3D data model or GM_Surface on 2D data model.

8.2.2.  GeneralSpace

The GeneralSpace class is one of the two subclasses of NavigableSpace (Figure 28). GeneralSpace is identified as any navigable cells such as rooms, lobbies, kitchen, etc., which agents can use for a longer period of time and can serve as starting and target cell in navigation. It carries the property function which specifies details about the function of the cell.

Figure 28 — GeneralSpace and its related class: NavigableSpace

8.2.3.  TransferSpace

The class TransferSpace is specialization of NavigableSpace. It is used to model a space that provides passages between GeneralSpaces. Thereby, it typically describes openings (mainly doors but also windows) for horizontal transfer and entrances to staircase or lift cells for vertical transfers. Similarly to the GeneralSpace class, TransferSpace carries a function property that describes whether the space is an AnchorSpace (a space allowing to connect the indoor and the outdoor) or a BoundarySpace (a space connecting two indoor or two outdoor spaces). Another of its property is category which specified through a codeList the TransferSpaceCategoryType (Door or Window).

Figure 29 — TransferSpace and its related class: NavigableSpace

8.2.4.  NavigableBoundary

The NavigableBoundary class is a specialization of a CellBoundary and provides further information related to NavigableSpace (Figure 30). As illustrated in Figure 26, it typically represents the space boundaries that correspond to entrances or exits through which agents navigate from one cell to another. The NavigableBoundary class is therefore mainly found between GeneralSpace and TransferSpace cells but can happen between two GeneralSpace cells as well such as in the case of a room subdivided to distinguish areas of different purposes.

A NavigableSpace is necessarily bound by at least one NavigableBoundary. In the specific case of a TransferSpace, it is expected to have at least two NavigableBoundary instances bound to it, as a TransferSpace serves for transition between connected spaces.

The class carries a boundaryOrientation property and a navigableBoundaryFunction property specifying if the boundary is an AnchorBoundary or a ConnectionBoundary (see Clause 8.2.3 for more details).

Figure 30 — NavigableBoundary and its related class: CellBoundary

8.2.5.  NonNavigableSpace

The NonNavigableSpace class represents cells that are occupied by obstacles (Figure 31). It can correspond to the structural elements of a building (walls, slabs, etc.) or other indoor features populating the space (furniture, appliances etc.). NonNavigableSpace is a class without properties, but allows options to further classify non-navigable cells.

Figure 31 — NonNavigableSpace its related class: CellSpace

8.2.6.  ObjectSpace

The ObjectSpace (Figure 32) class is meant to bring additional details to a NonNavigableSpace when it contains some objects that makes it non-navigable. The class has two properties: containedFeatures (Integer), and description (CharacterString).

Figure 32 — ObjectSpace and its related class: NonNavigableSpace

The containedFeatures property is an integer that describes the number of objects encapsulated within the ObjectSpace and thus, by extension within the parent NonNavigableSpace. The objects in question can be represented in a different layer of the model and the link to the corresponding ObjectSpace can be made through an InterLayerConnection instance with a within or contains relationship. The description property is meant to provide any relevant information regarding the objects contained within the space in plain text.

8.2.7.  NonNavigableBoundary

NonNavigableBoundary entities represent the boundaries between two NonNavigableSpace cells or between a NavigableSpace and a NonNavigableSpace cells (Figure 33). As such, it is the type of boundary that can be found typically at the lateral sides of a TransferSpace (see Figure 26(b)), corresponding for example to the walls surrounding a door.

Figure 33 — NonNavigableBoundary and its related classes: CellBoundary

8.2.8.  Route

The Route class is a specialization of a Dual space that represents a subset of Network (logical or physical), which includes a path to navigate through indoor space. It is usually defined as the result of a path finding query.

The Route class has one property: creationDate. Because dynamic indoor environments may imply change in space availability and accessibility, a suitable path at a given time may not be suitable at another time. For this reason, the creationDate property helps indicating at which time a given route was created. The routeNode and routeEdge properties are both ordered sequences of Node and Edge references to describe the different parts of the route path. Therefore, the first and last routeNode elements correspond respectively to the starting and destination points of the route.

Figure 34 — Route and its related classes: Node and Edge

9.1.1.  IndoorFeatures

9.1.2.  ThematicLayer

9.1.3.  PrimalSpaceLayer

9.1.4.  CellSpace

9.1.5.  CellBoundary

9.1.6.  DualSpaceLayer

9.1.7.  Node

9.1.8.  Edge

9.1.9.  InterLayerConnection

9.2.1.  NavigableSpace

9.2.2.  NonNavigableSpace

9.2.3.  GeneralSpace

9.2.4.  TransferSpace

9.2.5.  ObjectSpace

9.2.6.  NavigableBoundary

9.2.7.  NonNavigableBoundary

9.2.8.  Route