Efficient LiDAR Data Framework for Mobile Mapping Systems

1. Mobile Mapping System LiDAR-Data Framework Paul Lewis, Conor McElhinney, Bianca Schön, Tim McCarthy Introduction Access Because of our spatial database approach access to the MMS LiDAR data, using spatial queries, is much easier. Access queries can be defined programmatically, allowing for automated processing of the data, or through a simple web interface where data coverage is plotted and the user can segment the LiDAR using standard GIS tools for an area they wish to visualise, (figure 5). Mobile Mapping Systems (MMS) for infrastructural monitoring and mapping are becoming more prevalent as the availability and affordability of solutions that generate high accuracy geospatial data has matured. The NCG StratAG XP1 experimental MMS is an example of such a platform (figure 1). Figure 1: StratAG Mobile Mapping System (MMS) XP1 experimental platform. Figure 5: Selecting LiDAR data using a simple web interface The spatial data properties being collected on the XP1 MMS platform are shown in table 1 and are used in the development and testing of our storage, access and processing solution. This poster presents work that has been undertaken to optimally handle the large volumes of spatial data, specifically the MMSs navigation and LiDAR data. This work is defined as part of a framework (figure 2) for MMS spatial data handling that is being developed upon the open source spatial database technology PostGIS. Our results analyse the I/O challenges with handling these data and discuss how this solution is optimal in this context. We performed 27 different spatial queries on cached data by varying the length (15m, 30m, 60m) the width (1m, 10m, 20m) and the height (1m, 2m, 5m, no limit) of the queries, and executed each query 9 times. An average was taken, example times are shown in Figure 6. These demonstrate that 3D queries were faster than 2D queries. We believe this is based on the limiting factor for query execution which we found to be the number of points being returned. The query execution time was 0.0000935s per point with a standard deviation of 0.0000167. Figure 6: Timing information for spatial queries of different dimensions. Table 1: Some of the properties collected by the GPS and LiDAR equipment from a typical MMS survey. Processing large volumes of LiDAR data in a knowledge extraction work-flow is an active field of research; however, viable solutions in this context are normally bespoke, processing intensive operations, for example road-edge geometry extraction. Typical known approaches process LiDAR based on a survey methodology which constrains the systems to the data that is available in a single survey. In our solution we have developed a LiDAR data handling framework where all survey data is searchable. A key aspect is the ability to globally segment from this database based on spatially optimised constraints. In this poster we present three stages in this process, which are as follows (figure 3): STORAGE: Workflow used to upload, store and index very large volumes of LiDAR and Navigation data. ACCESS: Workflows and interfaces for defining optimised spatial queries for LiDAR data retrieval. PROCESSING: Results and visualisations from processing spatially segmented LiDAR through knowledge extraction algorithms. Processing We are developing algorithms to automatically extract a range of features from LiDAR data, Figure 7. Using the spatial database we can select the dimensions and the geographical area that suits the algorithm. For instance, when extracting the road we select points +-10m from the navigation point and +-2m below the vehicle. Figure 7: Tree extracted from LiDAR data. Figure 2: Over view of the MMS geospatial data handling framework model. * Road Edge * Tree * Man-made Pole With our partners in ITC we are developing automated algorithms for segmenting trees, man made poles, road edges and the road surface from LiDAR scans. In Figure 8, the results of this processing on a LiDAR segment are displayed. Figure 8: Processed LiDAR showing trees, poles and the road edge. Conclusions and Future Work Figure 3: Components discussed in this poster. This research, through preliminary testing and profiling, has shown that it is feasible for a PostgreSQL database with PostGIS spatial extensions to be used to efficiently store very large volumes of MMS LiDAR data. While significant issues exist with data preparation and input to any LiDAR framework, we have shown how these can be minimised through optimised processes using pg_bulkload. The significant advantage from this framework approach is the ability to dynamically access any LiDAR data from the database for any pocess. This LiDAR segmentation is done spatially, either through a visual interface or in a programmatically controlled context, and can optimise LiDAR data sets for distinct requirements as has been shown in the case of the road geometry extraction algorithm. Future work involves moving this framework onto a dedicated server hardware platform from which further test results and analysis can be performed. But also the framework will be extended to incorporate the large volumes of imagery that will also be captured from the MMS. Storage Our storage solution is built upon a PostgreSQL database with PostGIS spatial extensions. Data input and index generation is being handled through the pg_bulkload high speed data loading utility, (figure 4). It is currently being tested but early results are significant, (Table 2). More comprehensive and comparative test results are currently being compiled. Figure 4: pg_bulkload published results for high speed data loading. Table 2: Preliminary Post-Survey Lidar-data upload timing results to DB. Research presented in this poster was funded by a Strategic Research Cluster Grant (07/SRC/I1168) by Science Foundation Ireland under the National Development Plan and by the ERA-NET SR01 projects. The authors gratefully acknowledge this support.