3D MODELLING OF A BUILDING ORIENTED TO INDOOR NAVIGATION SYSTEM FOR USERS WITH DIFFERENT MOBILITY CONDITIONS

We implemented the semantic models required to develop an indoor navigation system to assist the movement of users with different physical mobility conditions inside the building of the Faculty of Agricultural Sciences of the National University of Colombia. Everything starts with the recollection of architectural data followed by an analysis and depuration of unnecessary elements (geometrically and semantically) ending with two models: 1) a CityGML model of the interior of the building (LOD4), being the data source for the IndoorGML model and for visualization, 2) an IndoorGML model, provider of the semantic network for the future application of routing algorithms. We present resulting models with the discussion of the challenges and limitations that authors face during this work.


INTRODUCTION
Navigation is an elemental activity in people's daily lives, Timpf et al. (1992), which allows the recognition of interior and exterior spaces, understanding as interior space everything is within a construction and exterior space as the space without limits or the open air, Yan et al. (2019). All indoor space represents a major navigation complexity because of the size of buildings, Alattas et al. (2017), and the architectural components such as stairs, doors and lifts, Kontarinis et al. (2019). These aspects have generated that people with some special condition of mobility, have as a continuous concern the navigation and orientation without help in buildings with which they are not familiar, in particular when there is no access to maps, signals or other navigation devices, Gorgonio et al. (2015).
This ongoing research implements the required 3D models for an indoor navigation system that takes into account the user's particular mobility conditions, such as disability and visual impairment. For this reason, it requires the building model to have a high level of geometric and semantic detail from which they support the navigation system. This document proposes the incorporation of the open data standards CityGML OGC (2012) and IndoorGML OGC (2014) to an indoor navigation system. The CityGML standard is based on the standard GML OGC (2006) for the exchange of 3D city models in order to reach a standard definition of the entities, attributes and basic relations of the model. CityGML supports different levels of detail (LOD) OGC (2012); Biljecki et al. (2016), which allows the visualization of the same object or physical structure of a city in different degrees of resolution.
The levels of detail of the standard go from the most general LO0 to LOD4 as the most detailed one that represents the internal space of the building OGC (2012). In the upcoming version of the standard, the proposed model of several levels of detail presented by Biljecki et al. (2016) will be adopted Kutzner (Kolbe). * Corresponding author However, this investigation implements the current official data model CityGML v.2 OGC (2012). The IndoorGML standard establishes the specification for representing and exchanging spatial information within constructions, including the prime characteristics of geometric, topographic and semantic models Li et al. (2019).
Each model has a role within the navigation system, the CityGML model aims to provide a visual interface and the source from which the IndoorGML model is implemented to provide the semantics and connectivity between the different spaces of the building, generating the topological network that will allow navigation.
This document presents the procedure followed to get the two models of the study area. In a first step, consists in the information's preparation, then the CityGML construction is presented and last, we derive the IndoorGML model from the previous model. We should point it out that we automated the creation of the CityGML and IndoorGML models as much as possible using several FME workbenches (Safe, 2020).

Study Area
We carry the implementation out on the building of the Agricultural Sciences Faculty of the National University of Colombia in Bogotá. It composes its structure of 4 stories where are located: In a construction with an approximate area of 8, 950m 2 , figure  1 shows the building of the Faculty of Agrarian Sciences (red border) of the National University of Bogotá.

Data
We use the following data on this project: The University's Office of Physical Planning and Development provided the architectural blueprints. The other data source for this project is the Spatial Data Infrastructure of Bogotá (DECA) Ideca (2020), the DTM of Bogotá that has a spatial resolution of 5m from Bogotá to get the base height of the building.
The construction data of the Bogota cadastral office is used to get the geographic coordinates of the building because the architectural blueprints have a local coordinate system whose origin is unknown. Therefore, it was not possible to carry out the transformation process but to position the building manually using GIS software. Figure 2 shows the data preparation workflow. The implementation uses the architectural blueprints provided by the university's Office of Physical Planning and Development.

Data Preparation
Subsequently, we refined the blueprints to have only the elements to generate the CityGML model with detail level 4 (LOD4), preserving only the elements that define the walls, columns, doors, windows, ceilings, floors and stairs. Because the architectural blueprints were not created using the standard Building  (2018), none of the stories have a consistency in the coordinates of their data, therefore the first step was the location of the layers of all the stories in the same x,y coordinates.
Following this, we adjusted manually all the elements of the building regarding the construction data of the Bogotá cadastral bureau, ALCALDÍA MAYOR DE BOGOTÁ D.C. (2019) so the building has the correct α, λ coordinates. We distribute the elements of the architectural blueprints in the following layers: wall, window, door, room, stairs, floor, ceiling and plate; The wall layer includes all vertical elements that generate a boundary or obstacle in the building, such as walls and columns. We assign to each layer the attributes described in the table 1.

Attribute Description
No.Piso Storey number where the item is located Altura Architectural height of the element AlturaZ Altitude above sea level of the element Tipo The element is external or internal Function Type of navigation in the spaces: transition or general(applies to rooms only) Considering the characteristics or factors to be taken into account for the creation of navigation systems for people with mobility disabilities established by Park et al. (2020) we assigned additional attributes in the room, door and stair layers. In the room layer with corridor function, we added width and slope.
In the door layer, we added the width of the door, direction of opening, type of door and automatic doors were added. In the stairs layer, which also includes ramps, we assigned width, slope, turning width and an attribute to identify handrails; for the stairs, we added an attribute to establishing the presence of stair lift platforms. We added other attributes: number of steps and the step height, with the purpose of providing contextual information to visually impaired users.
Building's altitude is assigned based on the DTM, it was determined from the height for the lowest point of the building; we used it as a reference to assign the height of the other storeys. Each storey elevation was calculated by adding the altitude of the building to the height of each structure. As shown in Figure  2, in the previous steps filtering the architectural information of the building was performed to generate the CityGML.

CityGML model creation
The creation of the CityGML model arises in response to the need for a semantic and geometric model of the building and for the 3D visu-alization of the storeys in the navigation system.We modelled in LOD4, using to the Building thematic module.
CityGML establishes a hierarchy within the model, linking the objects regarding its parent object OGC (2012). For this reason, we assigned two additional attributes to each architectural element: ID Object's identifying attribute ParentID Object assigned as parent We built the model using FME software v.2019 Safe (2020). The first step is the conversion of the 2D objects to 3D objects by assigning the AlturaZ attribute (table 1) to the z-coordinate. Then, element extrusion is done using the Altura attribute (table  1). We assign each element a color and texture to simulate the real characteristics of the building.
We assigned attributes according to the standard, paying special attention to the gml parent id attribute which establishes the relationships within the model OGC (2012)

IndoorGML model creation
We built the IndoorGML model from the CityGML model, starting from the classes CityModel, Building, Room and Door, as shown in figure 4. The Door class of CityGML allows us to define the ConnectionSpace and AnchorSpace classes, which allow communication with the exterior. The Room class allows the definition of the GeneralSpace and TransitionSpace classes Kim et al. (2014), being the latter one composed of all the spaces that allow transit between internal spaces OGC (2014), for example, the corridor that connects several rooms. Other structures such as stairs, elevator ramps, among others, also belong to this class Kim et al. (2014). By building the model topology using fme, the common surfaces between a GeneralSpace and ConnectionSpace were identified. These surfaces, which connect two adjacent navigable spaces, originate the class ConnectionBoundary OGC (2014). From this topology, the attribute partialboundedByn.xlink href was defined for the navigable spaces, which shows with a list the associated ConnectionBoundary.
The indoorGML standard specifies that we can convert a given space into a Node-Relation Graph (NRG) through the Poincaré duality, Hatcher (2002), allowing to simplify the spatial relations of the 3D model, OGC (2014). By pplying this theoretical concept the navigable spaces, we transformed GeneralSpace and TransitionSpace spaces into a point geometry giving rise to the class State, we created for the three classes the attribute duality.xlink href, identifying the dual class between the node and the navigable spaces and vice versa, this relationship in all cases is one to one.
We generated the nodes of each navigable space by knowing their adjacency relationship between the spaces, we generated the lines that structure the transition class. Later we created the attribute connectsn.xlink href in the State class and the Transition class. The State class identifies which objects of Trantision class allow their connections with other spaces, while for the Transition class the attribute identifies to which spaces the object communicates being this relationship one to many. The duality between the Transition class and the ConnectionBoundary class was identified through the duality.xlink href attribute.
Once the nodes of each navigable space were generated and knowing their adjacency relationship between the spaces, we generated the lines that structure the transition class. Later the connectsn.xlink href attribute was created in the State class and the Transition class. The State class identifies which objects of Trantision class allow their connections with other spaces, while for the Transition class the attribute identifies to which spaces the object communicates being this relationship one to many. The duality between the Transition class and the Connec-tionBoundary class was identified through the duality.xlink href attribute. Figure 5 shows the summary of the resulting structure of previous process, as you can see the IndoorGML model allows to establish the interactions between the spaces, therefore it will provide the routing scenario for the navigation system.

RESULTS
In this section we present some images of the resulting models and a comparison between the reality and its digital twin.
CityGML Figures 6 -7 show a comparison between the actual world (upper side of each image) and the Faculty building's CityGML (lower side of each image). Figure 6 shows the comparison of the south-west side of the Faculty building. It is possible to see the windows, walls and interior walls that define the facade.  Figure 7 shows the main entrance of the faculty's building. Specific details such as paintings or boards were not modeled. Authors considered that those elements are not fundamental for this implementation. Small boards are placed to show the room number or to whom it is assigned. Such information is available in the semantic information of the model.  figure 8 shows that level of detail of the ground floor of the Agricultural Sciences' building, elements such as the auditorium, classrooms, offices, bathrooms among others can be clearly differentiated. Each element is composed of several elements like doors, windows, floor, ceiling and internal infrastructure such as stairs.  Figure 9 shows the faculty cafeteria, which is in the first storey of the building gml id: GML 500, it shows the gml id of several elements that define the room such as the interior installations (IntBuildingInstallation), the floor (FloorSurface) and the interior walls (InteriorWallSurface), the latter one in contain a door and windows. The semantic herarchy of the room is represented in figure 10, which shows both the gml id and gml parent id attributes.

IndoorGML
We built the faculty's IndoorGML model according to the structure defined in the navigation module. Figure 11 shows how the GeneralSpace class is composed of classrooms, auditorium, cafeteria and laboratories. The corridors and stairway areas are part of the TransitionSpace class, which allow circulation between the GeneralSpaces. The doors are part of two classes: TransitionSpace and ConnectionBoundary, the first one provides a passage between the elements of the space and the second one allows the identification in a space of the limit that allows the connection to another space. Figure 11 shows how each space (GeneralSpace, Transition-Space, GeneralSpace) is analogous to the class State. Using the Poincaré duality each space became a node which conforms the State class. The Transition class represented with the green lines shows the connectivity between the spaces.

DISCUSSION
Automating the creation of models from a refined architectural blueprint has presented several challenges. Automating the model creation from a refined architectural plan has presented several challenges. First, the building information was in a CAD file, which lacked a coordinate system, drawn elements unconnected, something common in this format Srivastava et al. (2018); requiring manual debugging to get the input layers for the construction of the CityGML model. This process requires digital optimization and implementing tools to improve the extraction of construction elements as walls to generate topologically connected spaces, as also proposed by Srivastava et al. (2018). This is an aspect that not addressed in this work.
With the CityGML model, the height coordinate of the structure could not always be assigned from an attribute established in the data debugging. In structures with a slope like ramps, it was necessary to assign the height in each node to get a surface with a slope equivalent to its reality. This is another topic that requires further development to improve the model creation process.
In relation to its appearance there is still a long way to go, so far the construction of the faculty's CityGML model has been limited to applying a uniform color simulating the proper color of the surface. However, considering the purpose of the model it is necessary to explore other options of appearance such as photographs to get a scene closer to reality, as long as it does not affect the response times and performance of the future navigation system. As for the IndoorGML model, it was necessary to subdivide the spaces. For example, if we considered only the tangible limits of the corridor on the first floor of the faculty, it would only exist one object in the TransitionSpace class, and its respective dual or node in the State class. This node is in the center of geometry, where all the connectivity relations defined by the transition class converge. As seen in figure 12, this scenario is not suitable for a navigation purpose because the lines crossing the non-navigable boundaries. Therefore, the subdivision was necessary to get as a result a much more organized IndoorGML model, as seen in the lower part of the figure 12.
The above was developed within the framework of the OGC IndoorGML standard (OGC, 2014), and as it is addressed by other researchers (Diakité et al. (2017), Jung (Lee)). However, it is possible that the future phases of this research project will rethink the subdivision, considering the reduction of the complexity of the network and the identification of better paths according to the particular mobility conditions of each user.
In relation to the functionality of the models previously proposed in an indoor navigation system oriented to users with different mobility conditions, the IndoorGML model is more relevant since it provides the information required for the selection of an ideal route according to the preferences and particular conditions of each user. For example, for a person in a wheelchair, the ideal route excludes stairs, while for a visually impaired person the route may include stairs, but with a prior knowledge of aspects that help them perceive space such as the number of steps, step height, stairs' width and the existence of handrails. However, the efficiency of the model should be evaluated with the end users since it is possible that relevant aspects are being omitted; so far, only aspects mentioned in previous studies have been emphasized.

CONCLUSIONS
The IndoorGML and cityGML models, so far meet the requirements for the construction of a navigation system aimed to persons with disabilities. It is important to emphasize that as new needs or inconsistencies in the model arise it is necessary to review and correct both the architectural blueprints and the fme workbenchs. This is a recurrent process until an appropriate result is obtained.
It is worth mentioning that we got an IndoorGML model semantically enriched, that will simplify the selection of an optimal route according to the preferences and particular conditions of each user. This project offers an IndoorGML model with the information needed for an indoor navigation system oriented to users with special mobility conditions. However, it should be considered in the future to check out each one of the features covered with the final users to improve the model.
On the other hand, the automatization of the creation of the CityGML and IndoorGML models from an architectonic blueprint is reasonable. Though, it is not a straightforward path, for example in the depuration process, it must be ensured the organization of the information specifically the parentID attribute of each feature, which provides the organization of the objects' hierarchy in the semantic models. Additionally, the integrity of the information must be ensured, marking out that there must be no inaccuracies in the topology, because the definition of the connectivity relationships in the IndoorGML model depends on this.