IndoorGML is all set to become the reference standard within location-based services industry. It aims to provide a common framework of representation and exchange of indoor spatial information. By Prof. Ki-Joune Li and Dr. Giuseppe Conti
The increasing interest in location-bas
ed services (LBS) calls for a standardisation effort to ensure interoperability with fast evolving technological landscape. A noteworthy effort from the standardisation community in the domain of LBS is the recently published ISO/IEC 24730-1:2014 standard on ‘Information technology – real-time locating systems (RTLS)’, which defines a standardised data structure for exchange of positioning data from real-time locating systems.
However, requirements of LBS are significantly broader than the mere exchange of positioning data. It includes, most notably, dedicated models that can support definition of semantic properties of indoor spaces, their accessibility, their mutual relationship or connectivity which, ultimately, can be used to adapt to a variety of indoor navigation requirements. The specific nature of indoor spaces make existing approaches, traditionally used for outdoor navigation, unfit for indoor purposes as the diversity and complexity of indoor scenarios is significantly higher.
Within classical outdoor routing scenarios, navigation systems essentially rely on road networks, which are used to calculate the best route according to a limited number of preferences (e.g. shortest or fastest trip). Outdoor navigation systems account on a restricted number of parameters for each road segment (e.g. width, type of road, maximum speed etc.) and on additional constraints that may derive from real-time traffic conditions. Today, more advanced traveller information system can enable routing across different transportation means (eg bus, car, train etc.) essentially using different data structures, which are then combined together, each relying on an underlying street or public transportation network.
Complex indoor scenarios
Within indoor contexts, the basic concept of road networks — as we know — falls short, since the degrees of freedom of the users, typically people walking inside a building, are significantly higher than in outdoor navigation scenarios where vehicles are supposed to be driving along the streets. People can walk freely, without being constrained to a given ‘road’, with often no restrictions on direction flows. Additionally, the user can move across different floors, use different transportation modes such lifts, escalators etc. Also the number of navigation constraints is most diverse and may include, for instance, steps, stairs, doors etc. A building (or a part of it) may be publicly accessible only at specific times of the day or areas can only be accessed by a given user group.
To further increase the complexity, the type of users — and the consequent navigation requirements — can be very high, ranging from wheelchair users to indoor vehicles (e.g. golf cart used within airports), from indoor robots (eg used for logistics or cleaning) to drones.
Lastly, even classical approaches to navigation, such as after 200 metres turn right, may not be entirely appropriate in indoor navigation scenarios where relations to semantic of indoor spaces may be more appropriate (e.g. go to the second floor, walk past the reception, then enter the second door to the right).
Being able to address such articulated scenarios, yet ensuring scalability and adaptability to various conditions has been the inspiring principle behind IndoorGML, the forthcoming standard from the Open Geospatial Consortium (OGC) whose public release is due by September, 2014. As stated within the specifications of the standard, “The goal of IndoorGML is to represent and allow for exchange of geoinformation that is required to build and operate indoor navigation systems”. To do so, IndoorGML represents indoor spaces as a collection of non-overlapping cells with a unique identifier, which can be further qualified through geometric, topological, and semantic characterisations, and multi-layered space model.
Adjacency relationship between indoor cells of transformed graph
IndoorGML provides a basic support for 2D and 3D geometry model of cell, which can be expressed as ISO 19107. In 2D space, each cell is represented as a 2D geometric object such as polygon, while its geometry is 3D object like a cube in 3D space. The standard does not attempt to describe architectural features, but it rather aims at modelling indoor spaces and their relationships which are then used to support indoor navigation. Instead, whenever it is required to describe those architecture features, this can be done by referring — through links — to other existing standards such as ISO 19107, CityGML or Industry Foundation Classes.
The topology between cells is one of main concerns of IndoorGML. Based on a mathematical theory, called Poincaré duality, an indoor space as a collection of cells is transformed to a graph representing the topological relationship between cells. For example, the adjacency relationship is described by a transformed graph from the original indoor space. We can define or derive more complicated topological relationships on top of this graph of adjacency relationship.
Most notably, such a representation is used to derive a network-based representation which is essential for indoor navigation. This networked representation, which indeed represents the indoor counterpart of the traditional road network, is formalised through a Node-Relation Graph (NRG) that represents adjacency or connectivity between cells, which in fact are represented by the nodes of the graph. The nodes and edges of the graph are referred to as ‘states’ and ‘transitions’, respectively, in IndoorGML.
A semantic framework of cells and each topological relationship between cells are also given by IndoorGML. For example, cells are semantically classified into general navigable space, transition space, connection space, and anchor space in IndoorGML. While the current version of IndoorGML offers only a semantic framework for indoor navigation, more semantics are supposed to be defined for next versions depending on the application areas. In addition to classification of space, each cell is associated with a detail semantic description to qualify the ‘type’ of space, for instance to define that this is a ‘waiting lounge’ or a ‘ticket desk’.
Within IndoorGML, a cell can both represent ‘topographical’ spaces, for instance a room, as well as other forms of spaces, for instance cells of a Wi-Fi network coverage used for indoor localisation. In fact, IndoorGML supports the socalled multi-layered space model whereby the indoor space can be represented in many different ways.
However, it is equally possible to consider the indoor space from a location service point of view, therefore dividing the space into areas of coverage of each antenna used by the localisation. In this case ‘rooms’ are replaced by portions of space which represent the area covered by each Wi- Fi antenna used for localisation purposes and can be always represented through the concept of a ‘cell’.
This multi-layered space model supports multiple connectivity graphs at the same time. One graph, for instance, could be created for ‘walking users’, a second for ‘wheelchair users’. In this case, for instance, adjacent rooms connected by a door whose width is lower than 60 cm, would not be considered as ‘connected’ since the wheelchair could not possibly pass through the door. The different graphs which are stored within the various layers can be connected by further inter-layer connections, called joint edges, yielding a multi-layered graph. Since the aforementioned concept of ‘cell’ assumes that each of them does not have any overlapping area, an item or person being tracked can only be in one cell (a node of the graph) at time. In the model used by IndoorGML, this means that it is possible that, at each given time, the object or person being tracked is within different ‘states’ (at most one for each graph) at the same time.
Three options to represent geometry of each cell
Most interestingly, it is possible to leverage on semantic descriptions and on the concept of aggregation to define sub-cells. This is particularly useful in case of large spaces, such as check-in areas at airports, which can be further subdivided into smaller cells, for instance a cell for each checkin desk. This way it becomes possible to create multi-resolution navigation mechanism that can elegantly deal with coarse instructions at first.
Bridging indoor and outdoor contexts
IndoorGML also provides a native way to bridge indoor spaces (and indoor routing) with outdoor spaces. This is based on the concept of further nodes called ‘anchor nodes’, which can be used to represent the entry point of a building (there must be at least one within each model of building). Anchor nodes ensure connection with outdoor data structures allowing for a clear separation between the indoor and outdoor domain. Additionally, an anchor node can contain information that may be used, for instance, for conversion between indoor and outdoor Coordinate Reference Systems (CRS), allowing convenient use of relative coordinate systems when indoor.
For a sophisticated, scalable model
Complex structures allow for a powerful mechanism to address the most diverse routing requirements. It covers many different application areas from simple indoor navigation or indoor geo-portal services, to emergency responses (not only in a building but also in a cruise ship), robot tracking and navigations, asset management of hospitals, indoor multimedia services, location-based marketing, and big geospatial data analysis for indoor space.
Last, but not least, the entire standard has been designed keeping modularity in mind, through the development of a core standard data model with the possibility to extend it through modules. IndoorGML currently defines a single extension module for indoor navigation and more extension modules are expected to be developed in the next version of the standard on the top of the core module for many applications such as indoor facility management, indoor multimedia services, and indoor robot navigation.
- OGC, Requirementsand Space-Event Modelling for Indoor Navigation, OGC 10-191r1, 2010
- OGC, OGC IndoorGML, OGC 14-005r2, 2014
- ISO/IEC JTC 1 SC 31, Information technology — Real-time locating systems (RTLS), ISO/IEC 24730
- ISO/TC211, Geographic Information – Spatial Schema, ISO 19107:2003, 2003
- OGC, OGC City Geography Markup Language (CityGML) En-coding Standard, OGC 12-019, 2012
- buildingSmart, IFC4, 2014
Prof. Ki-Joune Li,
Pusan National University, Korea &
Chairman of IndoorGML Standard Working Group,
Dr. Giuseppe Conti
, CTO – Trilogis Srl
and Project Coordinator, i-locate,