EXTENDING INDOOR OPEN STREET MAPPING ENVIRONMENTS TO NAVIGABLE 3 D CITYGML BUILDING MODELS : EMERGENCY RESPONSE ASSESSMENT

Disaster scenarios in high-rise buildings such as the Address Downtown, Dubai or Grenfell Tower, London have showed ones again the importance of data information availability for emergency management in buildings. 3D visualization of indoor routing services using extensive and high quality geographic data sources is essential for spatial analysis in emergency responses. In order to facilitate emergency response simulations, a combination of geometrical, graphical and semantic information is essential. Successful and efficient emergency evacuation responses is facilitated by the availability of both digital static and dynamic information of the incident site. However, interruptions may be encountered with the availability of dynamic data, where static data developed using indoor navigation ontologies serve as an alternative to inform the first responders. Thus, it is necessary to obtain a firm, interactive and quasirealistic virtual simulation of the building environments. Voxelized CityGML models imported into voxel based hazard simulation systems fits well into the simulation algorithm requirements (Groger et al., 2008; Moreno et.al, 2010). Therefore, the research investigates an alternative platform for generating CityGML spatial analysis models. LoD4 models are developed using Computer Aided Design (Auto CAD) 2D files, crowdsourced geo-data (OpenStreetMap) and open source tools. A combination of software packages is utilized for 3D reconstruction of building interiors. This process is achieved through a Java application developed by researchers at Heidelberg University. Conclusions drawn from the research validate the 3D CityGML model generation process as an international standard to effectively enhance the outcome of emergency evacuation simulations of high rise buildings.


INTRODUCTION
Disaster management as a concept deals with humanitarian aspects of emergencies including preparedness, response and recovery, to reduce the harmful effects of disasters.However, within the urban context, the extent of damage is witnessed at both the macro and micro levels with causalities at different scales.The first few hours after the disaster is expressed as the most important hour for successfully saving human lives (Dilo & Zlatanova, 2011).Thus, it is necessary to improve situation preparedness and response made available to primary responders in emergency response systems.
As discussed by Decapua and Bhaduri (2007), a complete up-to date information is essential during emergency response to facilitate efficient communication, coordination and decision making.Information related to the indoor environment is inevitable for understanding the movement of people and finding paths (Boguslawski et al., 2016, Diakité & Fadli, 2016).Outdoor areas serves as assembly points in case of emergency evacuations.However, digitized information of existing indoor environment, organization of the accessible rooms and possible evacuation routes, enable better assessment of the scene (Tashakkori et al., 2015, Alattas et al 2017).Therefore, availability of digitized static/existing information in the form of 3D map or 3D visualization of building interiors and possible travel/evacuation routes is crucial.
Visualization of indoor routing services using high quality geographic data sources is essential for spatial analysis in emergency responses.For this purpose, many 2D geo-data (indoor) is provided through either commercial providers or through volunteered geographic information communities (VGI's).The commercial providers such as Micello, aisle411, Nokia, Point Inside, Google or Bing offer geo data which can be processed through diverse methods.Many approaches exist for reconstructing 3D interiors from 2D floor plans, but the resulting model using VGI's is application depended (Domínguez et al, 2009).3D indoor environments can also be created through point clouds or imagery, which however often requires an extensive 3D reconstruction process.Building Information models are also available for many of the new buildings, but they are difficult to maintain and become outdated quite quickly (Isikdag et al 2008).
Therefore, this research aims to provide an alternative platform for generating 3D indoor navigable building spatial models.The research extends these CityGML LoD4 high rise building models to aid emergency evacuation responses.Crowdsourced geo-data (Indoor OSM VGI community) is used as the primary data source for this application depended process.The study further explores the concept of crowdsourced geodata (Indoor OSM) and CityGML (Goetz 2012, Wang & Zipf, 2017).Finally, the research attempts to demonstrate and validate the generation of City GML LoD4 building models using indoor OSM.

BACKGROUND
One of the most important and demanding categories of disaster management is emergency evacuation responses (Dilo & Zlatanova, 2011).Effective coordination and implementation of policies and procedures among the respondents, depends on the availability of up-to date information on the incident.It is essential to develop digital geographic data models for acquiring both dynamic and static information.This enables effective preparedness and emergency evacuation responses.In disaster scenarios, interruptions may be encountered with availability of dynamic data.Delayed images from earth observing satellites and obstructed imagery due to smoke delay the data availability.Additionally, lack of power, internet connection or lack of applications to access the digital imagery may prevent acquiring available information.Therefore, availability of digital static information of the incident site is highly essential.This data may substitute the lack of dynamic information enabling effective emergency evacuation responses.
Towards the end of 20 th C, the concept of 'Digital Earth' emerged with an objective to provide a full resolution 3D representation of the Earth.DE had a vision to enable all users to consume extensive geo-referenced information about the environment.The digital data which was focused more on outdoor areas has extensively been expanded to capture interior data of complex buildings (Goetz, 2012).3D models are more effective than 2D due to representation of both geometric and semantic aspects.Emergency response measures in high rise building structures require exact knowledge of vertical connections.The 3D interoperable models represent these connections more effectively when compared to 2D maps.Thus, 3D mapping of indoor environments accurately observe, monitor, and forecast environments.
Different type of models have been presented by researchers, which serve as inputs for emergency evacuation simulations.These include rabbit model, urban fire models, physics based models and physical based models (Moreno, 2010).The simulated results using these models presented emergency situations (fire spread) limited to covering the building floors or the entire outer building blocks alone.Thus, no information was obtained related to emergency situation within the inner structures of the buildings (halls, rooms, corridors) (Moreno et al., 2011).This research identifies CityGML as a standard input field to enhance the outcome of hazard simulation systems such as urban fire spread and fire extinguisher simulation methods.
CityGML is an international standard capable of representing and storing both geometric and semantic information.However, 3D formats such as Virtual Reality Modelling Language (VRML) and Extensible 3D (X3D) focus on geometric information only (Zlatanova et al, 2012).These detailed models are created using Computer Aided Design (Auto CAD) 2D files and 3D graphic applications.In last decennia, a trend is observed: the digital data provided is evolving from the action of thousands of humans acting as sensors referred to as crowdsourced geo-data or VGIs.Here, individuals/citizens act as major information providers, encouraging dynamic and interactive data acquisition.Also, they can be seen as highly reliable sources as sharing, editing and addition of data is encouraged.Thus, VGI has high potential for the visualization of urban environments with 3D city models in a 3D spatial data infrastructure (SDI) (Schilling, A. et al, 2009).

OSM-Open Street Maps:
The quality of data used for analyzing spatial and geographic phenomena in urban regions is of prime importance.In the present day context, the concept of collaboratively collected data has gained importance among professionals and amateurs.These collected geodata are made available through user generated content in the Web 2.0.Availability of geodata for spatial references made by users using GPS-enabled smartphones or cameras is highly reliable and significant.One of the most popular among these Volunteered Geographic Information (VGI) is Open street maps (OSM).One among the most successful and reliable crowdsourced geodata is made available through OSM.Open street maps (OSM) aim at providing free and editable maps (Haklay & Weber, 2008;Goetz & Zipf, 2012).
OSM geodata is appropriate for the purpose of spatial urban environment analysis.OSM includes both geometrical (twodimensional) and semantic information data (Figure 1).The community can contribute data in OSM through two phases: (1) Development of two-dimensional geometries of the built form/urban spaces; (2) Annotating the geometries through additional information.OSM data is represented as a combination of four set of elements namely nodes, ways, relations and tags.The two-dimensional geometries are tagged using points on the map referred to as nodes in OSM (points with distinct coordinates).Lines or polygons are traced through a combination of several nodes referred to as ways (Goetz, 2012).The combined nodes and ways form relations which are used in mapping complex geometries such as voids, atriums etc.They are also used for developing relationships between different OSM features such as intersections, roads, etc.
An enrichment of the data is achieved by providing additional information or description of the geometries.This information and attributions are added through key-values.The keys describe the map characteristics.On the other hand, values add definition to the keys such as commercial center, North Avenue street etc.In summary, relational approach of an OSM building model depicting exterior information is as shown (Figure 2).Scholars argue that for the purpose of building analysis, both outdoor and indoor data are essential.This is crucial in cases where analysis supports specific tasks such as finding locations inside buildings or discerning optimal evacuation routes in cases of emergency (Gröger & Plümer, 2012).The OSM geodata are mainly focused on exterior objects or environments such as details related to the location, shape, height and occupancy.Research and development conducted by Marcus Goetz (2012), extends the OSM tagging schema for mapping the interiors through proposed Indoor OSM, which has been further improved in Wang & Niu (2018).

Indoor OSM
Past research efforts suggest that the 3D building analysis for specific functional tasks require appropriate common understanding of both interior and exterior information.Ontologies describing the building exteriors, appearances, location etc. were explored.These lacked information related to the interiors.In response to the query raised by researchers several indoor navigation ontologies were developed.
OpenStreetMaps (OSM) serve as an easy to use and reliable crowdsourced data with potential for visualizing an indoor navigation system.For this purpose, Goetz (2012), developed and extended the existing OSM tagging schema to map the interiors.Thus, IndoorOSM serves as an extension to the OSM geo data.Here, both outer appearance and detailed description of the inner building are made available.These extensions enable the mapping of not only the interior structures but also obstacles or objects in the urban environment (Goetz, 2012).This gives more detailed information regarding the building interiors.Additionally, this provides an alternative platform for generating 3D navigable spaces for emergency responses.
IndoorOSM considers the building as structurally integrated object of levels, entrances and exits.Each of these levels constitute rooms, corridors, halls, passageways, doors or windows.As shown in Figure 2, OSM maps the building as a main relation comprising of levels.Each of the levels are represented by level relations.Furthermore, these level relations comprise of relation members such as rooms, halls, passageways etc. Relation members are mapped within the corresponding levels.Indoor OSM attempts to provide detailed 3D information of interior objects or structures.Thus, depending on the requirement and complexity, sub-relations can be modelled.Closed ways representing polygonal footprint of the corresponding building part or as single point node forms a sub relation.A summary of indoor mapping schema for interior spaces and vertical elements is depicted as shown in Figure 3.
The 3D Building Ontology used by indoor OSM provides data related to both outer appearance and inner structures/objects.OSM data serves as a reliable data source for virtual 3D models which can be accessed easily by anyone at any time.This also serves as plug-ins of other indoor applications in fields such as pedestrian navigation and emergency responses.

Navigable 3D Building models: City GML
CityGML is an open geospatial consortium standard capable of representing city models in a three dimensional way.These include geometric, topologic and semantic aspects of urban spaces.CityGML facilitates the development of different applications including noise propagation simulation and mapping, indoor navigation (Goetz, 2012) and disaster management (Kolbe et al., 2005).A wider perspective of urban landscapes, objects and obstacles is focused under this research.
Models enable specific tasks such as location finding and arriving at possible escape routes (Groger & Plumer, 2012, Brown, et al 2013).Mobile robotics is also utilized to represent indoor navigation.Furthermore, studies conducted by (Lee & Kwan, 2005) reveal that reachability within the building is clearly represented by LoD4 indoor model.The application of CityGML provides an alternative platform for representing possible indoor navigable areas or emergency paths in scenarios of fire (Moreno et al., 2011;Becker, Nagel, & Kolbe, 2011).Different methods are implemented for the mapping of interior structures.These include node-edge depiction and partitioning interiors into nonoverlapping/non penetrating 3D cells (Beckeret al., 2008).However, representation using a node or set of nodes and defining reachable edges is the most effective.Hence, the research generates CityGML LoD4 models using VGI IndoorOSM data for evacuation response assistance.
Emergency response simulations such as urban fire simulation methods uses the concept of building.The method represents a 2.5 D building representation using approximated 2D building projection and segregated floor units.The algorithm identifies the building information by splitting the building into two: (1) Vertical cells called building units and; (2) smaller units called Floor Unit.As a result, building information filled into the field should constitute both geometric and semantic information.Consequently, CityGML models serve as an input data model for running emergency evacuation responses.

METHODOLOGY
Algorithms of emergency simulation systems such as urban forest fire simulation methods bases itself on field defined in terms of grid of square cells.These methods process the data based on both static and dynamic inputs.The static information of these cells are defined by both its geometric data (origin, size and elevation in the field) and semantic data (characteristics).Modifications or calculations of these information serve as rules for executing emergency simulations.The CityGML LoD4 models serve as the appropriate input model which aid the emergency response simulations.
A combination of software packages were utilized for 3D reconstruction of building interiors.Software package includes PostgreSQL/PostGIS, JOSM editor, OSMOSIS, Eclipse JEE, Java application (developed by Marcuz Goetz, 2012) and landXplorer CityGML viewer.Five practical application steps followed for model generation in order are: (1) Preparation of building data (Mapping) ; (2) Database preparation; (3) Import of mapping results to database; (4) CityGML model generation; and (5) Generated LoD4 model viewing (Figure 4).
Prior to the preparation of building data, i.e mapping of 2D architectural building plans, an extensive collection of data was conducted.This included: (1) Details related to geographic location and any relevant additional information; (2) 2D architectural floor plans with dimensions; (3) Elevations and sections for determining heights; and (4) Building materials, geometry, type and nature of building parts (roof, walls, windows and doors).
Prior to mapping building details, digital CAD or pictures of different floor plans of the high rise buildings were obtained.This data was imported into JOSM (Java Open Street Map) editor and scaled to fit the building footprint.Using JOSM, indoor objects were marked and key-value pairs assigned.The building output in the form of nodes, ways and relations were uploaded to the server.The file was then downloaded and saved in .osmformat to be used for the next stage of data preparation.
The data was prepared using PgAdmin III, the Graphical User Interface (GUI) of PostgreSQL.This performed as the server side where PostGIS extension served as a bowl for indoorOSM data.Further, the mapping results were imported into the database through open source command line OSMOSIS tool.Finally, the CityGML LoD4 model of the selected building was generated using a Java program developed by Marcuz Goetz (2012) and viewed using LandXplorer.

Figure 4. Methodology of research
The generated CityGML model can then be converted to voxels using point or curve voxelization algorithms proposed, devised and implemented in C# by Nourian, Goncalves, Zlatanova, Ohori & Vu Vo (2016).Voxelization is the process where model data structures storing geometric information in a continuous field is transformed into points within a discrete grid.Voxel is defined as a value in 3 dimensional space which is located on a regular grid, where the position in space is relative to other voxels.This method preserves the topological relations among the different objects which assist in analysing relation between topological objects, or generating graphs for indoor navigation and path planning.Further, the voxel model can be imported into hazard simulation systems such as urban fire simulation methods.

IMPLEMENTATION AND TESTING
The process of generating City GML LoD4 building models has been experimented on high rise towers (number of levels greater than 20).Three different phases have been designated for the 3D model generation.These include: 1. Preparatory phase: The preparatory phase included data collected of the 2D building plans to be mapped.

Preparatory Phase
The Qatar National News Agency tower, which falls under the governmental occupancy has been mapped to demonstrate the research.The building qualifies as a high rise tower with 25 different levels (Level 1 to 4 is typical, level 5 to 24 is typical) with three main entrances and an exit.The building mainly contains offices, rentable spaces and multi-purpose halls.The levels of the building are connected through both staircase and elevator passages.The building location as well as the preparatory plans were gathered by the authors from building authorities.
Figure 5. Footprint downloaded from OSM server for mapping Specific information, dimensions and interior structures of the tower were added to the data obtained from architectural floor plans.Initially, an OSM account was created to download and 1. 2D Floor plans -Edited and prepared to retain only the walls, openings, fixtures and room name tags. 2. Sections -Edited and prepared to retain building level heights; height, type and breast of openings and name tags.

Step 1:
The execution phase was initiated by mapping the prepared floor plans.This included the following steps: 1. Images of the filtered tower floor plans were imported one at a time (Level 0 mapped first) using "New picture layer from file".The image was adjusted to align with the building footprint downloaded from the OSM server.2. Level 0 layer was activated.The image to be traced including walls, openings and fixtures were appropriately aligned and adjusted using editor tools.3. Next, indoor objects including rooms, common hallways/corridors, vertical connectors (staircase and elevator wells) and openings (doors and windows) were mapped as shown in Figure 6.a.The openings such as doors and windows were represented by OSM nodes.b.The ground level boundary, walls, hallways, corridor spaces and vertical connectors were represented by OSM ways connecting the nodes.4. Key value pairs were added for the nodes, ways and shell of the level.They were edited as per previously discussed indoor tagging schema (Figure 7). 5.The above steps were repeated for each individual floor plan including level 1 to 24. 6. Relation was created for each level.Further, all the 25 relations were combined to form the building relation which also included entrances and exits (Figure 8).The tower was mapped as a relation with key values attached.Both semantic and general information such as addr:country= Qatar; addr:street= Aba Al Hanin Bil Hanin Street; etc were provided.A total of 29 relation members form the building relation.Among them four designate single nodes representing 3 entrances and 1 exit, with 25 members describing the level relations of the building.Each level relation member was tagged with keys such as level=0, name=ground floor; type=level; height=6.2;level:usage=governmental, providing corresponding level information .Closed ways were utilized to bind the building parts and openings together, referred to as shell.Also the rooms and enclosed rentable spaces were tagged as indoor=yes.
Appropriate key values such as buildingpart=room/hallway; height=6.2;and name=telecom room were also included.As discussed, the openings such as doors were marked as point nodes.Key tags such as door=yes; height= 2.2; indoor=yes and breast=.5 (only for windows) were added.The vertical connectors were mapped as closed ways with key values buildingpart=vertical passage; buildingpart:verticalpassage: floorrange=0 to 24; height=6.2for both staircases and elevators on every level.
Finally, the prepared data layers were merged and uploaded to the OSM server.The data layer with distinct id's were then downloaded and saved as .osmfile.

4.2.2
Step 2: A database was created to ensure the availability of mapped OSM data to different classes of users.The database was developed using PgAdmin III, the Graphical user interface of PostgreSQL/PostGIS.The following steps were then carried out to generate tables for storing and processing data (Figure 9).

2.
Three extensions were necessarily required to generate the required table.This included plpgsql, postgis and hstore.

3.
Eight tables were generated to represent information of the tower such as nodes, relation-members, relations, schema info, spatial_ref_system, users, way_nodes and ways.

Step 3:
The following process ensured that the data was imported and made available in the tables generated within the database.OSMOSIS tool was used to import data into the database.The inputs while connecting to the server included the path of the .osmfile, database name of the tower (qna2), username and password.The implementation of the command line provided a complete execution of pipeline developed.
Refreshing the database within PgAdmin III, the data was imported successfully into the respective tables.These tables provide both spatial as well as semantic information input by the users as shown below: 1. Openings such as doors and windows were imported and documented using corresponding table<nodes>.The attributes were recorded using "id", "user_id", "tstamp", "changeset_id", "tags" and "geom".The "id" identified the particular nodes and "geom" represented the central point of the openings.The tags with key-value pairs stored the semantic information such as "window", "width", "height", "level", "breast" etc.Here, "window=yes" provides information regarding the type of opening, whereas key values such as "width", "height" and "breast" gives us the width of the window, height of the window and level of placement of window above the floor slab.Also, "level" represents the level of the tower to which the window belongs.The above data were provided for different levels manually as they were not directly supplied by the 2D floor plans.Additionally, key values for the doors were also recorded in a similar manner such as "door=yes/manual", "name=store", "width=1.0","height=2.2","indoor=yes".
2. Imported building level was documented using corresponding table<ways>.The attributes were recorded using "id", "user_id", "tags", "nodes" and "linestring geometry".The "id" provided an identification number for particular ways."linestring geometry" and "nodes" provided the sequence of the point nodes in the boundary and "tags" represent the semantic information through key values such as "name", "buildingpart", "height", and "indoor".Here "name" represents the name of the room, "buildingpart" represents the category of space such as room, hallway, corridor etc and "height" represents the height of the mentioned building part.The key value "indoor" confirms that it is an indoor area.Additionally, "shell" represents the contour of each individual level.They are represented as "name=first floor", "type=level", "level=1", "height=6.2","level:usage=offices".
3. Processed individual floor plans were recorded using level relations in table <relations>.The table provided information using three attributes such as "id", "tstamp" and "tags".Number of relations used was also obtained.
The "id" generates an identification number for the relation.Semantic information is represented using key value pairs such as "name=ground floor", "type=level", "level=0", "height=6.2","level:usage=office", for each level separately.In this case, each floor plan was processed by the tool in order of the level.Alternatively, order of mapping was also considered.However, along with the file names of each level, the tower as a relation was represented with key value tags such as "name=Qatar News Agency", "type=building, height=186", "amenity = Government building", "building=yes/governmental", "addr:city=Doha", "addr:street=Aba Al Hanin Bil Hanin Street","addr:country=State of Qatar", "building:levels=25","building:buildyear=1975", "building:max_level=24","building:min_level=0", "building:roof:shape=flat","building:roof:colour=black" 4. As discussed, osmosis tool processed and documented the ways.This provided information of the relation between these ways and the level of the building.Also, processed floor plans generated records of the relation between the corresponding level and the building.The above two processes record and generate data represented in table <relation-members>.The attributes include relation_id, member_id, member_type, member_role and sequence_id.
For the purpose of study, the height of each level of the tower was set as the same value.Also, the width, height and breast of the windows were kept uniform (slight dimensional variations occur).Buildings with typical floors have been used for accurate model generation.OSM Mapping Process 1. Adjacent floor level shells of the mapped building did not overlap.2. Errors related to entering key values for building part geometry.3. Inaccurate mapping-Building part geometries of nodes such as doors and windows were outside the shell geometry.4. Duplication-Height of vertical connector added as value for each individual floor was a representation of height of the entire building.For example: "name=vertical stairway connector", "height=155", "indoor=yes", "buildingpart=vertical passage", "buildingpart:vertical passage=stairway", "buildingpart:vertical passage:floor range=0 to 24", was duplicated in each level.5. Inaccurate data entered in terms of measurements such as door width and height.Also, value entered less than zero showed errors.6. Information and key values were missing for the shell of individual floors.Hence, errors was witnesses during Java application execution.
Data Import 1. Data import using OSMOSIS tool witnessed error due to the usage of same worked on .osmfile, which was not uploaded and then downloaded from the OSM server as the required data layer.2. The path of the .osmfile was not easily visible to the tool leading to further errors in generating a successful pipeline.The file was not directly saved in a direct drive.
Finally, the generated .xmlfile was unavailable in the workspace after successful execution of the Java application (as shown by console) due to limitation of the program to generation of levels less than 10.
Overall this approach is very promising, but the available version is unstable and needs improvements.As mentioned on the OSM web site, the authors recognise some of these errors and have stopped this particular approach.New approximations and tagging schema are to be proposed in the future.
Such 3D reconstruction can be very useful for further development and support in disaster situation.One interesting approach for further development could be the use of voxels to be applied for simulations (e.g.fire simulation) as proposed by Moreno et al 2011.Future work on this will enable in comparing efficiency, effectiveness and realistic impressions of using these models in simulating different emergency response assessments.

Figure 1 .
Figure 1.Geometrical -semantic information provided by OSM Figure 2. OSM exterior building model with indoor extensions

Figure 6 .
Figure 6.Mapping of indoor objects

Figure 8 .
Figure 8. Building and individual level relations

Figure 9 .
Figure 9. Development of databases and running SQL

Figure 10 .
Figure 10.LoD4 CityGML building model of test bed