Publication Date: 2019-10-23
Approval Date: 2019-09-13
Submission Date: 2019-08-16
Reference number of this document: OGC 18-089
Reference URL for this document: http://www.opengis.net/doc/PER/IndoorPilotER
Category: OGC Public Engineering Report
Editor: Charles Chen (Skymantics, LLC)
Title: OGC Indoor Mapping and Navigation Pilot Engineering Report
COPYRIGHT
Copyright © 2019 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/
WARNING
This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Public Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.
LICENSE AGREEMENT
Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.
If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.
THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.
This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.
Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.
This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.
None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.
- 1. Executive Summary
- 2. References
- 3. Terms and definitions
- 4. Overview
- 5. Data Sources
- 5.1. Types of Data
- 5.2. Participant Provided Data
- 5.2.1. Point Cloud - Korea University Central Plaza
- 5.2.2. CityGML - Victoria Airport
- 5.2.3. CityGML - Korea University Central Plaza
- 5.2.4. CityGML - Korea University Central Plaza with Public Safety ADE
- 5.2.5. IndoorGML - Korea University Central Plaza
- 5.2.6. Data Cleansing
- 5.2.7. Public Safety Data
- 5.3. Sponsor Provided Data
- 6. Building Modeler Service
- 7. Navigation Modeler Service
- 8. Building Model Repository
- 9. Indoor Navigation Service
- 10. Pre-planning Tool Client
- 11. Public Safety Scenario (Demonstration)
- Appendix A: Building Repository Examples
- A.1. CSW Insert Transaction POST Request Example
- A.2. CSW Insert Transaction Response Example
- A.3. CSW Update Transaction Request Example
- A.4. CSW Update Transaction Response Example
- A.5. CSW Delete Transaction Request Example
- A.6. CSW Delete Transaction Response Example
- A.7. CSW GetRecords Request Example
- A.8. CSW GetRecords Response Example
- A.9. CSW GetRecordByID GET Request Example
- A.10. CSW GetRecordByID POST Request Example
- A.11. CSW GetRecordByID Response Example
- Appendix B: Skymantics Indoor Navigation Service Examples
- Appendix C: Compusult Indoor Navigation Service Examples
- Appendix D: Revision History
1. Executive Summary
The OGC Indoor Mapping and Navigation Pilot Initiative was sponsored by the National Institute of Standards and Technology (NIST) Public Safety Communications Research (PSCR) Division. This initiative addressed key challenges related to indoor mapping and navigation for the purpose of supporting first responders in fields such as fire-fighting. The focus of this initiative was on developing the capabilities and workflows required for pre-planning operations. This included scanning each building to produce a point cloud dataset and converting this source data into various intermediate forms to support the generation of indoor navigation routes. This Engineering Report (ER) describes the work conducted in this initiative, the lessons learned captured by participants, and future recommendations to support the public safety efforts and interoperability of the standards. It is expected that future OGC initiatives will address the real-time, event-driven aspects of indoor mapping and navigation for first response situations.
First responders typically survey high-risk facilities in their jurisdiction at least once per year as part of a pre-planning process. Pre-planning outputs are often in the form of reports, and first responders may generate their own hand-drawn maps during the process or annotate available floor plans (e.g., from computer-aided design models). Pre-planning is time-consuming, inefficient, and inherently complex considering the information and level of detail that should or could be captured, the lack of automation, and the difficulty identifying notable changes to facilities and infrastructure during successive pre-planning surveys.
Mobile three-dimensional (3D) Light Detection and Ranging (LiDAR) has been identified as a potentially transformational technology for first responders. Using LiDAR and 360-degree camera imagery, coupled with advanced software processing, first responders could efficiently capture 3D point clouds and a wealth of other information, both observed and derived, while walking through buildings as part of routine pre-planning operations. The use of 3D LiDAR and imagery has many potential upsides beyond just creating point clouds for visualization and mapping (e.g., use in localization, object classification, integration with virtual/augmented reality solutions, change detection, etc.).
Requirements and Research Motivation
The primary motivation for addressing the topic of indoor-mapping is based on a real-world scenario where public-safety first-responders such as firefighters are attempting to navigate a building to rescue a civilian or fellow downed firefighter. The scenario is focused on operational pre-planning using LiDAR based point cloud scans of buildings which may be used to map navigational routes around hazards and risks. To accelerate research and development for this public-safety-driven scenario, the requirements of this initiative were to conduct the following prototyping and demonstration activities:
-
Create and convert 3D indoor LiDAR point cloud models and associated imagery to functional building and navigation models.
-
Generate, store, and serve point cloud, building, and navigation models for visualization and navigation.
-
Derive dynamic turn-by-turn indoor navigation instructions based on the navigation model.
-
View and annotate point cloud data, imagery, and building models, along with navigation routes and instructions into, through, and out of buildings.
-
Capture and annotation of Public Safety features through buildings based on scans or images and including the public safety features as part of a Public Safety Extension.
Further, this initiative supported the improved interoperability of location-based technologies for indoor mapping and navigation through the use of OGC web services and OGC standards such as City Geography Markup Language (CityGML) and IndoorGML. The benefits from this initiative include the following:
Derived Benefits
-
Benefits to end users
-
First responders benefit from new tools and applications for improved awareness
-
Emergency evacuation processes can be expedited through better tools
-
Demonstration videos provide better community outreach for educational purposes
-
-
Benefits to SWG/DWG
-
Working groups may learn about the nuances in the use of point cloud data and associated standard data models
-
New insights into existing gaps in IndoorGML and CityGML for interoperability and real-world applications
-
Development of new algorithms or applications for IndoorGML navigation applications
-
-
Benefits to Developers
-
Ensure standards are truly interoperable for future standards and releases
-
Discovery of possible improvements to OGC standards and lessons learned
-
Lessons learned can assist with future research and reduce the learning curve
-
Key Findings
This pilot was successful in demonstrating 1) transformations of Point Clouds to CityGML with Public Safety Application Domain Extension (ADE), 2) transformations of CityGML into IndoorGML with Public Safety Extension, and 3) visualizations of the Public Safety data in a Pre-planning Tool Client using open standards and basic navigation capabilities. The participants met several challenges regarding data quality in the provided point cloud data, different interpretations of standards which caused errors and anomalies, and limited toolsets for manipulating CityGML and IndoorGML data. Many of these challenges are described within the individual ER sections and also in the final conclusions of the demonstration (see Chapter 11, Public Safety Scenario (Demonstration)).
Through the efforts of this pilot initiative, the following key findings have been determined:
-
Scanning was just the first step. It is critical that point cloud data scans are conducted thoroughly. Every effort should be made to ensure every unlocked door is opened and every locked door is annotated, and the resulting point cloud should be generated with Red-Green-Blue (RGB) data, not just grayscale, to ensure the best results from automation tools. Additional data cleansing of the point cloud data will still be required due to inherent building physics such as reflective surfaces and transparent glass. Automated conversions from one data form to another rarely produced a 100% complete result. A substantial amount of manual effort was required to repair the resulting output and fill gaps such as missing walls and doors. Once data has been cleansed and transformed to CityGML, manual annotation of public safety features is necessary. It is anticipated that future improvements in tools and software algorithms can begin to reliably automate some of these tasks.
-
CityGML Public Safety ADE was created as an ontology for first-responders. IndoorGML Core did not provide all requirements for Public Safety applications, so the IndoorGML Public Safety Extension was created to support the Public Safety contextual items.
-
If possible, all data should be georeferenced. If not, the data needs to be checked and manually repositioned to ensure the resulting data models are overlaid correctly. Misalignment due to improper georeference can result in improper subspacing due to rotation, incorrect network grid modeling, and navigation routing anomalies (e.g., zigzag lines).
-
Current editing tools for CityGML and IndoorGML are not sufficient enough to support editing functionality, and so use of other tools such as Revit (an IFC Editor) or TICA (an open source CityGML editor), to process point cloud data was necessary. It was found that conversion from point cloud to IFC first, then to CityGML simplified the process due to the better editing tools.
-
It remains an open question regarding how to best present navigation options to the end user. Higher density indoor subspacing network models allow for more precise navigation but clutter up the user’s view. Two methods are documented in this ER regarding room space calculations using centroid of rooms or grid-based subspacing. The goal is to achieve turn-by-turn directions, but the best result depends on the building and some combination of methods.
-
Some differences in GML 3.1.1 used by CityGML and GML 3.2.1 used by IndoorGML caused some issues. Future versions should consider harmonization of the standards.
Recommendations for Future Work
Future work items are documented in Section 11.4.2, “Recommendations for Future Work”. In summary, the recommendations for future work are as follows:
-
In terms of public safety, consideration should be made for both Indoor and Outdoor mapping as well as utilizing road and water networks and other accessibility
-
The National Alliance for Public Safety GIS Foundation (NAPSG) provides the public safety symbology, but CityGML and IndoorGML are semantic models that are not well-suited for symbology. The Styled Layer Descriptor (SLD) and Symbology Encoding (SE) standards could be improved beyond 2D into 3D to support this use case.
-
A large extent of this initiative involved data conversions into data models. For navigation, modeling must be extremely clean, whereas validation checks and business rules should be created to ensure the data is properly converted and suitable for use in calculating navigable routes.
-
Closer coordination between CityGML and IndoorGML is needed to ensure interoperability. This includes the GML difference, harmonized public safety ADE/Extension, and use of common building/space/room IDs.
-
Development of web and mobile clients could support public safety user applications as well as consideration for JSON, GeoJSON, and OpenAPIs.
-
Augmented Reality could provide significant benefits to public safety use cases, and use of 3D models used in this initiative can support these efforts.
1.1. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Contacts
| Name | Organization | Role |
|---|---|---|
Charles Chen |
Skymantics |
Editor |
Dean Hintz |
Safe Software |
Contributor |
Ki-Joune Li |
Pusan National University |
Contributor |
Jason MacDonald |
Compusult |
Contributor |
Ken Geange |
Compusult |
Contributor |
Mohsen Kalantari |
Faramoon |
Contributor |
Mike Cross |
Skymantics |
Contributor |
Abdoulaye Diakite |
University of New South Wales |
Contributor |
Chih-Wei Kuan (Will) |
Feng Chia University |
Contributor |
1.2. Foreword
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
2. References
The following normative documents are referenced in this document.
-
OGC: OGC 12-019, OGC® City Geography Markup Language (CityGML) Encoding Standard, Version 2.0
-
OGC: OGC 14-005r5, OGC® IndoorGML Implementation Specification, Version 1.0.3
-
[OGC: OGC 19-032, CityGML Public Safety ADE Engineering Report]
-
OGC: 09-025r2, OGC® Web Feature Service 2.0 Interface Standard – With Corrigendum
-
Safe Software: Scenario: Victoria Airport Esri Geodatabase to IMDF
-
STEMLab: Spatio-Temporal Databases Laboratory (STEMLab) IndoorGML Tools
-
National Alliance for Public Safety GIS (NAPSG) Public Safety library of features
-
NIST: NIST Public Safety Innovation Accelerator Program Point Cloud City Program
-
PointNet: Deep Learning on Point Sets for 3D Classification and Segmentation, April 10, 2017
-
UNSW: IndoorGML as a Linear Cell Complex (LCC) class of CGAL, University of New South Wales
3. Terms and definitions
For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard OGC 06-121r9 shall apply. In addition, the following terms and definitions apply.
-
Light Detection and Ranging (LiDAR) is a surveying method that uses laser light to illuminate an object or space and measure reflected light with a sensor. The variations in laser reflection and wavelengths is then used to generate a 3-dimensional representation of the target.
3.1. Abbreviated terms
-
3D 3-Dimensional
-
3DPS Three-Dimensional Portrayal Service
-
ADE Application Domain Extension
-
AEC Architecture, Engineering, and Construction
-
AR Augmented Reality
-
BIM Building Information Modeling
-
CFP Call for Participation
-
CGAL Computational Geometry Algorithm Library
-
CLI Command Line Interface
-
CSW Catalog Service for Web
-
CSW-T Transactional Catalog Service for Web
-
DDIL Denied, Degraded, Intermittent, or Limited
-
DWG Domain Working Group
-
EPSG European Petroleum Survey Group
-
ER Engineering Report
-
ETL Extract Transform Load
-
FME Feature Manipulation Engine (Safe Software)
-
FTP File Transfer Protocol
-
GML Geography Markup Language
-
IFC Industry Foundation Class
-
ISO International Organization for Standardization
-
IMDF Indoor Mapping Data Format (Apple Inc.)
-
LAZ LiDAR data file extension (.laz)
-
LCC Linear Cell Complex
-
LiDAR Light Detection and Ranging
-
MBB Minimum Bounding Box
-
NAPSG National Alliance for Public Safety GIS
-
NIST National Institute of Standards and Technology
-
NRG Node Relation Graph
-
OGC Open Geospatial Consortium
-
ORM OGC Reference Model
-
OWS OGC Web Services
-
PC Point Cloud
-
PCD Point Cloud Data
-
PS Public Safety
-
PSCR (NIST) Public Safety Communications Research Division
-
PSX Public Safety Extension
-
RGB Red Green Blue
-
RM-ODP Reference Model for Open Distributed Processing
-
SWG Standards Working Group
-
WFS-T Transactional Web Feature Service
-
WGS84 World Geodetic System 1984
-
WPS Web Processing Service
-
WG Working Group (SWG or DWG)
4. Overview
The Indoor Mapping and Navigation Pilot is an OGC Innovation Program initiative that addresses key challenges related to indoor mapping and navigation for first responders. The focus is on developing capabilities and workflows required to support pre-planning operations. These first responders periodically survey high-risk facilities as part of a pre-planning process and formulate reports which require floor plans and maps. Considerations are made to simplify this process to improve the efficiency, reduce complexity, and capture the necessary details through use of automation and tools.
This overview provides the following viewpoints according to the OGC Reference Model (ORM) which provides an architecture framework for the ongoing work of the OGC. The structure of the ORM is based on the Reference Model for Open Distributed Processing (RM-ODP).
4.1. Enterprise Viewpoint
The concept in this initiative is to take advantage of currently available LiDAR technology and camera imagery to capture a building as a set of 3D point cloud data during routing pre-planning operations, and then transform the data into usable formats for visualization and mapping. These tools already exist for the architecture, engineering, and construction (AEC) community, and it is expected that future investments will significantly lower the costs of tools such that it will become a cost-effective approach for public safety, building managers, and other industries.
In order to demonstrate this public-safety driven scenario, the following activities were conducted in this initiative:
-
Create and convert 3D indoor LiDAR point cloud models and associated imagery into functional building and navigation models.
-
Store and serve point cloud, building, and navigation models for visualization and navigation.
-
Derive dynamic indoor routes instructions based on the navigation model.
-
Enrich and annotate building models and navigation models, along with navigation routes with public safety features to help guide first responders in pre-planning activities.
4.2. Information Viewpoint
The Information Viewpoint considers the information models and encodings that will make up the content of the services and exchanges to be extended or developed to support this initiative. The following technical service components, data exchanges, and data model extension were developed by the initiative participants and demonstrated in this initiative:
-
Building Data - The building data consists of captured 3D point cloud data of buildings
-
Public Safety Features CityGML Application Domain Extension (ADE) - An XML extension of the CityGML standard to annotate features with public safety specific metadata and descriptions.
-
Building Modeler Service I (2 instances) - A web processing service that converts point cloud data into CityGML format.
-
Navigation Modeler Service I (3 instances) - A web processing service (WPS) that converts CityGML format data into IndoorGML format.
-
Building Model Repositories (3 variations) - A data storage and access service (Catalog) that provides the capability to store and retrieve data.
-
Indoor Navigation Service I (2 instances) - A web processing service that calculated an indoor navigable route using the IndoorGML data.
-
Pre-planning Tool Client I (2 instances) - A user interface client to interact with the various services and data components in a public safety scenario.
Figure 1 below shows a tiered technical viewpoint of the components in this pilot. Each tier is comprised of various components which access each other through open standards and interfaces to demonstrate interoperability. The Access Tier represents those components which include the data and the component services required to store and access the data. The Business Process Tier represents the components which provide data conversion into other data formats. The Client Tier represents the pre-planning clients which provide a user interface to interact with the components.
4.3. Computational Viewpoint
The Computational Viewpoint is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution. The interface architecture for the Indoor Mapping and Navigation Pilot initiative is derived from the functional architecture provided in the CFP with some key changes. The architecture, as described by the Indoor Mapping and Navigation CFP, places a focus on the use of OGC web services for implementation of the modeler services as seen in Figure 2.
During the kick-off discussions, it was determined that the initial viewpoint of the Building Modeler and Navigation Modeler fit well in the paradigm for WPS 2.0. However, it was determined that the interactions between the Pre-planning Tool Client and the Indoor Navigation Service is is better implemented using WPS instead of WFS. Additionally, the WFS-T originally envisioned for the Building Model Repository was replaced with a CSW-T interface. All components interface directly with the Building Model Repository via the CSW-T interface, retrieving necessary data and storing the resulting transformed data. The clients access the CSW-T to retrieve each data set to display in the client user interface and generate indoor routes for navigation. Figure 3 shows the updated component architecture after discussion at the Indoor Pilot Kick-off meeting.
It should be noted that the Navigation Modeler service was implemented in two different ways: 1) converting the CityGML output of the Building Modeler into IndoorGML, and 2) reversely, converting point cloud data directly into IndoorGML and then back into CityGML. The reason for this is due to the fact that one participant focused on the indoor spatial mapping from point cloud data rather than from a top-down building geometry to indoor space workflow. More details can be found in Chapter 7, Navigation Modeler Service.
4.4. Engineering Viewpoint
The Engineering Viewpoint is concerned with the infrastructure required to support system distribution. It focuses on the mechanisms and functions required to support distributed interaction between objects in the system, and hides the complexities of those interactions. It exposes the distributed nature of the system, describing the infrastructure, mechanisms and functions for object distribution, distribution transparency and constraints, bindings and interactions.
The following sequence diagram describes the conceptual flow for the Pilot architecture.
4.5. Technology Viewpoint
Each of the following chapters in this ER describe the individual Technology Viewpoint of the various components, how they are developed, the software tools utilized, and the distribution of components needed to achieve the result of the Technology Integration Experiments (TIEs) conducted in this initiative.
Chapter 5, Data Sources describes the various data sets provided in this pilot. The datasets include point clouds, CityGML, and IndoorGML data. This chapter also catalogs the provided sample data, the official demonstration data, data derived and converted from the original formats, and details the data cleansing and enrichment. Some data is enriched with Public Safety Features CityGML ADE, which is documented in a separate ER. For more information, refer to the OGC 19-032 CityGML Public Safety ADE Engineering Report.
Chapter 6, Building Modeler Service describes the Building Modeler Service which converts point cloud data into CityGML data. This task was to create a building modeler application that can convert point cloud models and associated images (such as those generated by the Building Data) into semantic 3D building models compliant with the most recent or stable version of CityGML (2.0). Models generated by this component are notated with Public Safety Features from the CityGML ADE. The building modeler may be developed as a web processing service (WPS) compliant with the OGC WPS 2.0 Interface Standard (OGC14-065), although this was not a strict requirement.
Chapter 7, Navigation Modeler Service describes the Navigation Modeler Service which converts CityGML data into IndoorGML data. This task was to create a navigation modeler application that can convert output from the Building Modeler Service to IndoorGML usable for indoor navigation. The Navigation Modeler also generated navigation network information to support route calculations by the Indoor Navigation Service. The navigation modeler may be developed as a WPS compliant service, although this was not a strict requirement.
Chapter 8, Building Model Repository describes the Building Model Repository which stores the various datasets and makes them available to other services and end users. This task was to create a building model repository to store and serve point cloud, building, and navigation models (see Building Data, Building Modeler Service, and Navigation Modeler Service). The repository exposes a model catalog and provides authenticated access. The repository is interoperable with application clients.
Chapter 9, Indoor Navigation Service describes the Indoor Navigation Service which consumes the IndoorGML data to produce a navigation route based on parametric inputs. This task involved creating an indoor navigation service that can derive ‘turn-by-turn’ instructions between any two points in a building, including exits, based on network models created by the Navigation Modeler Service and stored in the IndoorGML. The service used navigation algorithms, not necessarily developed in this Initiative, which were optimized for specific criteria (e.g. routes optimized based on time, distance, or risk) requested by the Pre-planning Tool Client.
Chapter 10, Pre-planning Tool Client describes the Pre-planning Tool Client for end user access to the services and dataset renderings for mapping and navigation display. This task was to create a visualization client application for users to request and view point cloud data and building models from the Building Model Repository, as well as navigation instructions and routes from the Indoor Navigation Service. The client is a graphical user interface that enables public safety personnel to view and annotate models captured during pre-planning. The client should seamlessly transition between 2D and 3D views and should allow users to visualize hypothetical routes into, through, and out of buildings along with the appropriate metrics (e.g. estimated time, distance, risk, etc.) based on additional input parameters considered by the navigation service. The client should use the OGC WFS Interface Standard and OGC 3DPS to request and receive models, scenes, and services.
5. Data Sources
This chapter describes the point cloud source data provided by the sponsor (Section 5.3, “Sponsor Provided Data”) and participants (Section 5.2, “Participant Provided Data”). It also describes the data derived from these sources into the CityGML, IndoorGML, and public safety extensions.
5.1. Types of Data
This Pilot uses several data sources for testing and experimentation including Point Cloud data, CityGML data, and IndoorGML data. CityGML is an open standardized data model and exchange format to store digital 3D models of cities and landscapes. The data files are hosted by the OGC in a secure File Transfer Protocol (FTP) server accessible to participants. Enriched data includes cleansed data which is then enriched with an Application Domain Extension (ADE), a built-in mechanism of CityGML to augment its data model with additional concepts required by particular use cases. The ADE is a mechanism for enriching the data model with new feature classes and attributes, while preserving the semantic structure of CityGML. IndoorGML is an OGC standard for an open data model and XML schema for indoor spatial information. IndoorGML does not officially have an extension mechanism, but one was needed to carry the Public Safety features that were forwarded from the CityGML Public Safety ADE.
5.1.1. Point Cloud Data
The point cloud data used in this pilot is generated through LiDAR scans of various buildings. Another concurrent project was developing LiDAR building scans, and as a result the data contribution (Section 5.3, “Sponsor Provided Data”) was delayed until later in the pilot. Therefore, sample data (Section 5.2, “Participant Provided Data”) provided by the participants was used for the beginning of the development phase. Test data provided by Pusan National University (PNU) was used for initial development and testing. Later, efforts transitioned to official data provided by the sponsor.
5.1.2. CityGML Data
CityGML 2.0 was used to represent the building geometries including walls, floors, ceilings, doors, windows, furniture, etc. In order to begin development and testing earlier in the pilot, CityGML was generated from Victoria Airport’s publicly available sample dataset in Apple IMDF using FME from Safe Software. The data was later enriched with Public Safety ADE. Pusan National University generated IndoorGML from point cloud data using a partial manual process with an open source software application, and then converted IndoorGML to CityGML. Other participants’ early attempts to generate CityGML datasets from point clouds resulted in CityGML with a few large mesh features that lacked structure and were not readily convertible to IndoorGML.
One workflow that proved productive was to do automated conversion of point cloud to IFC data, and then use an editing tool (Revit) to structure and enrich the data for use in IndoorGML. A key part of this process was room generation. FME was used to convert and simplify the IFC to CityGML in a mostly automated process with some minor configurations to account for dataset variations.
5.1.3. IndoorGML Data
IndoorGML data describes the indoor spaces of a building. Spaces are divided into navigable and non-navigable spaces. The navigable spaces are linked to generate a navigational network, which can then be traversed to generate navigable routes. IndoorGML does not officially have an extension mechanism, but the participants collaborated to develop an IndoorGML Public Safety Extension to carry the public safety features that were forwarded from the CityGML Public Safety ADE. This functionally is being proposed to the OGC IndoorGML SWG for consideration and is planned to be used for the new upcoming IndoorGML 2.0 work.
5.2. Participant Provided Data
The following sample data was provided by the participants for testing and evaluation as components were being developed. This was done to ensure parallel development to achieve the TIEs later in the project while participants were waiting on the demonstration data.
5.2.1. Point Cloud - Korea University Central Plaza
This data contains a LiDAR point cloud scan of Korea University’s Central Plaza, an underground plaza at the Anam Science Field Campus. The author, TeeLabs Co., is a collaborative work partner with Pusan National University and supplied the following point cloud data for use in this pilot initiative. The data contains a large point cloud with more than 100 million points and contains images with camera pose data. Most of the noise in the data has been cleansed, and each object is individually separated. The data was cleansed using Cloud Compare, an open source point cloud viewer.
-
Name: KU-Central-Plaza
-
Source: 3D LiDAR x 2EA, 360 Camera, IMU
-
Editing: Cleansing (PCD Noise Removal) using a semi-automatic process
-
Author: TeeLabs, Co. LTD.
5.2.2. CityGML - Victoria Airport
Safe Software provided a sample data set for Victoria Airport in CityGML format derived from an Apple IMDF data set. This data was used for initial development and testing of participants' individual components prior to the TIEs. This data was modified by Safe Software to include the Public Safety ADE. It includes PublicSafetyRooms, PublicSafetyDoors and Hatch features.
The overall workflow for the Indoor Pilot depended on generating good quality CityGML data outputs from point cloud data. Because it took a couple of months to accomplish this, having an interim dataset in CityGML to work with effectively saved those teams developing downstream components - that depended on CityGML as input - from waiting a couple of months to start development. Having a dataset to apply the draft ADE also helped with PS ADE design and vetting.
Some features contained in Victoria Airport data resulted in interesting anomalies such as the circular room in the center with pedestrian walkways around the perimeter. This proved challenging to calculate routing because it was difficult to automate the navigable spaces of nonplanar geometries. Since there was no floor in the open center, it was also difficult to cut the room into spaces. This attempt demonstrates that more advanced work could be done to improve identification of interior sub-spacing which is not always separated by floors, walls, and ceilings.
For more information on the Victoria Airport dataset, or to access the source IMDF, see: https://knowledge.safe.com/articles/76176/scenario-victoria-airport-esri-geodatabase-to-imdf.html
5.2.3. CityGML - Korea University Central Plaza
This CityGML data was provided by Pusan National University through conversion of the original manually cleansed point cloud into IndoorGML and then into CityGML. While the data may be lossy compared to the original data set, it provided a basis for early attempts for participants to develop the components.
-
Name: KU-Central-Plaza (Central Plaza, Korea University)
-
Source: Converted from IndoorGML Public Safety Extension to CityGML by Hale, a GML based open source conversion tool: https://www.wetransform.to/products/halestudio/)
-
Editing: None
-
Author: Pusan National University
5.2.4. CityGML - Korea University Central Plaza with Public Safety ADE
This data is the same as the previous CityGML with additional Public Safety ADE enriched in the data. The data is shown in Figure 8 displayed using FME. Note the 'ps_' namespace prefix for the public safety related properties and attributes. Also note the public safety feature types - in this case: PublicSafetyDoor and PublicSafetyRoom.
-
Name: KU-Central-Plaza-CityGML-ADE-PS.gml
-
Source: Pusan National University, Rendered by FME Data Inspector
-
Editing: None
-
Author: Pusan National University
5.2.5. IndoorGML - Korea University Central Plaza
This data is the intermediate data converted by Pusan National University from the point cloud data.
-
Name: KU-Central-Plaza (Central Square, Korea University)
-
Source:
-
Converted to Mesh from Point Cloud
-
Surface Extraction by TM2IN
-
Cleaning and Editing for missing part by TICA and export to IndoorGML (TM2IN and TICA are developed by PNU and available at https://github.com/stemlab)
-
-
Editing: Editing missing sections (e.g., doors) and occluded rooms
-
Author: Pusan National University
5.2.6. Data Cleansing
During point cloud collection, it was discovered that many undesired artifacts appear in the point cloud data due to noise from LiDAR scans. LiDAR is a powerful tool for building scanning, but it has issues with transparent glass surfaces such as windows and doors. The laser beams pass through the glass surfaces, and the point cloud captures outdoor features through the glass such as trees. Reflective surfaces such as mirrors and marble flooring create additional artifacts in the point cloud. Also, during a LiDAR scan, moving features such as pedestrians and vehicles will create artifacts in the point cloud. These artifacts can often interfere with the calculation of indoor spaces and the location of walls and doors. Therefore, data cleansing is a necessary step to ensure reliable data for navigation.
The point cloud is composed of two categories; architectural components such as walls, ceilings, and floors, and non-architectural components such as chairs, tables, and other types of furniture in indoor space as shown by Figure 10.
The point cloud for architectural components is converted to CityGML and IndoorGML data at later steps, while the point cloud for non-architectural components is converted into non-navigable spaces of IndoorGML. Non-navigable spaces are practically obstacles to pedestrians and simplified into MBBs (Minimum Bounding Box). Together with navigable spaces, they are very useful in deriving indoor navigation networks. Examples of non-navigable spaces are shown in Figure 11 in red.
During the generation of point cloud data, the team encountered several issues. First, point clouds created where there is transparent glass leads to noisy data. For example, point clouds of outdoor spaces also contain objects detected through transparent windows (see Figure 12). There is a similar issue due to reflective material such as marble floors (see Figure 13).
Secondly, it is also difficult to produce accurately geo-referenced images of oblique objects such as oblique pillars. Thirdly, the coverage of point cloud data is rather incomplete due to occlusive areas. For example, we could not acquire the point cloud data in the rooms where the doors were locked.
Some automated processes can be used for partial data cleansing, but additional manual cleansing is still needed. For example, Cloud Compare is an automation tool that can be used to remove outlier points from a point cloud. Any remaining outlier points within the point cloud which were not caught by Cloud Compare must still be manually cleansed. Non-architectural objects such as furniture create obstacles within the indoor space that also interfere with indoor space calculations. One automation method is to calculate the vertical alignment of geometry such as walls to floors and ceilings, and then remove any objects or artifacts which are not part of the vertical or horizontal planes. This method may not be usable in some cases such as curved walls or dome-shaped ceilings, etc. In the sample data for Hana Square, there were some objects such as pillars which were not exactly vertical (see Figure 14). Since this architecture does not fit the assumptions of the automation method, the software was unable to distinguish the architectural from non-architectural components.
An observation was made regarding how point cloud data is collected. In one data set, a Simultaneous Localization and Mapping (SLAM) robot was used to collect point clouds with a fixed height sensor. Upon inspection of the point cloud data, it was discovered that during the LiDAR scan, any data collected near the same level as the fixed position of the LiDAR sensor of the robot (i.e., the result is near the same linear level as the "eye" of the LiDAR sensor) results in a reduced output. This can result in poor data quality of certain features such as stairs near the same height of the sensor. One way to avoid this issue is to use a handheld SLAM sensor which can be varied in height during collection to ensure the best coverage of different angles of the environment.
5.2.7. Public Safety Data
The Public Safety enrichment process extends CityGML with the Application Domain Extension (ADE): Public Safety ADE schema version 3.1.2. At the time of this report this is published as ADE-PublicSafety.xsd. The development of the Public Safety ADE schema is the focus of the Public Safety ADE Engineering Report (OGC 19-032). Public Safety features are taken from the NAPSG Public Safety library of features. (https://www.napsgfoundation.org). The result was a new CityGML Public Safety ADE that adds five new feature types or elements to support public safety applications, namely: PublicSafetyDoor, PublicSafetyWindow, PublicSafetyHatch, PublicSafetyIntBuildingInstallation, and PublicSafetyRoom. The ADE also defines a set of attributes or properties for each new feature type, along with supporting code lists to predefine lists of acceptable values for certain fields such as door type, opening type etc.
Considerable effort was required to test and validate the new application schemas as they evolved and ensure that the extension of CityGML was properly aligned with the CityGML specification, UML and schemas, and ensure that they supported the public safety applications as needed. One key part of this process was enriching actual CityGML datasets with new PS ADE elements and validating the results against the ADE schemas. As mentioned in Section 5.1.3, “IndoorGML Data”, the Public Safety Extension was created to support the transference of the Public Safety ADE from CityGML to IndoorGML.
5.3. Sponsor Provided Data
The data provided by the sponsor was from a concurrent project, which created an external dependency for this Pilot. The source of this point cloud data was the Hancock County, Mississippi Emergency Management Agency ("Hancock County"), which received an award under the NIST Public Safety Innovation Accelerator Program Point Cloud City program (https://www.nist.gov/news-events/news/2018/10/pscr-awards-over-750k-psiap-point-cloud-city). Data was provided by NVision Solutions Inc, which supplied geospatial software licenses and workstations needed to analyze data and create work products (https://www.nist.gov/ctl/pscr/hancock-county-point-cloud-city). The lessons-learned from the Section 5.2, “Participant Provided Data” were applied to the Hancock data set including the enrichment of Public Safety ADE to the CityGML data and conversion to Public Safety Extension in IndoorGML.
-
Name: Hancock County, Mississippi Emergency Management Agency
-
Source: GeoSlam Reb Zevo RT and Standard unit
-
Editing: Processed the data with GeoSlam processing software (GeoSlam Hub). No cleansing of the data.
-
Author: NVisions Solutions, Inc.
5.3.1. Conversion to IFC
Industry Foundation Class (IFC) data was generated during the conversion process from the Hancock point cloud data. IFC data generated from the Hancock County point cloud was first filtered and cleaned. A key part of the conversion process was computing surface normals and using them to filter out unwanted geometric complexity using the FME Spatial Extract-Transform-Load (ETL) tool. IFC complex solids were converted to CityGML and IndoorGML multi-surfaces and Boundary Representation (BRep) solids. One of the key challenges was geometry simplification. Walls, floors, and roofs in IFC are typically represented as volumes. For both CityGML and IndoorGML, it is generally preferable to have walls and ceilings as surfaces from which to build rooms. Typical manual approaches require an editor to identify which surfaces to keep (e.g., inner walls, ceilings, etc.) and which surfaces to eliminate (e.g., all edges, outer ceilings, etc.). In this case, Z surface normal values were used to filter surfaces such that -0.1 < surfaceZ < 0.1 produced vertical wall faces, surfaceZ > 0.5 produced the top of floors, and surfaceZ < - 0.5 produced the bottom of the roof or ceiling.
Further experimentation is needed to refine these and other approaches. However, initial results suggest model-based approaches such as these hold promise for reducing the amount of manual effort required to take the raw surfaces produced from SLAM point clouds and refine them for use in generating structured building models in the form of IFC, IndoorGML or CityGML.
Figure 16 shows the Hancock County data converted from Point Cloud into IFC and displayed using FME.
-
Name: IFC Dataset Hancock County
-
Source: IFC source data from Building Modeler for Hancock County
-
Editing: Edited to clean data categorize features and create rooms
-
Author: Faramoon
5.3.2. IFC Conversion to CityGML with Public Safety ADE
Figure 17 shows the IFC data converted into CityGML and displayed in FME.
-
Name: Hancock County CityGML Public Safety ADE
-
Source: Converted from IFC to CityGML and then enriched with Public Safety ADE information using FME
-
Editing: Data Simplification, Geometry transformation, schema mapping, feature filtering, business rule application to autogenerate Public Safety ADE information
-
Author: Safe Software using FME converted from IFC provided by Faramoon
5.3.3. CityGML Converted to IndoorGML with Public Safety Extension
-
Name: Hancock County IndoorGML Public Safety Extension
-
Source: Hancock County CityGML Public Safety ADE
-
Editing: Schema mapping CityGML feature types and attributes to IndoorGML. ID and relationship generation to associate feature types as per IndoorGML schema and UML requirements. Navigation network generation (States and Transitions).
-
Author: Safe Software using FME to convert CityGML Public Safety ADE to IndoorGML Public Safety Extension
5.3.4. IndoorGML Navigation Network with Public Safety Extension
-
Name: Hancock County IndoorGML Public Safety Extension
-
Source: Hancock County CityGML Public Safety ADE
-
Editing: Schema mapping CityGML feature types and attributes to IndoorGML. ID and relationship generation to associate feature types as per IndoorGML schema and UML requirements. Navigation network generation (States and Transitions). Note that early network generation was not aligned with Hancock corridors yielding a network that produced more irregular paths.
-
Author: Safe Software using FME to convert CityGML Public Safety ADE to IndoorGML Public Safety Extension
6. Building Modeler Service
As described in Section 5.1.2, “CityGML Data”, the Building Modeler Service application converts point cloud models and associated images into semantic 3D building models compliant with the most recent or stable version of CityGML (2.0). Models generated by this component are annotated with Public Safety Features from the CityGML PS ADE. The building modeler was developed as web service that is compliant with the OGC WPS 2.0 Interface Standard (OGC14-065), although this was not a strict requirement.
6.1. Faramoon Building Modeler Service
Faramoon has designed and developed an automated technology that takes point clouds of building interiors and converts them into 3D models that conform to international standards without requiring any manual input. There are four stages including 1) structuring a point cloud, 2) filtering noises, 3) recognizing objects using deterministic and stochastic algorithms and methods, and 4) modeling indoor features in 3D.
Faramoon initially implemented a process using this methodology to maximize the value of the conversion process and increase productivity by removing the manual processes required to generate the CityGML. The process is purely based on the geometry of the point cloud without the use of the RGB data (i.e., images). The geometry is identified with attributes using semantics to describe ceilings, floors, walls, etc. These geometries are identified based on surfaces and perpendicularity to other surfaces to designate these spaces. Faramoon’s building modeler is independent of the data format provided. The initial LAZ data is first converted into PCD format. Following this, the PCD modeler executes the process flows described below.
6.1.1. Process Flow
Faramoon developed a WPS to convert point cloud files to CityGML files. A sequence diagram shown in Figure 22 describes each step in the process.
-
The user accesses the Faramoon File Storage server (SFTP) and uploads a point cloud in PCD file format.
-
The user makes an HTTP POST request to the WPS with the filename of the PCD file as the parameter.
-
The Processing Server downloads the PCD file from the File Storage server.
-
The Processing Server processes the file into a CityGML file with Faramoon’s software.
-
If the file was successfully processed into a CityGML file, the user receives a response from their HTTP POST request with a direct URL to the CityGML file. The processed CityGML file was uploaded back to the File Storage server.
-
If the file was unsuccessfully processed into a CityGML file, the user receives a “Bad Request” response from their HTTP POST request.
-
Due to many challenges described in Faramoon’s Section 6.1.2, “Lessons Learned”, the WPS could not be fully utilized. Therefore, the resulting CityGML files were processed on a local computer. Figure 23 shows steps taken to model the point cloud datasets.
-
Faramoon downloads LAZ files from OGC FTP server.
-
Faramoon manually cleans and converts LAZ files into PCD file format.
-
PCD files are processed into CityGML files with Faramoon Software.
-
CityGML files are converted into IFC file format with Faramoon Software.
-
IFC files are manually modified with Autodesk Revit.
-
Modified IFC files are exported from Autodesk Revit.
-
Modified IFC files are converted to resulting CityGML files with a workbench with FME.
-
The resulting CityGML file was uploaded to the OGC FTP server.
6.1.2. Lessons Learned
In developing Faramoon’s building modeler, the following challenges were identified:
-
The provided point cloud data was in grayscale. This made it difficult to discern various entries and exits as well as other features in the point cloud. This also makes it more difficult to identify objects that could have been more easily distinguished using color (RGB) point clouds as opposed to only geometry (e.g., signage).
-
While not part of the scope of this project, Faramoon attempted to identify some public safety features contained in point cloud data. Some of the public safety features (e.g., fire extinguishers, alarms, etc.) are difficult to identify due to the complexity of shape and size.
-
Initially, Faramoon attempted to automate the conversion of Hancock County point cloud data. However, the point cloud data was very noisy, resulting in a data output with false walls, missing doors, and incorrect geometries, etc. Therefore, it was determined that the output data needed to be cleaned manually or enriched in order to be used for the demonstration. Initial attempts to use TICA proved to be difficult due to immature developmental status and lack of existing documentation for the software. The automation tool from Faramoon can output either CityGML or IFC data (BIM standard). Since tools are limited for CityGML formats, Faramoon used Revit, a 3D BIM tool, to manually cleanse the output data in IFC format.
-
The Hancock dataset was provided in six different point cloud files. The resulting CityGML file contained the processed results of all six point cloud files combined. This was challenging because the point clouds overlapped but did not accurately fit together. With trial and error, the modified IFC models were placed in several different combinations until an accurate representation of the building appeared.
-
Georeferencing issues were discovered in the point cloud data because data was not geolocated. Therefore, to resolve this issue, a combination of Google Maps satellite imagery and QGIS was used. This was done by finding the location of the real building and positioning it along the corners of the Google Maps satellite imagery in QGIS, an open source GIS software, until the resulting CityGML model matched the satellite imagery.
6.2. GIS FCU Building Modeler Service
GIS FCU’s building modeler service calls a WPS service to convert point cloud data into CityGML data. The service relied on the use of Machine Learning techniques through the use of the open source PointNet library. This software library uses recognition to identify and classify clusters of point clouds as objects and separate the objects into individual geometries. The process flow is shown in Figure 24.
6.2.1. Process Flow
-
The user calls the WPS service with a mail address and URL link to a LAS file
-
The WPS service creates a new job ID for this request
-
The WPS service returns the job ID to the user
-
The WPS service sends the requirements to a processing server with the mail address and URL
-
The download service downloads the LAS file using the associated URL
-
The convert service converts the LAS file to PCD format
-
The building service consists of 3 services, including a Recognition service, a Segmentation service, and a Conversion service.
-
The Recognition service recognizes objects, walls, roof, floor and doors
-
The Segmentation service segments objects into several parts points group
-
The Conversion service converts the points group to a 3D surface which consists of objects of polygon type
-
-
The convert service converts the 3D surfaces into CityGML
-
The processing server sends the resulting URL of CityGML by email, or the user can use a job ID to query and retrieve the download URL
-
The user can query the job status by job ID during the processing time
-
The WPS service returns the status of this job. There are three types of statuses: Processing, Failed, and Finished.
The Point Cloud data is converted to CityGML with no manual intervention:
-
The WPS service downloads the point cloud dataset via the URL
-
It converts the LAS file to PCD format because PCD format is easier to manipulate. Then the file size is reduced by 100:1. This is a downsampling process which is considered lossy, but results in the reduction of the overall error rate.
-
The PointNet library (PointNet: Deep Learning on Point Sets for 3D Classification and Segmentation https://arxiv.org/pdf/1612.00593) is used to reconstruct surfaces. PointNet is a C-based open source library which supports C++, Python, and Java with Deep Learning libraries to identify and recognize 3D objects within the PCD. GIS FCU encodes this in Python, and the libraries are listed below:
-
The Recognition Library is used to identify and group objects based on clusters of point cloud points through a pattern recognition module. This includes 3D object recognition, hypothesis verification for 3D object recognition, and implicit shape model for calculating objects centers.
-
The Segmentation Library segments point cloud data based on various algorithms.
-
The Surface Library provides data smoothing and reconstructions using approximation algorithms.
-
-
Convert PCD file to SHP file to build 3D surface file.
-
Convert SHP file to GML file.
-
Build CityGML file from GML file.
6.2.2. Lessons Learned
Currently, PointNet is able to recognize some objects, but attempts to recognize boundaries and surfaces with straight polygons is very difficult.
Between the doors and the rooms, the spacing between the walls and the doors need to be highlighted. Attempts to use raw data resulted in a lot of noisy data. Downsampling the data by 10:1 showed some improvement with some noise. 100:1 was better, but 1000:1 was too lossy. The amount of reduction depends on the original raw data. Figure 25 shows the differences in the point clouds at various downsampling levels.
PointNet uses a deep learning neural network algorithm, and it needs many more examples of polygon objects such as windows, doors, walls, etc. to teach the network algorithm to better recognize these objects in point cloud. For example, with enough point clouds of trees, deep learning can be used to filter out trees from indoor space recognition. Additional examples are needed to improve the accuracy of the algorithm.
7. Navigation Modeler Service
As described in Section 5.1.3, “IndoorGML Data”, the purpose of the Navigation Modeler Service is to convert CityGML from the Building Modeling Service into IndoorGML for use by the Indoor Navigation Service. This service queries the CSW for a given building ID, retrieves the building data in CityGML via a URL, converts it to IndoorGML and then posts the results back to the CSW. The following describes the sub-components, process steps, data format, and service interfaces for this service component.
7.1. Pusan National University Navigation Modeler
The Pusan National University Navigation Modeler service operates differently than the prescribed data conversion flow. The workflow for PNU’s navigation modeler is to convert from point cloud data directly into IndoorGML, and then convert IndoorGML into CityGML. The conversion process conducted by Pusan National University is documented step-by-step as follows:
7.1.1. Conversion from Point Cloud data into IndoorGML
The point cloud data is captured. Figure 26 shows the undesired artifacts from unclean point cloud data.
The data is cleansed following a data cleansing process.
A reconstructed mesh is created from the cleansed point cloud data.
A set of simplified polygons are defined based on the mesh
The simplified polygons are converted using a tool called TM-based IndoorGML Cleaning & Authoring (TICA) tool.
https://github.com/STEMLab/TICA
TICA is used to apply cubemap texturing.
Missing walls are manually added.
Large single spaces are not very useful for navigation. Splitting a large single space into several smaller spaces is called sub-spacing. Partition of sub-spacing can be done using TICA for TM-based pipelines to construct indoor space models (see Figure 33).
The geometry is edited to add missing structures, merge surfaces, and remove "noisy" polygons.
Coplanar surfaces that have splits or stitches are merged into a single planar surface.
Missing floors are drawn for areas where the SLAM sensor could not capture point clouds.
Vertices and edges are aligned.
Solids are created for each room.
The result is a clean 3D geometry of the indoor space.
Doors and windows must be annotated.
Figure 41 shows the result after doors and windows are annotated.
States and transitions are edited and interlayer connections are made.
Public Safety features are added.
The states for corridor and states for non-navigable spaces are finalized.
The final result can be depicted in the InViewer application.
7.1.2. Conversion from IndoorGML into CityGML
Figure 46 shows the use of point cloud data with cuboid images to create texture mappings in a 3-dimensional representation using TICA.
Once the IndoorGML data set with public safety features and textures are prepared, it is converted to CityGML using Hale, an open-source conversion tool.
This process uses the Hale transformation rule. The Hale Mappings are provided at the following URL:
https://github.com/STEMLab/IndoorGML2CityGML_PSExtension
Since IndoorGML and CityGML are modeled as complex schemas, we have to define the mapping rules from the top level to lower ones.
-
The mapping rules in the attached file aim at converting IndoorGML 3D objects to CityGML Building features.
-
For the mapping rules between IndoorGML and CityGML, start with PrimalSpaceFeatures as the top level.
Hale provides several approaches, among which two are applied:
-
ReType:toplevel
-
Rename: mapping rules of lower levels of ReType (1:1, 1:n, n:1)
-
Retype PrimalSpaceFeatures in IndoorGML to CityModel in CityGML.
-
Define the mapping rules between feature types of the lower levels
-
IndoorGML.cellSpaceMember–CityGML.FeatureMember
-
IndoorGML.cellSpace–CityGML.Room
-
-
Define the mapping rules for the attributes such as
-
id
-
geometry
-
When converting from CityGML to IndoorGML, GML.ID is
-
not mandatory in GML3.1.1, which is the base standard for CityGML 2.0
-
Mandatory in GML3.2.1, which is the base standard for IndoorGML
-
generated using ‘Generate Unique Id” function
-
7.1.3. IndoorGML Network Sub-Spacing
The GRID team from University of New South Wales (UNSW) provides a tool, called IndoorGML2LCC which allows to add a Node Relation Graph (NRG) to IndoorGML models. The tool, available online (https://github.com/grid-unsw/IndoorGML2LCC), uses the Linear Cell Complex (LCC) package from the Computational Geometry Algorithm Library (CGAL) as a data structure to handle the geometric and topological information described in IndoorGML. It is provided as a plugin that fits directly to the 3D LCC demo of CGAL. While the installation process of IndoorGML2LCC is described in the Github page, its use is described below.
The IndoorGML files loaded in the tool were expected to be missing topological information and solely describe the spaces called CellSpace units. However, it is designed to preserve such data if already available and add another graph layer on top of it.
Once the IndoorGML model is loaded, the user interface (UI) allows several views of the model and interaction options. Figure 49 illustrates the original view where every cell is represented with a unique color, which stands as a basic ID in the LCC. That view can be changed into a wireframe to see just the outline of the cells shown in Figure 50.
From the loaded CellSpace units, each of them is represented as a 3-Cell in the LCC. From there, the NRG can be automatically derived by running the “Add NRG Layer” operation (see Figure 51). It is called “basic” because it is implementing the original Poincare Duality theory which consists in abstracting every volume with a point (node) and every volume to volume adjacency with an edge, forming together the NRG. The nodes are obtained based on the centroids of the CellSpaces (see Figure 52) and their adjacency relationships are deduced from the faces that they share between them.
While the graph visualization of IndoorGML2LCC is still under development, the exported model, enriched with an NRG layer can be visualized using FME (see Figure 53) or InViewer.
7.2. Safe Software Navigation Modeler
Safe Software’s approach used the FME spatial ETL tool to read the CityGML 2.0 Public Safety ADE data and transform it to IndoorGML v1.1 with the Public Safety Extension. Because FME uses a model-based approach, the transformation rules are tied to the underlying CityGML and IndoorGML schemas and are not dependent on particular datasets. This means that once the transformation was defined for one dataset, it was possible to use the same CityGML-to-IndoorGML model to transform other datasets. Some minor configurations were required, but these are mostly limited to mitigating deficiencies in individual datasets, or introducing custom business rules to auto-generate public safety content that was missing in a particular dataset.
The ETL tool provides a number of functions mapped out in a feature flow diagram so that no coding is required. The primary transformation steps involved were: map schema from CityGML to IndoorGML, generate IDs, parent IDs, and parent property types to satisfy IndoorGML schema / UML requirements, and establish required nesting and parent child feature relationships. There were also business rules added to generate default values required for each feature type. Some of these are constants and some are based on feature context including public safety information.
Finally, a navigation network topology was generated and decomposed into nodes and linkages to support navigation. The navigation network was auto-generated within the cell spaces of the Indoor GML model using the state and transition feature types. The basic approach was to generate a Triangulated Irregular Network (TIN) and then remove all the edges that crossed wall boundaries. Doors were used to cut holes in the walls to allow the network to traverse the building. In some datasets a few key doors were missing so a few transition features were added to better support network connectivity. Finally, the output was validated against the IndoorGML Public Safety Extension schemas to make sure that the results were consistent with the requirements of the IndoorGML standard.
The main process steps for the Navigation Modeler (NM) Service are as follows:
-
Query the CSW for a given building (CSW GET GetRecordById).
-
Parse the CSW response metadata and retrieve the associated CityGML via resolving dataset URL.
-
Convert CityGML 2.0 Public Safety ADE to OGC Indoor GML using data transformation model developed in FME:
-
Map schema from CityGML to Indoor GML.
-
Set default values where none are available in source.
-
Merge indoor context information such as public safety data.
-
Generate nodes and linkages to support navigation.
-
Generate OGC IndoorGML v1.0. data in LLWGS84 (EPSG:4326) or Web Mercator (EPSG:3857) using an IndoorGML Public Safety Extension to IndoorGML in order to capture information related to the CityGML public safety ADE.
-
-
Perform validation and publish validated IndoorGML to publicly available file service end point.
-
Generate metadata and publish metadata record with building ID and dataset link to CSW (CSW POST Transaction Insert)
For more information including the FME workspace model used to transform from CityGML to IndoorGML see: https://knowledge.safe.com/articles/96851/ogc-indoor-gml-pilot.html
Runtime parameters control specification of CityGML input path, IndoorGML output path, navigation network grid size (vertical and horizontal tiles), rotation angle, and validation.
The core requirement for the Navigation Modeling Service is the ability to convert from CityGML Public Safety ADE to IndoorGML. During the kickoff meeting it was agreed that the central reference for all datasets would be an Indoor Pilot CSW. Each service that generates a new dataset publishes it to the CSW. Any service that requires a dataset can request it from the CSW based on its ID. The CSW also lists all available buildings by name and ID.
Figure 57 shows the FME Workspace which was used to automate the posting of IndoorGML results generated by NIST004 to the CSW.
The primary risk factors to implementing this service were:
-
Development of the CityGML Public Safety ADE and IndoorGML Public Safety Extension. This took a significant amount of collaborative effort and, naturally, changes to these schemas did require significant adjustments and retooling of transformation algorithms.
-
Quality and type of incoming CityGML was not known ahead of time. Some of the earlier point cloud-to-CityGML sample datasets were composed of a few very large mesh features representing large building elements. These were not relatable to individual rooms, walls, or doors and, as such, were not usable for navigation.
-
Availability of format and schema of data required by IndoorGML but not present in CityGML not yet known (e.g., occupancy, room use, and public safety information were often not available from the source CityGML, etc.)
-
Basic validation for the output IndoorGML was conducted by validating the GML against the IndoorGML application schemas and Public Safety Extension schemas. Beyond this, there were few business rules provided to help qualify the quality of indoor data or assure accuracy of the output relative to the input IFC or CityGML.
-
Navigation service example requests and use cases that need to be answered by IndoorGML
7.2.1. Considerations
CityGML is a useful input format for the Navigation Modeler because it is a mature and widely adopted standard, with many datasets available in CityGML format. CityGML is a good focal point for building data because it can be created from IFC, IMDF, BIM, and other GIS formats. Safe Software generated CityGML data from Apple IMDF in order to create test data to begin early development and testing of the Indoor Navigation Modeler service.
IndoorGML is primarily an exchange format, not an application format. Examples of typical application formats include Apple IMDF and Google KML. IndoorGML’s core purpose is to provide information exchange to support indoor navigation. Domain application specific content should remain in the extensions. For example, the public safety features developed for IndoorGML belong as features defined in the schema of the Public Safety Extension, not in the core IndoorGML. While CityGML data is a good source of building data since it is widely available, IndoorGML is ideally suited for indoor mapping and navigation – the application for which it is designed.
The Navigation Modeler component converts from CityGML to IndoorGML from which navigation routes are calculated. CityGML is potentially richer in 3D physical representation and also contains more information than is typically needed for indoor applications. CityGML models are comprised of 3D surface structures. The intent of IndoorGML is to model interior spaces and the relationship between those spaces for the purposes of navigation. For example, interior furniture or installations are multi-surface solids in CityGML, whereas in IndoorGML they are modeled as 3D points. Point Clouds are converted into CityGML multi-surface objects to provide cleaner, discrete physical representations of the spaces and objects being modeled. This is then converted into IndoorGML, which is a simpler, logical representation of indoor spaces, connectivity, and points of interest.
7.2.2. Lessons Learned
-
CityGML doors: Correct door definition is critical to any indoor mapping model, but often presents challenges when it comes to interpreting the type and state of the doors. Some doors were miscategorized as rooms which broke the network. The workaround to this was to filter these features out by their ids and correct their categorization.
-
Depending on the coordinate transformations, some datasets had a north up layout while others such as Hancock County are oriented at a significant angle away from north up. In the latter case, we used a calibration factor to rotate the navigation network so that it aligned with the building corridors to produce a navigation network in line with building corridors. In the future, logic could be added to detect corridor orientation so that this rotation could be applied automatically.
-
There were a variety of approaches that proved useful in geometry simplification. In the case of the Hancock County CityGML, the doors were complex multisurfaces. These were simplified into vertical planar surfaces using a combination of FME and ETL functions including a PlanarityFilter followed by a Tester set to filter out all faces except those whose Z surface normal = 0. This proved to be a useful approach to filter out everything except vertical surfaces.
-
CenterPointReplacer was used to convert building installation objects represented as solids or multisurfaces in CityGML, into points of interest that were represented as a simple 3D point in IndoorGML.
-
In practical situations, first responders need to transition between buildings or across outdoor spaces and in / out of buildings. To this end, focusing only on indoor spaces is not sufficient. There needs to be connection points which link buildings with external / outside spaces so that indoor / outdoor navigation can happen seamlessly.
-
There is a need for a Quality Assurance process for data quality (e.g., Data Quality DWG). At the moment validation of output is primarily against the IndoorGML schemas including the Public Safety Extension. Other business rules need to be developed to validate the data content. Rooms need doors. Rooms should cover the level. Doors and room walls should be coincident. Rooms should be enclosed spaces. In FME, the Geometry Validator transformer was used for some of these checks.
-
For the purpose of this pilot, a published parameter for navigation grid resolution was provided (horizontal and vertical tiles) to enable control of the granularity of navigation.
-
The multi-layer graph generation from CityGML to IndoorGML may have varied results depending on the algorithm and resolution applied. These non-uniform results, when processed for navigation, could produce different navigation routes depending on the graph generated. Different applications may require different types of navigation routes. Basic instructions to get from room A to room B might only require room sequence information provided by a simple center-point network. Routing to support a first responder and provide the shortest path from point A to B across rooms of various sizes and with multiple entrances would likely require a higher resolution navigation network that supports multiple possible routes across a given room depending on obstacles, hazards, start and end points etc.
-
Overall, once configured, spatial ETL transform models proved capable of automating most of the process for converting indoor building data from one format to another, particularly when the source and destination formats conformed to clearly defined open standards such as CityGML, IndoorGML or IFC. The initial FME transform model was developed to convert Victoria Airport CityGML to IndoorGML. Once this model was developed and tested, the same model was employed to convert the PNU Central Plaza CityGML to IndoorGML. Some modifications were required to manage anomalies in each dataset - such as misclassified doors. Also, edits were made to accommodate changes to the Public Safety ADE and enhancements to improve navigation network generation. However, by the time the Hancock dataset became available, only minimal calibration changes were required to perform the conversion (e.g. navigation network resolution and alignment calibration).
7.3. Skymantics Navigation Modeler
Skymantics was a relatively newer user of the CityGML and IndoorGML standards, enabling them to provide a fresher perspective on the tasks of implementing these standards. Skymantics developed the Navigation Modeler Service using WPS as the primary interface. The main process steps for the Navigation Modeler (NM) Service are as follows:
-
Client Tool makes a request to the WPS to retrieve IndoorGML data based on CityGML data as an input.
-
The WPS processes the request and submits a job to the Navigation Modeler service.
-
The Navigation modeler retrieves the information from the CSW based on the job inputs and processes the CityGML-to-IndoorGML conversion.
-
The Navigation modeler reinserts the new IndoorGML converted data back into the CSW.
-
The Navigation modeler responds to the WPS to notify completion of the job.
-
The WPS provides the client with the URL of the converted IndoorGML data.
-
The client is able to retrieve the completed IndoorGML from the CSW.
The Indoor Navigation Modeler is responsible for CityGML retrieval and IndoorGML insertion compliant with the OGC WPS 2.0 standard and its associated domain logic. The server consumes GML data from the CSW and produces IndoorGML compliant with the requirements of Indoor Navigation for the Pre-planning Tool Client. The front-facing WPS server is 52°North’s Java based implementation of WPS 2.0, JavaPS. This WPS server is hosted on a Tomcat instance on a Docker-based Debian GNU/Linux 8 distribution, hosted on a Microsoft Azure Cloud server. The backend Processing Service is a Java-based implementation for transforming the relevant CityGML-to-IndoorGML data, in part utilizing the open source library citygml4j. The WPS provides asynchronous, scalable capability by containerizing these Processes using Docker.
7.3.1. Lessons Learned
CityGML appears to be a very large standard (i.e., over 270 pages). This standard covers various Levels of Detail (LOD), which it was later discovered that only LOD4 pertained to the pilot. The LOD4 describes the exterior and interior geometries of buildings, openings (e.g., doors, windows, etc.), and interior objects such as furniture. These interior objects could include public safety features such as fire extinguishers, shut off valves, etc. which apply to the public safety scenario of this pilot.
The sponsor requirements mandated, however, that additional metadata was needed to describe certain public safety specific features regarding interior objects such as the direction a door swings inward/outward, symbology, and hazards such as oxygen tanks, etc. In order to incorporate this data, the Public Safety ADE was developed and incorporated into CityGML. The Public Safety ADE extends features within CityGML with additional properties such as whether a door is locked and direction it opens.
Automatic generation of IndoorGML SpaceLayers was very challenging without utilizing existing enterprise tools. Complex polygons, such as a horseshoe shaped room, are difficult to conduct using fast and efficient algorithms. As such, transformations such as Delaunay Triangulations of CityGML Geometry were required. Our approach was achieved using FME Workbench to generate a TIN of the topographical space. Even a semi-manual process such as this may result in bugs or stranded States. Additionally, it is highly difficult to utilize all IndoorGML specifications in an automated fashion based purely on Geometry alone for converting CityGML to IndoorGML due to CityGML’s more generalized and abstracted semantic definitions. An example of this is CityGML’s standard Room definition. IndoorGML specifies subtype of Rooms, such as hallways or archways. Without additional semantic information, it is very difficult for an automated process to differentiate between a very long and narrow room and a hallway. Some manual definition of these spaces is required in order to utilize some the respective IndoorGML definitions in the case of this pilot.
In order to convert CityGML to IndoorGML, the Java Architecture for XML Binding (JAXB) was used for transformation of the XML data types. It was discovered that an open source bindings based on XML-Java Binding (XJB) exist, specifically for CityGML to use with JAXB, called ogc-schemas. These files are bindings that are required in order to transform CityGML markup into Java class representations. Using the XJC command line interface (CLI) and the ogc-schemas bindings, the CityGML java objects can be generated. Once the objects are generated, additional properties can be annotated. Then the objects and be transformed into different representations such as IndoorGML.
Some challenges were encountered during development. Writing XJB bindings for such a large schema such as CityGML is too complex due to the number of dependencies required considering the scope and the development time allocated for the pilot. It was also discovered that there is a mismatch of GML versions between CityGML and IndoorGML. CityGML is an application schema of GML version 3.1.1 whereas IndoorGML targets GML version 3.2.1 which created issues. For example, a solid property type in CityGML is different than a solid property type in IndoorGML. It was learned that objects of type GML 3.1.1 could not be casted to objects of type GML 3.2.1. For example, CityGMLSolid = new IndoorGMLSolid() would result in a Typecast compilation error. Since IndoorGML and CityGML both inherit from GML types, manual generation of GML 3.2.1 was required to transform the CityGML to IndoorGML.
|
Note
|
CityGML3 - the new version of CityGML – is currently being developed to support GML 3.2.1 (https://github.com/opengeospatial/CityGML-3.0Encodings). |
As both CityGML and IndoorGML geometric representations use GML, and GML did not change the core representation of objects composed of primitive types such as character arrays, int, long, float etc., a developmental workaround was able to be implemented. The workaround is shown in the following Java listing.
private net.opengis.gml._3.SurfacePropertyType
CreateNewSurfaceMembers(List<Double> list){
net.opengis.gml._3.DirectPositionListType outputPosList = new net.opengis.gml._3.DirectPositionListType();
outputPosList.getValue().addAll(list);
net.opengis.gml._3.LinearRingType myring = new net.opengis.gml._3.LinearRingType();
myring.setPosList(outputPosList);
JAXBElement<net.opengis.gml._3.LinearRingType> ring = objfac.createLinearRing(myring);
net.opengis.gml._3.AbstractRingPropertyType absRing = objfac.createAbstractRingPropertyType();
absRing.setAbstractRing(ring);
net.opengis.gml._3.PolygonType poly = objfac.createPolygonType();
poly.setExterior(absRing);
poly.setSrsDimension(BigInteger.valueOf(3));
JAXBElement<net.opengis.gml._3.PolygonType> absSurface = objfac.createPolygon(poly);
net.opengis.gml._3.SurfacePropertyType surfacePropertyType =objfac.createSurfacePropertyType();
surfacePropertyType.setAbstractSurface(absSurface);
return surfacePropertyType;
}
First, the CityGML geometry primitives of GML type 3.1.1 were extracted. The geometry primitives are posList, which is a collection of doubles that represent geometric coordinates. Then, a new PosList of type GML 3.2.1 was created. JAXB object factories were used in this process to generate compliant GML classes. The CityGML primitive collection of type GML 3.1.1 would then be copied onto this newly generated 3.2.1 PosList. The geometric representation would then propagate up the abstraction hierarchy such that PosLists are nested into AbstractRings into Polygons into Surface Members. These surface members represent the walls, doors, and openings of a building space. However, this approach is prone to error because new code must be generated to map the appropriate version types for each mismatch, for example GML 3.1.1 to GML 3.2.1. This could become a continued issue and should be carefully considered in a future version of IndoorGML and the target application of the GML schema versions for interoperability.
8. Building Model Repository
8.1. Compusult Building Model Repository
The Building Model Repository stores CityGML, IndoorGML, and Point Cloud URLs inside a Catalog service using a Catalog Service for Web-Transactional (CSW-T) interface. A client can search for information to discover the data and the available services. The CSW-T provides a response containing links to the data and/or services. A WFS-T is not provided since CSW-T can provide the necessary transactional requests to discover and access the services and data. For this pilot, the data is stored in an FTP location, and the URL to the data is stored in the CSW.
Compusult has a product called Web Enterprise Suite (WES) which provides the capability to interface with the CSW to retrieve Point Cloud, CityGML, and IndoorGML data and convert them into 3D Tiles and store them within a GeoPackage. Additionally, IndoorGML data is natively stored in a GeoPackage Related Tables extension. The IndoorGML Route is used for navigation purposes. In these formats, they are delivered via 3DPS to a Pre-planning Tool Client provided by the Compusult GoMobile Client. This enables offline viewing and navigation routing of the content on a mobile device in a disconnected environment, also known as Denied, Degraded, Intermittent, or Limited (DDIL) Bandwidth environment.
The Building Model Repository provided by Compusult performs according to the following sequence diagram.
-
Users authenticate with the CSW service
-
Authenticated users execute a CSW Insert, Update or Delete Transaction using an HTTP POST request. The Insert transaction’s POST data contains the URLs to the raw Point Cloud data, IndoorGML and/or the CityGML along with the Metadata. The Update transaction’s POST data contains the filter criteria of the CSW record(s) to be updated to the Point Cloud URL, IndoorGML URL and/or CityGML URL data along with the Metadata. The Delete transaction’s POST data contains the filter criteria of the CSW record(s) to be deleted.
-
The CSW object classifications shall be of the following types:
-
urn:ogc:def:ebRIM-ObjectType:OGC:Dataset:3DData:Lidar
-
urn:ogc:def:ebRIM-ObjectType:OGC:Dataset:3DData:CityGML
-
urn:ogc:def:ebRIM-ObjectType:OGC:Dataset:3DData:IndoorGML
-
urn:ogc:def:ebRIM-ObjectType:OGC:Dataset:3DData:IndoorGMLRoute
-
-
Clients execute a GetRecords or GetRecordByID request to the CSW to find Indoor Mapping Service records.
-
Clients extract the raw data URL to download the data files.
-
CSW INSERT, UPDATE and DELETE Transactions
-
Input
-
POST data with the URL(s) to the raw data files, CSW Classification Type, and associated Metadata
-
-
Output
-
<csw:TransactionResponse>
-
-
-
CSW GetRecords
-
Input
-
Spatial, Keyword, and Classification Type (see CSW Classification Types above)
-
-
Output
-
<csw:GetRecordsResponse>
-
-
-
CSW GetRecordByID
-
Input
-
RecordID
-
-
Output
-
<csw:GetRecordByIdResponse>
-
-
8.1.1. CSW Transactions
Examples are shown in Annex A - Appendix A, Building Repository Examples.
The CSW Insert Transaction Post request initiates the ingestion of metadata describing the data with a link to the raw product. (see Section A.1, “CSW Insert Transaction POST Request Example”)
The CSW Update Transaction Post request updates the metadata and/or raw product link. (see Section A.3, “CSW Update Transaction Request Example”)
The CSW Delete Transaction Request deletes the records in the CSW matching the criteria specified. (see Section A.5, “CSW Delete Transaction Request Example”)
The GetRecords Request returns the records that meet the criteria specified. (see Section A.7, “CSW GetRecords Request Example”)
The GetRecordByID Request returns the record for the specified ID. (see Section A.11, “CSW GetRecordByID Response Example”)
8.1.2. Lessons Learned
Compusult did not have access to a stable basic dataset to work with at the beginning of the pilot. Most datasets that were initially provided by participants had issues (e.g., CRS not specified, missing GML tags, etc.), which led to a series of iterations to try to determine the issues and work with the corresponding participants to get the data cleaned up. In order to create a complete scenario with building models, navigation routes, and public safety features, all datasets (point cloud, IndoorGML, CityGML, and Public Safety) are required. Sometimes only a subset of these were available. Without IndoorGML, the navigation routing cannot be provided. Without CityGML, the building model cannot be represented. Without Public Safety feature point-of-interest, we cannot render things such as fire extinguishers, gas shut off valves, etc.
Another challenge faced by Compusult was that participants did not always implement the CityGML or IndoorGML standards in the same way, which caused inconsistencies in the data and resulted in errors or unexpected outputs when new data was received. To avoid such pitfalls in the future, validation tools could be developed for the datasets to ensure contributions follow the standards specifications more closely.
Compusult worked with the other participants to identify the discrepancies and work through the issues. The following issues were identified:
-
Missing Coordinate Reference System (CRS)
-
Use of different coordinate systems without specifying CRS
-
Inconsistent use of namespaces
-
Missing datasets (e.g., Point Cloud and CityGML existed but not the corresponding IndoorGML, having CityGML and IndoorGML datasets but missing Point Cloud data (Victoria Airport), or missing CityGML Public Safety ADE or IndoorGML PS Extension.)
9. Indoor Navigation Service
The purpose of the Indoor Navigation Service is to provide the optimal route for a firefighter to safely reach their target within the building. Conceptually, the IndoorGML data should already be annotated with the PS extension and provide notable cues for guidance throughout the navigable path. The indoor navigation service is intended to help first responders to navigate the interior spaces of a building during an emergency. It creates a route between two points, a start and an end point. The service is also intended to support navigation to public safety features along the way such as fire extinguishers, shut-off valves, etc. or avoid hazards such as locked doors, rooms with oxygen tanks, etc. The indoor navigation service takes IndoorGML as an input and parameters from the pre-planning client to generate an IndoorGML route.
9.1. Skymantics Indoor Navigation Service
Skymantics' Indoor Navigation Service was developed using Java, specifically JDK 1.8. This includes libraries such as the Apache Commons networking library to extend FTP and HTTP access, as well as the JAXB XML processing libraries for the consumption and generation of XML data based on the IndoorGML schema specifications. This domain logic was integrated into JavaPS, an Open Source WPS implementation from 52North. The WPS was hosted on a Tomcat 8.0 instance contained in Docker which was then deployed to an Azure Cloud server. An FTP endpoint specified by the client is used to extract the relevant IndoorGML for a given navigation area. The JAXB library is then used to create IndoorGML Java Objects from their respective markup classes using .xjb binding files provided by the Open-Source ogc-schemas repository.
The Navigation Service extracts the State-Transition Network from the IndoorGML topographical SpaceLayer and proceeds to parse the graph, associating the various states to their respective transitions, whilst also checking the semantic definition of States or transitions to delineate hazards (e.g., locked doors). These public safety enhanced state / transitions are assigned specific weights if none are provided. For example, the connected Transition of any public safety hazard has all its inbound edges set to a weight of Infinity. Likewise, Transitions that represent locked doors also have their weight set to Infinity. This guarantees that an inaccessible node will not be considered during the Navigation process. An implementation of Dijkstra’s algorithm was used to navigate interior spaces, utilizing IndoorGML’s SpaceLayer architecture to calculate the most eligible route for a given Start and End point. Functionally, the Navigation Service takes two IndoorGML states from the topographical SpaceLayer. These states are chosen by the end user in the pre-planning client application. The Navigation Service then calculates the shortest, most viable path from the Start state to the End state. The result of this process is an ordered set of Route objects. This list is then deserialized using the relevant .xjb binding to produce schema-compliant IndoorGML that represents a Route, with the relevant states as RouteNodes and transitions between them as RouteSegments. This markup is then sent as a response to the requesting Client tool. The Indoor Navigation Service provided by Skymantics performs according to Figure 62.
-
Client application sends selected Start and End StateId’s and accompanying Catalog GUID to the WPS instance
-
WPS obtains the IndoorGML data associated with the GUID via the IndoorPilot FTP Server
-
WPS transforms this data via JAXB into an annotated Java Object
-
Domain Logic consumes this Java Object to extract the State-Transition network and transforms it into a graph representation
-
The Start and End states are fed into a graph traversal function based on Dijkstra’s algorithm, and the most optimal route is calculated using the Weight property of the Transition class
-
The series of States visited are inserted into a Stack, which is then unwound and transformed into a Route object that mirrors IndoorGML Navigation modules Route schema
-
The WPS returns this Route Object in XML format back to the Client tool, adhering to the schema put forth for the IndoorGML navigation module.
9.1.1. Lessons Learned
One recommendation to the IndoorGML SWG is to eliminate or refactor the Node and Edge property of the SpaceLayer Class (see SpaceLayerType in Section B.3, “SpaceLayerType Example”). Specifically, the unbounded maxOccurs property of both Edge and Node classes, in conjunction with the minOccurs property of the Edge class, can result in IndoorGML markup in which States are stranded with no Transition. It may also result in improperly formatted Markup, in which connected states are erroneously logically separated into different Node collections. An expansion of the IndoorGML schema document of the NodeType and EdgeType classes, and their precise purpose, in regards to the schema, may eliminate some confusion associated with these particular objects.
9.2. Compusult Indoor Navigation Service
The Indoor Navigation Service provided by Compusult has the following functionality:
-
Users will initiate a navigation request by specifying a start point, an end point in the GetNavigationRoutes request.
-
The Indoor Navigation Service will request IndoorGML data.
-
IndoorGML Data will be returned to the Indoor Navigation Service.
-
The Indoor Navigation Service will calculate the route.
-
The Route info (GML) will be passed back to the User for visualization in the Indoor Mapping Client
-
WPS GetNavigationRoutes
-
Input
-
IndoorGML ID
-
Start Point
-
End Point
-
-
Response
-
GML Navigation Routes (including Metadata)
-
-
Examples of interface calls are provided in Appendix C, Compusult Indoor Navigation Service Examples.
9.2.1. Lessons Learned
It was found that the Coordinate Reference System (CRS) was specified inconsistently or sometimes missing altogether in CityGML / IndoorGML. The following examples show different representations of the srsName. In the future there may need to be a standardized way of representing the srsName to increase the interoperability between various clients. Some examples include the following[1]:
-
srsName="EPSG3850"
-
srsName="EPSG:3850"
-
srsName="EPSG::3850"
-
srsName="urn:ogc:def:crs,crs:EPSG::25832,crs:EPSG::5783"
The pre-planning client has the capability to turn on and off the display of specific floors. Initially, there was no specification of a floor / story so Compusult attempted a few approaches for the representation of a floor (such as using the z-value). However, a good solution could not be reached, so it was recommended to add a "Storey" attribute to IndoorGML which would represent the floor level. This was initially implemented as text in the comment for the element which is a suboptimal approach.
There was also some discussion about adding the Story as a parent element and grouping other child elements inside the parent element. This also highlights an issue between the various worldly spellings of some words. Storey is the British spelling and story is American English.[2]
The Storey attribute is required to identify the floor or story being represented in the building. Knowing this would allow the client software to be able to turn on/off all the feature data for a given floor. For example, if the user only wanted to see the navigation points and public safety features for floor 4, this attribute would allow the software to identify the floors and disable all but Storey 4.
When defining the start and end navigation points for a route, there were differences in approaches to mapping the start and end points to elements in IndoorGML in an interoperable way. Initially, Compusult’s implementation provided the start and end points as x, y, z values whereas Skymantics provided the start and end points as named points. All points in the IndoorGML model have a unique ID which is used to name the point. It was decided to change the implementation to match the Skymantics implementation to facilitate interoperability between the routing services. Both of these methods are viable, however, it was determined that using the named method was cleaner because there was no additional work required to find the closest point to a user’s selection.
The routing information is stored in IndoorGML so it was decided to store the IndoorGML in the GeoPackage for offline routing in a Denied, Degraded, Intermittent, or Limited Bandwidth (DDIL) environment. This was accomplished by using the GeoPackage Related Tables extension to store the IndoorGML in its native format. This gave the additional benefit of being able to implement routing in DDIL environments as we could read the GML directly from the GeoPackage without the need to interface with the WPS service.
The Indoor Navigation Service was implemented as a WPS instead of the suggested WFS-T due to flexibility required for the implementation. The WPS allowed for a simpler interface to pass the start and end points as well as the IndoorGML to the navigation service and to return the route information as IndoorGML. A Web Feature Service (WFS) would not work for this as it is simply a query interface to return feature information. There was no clear way to pass the IndoorGML data using a WFS.
10. Pre-planning Tool Client
The pre-planning tool client is the user interface that a first responder or technician would interact with during a pre-planning scenario. The client provides 3D and 2D views of the captured point cloud, converted CityGML geometries, IndoorGML indoor spaces, and IndoorGML navigational networks. Using the pre-planning client, a user can access the building repository to retrieve the stored datasets, display and manipulate the viewing angles, and generate routes by specifying start and end points. The routes are displayed within the client along with the public safety features. In the future, turn-by-turn directions could be incorporated to provide the optimal route safely throughout the building and avoid hazards.
10.1. Compusult Pre-planning Tool Client
Compusult extended their current desktop and mobile client offering called GoMobile to support CityGML, IndoorGML, and Point Cloud datasets. The GoMobile Pre-planning Tool client can display 2D maps and images, Point Clouds, 3D maps (See Figure 65), and 3D Indoor data (See Figure 66).
10.1.1. Workflow
GoMobile has the ability to query, render and navigate indoor scenes according to the following workflow:
-
GoMobile initiates a getData request to Compusult’s Web Enterprise Suite (WES) platform which returns an ISO document with URLs to the map, point cloud, navigation resources
-
GoMobile calls the 3DPS to retrieve the 3D map or the point cloud data.
-
Users can use GoMobile to initiate a WPS navigation request by specifying a start point, an end point in the WPS GetNavigationRoutes request.
-
The Route info (GML) is passed back to the user for visualization in GoMobile client application.
10.1.2. Lessons Learned
The first challenge was how to pick the start and end point in 3D space. Due to the nature of 3D rendering, a user can rotate the model so that multiple points can be oriented behind each other. This presented a challenge to determine which point the user meant to click on when they click in 3D viewer. It was assumed that the user meant to click the closest point, which is used for the route start or end point.
The specification lacked guidance on how to represent the 3D model so it was implemented with gray translucent walls, floors, and ceilings, gray non-public safety doors, and brownish red public safety doors. This type of information could have been more clearly defined in the appearance module of the CityGML. Without the appearance module definitions individual clients could render the building differently. Additional guidance for public safety viewing.
There appears to be inconsistent use of the boundary surface thematic classes (e.g., <bldg:RoofSurface>, <bldg:CeilingSurface>, <bldg:FloorSurface>, etc.) as opposed to LOD4MultiSurface. Therefore, the client could not reliably represent surfaces based on the element class in some models. Use of the thematic classes would allow for finer detailed representation of the building parts. For example, a client could render the floor a different color than the roof or ceiling. It would also allow for parts of the building to be turned on/off in the display, giving the user the ability to turn off the roof, for example.
Different uses of the standard CityGML namespaces (e.g., generic vs building vs bridge) presented challenges for parsing CityGML data. Different datasets used different elements / namespaces. Use of namespaces such as 'generic' instead of 'building' caused parsing errors when using the CityGML.
There is a lack of a specification on how to represent Public Safety features. It was decided to use a lookup dictionary for mapping the icon to the Public Safety feature type. This means users of the ADE have to parse the XML to get the type of the feature, then take the type and do a lookup to find the URL to the icon, then download the icon for use. This limits certain types (e.g., fire extinguisher) to a single icon. It would be simpler if the ADE XML itself contained the URL directly to the icon and by-pass the lookup. However, there is the benefit that if the URL to the icon changes it only needs to be updated in the lookup table and not in all places throughout the XML.
It was found that there were different versions of GML used between CityGML and IndoorGML. CityGML used V3.1.1 whereas IndoorGML used v3.2.1 which led to parsing issues. Initially, it was expected that the CityGML and IndoorGML needed to be consistent in versions. However, the issue was overcome by adding support for both versions of GML.
Point Cloud data was received in three formats (PCD, LAS and LAZ). In order to process the various formations, Compusult used a 3rd party tool to manually convert all Point Clouds to LAZ before being converted into 3DTiles in .PNTS format which was used by the client for display. This introduced a manual step in the process which is not desirable.
The Point Cloud datasets did not contain any information for georeferencing so a manual process was introduced to georeference, scale, and rotate the point cloud so that it displayed corrected on the maps in Compusult’s 3D mapping client. The specification does allow for georeferencing information which, if provided, would allow rendering of the building in the correct location. In the absence of a geo-location to draw the points our client would default to 0,0.
10.2. EcoDomus Pre-planning Tool Client
EcoDomus is the software platform to create Digital Twins of facilities and infrastructure objects. The software tracks every object’s attributes (e.g., from a rooftop chiller to a receptacle) and allows visualizing objects in 3D and 2D. For this research project, EcoDomus expanded its 3D Viewer capabilities to support CityGML and IndoorGML.
EcoDomus Viewer is able to render CityGML geometry and show properties for the selected objects. The software allows loading multiple CityGML files and aligning the objects (facilities) by moving them within the 3D scene. An example below (See Figure 68) shows a campus 3D map using CityGML (white buildings) alongside the BIM model (yellow-brown building, exported from Revit):
CityGML-rendered facilities can also be merged within the 3D scene with point clouds as shown in Figure 69 below.
10.2.1. Workflow
EcoDomus Viewer operates in a standard browser (e.g., Google Chrome) via WebGL and does not require special plugins. Asset data is stored in MS SQL server and can be edited by the authorized users.
-
The authorized user logs into EcoDomus software and opens the Viewer.
-
The user enters some facility’s address into a textbox in the menu.
-
EcoDomus software accesses CSW hosted by another project participant and searches by a keyword agreed upon (e.g., “Hancock County”).
-
EcoDomus software retrieves the CityGML file for the facility and loads it into the Viewer.
-
The user can navigate within the scene using standard controls (walk, orbit, pan, zoom, etc.), select objects and see/edit its data. The user can hide selected objects, isolate objects making the objects semi-transparent, etc.
EcoDomus Viewer operates in a standard browser (Chrome) via WebGL and does not require special plugins. Asset data is stored in MS SQL server and can be edited by the authorized users. For this project, EcoDomus added IndoorGML processor. An example of a project file is shown below:
Red objects show the nodes and blue lines show the suggested navigation between the nodes.
Figure 71 shows the resulting Hancock data in the Ecodomus Viewer.
10.2.2. Lessons Learned
-
The different CityGML files have different coordinate reference systems. The Faramoon data does not contain a CRS, and using a local cartesian reference worked fine. The Safe software data does and opens correctly on first try. So, the CRS should be specified in the CityGML data to avoid interoperability issues.
-
Need standards for units of measure such as millimeters or meters.
-
In order to properly view the navigational routes, they need to be overlaid on top of the CityGML view.
11. Public Safety Scenario (Demonstration)
The NIST Public Safety Communications Research Division is the primary federal laboratory conducting research, development, testing, and evaluation for public safety communications technologies. This OGC Innovation Pilot initiative is focused on the research and development of Indoor Mapping technologies and public safety extensions using CityGML and IndoorGML derived from point clouds and other 3-dimensional data from automated scans. The goal is to incorporate open standards to support the public safety objectives and increase adoption of these standards to improve tooling and support from the geospatial community.
The scenario for this initiative is based on pre-planning for firefighting and emergency first-responder operations. First responders typically survey high-risk facilities in their jurisdiction for pre-incident planning, but they are often forced to create their own hand-drawn maps during the process. LiDAR and image scans can be conducted periodically in large buildings to capture any changes in the building construction, remodeling, expansion, and placement of public safety features including fire extinguishers, fire exits, water pumps, etc. Using mobile mapping systems (see Figure 72) equipped with LiDAR and a 360-degree camera, technicians can efficiently capture 3D point clouds (see Figure 73), transform them into vector formats (CityGML, IndoorGML), and calculate and modify navigable indoor routes for incident response. The scenario demonstrates the use of point cloud data to support firefighting and emergency operations pre-planning.
The process begins with the conversion of point cloud data into CityGML format (see Figure 74). The resulting CityGML data can be enriched with Public Safety features captured from image scans, point cloud object identification, or manual insertion. New Public Safety features are taken from the NAPSG Public Safety library of features. (https://www.napsgfoundation.org). The Public Safety ADE provides the CityGML schema extension for these features which are then converted to Public Safety Extension in IndoorGML to provide navigational support for indoor routing.
Once the conversion process is complete, a planner can support training operations for emergency response using a pre-planning client to view the information in a graphical user interface. Having knowledge of public safety features and the best route through an interior space during an emergency would help in firefighting situations and support emergency operations.
11.1. Point Cloud to CityGML Data Conversion
Initially, the initiative began testing with readily available point cloud data scans and textured images of Korea University and CityGML data of Victoria International Airport. Later in the initiative, official Hancock County data was provided which contained captured point cloud data and image scans. In the beginning, the team attempted to automate the conversion of the point cloud data. However, point cloud data tends to be very noisy, and the common result was a data output with false walls, missing doors, and incorrect geometries, etc. Notice the noise at the bottom and right sides of Figure 75 likely caused by LiDAR scans leaking through transparent door or window glass (see Figure 76).
The Hancock County point clouds came as separate files and had to be merged.
The consensus is that current software tools and libraries are not yet mature enough to produce clean geometries from point cloud data, and the data needed to be cleansed manually and enriched in order to be used for the demonstration. Attempts to use open source tools proved to be difficult due to immature developmental status and lack of existing documentation for the software. In general, the team was able to use automation to output either CityGML or IFC data (BIM standard). Since editing tools are limited for CityGML formats, the team had to manually cleanse the data and output the data in IFC format (See Figure 77 and Figure 78). Once the data was output in IFC format and georeferenced, it is considered clean enough to use for demonstration purposes.
The edited IFC data was then post-processed using FME for geometric processing to convert IFC into CityGML. This process required experimentation to create the proper processing to convert into CityGML. Once a satisfactory method was achieved, this processing step was mostly automated. This process is shown in Figure 79 and Figure 80.
In IFC, indoor geometries are typically represented as solids. However, for CityGML, geometries typically are represented as surfaces, and therefore need to be converted from solids into multi-surface elements to properly represent the room boundaries. CityGML contains "walls" and "rooms" whereas IndoorGML contains "Cell" or "GeneralSpace" which are mapped from CityGML "rooms". In order to support this conversion to CityGML, a new feature called <ifcSpace> was created which were then converted into CityGML "rooms". During this step, often too many surfaces are generated. Extra surfaces were filtered and discarded in FME with a process using surface normal generation and analysis. For more information see Section 5.3.1, “Conversion to IFC”.
In another method, the team used a MatLab application called PolyFit to manually cleanse the point cloud data and redraw 3D surfaces. The output of the PolyFit is a clean point cloud data file. Once the data is cleaned and surfaces are reconstructed using PolyFit, it is processed using PointNet functions to manually convert the data into mesh data file set.
11.2. CityGML to Indoor GML Data Conversion
The team implemented a couple different methods to generate routing networks. One method was to calculate the centroid of the segmented sub-spacing, the centroid of segmented subspaces within the corridors, the door centroids, and generate network nodes and edges between these center points. This is shown in Figure 83. This methodology is also described in more detail in Section 7.1.3, “IndoorGML Network Sub-Spacing”.
The other more fine-grained method is to generate a dense network of points within each indoor space and calculate the most efficient method of routing within each space. This can be seen in Figure 84. This is done by overlaying a mesh over the space, and using walls and doors (non-navigable objects) to cut the mesh, resulting in a navigable node and edge network. For this reason, correct doors and walls are required to create an optimal network mesh and routes.
11.3. Visualizing Indoor Mapping for Pre-Planning Events
By defining a start and end point, an optimal route can be generated based on various algorithms (e.g., A-Star algorithm). Once the Navigation Modeler has completed the navigational route calculations, the route can be displayed in the pre-planning client in 3D to show the navigable path for a first-responder.
Additionally, public safety features can be visualized as part of the pre-planning walkthrough as seen in the example in Figure 86. These features include fire pumps, public safety doors and windows, and gas shutoff valves, and can be placed throughout the building as required.
11.4. Conclusions
From the perspective of the approach of this pilot, creating maps of indoor spaces is very demanding, and one of the promising approaches is to use point clouds to create indoor maps.
The team demonstrated that it is possible to transform a point cloud to CityGML Public Safety ADE and IndoorGML with a Public Safety Extension, and then visualize the public safety data in the Pre-planning Tool using open standards and basic navigation capabilities. Open standards made the process possible for data processing, modeling, exchange, and display. While some steps were automated, some manual effort is still required to get from point cloud to building features. The team had some success with semi-automated tools, and observed there is potential for automation to be improved. IndoorGML is primarily focused on indoor navigation, but this cannot be completely separated from the physical view of CityGML for the representation of the building.
Some integration of the two models would improve the use and capabilities of each. More work needs to be done to improve the capability of point cloud feature extraction, editors, converters, and develop quality, symbology and validation rules for indoor mapping and navigation data. Potential gaps between indoor and outdoor maps and simplified data stream profiles for mobile use should also be explored. Finally, enhancing client tools by integrating indoor maps with real-time environmental information and augmented reality would significantly enrich the information provided to first responders. Combined, these have the potential to significantly improve safety and enhance effectiveness when responding to a wide array of potential emergencies.
11.4.1. Summary of Lessons Learned
-
Calculating the centroid of a space for IndoorGML causes anomalies if the spaces are not properly segmented. In the example shown in Figure 87, using only one centroid for a long hallway with corners caused an anomaly with route generation in the center of the hallway and caused all routes for that hallway to map to a single node. This can be solved by sub-spacing such spaces.
-
When generating a mesh of points for indoor spaces, it is important to rotate the overlaid graph to ensure alignment with the georeferenced IndoorGML. The orientation of the IndoorGML model affects the way in which the routing nodes are generated and requires some calibration of the orientation angle in order to ensure points are aligned. This can be seen in Figure 88. Early network generation in Hancock data was not aligned with the corridors yielding a network that produced irregular paths.
-
This pilot would have benefited from the use of clean reference data for developing standards. The primary data still introduced issues that were unresolvable from automated data conversion which impacted the overall project. From a public safety perspective, data capture and structure are critical, particularly the RGB data of a point cloud. This affects how doors and windows can be identified. Having an accurate representation of doors is critical to a public safety scenario including which doors are closed and/or locked. Indoor navigation routing requires these doors, but point cloud scans do not easily detect closed doors. During the scanning process, the person executing the scan needs to make every effort to identify every door (and open it if possible) and identify locked doors. Richer data leads to better results.
-
Automatic conversion of point cloud data into CityGML resulted in significant levels of noise including false walls and incorrect geometries. Reflective floors and transparent glass cause artifacts in the point cloud data. Therefore, it was determined that the output data needed to be cleansed manually in order to be used for the pilot demonstration. Automation tools and processes are not yet mature enough yet to generate models for navigation purposes without manual intervention and data cleansing.
-
Existing CityGML tools did not provide the type of editing functionality required. The IFC standard was easier to edit using REVIT. For this reason, Faramoon chose to convert first to IFC for editing and cleaning, and then to CityGML. PNU also used an editing tool - in this case TICA - to clean up their GML data. Some issues may have been created due to the conversion of PC data into IFC data and then IFC into CityGML. These issues have to do with differences in the data model formats. Potential issues may be mitigated by reducing the number of conversions. So, there is a trade-off between editing tool functionality and the conversions required to make use of that tool. Ideally it would be best to convert directly from PC to CityGML. However, the output of both approaches proved to be usable for indoor navigation purposes. In the future, further development of tools for this application is needed to improve the maturity, capability, and ease of use. Also, quality control and validation methods can mitigate issues raised by data model differences and conversion.
-
IndoorGML Core does not provide all requirements for Public Safety applications, so this is why the Public Safety Extension is needed.
-
IndoorGML can be used for improving navigation instructions within a building. However, the data model could be harmonized with other indoor formats from industry standards (e.g., Apple IMDF, ESRI Indoor, etc.) to promote cross interoperability.
-
Data conversions between data formats with established open geospatial standards such as CityGML and IndoorGML proved to be relatively straightforward to apply to new datasets. Once the transform processes or models were defined, developed and validated, the same conversion processes could be applied to new datasets with significantly less reconfiguration or development effort with some variations depending on tools or libraries employed. In short, the use of open standards directly supported efforts towards increasing automation and scalability, both of which are critical for any potential new system to move beyond prototype to production.
11.4.2. Recommendations for Future Work
-
This pilot focused on working with indoor data. For the purposes of public safety and other mapping applications, the distinction between indoor and outdoor is somewhat arbitrary. Often public safety incidents may involve multiple buildings and resources need to take into account road and water networks and other accessibility considerations. Future work related to indoor mapping should take into account how best to interface with outdoor mapping and utilizes data sources such as CityGML which can model both.
-
Rendering the symbology for Public Safety is not well defined in the context of IndoorGML and CityGML. For the demonstration, some notations can be made in CityGML and IndoorGML for symbology. The NAPSG symbology within the CityGML Public Safety ADE and the IndoorGML Public Safety Extension could be encoded using Style Layer Descriptors (SLD). SLD currently supports 2-dimensional rendering, but future support for 3-dimensional rendering could be considered.
-
Consideration could be made toward the development and improvement of tools (e.g., TICA) that combine machine learning and manual processes with interactive guidance to intelligently identify surfaces generated using ML or Deep Learning processes.
-
The CityGML data output created from Point Cloud data may be valid, but not usable when converted into IndoorGML. The spaces need to be properly segmented into subspaces with each space defining a fully enclosed volume. For example, some of the early approaches yielded building models composed of just a few large objects. From a CityGML perspective, this result might look adequate in a visual representation, but not be usable for navigation purposes because the individual rooms and doors are not defined. For use in a navigational model, additional checks are needed to ensure connectivity and sub-spacing is adequate. Future work should include investigation to formalize what business rules, checks, and validations are needed to define a successful conversion from CityGML to IndoorGML.
-
CityGML 3.0 has some enhancements that relate to indoor mapping and hold promise as an intermediary format. Future work on IndoorGML should consider closer coordination with CityGML 3.0 developments.
-
Refine approaches for generating navigation routes in IndoorGML for turn-by-turn navigation and for optimized routes. Optimization methods could be developed for calculating by distance, by hazard avoidance, and potentially by taking into account breakable windows and walls.
-
In this pilot, most enrichment related to Public Safety information was done manually as Public Safety information was not readily available for the test areas. On the one hand, most indoor applications require frequent updates in order to remain current and relevant. On the other hand, geometry processing is typically expensive in terms of processing and effort. Thus, typically the most efficient way of providing updates is via tables of attribute information related to a common key such as room ID. Going forward, future applications should provide a means of combining non-spatial room attribute table information with room spaces based on a common ID. This would enable many updates to be performed autonomously.
-
Due to the scope and early stage of this pilot, work was necessarily focused on data generation and modeling. Future work would benefit from a greater focus on web and mobile clients. IndoorGML is designed as an exchange format for indoor data, and is optimized for that. It is not an ideal client for many end user applications, especially for mobile clients. Typically, mobile clients are easier to support using lightweight data streams based on JSON. Future work should look at integrating with the emerging OGC OpenAPIs and perhaps explore an Indoor light data model deployable via GeoJSON over WFS3.
-
Another area that will benefit from significant research and development is studying how indoor maps and building models can be used to guide first responders during emergency events. Integration with real-time position and situational information will be critical, combined with methods of continually providing updates of the building structures, accessibility, and environmental conditions. Methods for enriching awareness through the use of Augmented Reality (AR) should also be explored as this would be very beneficial for first responders working within a restricted visibility environment, as well as adding the ability to see through barriers to assess possible hazards such as gas lines or hot spots. Ways of combining multiple technologies could also be explored. With a comprehensive BIM-oriented 3D model as a frame of reference, point cloud updates combined with drone and robot derived infrared imagery could be used to develop a dynamic model of a fire in progress which could then inform AR systems guiding responders.
Appendix A: Building Repository Examples
A.1. CSW Insert Transaction POST Request Example
https://ogc-indoor-pilot.compusult.net/wes/serviceManagerCSW/cswt<?xml version="1.0" encoding="UTF-8"?>
<csw:Transaction xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dct="http://purl.org/dc/terms/" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:wrs="http://www.opengis.net/cat/wrs/1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" service="CSW"
version="2.0.2" xmlns:xml="http://www.w3.org/XML/1998/namespace" xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 http://docs.oasis-open.org/regrep/v3.0/schema/rim.xsd http://www.opengis.net/cat/wrs/1.0 http://schemas.opengis.net/csw/2.0.2/profiles/ebrim/1.0/csw-ebrim.xsd">
<csw:Insert>
<wrs:ExtrinsicObject id="c7694e02-01b7-4267-8827-2eef63b84807" mimeType="text/xml" objectType="urn:ogc:def:ebRIM-ObjectType:OGC:Dataset:3DData:Lidar">
<rim:Slot name="http://purl.org/dc/terms/modified" slotType="urn:oasis:names:tc:ebxml-regrep:DataType:DateTime">
<rim:ValueList>
<rim:Value>2019-01-17T13:01:11</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="http://purl.org/dc/terms/created" slotType="urn:oasis:names:tc:ebxml-regrep:DataType:DateTime">
<rim:ValueList>
<rim:Value>2019-01-17T13:01:11</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="http://purl.org/dc/elements/1.1/language" slotType="urn:oasis:names:tc:ebxml-regrep:DataType:String">
<rim:ValueList>
<rim:Value>en</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="http://purl.org/dc/terms/dateSubmitted" slotType="urn:oasis:names:tc:ebxml-regrep:DataType:DateTime">
<rim:ValueList>
<rim:Value>2019-01-17T01:01:11</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="http://purl.org/dc/terms/spatial" slotType="urn:ogc:def:dataType:ISO-19107:GM_Envelope">
<wrs:ValueList>
<wrs:AnyValue>
<gml:Envelope srsName="EPSG:4326">
<gml:lowerCorner>-180.0 -90.0</gml:lowerCorner>
<gml:upperCorner>180.0 90.0</gml:upperCorner>
</gml:Envelope>
</wrs:AnyValue>
</wrs:ValueList>
</rim:Slot>
<rim:Slot name="Editable" slotType="urn:oasis:names:tc:ebxml-regrep:DataType:Boolean">
<rim:ValueList>
<rim:Value>true</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="Transfer Option Type" slotType="urn:oasis:names:tc:ebxml-regrep:DataType:String">
<rim:ValueList>
<rim:Value>FTP</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="Transfer Option Name" slotType="urn:oasis:names:tc:ebxml-regrep:DataType:String">
<rim:ValueList>
<rim:Value>Lidar data of Korean Mall</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="Transfer Option Description" slotType="urn:oasis:names:tc:ebxml-regrep:DataType:String">
<rim:ValueList>
<rim:Value>Description of Lidar data of Korean Mall</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Slot name="Transfer Option URL" slotType="urn:oasis:names:tc:ebxml-regrep:DataType:URI">
<rim:ValueList>
<rim:Value>
ftp://user:password@ftp.somewhere.org/PointCloudData/filename.zip
</rim:Value>
</rim:ValueList>
</rim:Slot>
<rim:Name>
<rim:LocalizedString charset="UTF-8" xml:lang="en" value="Lidar data of Korean mall" />
</rim:Name>
<rim:Description>
<rim:LocalizedString charset="UTF-8" xml:lang="en" value="Description for Lidar data of Korean mall"/>
</rim:Description>
<wrs:repositoryItemRef xlink:href="http://ogc-indoor-pilot.compusult.net/wes/serviceManagerCSW/csw" xlink:type="simple" />
</wrs:ExtrinsicObject>
<rim:Classification classificationNode="urn:ogc:def:ebRIM-ObjectType:OGC:Dataset:3DData:Lidar" classificationScheme="urn:ogc:def:ObjectType:OtherResources" classifiedObject="c8694e02-01b7-4267-8827-2eef63b84807" id="dd27a7b5-e8f9-c2a9-633c-d61afa453012" />
</csw:Insert>
</csw:Transaction>A.2. CSW Insert Transaction Response Example
<?xml version="1.0" encoding="UTF-8"?>
<csw:TransactionResponse xmlns:csw="http://www.opengis.net/cat/csw/2.0.2">
<csw:TransactionSummary>
<csw:totalInserted>1</csw:totalInserted>
<csw:totalUpdated>0</csw:totalUpdated>
<csw:totalDeleted>0</csw:totalDeleted>
</csw:TransactionSummary>
</csw:TransactionResponse>A.3. CSW Update Transaction Request Example
https://ogc-indoor-pilot.compusult.net/wes/serviceManagerCSW/cswt<?xml version="1.0" encoding="UTF-8"?>
<csw:Transaction xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dct="http://purl.org/dc/terms/" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:wrs="http://www.opengis.net/cat/wrs/1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" service="CSW" version="2.0.2" xmlns:xml="http://www.w3.org/XML/1998/namespace" xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 http://docs.oasis-open.org/regrep/v3.0/schema/rim.xsd http://www.opengis.net/cat/wrs/1.0 http://schemas.opengis.net/csw/2.0.2/profiles/ebrim/1.0/csw-ebrim.xsd">
<csw:Update>
<wrs:ExtrinsicObject id="c8694e02-01b7-4267-8827-2eef63b84807" mimeType="text/xml" objectType="urn:ogc:def:ObjectType:OGC:GeoPackage">
<rim:Name>
<rim:LocalizedString charset="UTF-8" xml:lang="en" value="http://mark-UPDATED-dev.compusult.net/wes/serviceManagerCSW/csw" />
</rim:Name>
<rim:Description>
<rim:LocalizedString charset="UTF-8" xml:lang="en" value="Uploaded file: http://mark-UPDATED-dev.compusult.net/wes/serviceManagerCSW/csw" />
</rim:Description>
</wrs:ExtrinsicObject>
</csw:Update>
<csw:Update>
<wrs:ExtrinsicObject id="c9694e02-01b7-4267-8827-2eef63b84807" mimeType="text/xml" objectType="urn:ogc:def:ObjectType:OGC:GeoPackage">
<rim:Name>
<rim:LocalizedString charset="UTF-8" xml:lang="en" value="http://mark-UPDATED2-dev.compusult.net/wes/serviceManagerCSW/csw" />
</rim:Name>
<rim:Description>
<rim:LocalizedString charset="UTF-8" xml:lang="en" value="Uploaded file: http://mark-UPDATED2-dev.compusult.net/wes/serviceManagerCSW/csw" />
</rim:Description>
</wrs:ExtrinsicObject>
</csw:Update>
</csw:Transaction>A.4. CSW Update Transaction Response Example
<?xml version="1.0" encoding="UTF-8"?>
<csw:TransactionResponse xmlns:csw="http://www.opengis.net/cat/csw/2.0.2">
<csw:TransactionSummary>
<csw:totalInserted>0</csw:totalInserted>
<csw:totalUpdated>2</csw:totalUpdated>
<csw:totalDeleted>0</csw:totalDeleted>
</csw:TransactionSummary>
</csw:TransactionResponse>A.5. CSW Delete Transaction Request Example
https://ogc-indoor-pilot.compusult.net/wes/serviceManagerCSW/cswt<?xml version="1.0" encoding="UTF-8"?>
<csw:Transaction xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dct="http://purl.org/dc/terms/" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:wrs="http://www.opengis.net/cat/wrs/1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" service="CSW" version="2.0.2" xmlns:xml="http://www.w3.org/XML/1998/namespace" xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 http://docs.oasis-open.org/regrep/v3.0/schema/rim.xsd http://www.opengis.net/cat/wrs/1.0 http://schemas.opengis.net/csw/2.0.2/profiles/ebrim/1.0/csw-ebrim.xsd">
<csw:Delete>
<csw:Constraint version='1.0.0'>
<ogc:Filter>
<ogc:PropertyIsEqualTo>
<ogc:PropertyName>DOES NOT MATTER, USES ID</ogc:PropertyName>
<ogc:Literal>c7694e02-01b7-4267-8827-2eef63b84807</ogc:Literal>
</ogc:PropertyIsEqualTo>
</ogc:Filter>
</csw:Constraint>
</csw:Delete>
</csw:Transaction>A.6. CSW Delete Transaction Response Example
<?xml version="1.0" encoding="UTF-8"?>
<csw:TransactionResponse xmlns:csw="http://www.opengis.net/cat/csw/2.0.2">
<csw:TransactionSummary>
<csw:totalInserted>0</csw:totalInserted>
<csw:totalUpdated>0</csw:totalUpdated>
<csw:totalDeleted>1</csw:totalDeleted>
</csw:TransactionSummary>
</csw:TransactionResponse>A.7. CSW GetRecords Request Example
https://ogc-indoor-pilot.compusult.net/wes/serviceManagerCSW/csw<?xml version="1.0" encoding="ISO-8859-1"?>
<csw:GetRecords xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"
xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dct="http://purl.org/dc/terms/"
xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml"
xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:wrs="http://www.opengis.net/cat/wrs/1.0"
xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
maxRecords="10" outputFormat="application/xml" outputSchema="http://www.isotc211.org/2005/gmd"
resultType="results" service="CSW" startPosition="1" version="2.0.2"
xmlns:xml="http://www.w3.org/XML/1998/namespace"
xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 http://docs.oasis-open.org/regrep/v3.0/schema/rim.xsd http://www.opengis.net/cat/wrs/1.0 http://schemas.opengis.net/csw/2.0.2/profiles/ebrim/1.0/csw-ebrim.xsd">
<csw:Query typeNames="csw:Record Classification_resourceTypes">
<csw:ElementSetName typeNames="csw:Record">full</csw:ElementSetName>
<csw:Constraint version="1.1.0">
<ogc:Filter>
<ogc:And>
<ogc:Intersects>
<ogc:PropertyName>ows:BoundingBox</ogc:PropertyName>
<gml:Envelope>
<gml:lowerCorner srsName="EPSG:4326">-180.0 -90.0</gml:lowerCorner>
<gml:upperCorner srsName="EPSG:4326">180.0 90.0</gml:upperCorner>
</gml:Envelope>
</ogc:Intersects>
</ogc:And>
</ogc:Filter>
</csw:Constraint>
</csw:Query>
</csw:GetRecords>A.8. CSW GetRecords Response Example
<?xml version="1.0" encoding="UTF-8"?>
<csw:GetRecordsResponse xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dct="http://purl.org/dc/terms/" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml" xmlns:ows="http://www.opengis.net/ows" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:wrs="http://www.opengis.net/cat/wrs/1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xml="http://www.w3.org/XML/1998/namespace" xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd">
<csw:SearchStatus timestamp="2019-01-24T07:03:16"/>
<csw:SearchResults elementSet="full" nextRecord="0" numberOfRecordsMatched="3" numberOfRecordsReturned="3">
<gmd:MD_Metadata xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.isotc211.org/2005/gmd http://www.isotc211.org/2005/gmd/gmd.xsd http://www.isotc211.org/2005/gmx http://www.isotc211.org/2005/gmx/gmx.xsd">
<gmd:fileIdentifier>
<gco:CharacterString>150ffeee-d3ec-47d2-97bf-39df28c73be7</gco:CharacterString>
</gmd:fileIdentifier>
<gmd:language>
<gmd:LanguageCode codeList="http://www.loc.gov/standards/iso639-2/" codeListValue="eng"/>
</gmd:language>
<gmd:characterSet>
<gmd:MD_CharacterSetCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_CharacterSetCode" codeListValue="utf8"/>
</gmd:characterSet>
<gmd:hierarchyLevel>
<gmd:MD_ScopeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset"/>
</gmd:hierarchyLevel>
<gmd:dateStamp>
<gco:DateTime>2019-01-24T04:51:01</gco:DateTime>
</gmd:dateStamp>
<gmd:metadataStandardName>
<gco:CharacterString>ISO 19119/2005</gco:CharacterString>
</gmd:metadataStandardName>
<gmd:metadataStandardVersion>
<gco:CharacterString>1.0</gco:CharacterString>
</gmd:metadataStandardVersion>
<gmd:identificationInfo>
<gmd:MD_DataIdentification>
<gmd:citation>
<gmd:CI_Citation>
<gmd:title>
<gco:CharacterString>IndoorGML Sample Data</gco:CharacterString>
</gmd:title>
<gmd:date>
<gmd:CI_Date>
<gmd:date>
<gco:Date>2019-01-15</gco:Date>
</gmd:date>
<gmd:dateType>
<gmd:CI_DateTypeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CI_DateTypeCode" codeListValue="creation"/>
</gmd:dateType>
</gmd:CI_Date>
</gmd:date>
<gmd:edition gco:nilReason="missing">
<gco:CharacterString/>
</gmd:edition>
</gmd:CI_Citation>
</gmd:citation>
<gmd:abstract gco:nilReason="missing">
<gco:CharacterString/>
</gmd:abstract>
<gmd:status>
<gmd:MD_ProgressCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_ProgressCode" codeListValue="latestAvailable"/>
</gmd:status>
<gmd:resourceMaintenance>
<gmd:MD_MaintenanceInformation>
<gmd:maintenanceAndUpdateFrequency>
<gmd:MD_MaintenanceFrequencyCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_MaintenanceFrequencyCode" codeListValue="unknown"/>
</gmd:maintenanceAndUpdateFrequency>
</gmd:MD_MaintenanceInformation>
</gmd:resourceMaintenance>
<gmd:graphicOverview>
<gmd:MD_BrowseGraphic>
<gmd:fileName>
<gco:CharacterString>https://ogc-indoor-pilot.compusult.net/wes/serviceManagerCSW/csw?request=GetRepositoryItem&service=CSW&version=2.0.2&id=84e2ee01-ecd7-720e-27f2-21f4e41067b1</gco:CharacterString>
</gmd:fileName>
<gmd:fileDescription>
<gco:CharacterString>Uploaded Browse Graphic</gco:CharacterString>
</gmd:fileDescription>
<gmd:fileType>
<gco:CharacterString>png</gco:CharacterString>
</gmd:fileType>
</gmd:MD_BrowseGraphic>
</gmd:graphicOverview>
<gmd:descriptiveKeywords>
<gmd:MD_Keywords>
<gmd:keyword>
<gco:CharacterString>IMAGERY/BASE MAPS/EARTH COVER</gco:CharacterString>
</gmd:keyword>
<gmd:keyword>
<gco:CharacterString>STRUCTURE</gco:CharacterString>
</gmd:keyword>
<gmd:thesaurusName>
<gmd:CI_Citation>
<gmd:title>
<gco:CharacterString>ISO Topic Category</gco:CharacterString>
</gmd:title>
<gmd:alternateTitle>
<gco:CharacterString>ISO Topic Category</gco:CharacterString>
</gmd:alternateTitle>
<gmd:date>
<gmd:CI_Date>
<gmd:date>
<gco:DateTime>2019-01-24T03:59:14</gco:DateTime>
</gmd:date>
<gmd:dateType>
<gmd:CI_DateTypeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CI_DateTypeCode" codeListValue="date"/>
</gmd:dateType>
</gmd:CI_Date>
</gmd:date>
</gmd:CI_Citation>
</gmd:thesaurusName>
</gmd:MD_Keywords>
</gmd:descriptiveKeywords>
<gmd:descriptiveKeywords>
<gmd:MD_Keywords>
<gmd:keyword>
<gco:CharacterString>OFF-LINE DIGITAL DATA</gco:CharacterString>
</gmd:keyword>
<gmd:thesaurusName>
<gmd:CI_Citation>
<gmd:title>
<gco:CharacterString>Data Resources</gco:CharacterString>
</gmd:title>
<gmd:alternateTitle>
<gco:CharacterString>Data Resources</gco:CharacterString>
</gmd:alternateTitle>
<gmd:date>
<gmd:CI_Date>
<gmd:date>
<gco:DateTime>2019-01-24T03:59:14</gco:DateTime>
</gmd:date>
<gmd:dateType>
<gmd:CI_DateTypeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CI_DateTypeCode" codeListValue="date"/>
</gmd:dateType>
</gmd:CI_Date>
</gmd:date>
</gmd:CI_Citation>
</gmd:thesaurusName>
</gmd:MD_Keywords>
</gmd:descriptiveKeywords>
<gmd:language>
<gmd:LanguageCode codeList="http://www.loc.gov/standards/iso639-2/" codeListValue="eng"/>
</gmd:language>
<gmd:characterSet>
<gmd:MD_CharacterSetCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_CharacterSetCode" codeListValue="utf8"/>
</gmd:characterSet>
<gmd:topicCategory>
<gmd:MD_TopicCategoryCode>imageryBaseMapsEarthCover</gmd:MD_TopicCategoryCode>
</gmd:topicCategory>
<gmd:extent>
<gmd:EX_Extent>
<gmd:geographicElement>
<gmd:EX_GeographicBoundingBox>
<gmd:westBoundLongitude>
<gco:Decimal>-180</gco:Decimal>
</gmd:westBoundLongitude>
<gmd:eastBoundLongitude>
<gco:Decimal>180</gco:Decimal>
</gmd:eastBoundLongitude>
<gmd:southBoundLatitude>
<gco:Decimal>-90</gco:Decimal>
</gmd:southBoundLatitude>
<gmd:northBoundLatitude>
<gco:Decimal>90</gco:Decimal>
</gmd:northBoundLatitude>
</gmd:EX_GeographicBoundingBox>
</gmd:geographicElement>
</gmd:EX_Extent>
</gmd:extent>
</gmd:MD_DataIdentification>
</gmd:identificationInfo>
<gmd:distributionInfo>
<gmd:MD_Distribution>
<gmd:transferOptions>
<gmd:MD_DigitalTransferOptions>
<gmd:onLine>
<gmd:CI_OnlineResource>
<gmd:linkage>
<gmd:URL>ftp://user:password@ftp.somewhere.org/IndoorGML-Sample.gml</gmd:URL>
</gmd:linkage>
<gmd:protocol>
<gco:CharacterString>FTP</gco:CharacterString>
</gmd:protocol>
<gmd:name>
<gco:CharacterString>IndoorGML-Navi-Sample-PNU201-2019-01-15.gml</gco:CharacterString>
</gmd:name>
<gmd:description>
<gco:CharacterString>IndoorGML Sample Data</gco:CharacterString>
</gmd:description>
<gmd:function>
<gmd:CI_OnLineFunctionCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CI_OnLineFunctionCode" codeListValue=""/>
</gmd:function>
</gmd:CI_OnlineResource>
</gmd:onLine>
<gmd:onLine>
<gmd:CI_OnlineResource>
<gmd:linkage>
<gmd:URL>ftp://user:password@ftp.somewhere.org/PointCloudFile.zip</gmd:URL>
</gmd:linkage>
<gmd:protocol>
<gco:CharacterString>FTP</gco:CharacterString>
</gmd:protocol>
<gmd:name>
<gco:CharacterString>Point Cloud Data</gco:CharacterString>
</gmd:name>
<gmd:description>
<gco:CharacterString>KU-HanaSquare-v2</gco:CharacterString>
</gmd:description>
<gmd:function>
<gmd:CI_OnLineFunctionCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#CI_OnLineFunctionCode" codeListValue=""/>
</gmd:function>
</gmd:CI_OnlineResource>
</gmd:onLine>
</gmd:MD_DigitalTransferOptions>
</gmd:transferOptions>
</gmd:MD_Distribution>
</gmd:distributionInfo>
<gmd:dataQualityInfo>
<gmd:DQ_DataQuality>
<gmd:scope>
<gmd:DQ_Scope>
<gmd:level>
<gmd:MD_ScopeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset"/>
</gmd:level>
</gmd:DQ_Scope>
</gmd:scope>
</gmd:DQ_DataQuality>
</gmd:dataQualityInfo>
</gmd:MD_Metadata>
</csw:SearchResults>
</csw:GetRecordsResponse>A.9. CSW GetRecordByID GET Request Example
https://ogc-indoor-pilot.compusult.net/wes/serviceManagerCSW/csw?Service=CSW&Version=2.0.2&request=GetRecordByID&id=150ffeee-d3ec-47d2-97bf-39df28c73be7&elementSetName=summary&outputSchema=http://www.isotc211.org/2005/gmdA.10. CSW GetRecordByID POST Request Example
https://ogc-indoor-pilot.compusult.net/wes/serviceManagerCSW/csw<csw:GetRecordById service="CSW" version="2.0.2" outputFormat="application/xml" outputSchema="http://www.isotc211.org/2005/gmd" xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd">
<csw:Id>150ffeee-d3ec-47d2-97bf-39df28c73be7</csw:Id>
<csw:ElementSetName>summary</csw:ElementSetName>
</csw:GetRecordById>A.11. CSW GetRecordByID Response Example
<?xml version="1.0" encoding="UTF-8"?>
<csw:GetRecordByIdResponse xmlns:csw="http://www.opengis.net/cat/csw/2.0.2" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:dct="http://purl.org/dc/terms/" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:gml="http://www.opengis.net/gml" xmlns:ows="http://www.opengis.net/ows" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0" xmlns:wrs="http://www.opengis.net/cat/wrs/1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xml="http://www.w3.org/XML/1998/namespace" xsi:schemaLocation="http://www.opengis.net/cat/csw/2.0.2 http://schemas.opengis.net/csw/2.0.2/CSW-discovery.xsd">
<gmd:MD_Metadata xmlns:gco="http://www.isotc211.org/2005/gco" xmlns:gml="http://www.opengis.net/gml/3.2" xmlns:gmd="http://www.isotc211.org/2005/gmd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<gmd:fileIdentifier>
<gco:CharacterString>150ffeee-d3ec-47d2-97bf-39df28c73be7</gco:CharacterString>
</gmd:fileIdentifier>
<gmd:characterSet>
<gmd:MD_CharacterSetCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_CharacterSetCode" codeListValue="utf8"/>
</gmd:characterSet>
<gmd:hierarchyLevel>
<gmd:MD_ScopeCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_ScopeCode" codeListValue="dataset"/>
</gmd:hierarchyLevel>
<gmd:dateStamp>
<gco:DateTime>2019-01-24T04:51:01</gco:DateTime>
</gmd:dateStamp>
<gmd:metadataStandardName>
<gco:CharacterString>ISO 19119/2005</gco:CharacterString>
</gmd:metadataStandardName>
<gmd:metadataStandardVersion>
<gco:CharacterString>1.0</gco:CharacterString>
</gmd:metadataStandardVersion>
<gmd:identificationInfo>
<gmd:MD_DataIdentification xmlns:srv="http://www.isotc211.org/2005/srv">
<gmd:citation>
<gmd:CI_Citation>
<gmd:title>
<gco:CharacterString>IndoorGML Sample Data</gco:CharacterString>
</gmd:title>
</gmd:CI_Citation>
</gmd:citation>
<gmd:graphicOverview>
<gmd:MD_BrowseGraphic>
<gmd:fileName>
<gco:CharacterString>https://ogc-indoor-pilot.compusult.net/wes/serviceManagerCSW/csw?request=GetRepositoryItem&service=CSW&version=2.0.2&id=84e2ee01-ecd7-720e-27f2-21f4e41067b1</gco:CharacterString>
</gmd:fileName>
</gmd:MD_BrowseGraphic>
</gmd:graphicOverview>
<gmd:extent>
<gmd:EX_Extent>
<gmd:geographicElement>
<gmd:EX_GeographicBoundingBox>
<gmd:westBoundLongitude>
<gco:Decimal>-180</gco:Decimal>
</gmd:westBoundLongitude>
<gmd:eastBoundLongitude>
<gco:Decimal>180</gco:Decimal>
</gmd:eastBoundLongitude>
<gmd:southBoundLatitude>
<gco:Decimal>-90</gco:Decimal>
</gmd:southBoundLatitude>
<gmd:northBoundLatitude>
<gco:Decimal>90</gco:Decimal>
</gmd:northBoundLatitude>
</gmd:EX_GeographicBoundingBox>
</gmd:geographicElement>
</gmd:EX_Extent>
</gmd:extent>
<gmd:characterSet>
<gmd:MD_CharacterSetCode codeList="http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_19139_Schemas/resources/codelist/ML_gmxCodelists.xml#MD_CharacterSetCode" codeListValue="utf8"/>
</gmd:characterSet>
<gmd:topicCategory>
<gmd:MD_TopicCategoryCode>imageryBaseMapsEarthCover</gmd:MD_TopicCategoryCode>
</gmd:topicCategory>
</gmd:MD_DataIdentification>
</gmd:identificationInfo>
<gmd:distributionInfo>
<gmd:MD_Distribution xmlns:srv="http://www.isotc211.org/2005/srv">
<gmd:transferOptions>
<gmd:MD_DigitalTransferOptions>
<gmd:onLine>
<gmd:CI_OnlineResource>
<gmd:linkage>
<gmd:URL>ftp://user:password@ftp.somewhere.org/filename.gml</gmd:URL>
</gmd:linkage>
<gmd:linkage>
<gmd:URL>ftp://user:password@ftp.somewhere.org/pointcloud.zip</gmd:URL>
</gmd:linkage>
</gmd:CI_OnlineResource>
</gmd:onLine>
</gmd:MD_DigitalTransferOptions>
</gmd:transferOptions>
</gmd:MD_Distribution>
</gmd:distributionInfo>
</gmd:MD_Metadata>
</csw:GetRecordByIdResponse>Appendix B: Skymantics Indoor Navigation Service Examples
B.1. Indoor Navigation WPS Request Example
<wps:Execute xmlns:wps="http://www.opengis.net/wps/2.0"
xmlns:ows="http://www.opengis.net/ows/2.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wps/2.0 ../wps.xsd"
service="WPS"
version="2.0.0" response="document" mode="sync">
<ows:Identifier>org.n52.javaps.service.NIST006Test</ows:Identifier>
<wps:Input id="indoorGMLId">
<wps:Data
mimeType="text/xml"><wps:LiteralValue>a989ea1c-360c-4e8d-a171-b7f2dbccc828</wps:LiteralValue></wps:Data>
</wps:Input>
<wps:Input id="start">
<wps:Data
mimeType="text/xml"><wps:LiteralValue>St_188</wps:LiteralValue></wps:Data>
</wps:Input>
<wps:Input id="end">
<wps:Data
mimeType="text/xml"><wps:LiteralValue>St_229</wps:LiteralValue></wps:Data>
</wps:Input>
<wps:Output id="route" mimeType="application/xml" transmission="value"/>
</wps:Execute>B.2. Indoor Navigation WPS Response Example
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ns4:Route xmlns:ns1="http://www.opengis.net/gml/3.2" xmlns:ns2="http://www.w3.org/1999/xlink" xmlns:ns3="http://www.opengis.net/indoorgml/1.0/core" xmlns:ns4="http://www.opengis.net/indoorgml/1.0/navigation">
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:routeNodes>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:nodeMember>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P23">
<ns1:pos>445538.526005699 5444902.33091888 3.44</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:nodeMember>
<ns4:nodeMember>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P12">
<ns1:pos>445538.526005699 5444902.30232276 0.66</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:nodeMember>
<ns4:nodeMember>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P23">
<ns1:pos>445538.526005699 5444902.33091888 3.44</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:nodeMember>
<ns4:nodeMember>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P12">
<ns1:pos>445538.526005699 5444902.30232276 0.66</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:nodeMember>
<ns4:nodeMember>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P12">
<ns1:pos>445538.526005699 5444902.30232276 0.66</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:nodeMember>
<ns4:nodeMember>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P3">
<ns1:pos>445538.543473167 5444902.27372664 -2.02</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:nodeMember>
<ns4:nodeMember>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P3">
<ns1:pos>445538.543473167 5444902.27372664 -2.02</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:nodeMember>
<ns4:nodeMember>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P1">
<ns1:pos>445536.499779417 5444906.24858758 -2.02</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:nodeMember>
</ns4:routeNodes>
<ns4:path>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:routeMember>
<ns4:RouteSegment>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:weight>0.0</ns4:weight>
<ns4:connects>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P23">
<ns1:pos>445538.526005699 5444902.33091888 3.44</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:connects>
<ns4:connects>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P12">
<ns1:pos>445538.526005699 5444902.30232276 0.66</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:connects>
<ns4:geometry>
<ns1:LineString ns1:id="LS24">
<ns1:pos>445538.526005699 5444902.33091888 3.44</ns1:pos>
<ns1:pos>445538.526005699 5444902.30232276 0.66</ns1:pos>
</ns1:LineString>
</ns4:geometry>
</ns4:RouteSegment>
</ns4:routeMember>
<ns4:routeMember>
<ns4:RouteSegment>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:weight>0.0</ns4:weight>
<ns4:connects>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P23">
<ns1:pos>445538.526005699 5444902.33091888 3.44</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:connects>
<ns4:connects>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P12">
<ns1:pos>445538.526005699 5444902.30232276 0.66</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:connects>
<ns4:geometry>
<ns1:LineString ns1:id="LS24">
<ns1:pos>445538.526005699 5444902.33091888 3.44</ns1:pos>
<ns1:pos>445538.526005699 5444902.30232276 0.66</ns1:pos>
</ns1:LineString>
</ns4:geometry>
</ns4:RouteSegment>
</ns4:routeMember>
<ns4:routeMember>
<ns4:RouteSegment>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:weight>0.0</ns4:weight>
<ns4:connects>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P12">
<ns1:pos>445538.526005699 5444902.30232276 0.66</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:connects>
<ns4:connects>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P3">
<ns1:pos>445538.543473167 5444902.27372664 -2.02</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:connects>
<ns4:geometry>
<ns1:LineString ns1:id="LS10">
<ns1:pos>445538.526005699 5444902.30232276 0.66</ns1:pos>
<ns1:pos>445538.543473167 5444902.27372664 -2.02</ns1:pos>
</ns1:LineString>
</ns4:geometry>
</ns4:RouteSegment>
</ns4:routeMember>
<ns4:routeMember>
<ns4:RouteSegment>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:weight>0.0</ns4:weight>
<ns4:connects>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P3">
<ns1:pos>445538.543473167 5444902.27372664 -2.02</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:connects>
<ns4:connects>
<ns4:RouteNode>
<ns1:boundedBy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:nil="true"/>
<ns4:geometry>
<ns1:Point ns1:id="P1">
<ns1:pos>445536.499779417 5444906.24858758 -2.02</ns1:pos>
</ns1:Point>
</ns4:geometry>
</ns4:RouteNode>
</ns4:connects>
<ns4:geometry>
<ns1:LineString ns1:id="LS1">
<ns1:pos>445538.543473167 5444902.27372664 -2.02</ns1:pos>
<ns1:pos>445537.914644321 5444904.59001251 -2.02</ns1:pos>
<ns1:pos>445536.499779417 5444906.24858758 -2.02</ns1:pos>
</ns1:LineString>
</ns4:geometry>
</ns4:RouteSegment>
</ns4:routeMember>
</ns4:path>
</ns4:Route>B.3. SpaceLayerType Example
<xs:complexType name="SpaceLayerType">
<xs:complexContent>
<xs:extension base="gml:AbstractFeatureType">
<xs:sequence>
<xs:element name="usage" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="terminationDate" type="xs:dateTime" minOccurs="0" maxOccurs="1"/>
<xs:element name="function" type="gml:CodeType" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="creationDate" type="xs:dateTime" minOccurs="0" maxOccurs="1"/>
<xs:element name="class" type="SpaceLayerClassTypeType" minOccurs="0" maxOccurs="1"/>
<xs:element name="nodes" type="NodesType" minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="edges" type="EdgesType" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>Appendix C: Compusult Indoor Navigation Service Examples
C.1. Indoor Navigation WPS DescribeProcess Request Example
<?xml version="1.0" encoding="UTF-8"?>
<wps:DescribeProcess
xmlns:ows="http://www.opengis.net/ows/2.0"
xmlns:wps="http://www.opengis.net/wps/2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.opengis.net/wps/2.0 ../wps.xsd"
service="WPS"
version="2.0.0">
<ows:Identifier>GetNavigationRoutes</ows:Identifier>
</wps:DescribeProcess>C.2. Indoor Navigation WPS DescribeProcess Response Example
The DescribeProcess Request will return a description of the inputs and outputs of the GetNavigationRoutes request.
<ProcessOfferings xmlns="http://www.opengis.net/wps/2.0" xmlns:ns="http://www.opengis.net/ows/2.0">
<ProcessOffering jobControlOptions="sync-execute" outputTransmission="value">
<Process>
<ns:Title xml:lang="en">Get Navigation Routes</ns:Title>
<ns:Abstract xml:lang="en">Get A list of Navaigation Routes based on start/end points and a routing source.</ns:Abstract>
<ns:Identifier>GetNavigationRoutes</ns:Identifier>
<Input>
<ns:Title xml:lang="en">Route Start Point</ns:Title>
<ns:Abstract xml:lang="en">GML Representation Of Navigation Route Start Point</ns:Abstract>
<ns:Identifier>START_POINT</ns:Identifier>
<ComplexData>
<Format mimeType="application/gml+xml" encoding="UTF-8" schema="http://schemas.opengis.net/gml/" default="true"/>
</ComplexData>
</Input>
<Input>
<ns:Title xml:lang="en">Route End Point</ns:Title>
<ns:Abstract xml:lang="en">GML Representation Of Navigation Route End Point</ns:Abstract>
<ns:Identifier>END_POINT</ns:Identifier>
<ComplexData>
<Format mimeType="application/gml+xml" encoding="UTF-8" schema="http://schemas.opengis.net/gml/" default="true"/>
</ComplexData>
</Input>
<Input>
<ns:Title xml:lang="en">IndoorGML ID</ns:Title>
<ns:Abstract xml:lang="en">IndoorGML ID</ns:Abstract>
<ns:Identifier>INDOOR_GML_ID</ns:Identifier>
<ComplexData>
<Format mimeType="application/string" encoding="UTF-8" schema="http://schemas.opengis.net/gml/" default="true"/>
</ComplexData>
</Input>
<Output>
<Output>
<ns:Title xml:lang="en">Navigation Routes</ns:Title>
<ns:Abstract xml:lang="en">Available Navigation Routes based on Start/End Points</ns:Abstract>
<ns:Identifier>NAVIGATION_ROUTES</ns:Identifier>
<ComplexData>
<Format mimeType="application/gml+xml" encoding="UTF-8" schema="http://schemas.opengis.net/gml/" default="true"/>
</ComplexData>
</Output>
</Output>
</Process>
</ProcessOffering>
</ProcessOfferings>C.3. Indoor Navigation WPS GetNavigationRoutes Request Example
The GetNavigationRoutes Request will return the navigable routes based on the criteria specified.
<wps:Execute ... service="WPS" version="2.0.0" response="raw" mode="sync">
<ows:Identifier>GetNavigationRoutes</ows:Identifier>
<wps:Input id="START_POINT">
<wps:Data>
<wps:ComplexData>
<wps:Format mimeType="application/gml+xml" encoding="UTF-8" schema="http://schemas.opengis.net/gml/3.1.1/base/geometryBasic0d1d.xsd"/>
<gml:Point srsName="EPSG:4326" srsDimension="3">
<gml:description>The start point required to determine the navigation routes</gml:description>
<gml:identifier>START_POINT</gml:identifier>
<gml:name>startPoint</gml:name>
<gml:pos>1.0 1.0 1.0</gml:pos>
</gml:Point>
</wps:ComplexData>
</wps:Data>
</wps:Input>
<wps:Input id="END_POINT">
<wps:Data>
<wps:ComplexData>
<wps:Format mimeType="application/gml+xml" encoding="UTF-8" schema="http://schemas.opengis.net/gml/3.1.1/base/geometryBasic0d1d.xsd"/>
<gml:Point srsName="EPSG:4326" srsDimension="3">
<gml:description>The end point required to determine the navigation routes</gml:description>
<gml:identifier>END_POINT</gml:identifier>
<gml:name>endPoint</gml:name>
<gml:pos>1.0 2.0 1.0</gml:pos>
</gml:Point>
</wps:ComplexData>
</wps:Data>
</wps:Input>
<wps:Input id="INDOOR_GML_ID">
<wps:Data>hshshs-383838-ahahah</wps:Data>
</wps:Input>
<wps:Output id="NAVIGATION_ROUTES" mimeType="application/gml+xml" transmission="value"/>
</wps:Execute>C.4. Indoor Navigation WPS GetNavigationRoutes Response Example
<gml:MultiGeometry xmlns:gml="http://schemas.opengis.net/gml/3.2.1">
<gml:metaDataProperty>
<gml:GenericMetaData>Any text, intermingled with:
<!--any element-->
</gml:GenericMetaData>
</gml:metaDataProperty>
<gml:description>The available routes based on user start and end points</gml:description>
<gml:descriptionReference/>
<gml:identifier>AvailableRoutes</gml:identifier>
<gml:name>AvailableRoutes</gml:name>
<gml:geometryMembers>
<gml:LineString>
<gml:posList>48.6406778 -123.4316012 0 48.640678199999996 -123.4316055 0 48.640678199999996 -123.4316055 0.00015 48.6406778 -123.4316012 0.00015 48.6406778 -123.4316012 0</gml:posList>
</gml:LineString>
<gml:LineString>
<gml:posList>48.6406778 -123.4316012 0 48.640678199999996 -123.4316055 0 48.640678199999996 -123.4316055 0.00015 48.6406778 -123.4316012 0.00015 48.6406778 -123.4316012 0</gml:posList>
</gml:LineString>
</gml:geometryMembers>
</gml:MultiGeometry>