While a number of methods have been proposed to build indoor map data, LiDAR is also a promising approach among them.A pilot project was launched in 2018 with an aim to investigate the feasibility of generating indoor maps in a standard format, OGC IndoorGML [4] with public safety features from point cloud data. It may be the eventual goal of the pilot to generate IndoorGML data in fully automated ways but many technical challenges prevent us from achieving this goal in reality. In this paper, we discuss important technical issues that we encountered during the pilot project and present a semi-automatic approaches to generate IndoorGML data from point cloud data collected by LiDAR sensors.
Construction of indoor maps di ers from outdoor due to complicated indoor
structures and geometries, which results in an increase of map production cost.
Many approaches have been proposed such as constructing indoor maps
OpenStreetMap [
Among these approaches, constructing indoor maps from point clouds is a promising method particularly if the entire process could be fully automatic from point cloud to geometry, semantics, and topology of indoor maps. With this background, we have started a pilot project to study the feasibility of constructing IndoorGML data from point cloud and applying them to pre-incident planning of rst responders. Pre-incident planning is time-consuming, ine cient, and inherently complex due to the lack of proper indoor maps and automated process, and the di culty identifying notable changes to facilities and infrastructure during successive pre-incident planning surveys. We expect that the automated or semi-automated construction of indoor maps from point clouds could improve the pre-incident planning for rst responders.
In this paper, we present the part of the pilot project for constructing IndoorGML data from point cloud data. However it is not only a presentation of a method and use-case but also identi cation of technical challenges that we encountered during the pilot project.
The paper is organized as follows; in the next section, we explain the overview of the pilot project. In section 3 and 4, we present how we collected the point cloud data of the test site and converted them to surfaces and the conversion from the surfaces to IndoorGML, respectively. In section 5, we discuss the achievements of the project, the technical issues, and future works. 2
Due to continuous urbanization, buildings are becoming larger, taller and more numerous with increasingly complex interior spaces. Correspondingly, the need for indoor maps has increased to the point that demand for them is now comparable to that for outdoor maps. However the indoor maps have fundamental di erences from outdoor maps, and it is typically signi cantly more expensive and complicated to construct them than outdoor maps. The requirements of constructing indoor maps are summarized as follows: { Low cost { Automatic construction from the beginning { Accuracy { Semantics { Standard format { Inclusion of features for applications { 3D
The construction methods of indoor maps developed so far include 1) the conversion from CAD or BIM, 2) automatic recognition of indoor maps from blueprint, 3) VGI (Volunteered Geographic Information) such as Indoor OpenStreetMap (OSM), 4) crowdsourcing from trajectories of pedestrians, and automatic recognition from the point cloud data collected by 5) personal devices such as Google Tango or by 6) SLAM (Simultaneous Location and Mapping). Among these approaches, we expect that the automatic conversion from point cloud collected by SLAM would be the most promising. The conversion from CAD or BIM requires preliminary data but no CAD or BIM data are available for some old buildings. Also it is very di cult to make 3D indoor maps from blueprint oor plans.The quality of indoor OSM highly depends on contributors and it is also di cult to make 3D indoor maps from indoor OpenStreetMap. The quality of indoor maps by crowdsourcing is also very limited. However it would be an ideal approach to make indoor maps from point cloud collected by SLAM particularly if the process could be highly automatic.
With this background, the pilot project has started to investigate the feasibility of constructing OGC IndoorGML data from indoor point cloud collected by SLAM in automatic or semi-automatic ways. The overall process is illustrated by Fig.1.
Two di erent approaches are applied for generating surfaces from point
clouds for the pilot project. The rst approach (2(A) in Fig. 1) is based on
a conventional surface extraction using geometric computation [
Collecting Point Cloud and Converting to Surfaces The test site of the pilot project is an underground shopping mall in Korea University South Korea, called Central Plaza (CP). CP point cloud data contains not only a large point cloud data set of more than 100 million points but also images with camera pose. Most of noise in the data are cleaned by CloudCompare, which is an open source software tool handling point cloud data1. After cleaning the data, it is converted to surfaces and this process corresponds to step 2(A) of Fig. 1. The detail process is explained below: Procedure: Converting Point Cloud to Surfaces 1. Removing outliers and pedestrians: Most of the noisy data (outliers and points on moving objects) are automatically removed by CloudCompare but a small number of noisy points need to be manually cleaned (see Fig. 2(a) and 2(b)), 2. Separating architectural and non-architectural components: Indoor maps are mainly determined by architectural components consisting of walls, ceilings, and oors, which actually separate rooms or cell spaces. We therefore classify point clouds for architectural components from non-architectural com
(a) CO PCD before Cleaning
(b) CP PCD after Cleaning (c) Triangular Mesh
(d) Surfaces ponents like tables. Then the point cloud for the architectural components is converted to triangular mesh (see Fig. 2(c)). 3. Converting triangular mesh to surfaces: Once the triangular mesh is generated from the point cloud, then we merge co-planar triangles into a single surface (see Fig. 2(d)).
While we produced the point cloud data and converted them to surfaces, we encountered several technical challenges. Among these challenges, the most signi cant ones are listed below: { transparent glass: Due to the physical limitation of LiDAR, it is not possible to collect points on transparent glass. It results in exterior outliers as Fig. 2(a). { re ective materials: Re ective materials also make it di cult to collect correct point cloud. { oblique components: Our approach assumes that wall surfaces are vertically aligned. Some of the components in CP data set are oblique as Fig. 3. It prevents the conversion process from generating correct surfaces.
Due to these problems, it was not possible to generate point clouds and convert them to surfaces in a fully automated way. We needed manual intervention to solve these problems, which will be explained in the next section. 4
In this section, we explain the process to produce IndoorGML data from the surfaces given from the previous step (step 2(A)). We experimented with model-based spatial ETL (extract, transform, load) methods for transforming surface data as these approaches are often useful to assist in automating spatial data transformation and translation work ows. To begin with, we loaded the surfaces given from the previous step into Revit2 to convert it to IFC (Industrial Foundation Classes)3. Then we used FME (Feature Manipulation Engine from Safe Software)4 to lter and clean the IFC data. One of the key challenges is that the walls, oors and roofs in IFC are generally represented as volumes.
For IndoorGML in particular, and indoor navigation data in general, it is preferable to have walls and ceilings as simple surfaces from which we can build rooms. We ran experiments with proper Z surface normal values to lter surfaces, 0:1 < surf aceZ < 0:1 for vertical wall faces, surf aceZ < 0:5 for the top of oors, and surf aceZ < 0:5 for the bottom of the roof or ceiling. We also tried using minimum volume and volume to surface area ratios to lter out fragments and unwanted spaces. After simplifying volumes to surfaces, we converted them to CityGML. The ETL rules in FME for the transformation is shown in Fig. 4.
Further experimentation is needed to re ne these and other approaches. Still, the initial results suggest model-based approaches such as this hold promise for reducing the amount of manual e ort required to take the raw surfaces produced from point clouds and re ne them for use in generating structured building models in the form of IFC, IndoorGML or CityGML. 4.2
Once we produce CityGML data as explained in the previous subsection, it may be ready to convert them into IndoorGML data. However due to noisy and missing surfaces, we used TICA (Tool for generating IndoorGML data by Cleaning and Authoring)5 to clean them (see Fig. 5(a)), which is an editing tool
3 https://www.buildingsmart.org/about/what-is-openbim/ifc-introduction/ 4 https://www.safe.com/ 5 open source available via https://github.com/stemlab/TICA for generating clean IndoorGML data from surfaces. TICA developed for the pilot project o ers the following functions; { Removing duplicated or sliver surfaces, { Dividing a large surface crossing multiple rooms { Checking the closure of a solid { Adding POIs for public safety features, doors, and windows { Editing connectivity topology { Texturing with image les { Generating IndoorGML data (a) User-Interface example of TICA (b) IndoorGML data from TICA
After cleaning the surfaces, TICA converts them to solids for each cell. We added doors and public safety features such as extinguishers, and edited the connectivity network. Finally we exported the result to IndoorGML data containing not only the core and navigation data but also public safety features as de ned by the Public Safety Extension of IndoorGML6. Fig. 5(b) shows the results converted from Central Plaza point cloud data.
The point cloud was captured with referenced photographs and RGB components for texture, which enabled an operator with domain knowledge to capture the public safety features in automated or manual ways using TICA (Fig. 6(a)).
As part of this process, we auto-generated a ne-grained navigation network within the cell spaces of the IndoorGML using the state and transition feature types - this navigation network is shown in Fig. 6. The basic approach was to generate a gridded TIN(Triangular Irregular Network) and then drop all the edges that crossed wall boundaries. 5
As indoor spaces become larger and more complex, the demand for indoor maps increases accordingly. The construction process of indoor maps is however complex and expensive. We conducted a pilot project for indoor mapping and navigation for public safety. In this paper, we presented a part of this pilot project on the construction of indoor maps in IndoorGML data using point cloud data. While it would be ideal to automate the entire process, it is very di cult due to several technical issues. Our approach is therefore based on semi-automatic 6 the XML schema of IndoorGML extension for Public Safety is available via http://indoorgml.net/resources method that the conversion is mostly automatically processed while a fraction of the process requires manual intervention to correct errors. The contributions of this paper are { generation of IndoorGML data with public safety features from point cloud, { identi cations of technical issues on building IndoorGML from point cloud, { conversion between IndoorGML and other building formats such as CityGML, { experimentation with model based transformation methods for cleaning and automation
While we did have some early success with automating data cleaning using model based methods, it would be useful to further develop these approaches in order to reduce the manual e ort currently required with tools like TICA. Particularly we need more e orts for domain-speci c machine learning. For example, we could improve the automated detection of public safety features such as extinguishers by proper training data sets. Another area that would merit further investigation is validation. If an independent method is used to summarize indoor space statistics, such as volumes and dimensions, those statistics could be used to verify that the building data set outputs are a reasonable representation of the indoor space being modelled. Finally, IndoorGML holds much promise as an indoor data exchange format, but its utility can be further enhanced if there are conversion approaches developed to support other formats adapted for speci c mapping applications such as for mobile devices.