Publication Date: 2017-10-20

Approval Date: 2017-08-17

Posted Date: 2017-06-27

Reference number of this document: OGC 16-115

Reference URL for this document: http://www.opengis.net/doc/PER/FCP1-IFCviaWFS

Category: Public Engineering Report

Editor: Guy Schumann

Title: FCP-1 Recommendations on Serving IFC via WFS

OGC Engineering Report

COPYRIGHT

Copyright © 2017 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 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.

Abstract

This Engineering Report (ER) gives recommendations on serving IFC via WFS and discusses related issues. It was decided that the focus of this ER is to summarize issues and give recommendations for future work and discuss the nature of such work. In other words, this ER should be viewed as an initial set of discussion points on the topic of serving IFC via WFS.

Business Value

High schema complexities are "still" difficult to handle in a WFS, so it is important to first review status quo and set out a set of recommendations on this topic and this is the goal of this ER.

What does this ER mean for the Working Group and OGC in general

It sets out recommendations for future work/interoperability testbeds.

Keywords

IFC; WFS

1. Introduction

1.1. Scope

The purpose of this ER is to discuss current issues and set out recommendations on serving IFC via WFS.

1.2. Document contributor contact points

All questions regarding this document should be directed to the editor or the contributors:

Table 1. Contacts
Name Organisation

Bart De Lathouwer

Open Geospatial Consortium

Guy Schumann

Remote Sensing Solutions, Inc.

Mohsen Kalantari

University of Melbourne

Ross Eve

Consultant (Remote Sensing Solutions, Inc.

Rob Atkinson

Rob Atkinson

Claus Nagel

virtualcitySYSTEMS GmbH

1.3. Future Work

No future work is planned to this specific document but other testbeds should look into this topic (see "Recommendation" section).

1.4. 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 documents are referenced in this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

  • OGC: OGC 06-121r9, OGC® Web Services Common Standard, 2010

3. Terms and definitions

NOTE: This OWS Common Standard contains a list of normative references that are also applicable to this Engineering Report.

For the purposes of this report, the definitions specified in Clause 4 of the OWS Common Implementation Standard [OGC 06-121r9] and in OGC® Abstract Specification Topic TBD: TBD shall apply.

4. Overview

This ER discusses the current status quo on serving IFC via WFS and recommends possible solutions and topics for future work.

The clause requirements explains the status quo and the new requirements or existing problems/issues that have been addressed by this ER.

The clause solutions outlines the solutions that have been envisioned at the beginning of the testbed, experimented with during the testbed, and that have either been discarded, or implemented, or the decision has been deferred to future activities.

5. Status Quo & New Requirements Statement

5.1. Status Quo

The idea to use WFS to serve IFC was considered in the OGC OWS4 Testbed in 2006. It was felt that the idea to use a well-tested OGC content transport mechanism for payload other than GML would only stretch the scope of GML a small amount (though schemas might be different and perhaps more complex). Complex schemas are still "hard work" for WFS - optimization is needed for robust performance at the server end and specialized clients are generally required.

Considering the above, increasingly Web developers are using complex schemas in JSON: so it is not really the complexity that results in the "hard work," rather support for XML parsing and schema interpretation are a challenge for WFS clients. JSON parses "out-of-the-box" - but loses explicit namespace support, so it is harder to interpret exactly what data means. JSON-LD may resolve this problem.

It is easier to deal with a complex schema than many inter-related simple fragments if there is a need to transact data - i.e., deliver an atomic high-fidelity data package. A normalized (i.e., lots of related objects) database does not have duplicates and can safely be updated keeping the system integrity. However, for many Use Cases, only a simple view of the data is needed (a set of geometries to highlight, for example) to enable identification of the set of entities that match a search, etc.

At this point, one should think about typical OLAP cases - and the use of simplified read-only "data marts" to hide the complexity of a (possibly) transactional, normalized database.

5.2. Requirements Statement

What is needed is a standardized approach to discovering and linking together multiple simplified views (i.e., WFS simple features) as well as the full schema (complex feature WFS), along with other specialized APIs and data structures, (e.g., WCS), operations (WPS), and visualizations (WMS).

A recommended Use Case is to consider object identity, use URIs to simplify identification of the same object in different views, and discover the views available for a given object. The Spatial Data on the Web Best Practices (SDWBP) touches upon this concept, however implementation against the Use Case will require a testbed to work through the necessary agreements on the terminology (ontology) used to describe such relationships.

Defining simplified views of a more complex data model needs additional specification methodology - some formalism needs to be identified, adapted, or developed. Note these concerns have emerged in the Hydrology Domain Working Group, as well.

Virtualcitysystems have a very performant WFS implementation serving CityGML data from a spatial database. Although the model complexity of CityGML is low compared to IFC, CityGML is considered a complex schema in the GIS community. So serving complex schemas via WFS is definitely doable.

Any WFS can choose to serve (Geo)JSON encodings. However, GeoJSON lacks support for 3D geometry types (and reference systems and nested features), so Virtualcitysystems currently cannot easily use GeoJSON for 3D CityGML objects. This constraint is also an issue with IFC. So Virtualcitysystems' clients (including web clients) directly consume the CityGML XML – and it works well.

At the FCP1 kick-off meeting, it was suggested that there might possibly be more relevant and effective mechanism, such as BIM-server, to do this and it was suggested to try this technology in FCP1.

5.2.1. Report on the IFC File Validity (on BIM server).

A detailed discussion of review and validation of IFC data is provided in Section 7.2.1 of [OGC 16-097] "Future City Pilot-1: Using IFC/CityGML in Urban Planning Engineering Report."

6. Solutions

6.1. Targeted Solutions

Suggest a Testbed activity to explore the following.

  • Use Cases in terms of an OLAP model - what are transactional vs. data-mart types of requirements?

  • How available OGC standards meet the requirements put forth in this document, and what guidance is necessary. What gaps need addressing?

  • How to simplify access to data elements - explore options of RESTful interfaces, SDWBP principles (e.g., URI references).

  • How the disposition of multiple related views of data can be described, discovered, and inter-linked to support end-user needs (i.e., test the potential of Linked Data ).

  • Formalize description of profiles/mappings of canonical data models to simplified views.

6.2. Recommendations

The following is recommended for a testbed activity:

  • Have simplified views on a complex schema, which are served via WFS simple features and then linked together.

Appendix A: Revision History

Table 2. Revision History
Date Release Editor Primary clauses modified Descriptions

June 8, 2016

Bart De Lathouwer

.1

all

initial version

Appendix B: Bibliography

[1] OGC: OGC FC 11 Demonstration. (2015).

[2] Lee, J., Zlatanova, S.: 3D geoinformation science. Springer (2009).