i. Abstract
This OGC^{®} IndoorGML standard specifies an open data model and XML schema for indoor spatial information. IndoorGML is an application schema of OGC^{®} GML 3.2.1. While there are several 3D building modelling standards such as CityGML, KML, and IFC, which deal with interior space of buildings from geometric, cartographic, and semantic viewpoints, IndoorGML intentionally focuses on modelling indoor spaces for navigation purposes.
ii. Keywords
ogcdoc, ogc documents, indoorgml, gml, indoor, navigation
iii. Submitting organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
 Pusan National University
 University of Seoul
 Technical University of Munich
 Technical University of Berlin
 Technical University of Delft
 University of Nottingham
 Hitachi Ltd.
 Electronic and Telecommunication Research Institute
iv. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
Name  Representing  OGC member 

Participants list in development  
KiJoune Li  Pusan National University  Yes 
Joonseok Kim  Pusan National University  Yes 
Jiyeong Lee  University of Seoul  Yes 
HyeYoung Kang  University of Seoul  Yes 
Thomas H. Kolbe  Technical University of Munich  Yes 
Thomas Becker  Technical University of Berlin  Yes 
Robert Kaden  Technical University of Berlin  Yes 
Claus Nagel  Virtual City Systems  Yes 
Sisi Zlatanova  Technical University of Delft  Yes 
Jeremy Morley  University of Nottingham  Yes 
Nobuhiro Ishimaru  Hitachi Ltd.  Yes 
Yaemi Teramoto  Hitachi Ltd.  Yes 
JaeJoon Yu  ETRI  Yes 
SeokHo Lee  Hyundai MNSoft Co.  Yes 
Dongkwon Seo  Hyundai MNSoft Co.  Yes 
Cliff Behrens  Applied Communication Sciences  Yes 
v. Changes to the OGC^{®} Abstract Specification
The OGC^{®} Abstract Specification does not require changes to accommodate this OGC^{®} standard.
vi. Foreword
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights. However, to date, no such rights have been claimed or identified.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
vii. Introduction
The goal of IndoorGML is to represent and allow for exchange of geoinformation that is required to build and operate indoor navigation systems. Several standards such as CityGML[10,28], KML[30], and IFC[31] have been published to describe 3D geometry and semantics of buildings not only for outdoor space but also indoor space, but they lack important features that are required by indoor navigation applications. This standard aims to provide complementary and additional encoding features for indoor spatial information required for indoor navigation.
This OGC standard consists of two components: 1) a core data model to describe topological connectivity and different contexts (e.g. topographic space and sensor space) of indoor space, and 2) a data model for navigation in indoor space.
IndoorGML covers geometric and semantic properties relevant for indoor navigation in an indoor space. These spaces may differ from the spaces described by other standards such as CityGML, KML, and IFC. In this respect, IndoorGML is a complementary standard to CityGML, KML, and IFC to support location based services for indoor navigation.
Scope
IndoorGML is an OGC^{®} standard for the representation and exchange of indoor navigation network models. IndoorGML is implemented as an application schema of the Geography Markup Language version 3.2.1.
IndoorGML aims to establish a common schema for indoor navigation applications. It models topology and semantics of indoor spaces, which are needed for the components of navigation networks. Nevertheless, IndoorGML contains only a minimum set of geometric and semantic modelling of construction components to avoid duplicated efforts with other standards, such as CityGML and IFC.
IndoorGML defines the following information about indoor space;
 Navigation context and constraints
 Space subdivisions and types of connectivity between spaces
 Geometric and semantic properties of spaces and connectivity
 Navigation networks (logical and metric) and their relationships
Conformance
Conformance targets of this OGC^{®} Standard are IndoorGML instance documents. Conformance with this standard shall be checked whether IndoorGML instance documents achieve the criteria as defined in clause 7 to 9.
In order to conform to IndoorGML, and schema document should
 conform to the rules, specifications, and requirements in clauses 7 to 9,
 pass all relevant test cases of the abstract test suite given in annex B
Normative References
The following normative documents contain provisions, which, through reference in this text, constitute provisions of this document. For dated references, subsequence amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.
 ISO 8601:2004, Data elements and interchange formats – Information interchange – Representation of dates and times
 ISO/TS 19103:2005, Geographic Information – Conceptual Schema Language
 ISO 19105:2000, Geographic information – Conformance and testing
 ISO 19107:2003, Geographic Information – Spatial Schema
 ISO 19109:2005, Geographic Information – Rules for Application Schemas
 ISO 19111:2003, Geographic information – Spatial referencing by coordinates
 ISO 19115:2003, Geographic Information – Metadata
 ISO/TS 19139:2007, Geographic Information – Metadata – XML schema implementation
 OpenGIS® Abstract Specification Topic 0, Overview, OGC document 04084
 OpenGIS® Abstract Specification Topic 5, The OpenGIS Feature, OGC document08126
 OpenGIS® Abstract Specification Topic 8, Relations between Features, OGC document 99108r2
 OpenGIS® Abstract Specification Topic 10, Feature Collections, OGC document 99110
 OpenGIS® Geography Markup Language Implementation Specification, Version 3.2.1, OGC document 07036
Terms and Definitions
For the purposes of this document, the following terms and definitions apply.
 4.1 Indoor Space

A space within one or multiple buildings consisting of architectural components.
 4.2 Coordinates Space

A space where location is identified by (x,y) or (x, y, z) coordinates where x, y, andz are real values.
 4.3 Cellular Space and Symbolic Space

A space where location is identified by a cell identifier (or symbolic code).
 4.4 NR (NodeRelation) Graph

A graph (V, E) where V is a set of nodes representing cells in indoor space and E is the set of edges indicating the topological relationship between two cells, which may be connectivity or adjacency.
 4.5 Connectivity NRG

A NR graph (V, E) where V is a set of nodes representing cells in indoor space and E is the set of edges indicating the connectivity.
 4.6 Adjacency NRG

A NR graph (V, E) where V is a set of nodes representing cells in indoor space and E is the set of edges indicating the adjacency relationship.
 4.7 Accessibility NRG

A NR graph (V, E) where V is a set of nodes representing cells in indoor space and E is the set of edges indicating the accessibility relationship.
 4.8 Logical NRG

A NR graph (V, E), where node v in V and edge e in E do not contain any geometric properties.
 4.9 Geometric NRG

A NR graph (V, E) where node v in V and edge e in E contain geometric properties.
 4.10 MultiLayered Space Model

A space represented by multiple layers of connectivity graphs and interlayer connections between two nodes from different layers.
Conventions
Abbreviated terms
The following symbols and abbreviated are used in this standard;
 BIM
 Building Information Modeling
 CityGML
 City Geographic Markup Language
 GPS
 Global Positioning Systems
 CRS
 Coordinate Reference System
 GML
 Geographic Markup Language
 IndoorGML
 Indoor Geographic Markup Language
 IFC
 Industry Foundation Classes
 ISO
 International Organization for Standardization
 KML
 Keyhole Markup Language
 LOD
 Level of Detail
 MLSM
 MultiLayered Space Model
 MVD
 Model View Definition
 NRG
 NodeRelation Graph
 OGC
 Open Geospatial Consortium
 RFID
 Radio Frequncy IDentifier
 SensorML
 Sensor Model Language
 UML
 Unified Modeling Language
 XML
 eXtended Markup Language
 1D
 One Dimensional
 2D
 Two Dimensional
 3D
 Three Dimensional
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.
In this standard, the following three stereotypes of UML classes are used:
 <<Interface>> A definition of a set of operations that is supported by objects having this interface. An Interface class cannot contain any attributes.
 <<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.
 <<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:
 CharacterString – A sequence of characters
 Integer – An integer number
 Double – A double precision floating point number
 Float – A single precision floating point number
Overview of IndoorGML
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 are 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 locationbased services, indoor route analysis or indoor geotagging 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.
General characteristics of IndoorGML
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
 MultiLayered Representation
Definition of Indoor Space
Indoor space is defined as space within one or multiple buildings consisting of architectural components such as entrances, corridors, rooms, doors, and stairs. In IndoorGML, we are not concerned about architectural components themselves (e.g. roofs, ceilings, walls) but instead the spaces (e.g. rooms, corridors, stairs) defined by architectural components, where objects can be located and navigate. IndoorGML is also concerned with the relationships between spaces. Components irrelevant to describe the spaces, such as furniture, are not within the scope of IndoorGML.
While indoor space models may be restricted to a single building, they may be comprised of multiple buildings or a complex of connected buildings. All the buildings are not necessarily covered by a roof. For example, an inner court or veranda can belong to an indoor space.
Cellular notion of space and cells
One of the differences of IndoorGML from standards dealing with building interior space such as IFC is that they provide standards for representing architectural components but standards for indoor space. For this reason, we consider an indoor space as a set of cells, which are defined as the smallest organizational or structural unit of indoor space [28]. A cellular space S is defined as follows;
S= {c_{1}, c_{2}, … , c_{n} }, where c_{i} is i^{th} cell.
Cellular space has important properties. First, every cell has an identifier (namely c.ID), such as a room number. Second, each cell may have a common boundary with other cells but does not overlap with any other cell. Third, postion in cellular space can be specified by cell identifier, although we may employ (x, y, z) coordinates to specify a position for more precise location.
While a set of cells is the minimum information to determine a cellular space, additional information can be also included in cellular space as follows;
 semantics: e.g. classification and interpretation of cells
 geometry: e.g. solids in 3D or surfaces in 2D
 topology: e.g. adjacency or connectivity
Semantic Representation of Indoor Space
Semantics are an important characteristic of cells. The indoor space can be decomposed into different cells if differet criteria are considered. The cell subdivision can represent the topography (construction) of a building, available WiFi coverages, indicate security areas, or public/office areas, etc. Every cell is then given semantics with respect to the semantics used to the space subdivision. For example, in a topographic space it is possible to have‘room’, ‘door’, ‘window’, in WiFi space  ‘WiFi point A’, ‘WiFipoint B’, etc. andin a security space  ‘checkin area’, ‘boarding area’, ‘crew areas’.
In IndoorGML, semantics is used for two purposes: to provide classification and to identify a cell and determine the connectivity between cells. Semantics thus allows us to define cells that are important for navigation. For example, the most commonly used classification of cells in topolographic space is into navigable (rooms, corridors, doors) and nonnavigable (walls, obstacles) cells.
Cells can be organised in a hierarchical structure according to their semantics, corresponding properties and semantic interrelations (specialisation and generalisation). For example ‘room’ is a specialisation of ‘navigable cell’ and ‘nonnavigable cell’ is a generalisation of ‘walls’ and ‘obstacles’. Cells created for one space represenation may be aggregated or subdivided for the purpose of another one. For example, in security space ‘checkin area’ cell can be an aggregation of several ‘room’ cells, which have been created for the topography space.
Connectivity, in terms of possibility to navigate through cells, is largely derived from the semantics of cells. For example to be able to go from one room to another, we need to know that at least one common opening (door, window) cell exists.
The properties of a semantically identified cell have impact on connectivity and can act as a navigation constraint. For example, certain doors might provide access in one direction only (emergency exits), or forbid access to a specific group of users (security areas) or allow access according to specific time intervals (e.g. shops).
IndoorGML allows different space representation to be integrated via the concept of MultiLayered Space Representation (see 7.1.6).
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 selfcompleteness, 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;
 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.
 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.
 No Geometry (Option 3): No geometric information is included in IndoorGML document.
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.
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 NodeRelation 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 kdimensional object in Ndimensional primal space is mapped to (Nk) 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 3a and Figure 3b 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 4a 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 4b. 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 4b becomes a different graph, called connectivity graph, which represents connectivity between cells as shown in Figure 5. Among adjacency relationships between cells in Figure 4b, the edge 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.
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 4a, and they are accordingly mapped to edges in dual space as depicted in Figure 4b. 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.
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.
MultiLayered 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 eachdecomposition forms a separate layer of cellular space as shown in Figure 8.
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 interlayer 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 interlayer space edges.
Structured Space Model
IndoorGML is based on two conceptual frameworks: the Structured Space Model and thye MultiLayered 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 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 modelling geometrical features of real world phenomena. However, the transition from primal to dual space cannot be modelled 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 logicalNRG, while the NRG embedded to Euclidean IR^{3} space is a geometricNRGas 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 statetransition 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.
MultiLayered Space Model
The concept of Structure Space model is further extended to MultiLayered Space Model (MLSM). MultiLayered Space Model provides an approach for combining multiple space structures for different interpretations and decomposition layers to support full indoor information services.
MultiLayered 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.
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, sensor space layer is also a fundamental one, 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.
InterLayer Relations
Layers of multilayered space model can be connected by interlayer 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 multilayered graph. Figure 12 illustrates overlaid space layers.