Publication Date: YYYY-MM-DD
Approval Date: YYYY-MM-DD
Submission Date: YYYY-MM-DD
Reference number of this document: OGC 18-021
Reference URL for this document: http://www.opengis.net/doc/PER/t14-D040
Category: Public Engineering Report
Editor: Clemens Portele
Title: OGC Testbed-14 Next Generation APIs: Complex Feature Handling Engineering Report (DRAFT)
COPYRIGHT
Copyright (c) 2018 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.
- 1. Summary
- 2. References
- 3. Terms and definitions
- 4. Overview
- 5. Use cases
- 5.1. Introduction
- 5.2. Managing and using a Cadastral dataset
- 5.2.1. Description
- 5.2.2. Selection of protected sites
- 5.2.3. Select the owners of cadastral parcels in an area
- 5.2.4. Select versions of cadastral parcels based on their temporal validity
- 5.2.5. Select cadastral parcels for rendering with a specific style
- 5.2.6. Selection of building parts of a building
- 5.3. Building heating demand simulation and visualization
- 5.3.1. Description
- 5.3.2. Data
- 5.3.3. Open a webpage to display a 3D map using 3D Portrayal Service and select a polygonal area / district
- 5.3.4. Using 3D Portrayal Service and WFS to query the simulation result and visualize it in a 3D scene by building Id
- 5.3.5. Query a feature from a city model by id
- 5.3.6. Select buildings in a 2D region from a city model
- 5.3.7. Select buildings based on nested features or properties
- 6. Requirements analysis
- 7. Assessment of OGC standards and community specifications
- 8. Recommendations
- 8.1. Recommendation 1a: Specify WFS 3.0 extensions for improved fetching of feature data
- 8.2. Recommendation 1b: Make CQL an OGC standard on its own
- 8.3. Recommendation 2: Migrate additional OGC web service standards to the NextGen architecture
- 8.4. Recommendation 3: Investigate if/how GraphQL could be used to query a dataset
- 8.5. Recommendation 4: Consider the use of CityJSON for 3D city models
- 8.6. Recommendation 5: Develop guidance for implementing additional search capabilities
- 8.7. Recommendation 6: Validate and refine recommendations through implementation
- 8.8. Recommendation 7: Register media types for encodings to be used in Web APIs
- Appendix A: Revision History
- Appendix B: Bibliography
1. Summary
OGC Web Feature Service (WFS) 3.0 is a revision of the WFS standard that proposes a modernized service architecture, that follows the current Web architecture, has a focus on the developer experience, supports the OpenAPI specification, and modularizes WFS into building blocks for fine-grained access to spatial data that can be used in Application Programming Interfaces (APIs) for data.
This document reviews the work that proposes a next generation of OGC web services ("NextGen services" or "Next Generation APIs") from the perspective of supporting complex three-dimensional (3D) data or complex data schemas. The goal is to identify the best service solution for these particular needs, whether the results are WFS 3.0 extensions or other approaches. In this context the approach of the NextGen services is not of monolithic web services, but Web API building blocks. This is an important point. The same API should be able to support requirements that currently require separate OGC web services, e.g. a WFS and a 3D Portrayal Service (3DPS).
The purpose of this work is not to preempt other next-generation discussions taking place in OGC but rather to inform and complement that work.
The report includes proposals on how to extend the NextGen service architecture with API building blocks for complex data, complex queries and 3D portrayal. WFS 3.0, Part 1, is used as the starting point for the NextGen service architecture. The proposals are based on existing requirements and use cases as well as existing support for developers to simplify implementation.
The work has found no general issues with migrating current WFS, 3DPS, Web Map Tile Service (WMTS) and Web Map Service (WMS) capabilities to the NextGen architecture. On the contrary, the NextGen approach improves the consistency of the interface and removes redundancies (e.g., between the feature access in WFS and the feature info requests in the other standards).
1.1. Requirements & Research Motivation
The current work on WFS 3.0 has focused on simple features and interaction, interrogation and extraction of these. However, there are more complex use cases that require 3D data and/or more complex data schemas to achieve a user-desired outcome.
This report documents real-world use cases and requirements that feature servers will have to support in the future, besides the essential capabilities specified in Part 1 of the WFS 3.0 series. These will include the following:
-
Querying / filtering features based on properties of related or nested objects or structured data types, including cases where more than one level of relationships/nesting is used;
-
Querying / filtering features based on expressions built from complex predicates consisting of predicate groups and combinations of logical operators;
-
Querying feature data and returning only parts of the features (selected properties, a single property only, etc.);
-
Access to and query of solid geometries and other geometries in a 3D Coordinate Reference System (CRS);
-
Use of responses for display in a web browser;
-
Accessing different versions (including historic representations) of features.
The use cases cover aspects like CityGML, CityGML ADEs, 3DPS, and WFS 2.0 interactions, but use other complex data schemas as background, too.
Based on the identified requirements, this report addresses the following aspects:
-
Assessment of what use cases, especially those that utilize 3D or more complex data schemas, would require more complex interactions than the current WFS 3.0, Part 1, draft would provide;
-
Assessment of current OGC standards and community specifications on the basis of both supporting the uses cases captured and alignment to NextGen service approaches, including a review around the interaction between 3DPS and WFS 2.0;
-
Recommendations for the most appropriate way to support these use cases within the NextGen service architecture.
Developer requirements have to be taken into account in the design. That is, the implementation of the proposed design should be as simple as possible (given the advanced, complex requirements). This includes research for available libraries that support implementations. The OGC community is not the only one implementing rich queries on complex data.
1.2. Prior-After Comparison
The current work on WFS 3.0 in the WFS/FES Standards Working Group (SWG) has focused on simple features and interaction, interrogation and extraction of these. However, there are more complex use cases that require 3D data and/or more complex data schemas to achieve the results that a user is looking for.
This work propose extensions to the NextGen service architecture to support such use cases.
Initial discussions about related topics are:
-
Placeholder issue in the WFS 3.0 repository for richer query capabilities: WFS 3.0 Search extension
-
Representational State Transfer (REST) binding in the WFS 2.x and Filter Encoding Standard (FES) 2.x draft specifications: Document folder in the OGC portal (only accessible to OGC WFS/FES SWG members)
Like the work in the WFS/FES SWG on WFS 3.0, the work on this report has been open to the public from the beginning in order to allow early feedback from developers already during the testbed.
The formal review of the draft report before it will be submitted to the OGC Technical Committee for consideration and publication as an OGC Engineering Report will be by the WFS/FES SWG.
1.3. Recommendations for Future Work
See the chapter "Recommendations". The OGC Innovation Program would be ideal to continue work on the recommendations 1 to 4 based on recommendation 6 (validate and refine recommendations through implementation):
-
Recommendation 1a: Specify WFS 3.0 extensions for improved fetching of feature data
-
Recommendation 2: Migrate additional OGC web service standards to the NextGen architecture
-
Recommendation 3: Investigate if/how GraphQL could be used to query a dataset
-
Recommendation 4: Consider the use of CityJSON for 3D city models
Recommendation 5 (develop guidance for implementing additional search capabilities) could also be a candidate for the development of a Guide as part of a Testbed.
Recommendation 7 (register media types for encodings to be used in Web APIs) is future work for the organisations that govern the i3s, 3D Tiles and CityJSON specifications.
The remainder of this section structures these recommendations in terms of potential future tasks, components, and engineering reports of future OGC Innovation Program initiatives.
The topic of GraphQL for feature data could be a candidate for a dedicated code sprint / hackathon.
1.3.1. Recommended Future Tasks
Next Generation APIs
OGC Web Feature Service (WFS) 3.0 is a revision of the WFS standard that proposes a modernized service architecture, that follows the current Web architecture, has a focus on the developer experience, supports the OpenAPI specification, and modularizes WFS into building blocks for fine-grained access to spatial data that can be used in Application Programming Interfaces (APIs) for data.
OGC Testbed-14, the OGC Vector Tiles Pilot, the ongoing discussions in the OGC Architecture Board, the OGC Architecture DWG and the OWS Common SWG as well as various other activities outside of the OGC have advanced the architecture for a Next Generation of OGC standards for Web APIs significantly. The work in future OGC Innovation Program initiatives can build on these results to mature preliminary results and prepare them for standardization and to explore additional capabilties, resource types and encodings.
In particular, the following sub-tasks are recommended:
-
Specify WFS 3.0 extensions for improved fetching of feature data
-
Migrate additional resource types used in current OGC web service standards to a Next Generation architecture
-
Investigate if/how GraphQL could be used to query a feature dataset
-
Consider the use of CityJSON as an additional WFS 3.0 encoding for 3D city models
-
Develop guidance for implementing advanced search capabilities in WFS 3.0 APIs
In addition, if work on portrayal is planned, it should also be investigated how styling should be supported in a Next Generation architecture.
1.3.2. Recommended Future Deliverables
Recommended Future Components
The following components are suggested to be deployed to test and demonstrate "complex feature handling" capabilities in Web APIs. Validation and refinement through implementation is fundamental for standards related to Web API building blocks. All requirements should be validated in multiple implementations before considering them for standardisation.
-
Next Generation API server(s) with support for CQL Core predicates
-
Next Generation API server(s) with support for STAC JSON queries
-
Next Generation API server(s) with support for CQL Extensions predicates
-
Next Generation API server(s) with support for GraphQL
-
Next Generation API server(s) with support for 2D maps
-
Next Generation API server(s) with support for 3D scenes and views
-
Next Generation API client(s)
As usual, the client(s) should support all tested capabilities.
Recommended Future Engineering Reports (ER)
These Engineering Reports would document the results of the component development and be written so that the result can be used in the OGC Standards Program as initial drafts for new standards. Exceptions are the Guide, which is about guidance, not conformance and potentially the GraphQL ER, which is more about experiments and documenting the results.
-
CQL Core standard (Draft) ER (see recommendation 1b)
-
CQL Extensions standard (Draft) ER (see item 2 in recommendation 1a and recommendation 1b)
-
Web APIs: WFS 3.0 Extensions ER (see items 1, 3 and 4 in recommendation 1a and recommendation 4)
-
Web APIs: Additional Resource Types ER (see recommendation 2)
-
Web APIs: GraphQL ER (see recommendation 3)
-
Web APIs: Rich Queries Guide (see recommendation 5)
1.4. Document contributor contact points
All questions regarding this document should be directed to the editor or the contributors:
Contacts
| Name | Organization |
|---|---|
Clemens Portele (editor) |
interactive instruments GmbH |
Volker Coors |
Hochschule für Technik Stuttgart |
1.5. 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.
3. Terms and definitions
The following terms and definitions apply:
- dataset
-
collection of data, published or curated by a single agent, and available for access or download in one or more formats
[W3C Data Catalog Vocabulary (DCAT)]
|
Note
|
The use of 'collection' in the definition from DCAT is broader than the use of the term in WFS 3.0. See the definition of 'feature collection'. |
- distribution
-
represents an accessible form of a dataset
[W3C Data Catalog Vocabulary (DCAT)]
|
Note
|
Examples are: a downloadable file, an RSS feed or a web service that provides the data. |
- feature
-
abstraction of real world phenomena
[ISO 19101-1:2014]
|
Note
|
If you are unfamiliar with the term 'feature', the explanations in the W3C/OGC Spatial Data on the Web Best Practice document [1] may help, in particular the section on Spatial Things, Features and Geometry. |
- feature collection; collection
-
a set of features from a dataset
[OGC Web Feature Service 3.0: Part 1 - Core]
|
Note
|
In WFS 3.0, 'collection' is used as a synonym for 'feature collection'. This is done to make, for example, URI path expressions shorter and easier to understand for those that are not geo-experts. |
- OpenAPI definition | OpenAPI document
-
a document (or set of documents) that defines or describes an API and conforms to the OpenAPI Specification
[derived from OpenAPI Specification]
3.1. Abbreviated terms
- 2D
-
two-dimensional
- 3D
-
three-dimensional
- 3DPS
-
3D Portrayal Service
- ADE
-
Application Domain Extension
- API
-
Application Programming Interface
- CQL
-
Common Query Language
- CRS
-
Coordinate Reference System
- DCAT
-
Data Catalog Vocabulary
- DWG
-
Domain Working Group
- FES
-
Filter Encoding Specification
- GML
-
Geography Markup Language
- HTML
-
Hypertext Markup Language
- IANA
-
Internet Assigned Numbers Authority
- JRC
-
Joint Research Centre of the European Commission
- JSON
-
Java Script Object Notation
- LoD
-
Level of Detail
- NAS
-
Normbasierte Austauschschnittstelle (Standards-based Data Exchange Interface)
- OGC
-
Open Geospatial Consortium
- REST
-
Representational State Transfer
- SLD
-
Styled Layer Descriptor
- SE
-
Symbology Encoding
- SWG
-
Standards Working Group
- STAC
-
SpatioTemporal Asset Catalog
- UTC
-
Coordinated Universal Time
- W3C
-
World Wide Web Consortium
- WFS
-
Web Feature Service
- WMS
-
Web Map Service
- WMTS
-
Web Map Tile Service
- XML
-
Extensible Markup Language
4. Overview
Section 5 documents real-world use cases and requirements that more advanced feature servers will have to support in the future, besides the essential capabilities specified in Part 1 of the WFS 3.0 series.
Section 6 analyses the use cases and identifies the requirements that would require more complex interactions than those supported by the current draft of WFS 3.0, Part 1.
Section 7 assesses current OGC standards and community standards with respect to the use cases and the approach to a next generation of OGC services ("NextGen services") based on the approach taken by WFS 3.0.
Section 8 provides recommendations for the most appropriate way to support the use cases within the NextGen service architecture.
5. Use cases
5.1. Introduction
This section will document real-world use cases and requirements that more advanced feature servers should support in the future, besides the essential capabilities specified in Part 1 of the WFS 3.0 series.
All query examples are used in practice, either as queries submitted by a client, in stored queries of a WFS or in Styled Layer Descriptor (SLD)/Symbology Encoding (SE) documents defining layers based on feature data.
The use cases cover aspects like CityGML, CityGML Application Domain Extensions (ADEs), 3DPS, and WFS 2.0 interactions, but use other complex data schemas, too.
We identify for each use case example why the example has been included in this report. There is at least one example for each of the following aspects:
-
Querying features based on properties of related or nested objects or structured data types (one level)
-
Querying features based on properties of related or nested objects or structured data types (several levels)
-
Querying features based on expressions built from complex predicates consisting of predicate groups and combinations of logical operators
-
Querying feature data and returning only parts of the features (selected properties, a single property only, etc.)
-
Querying feature data and returning additional features linked to the selected features
-
Access to and query of solid geometries and other geometries in a 3D CRS
-
Use of responses for display in a web browser
-
Accessing different versions (including historic representations) of features
5.2. Managing and using a Cadastral dataset
5.2.1. Description
The dataset used in this section is about cadastral parcels and related information. It is using the AFIS-ALKIS-ATKIS application schema of the Surveying Authorities in Germany. The GML application schema is the so-called "Standards-based Data Exchange Interface" (NAS).
The application schema is optimized for maintaining the data by the Surveying Authorities and reflects the legal requirements. As a result, the application schema contains many relationships between feature types as well as structured data types. The application schema includes information related to portrayal of the data at map scales that are traditionally used for base maps, too. For example, information is included about text placement in specific maps.
Since cadastral law permits arcs in a boundary of a cadastral parcel, Simple Feature geometries are not sufficient for storing the authoritative feature data.
Outside of the Surveying Authorities the data is often simplified / flattened to simplify the use of the data, but a number of workflows require the full use of the complex data structures included in the dataset.
As the application schema is used in Germany, it uses German terms. For better readability we show a simplified schema using English translation for each query described in this section.
5.2.2. Selection of protected sites
This is a relatively simple use case where features are selected based on properties of related features, i.e. features that are the value of an association role property.
The following aspects are covered by this use case:
-
Querying features based on properties of related or nested objects or structured data types (one level)
-
Querying feature data and returning additional features linked to the selected features
Data
The queries use the following feature types:
- ProtectedSite_Water (AX_SchutzgebietNachWasserrecht)
-
A protected site based on laws pertaining to water and waterways. It consists of one or more zones.
- ProtectedZone (AX_Schutzzone)
-
An area in a protected site with a homogeneous classification.
Query 1: Select just the protected site features
The following WFS query selects all ProtectedSite_Water (AX_SchutzgebietNachWasserrecht)
features that have a protected zone in a given bounding box using a value reference
contains/ProtectedZone/position (adv:bestehtAus/adv:AX_Schutzzone/adv:position).
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_SchutzgebietNachWasserrecht&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Intersects>
<fes:ValueReference>
adv:bestehtAus/adv:AX_Schutzzone/adv:position
</fes:ValueReference>
<gml:Envelope
srsName="http://www.opengis.net/def/crs/epsg/0/25832">
<gml:lowerCorner>360000 5600000</gml:lowerCorner>
<gml:upperCorner>370000 5700000</gml:upperCorner>
</gml:Envelope>
</fes:Intersects>
</fes:Filter>The result is a feature collection with four ProtectedSite_Water (AX_SchutzgebietNachWasserrecht) features.
Query 2: Select also the related protected zone features
The following WFS query selects not only the ProtectedSite_Water (AX_SchutzgebietNachWasserrecht)
features that have a protected zone in a given bounding box, but uses the
WFS resolve and resolvedepth parameters to retrieve all the zone features in the same query.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_SchutzgebietNachWasserrecht&
resolve=local&
resolvedepth=1&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Intersects>
<fes:ValueReference>
adv:bestehtAus/adv:AX_Schutzzone/adv:position
</fes:ValueReference>
<gml:Envelope
srsName="http://www.opengis.net/def/crs/epsg/0/25832">
<gml:lowerCorner>360000 5600000</gml:lowerCorner>
<gml:upperCorner>370000 5700000</gml:upperCorner>
</gml:Envelope>
</fes:Intersects>
</fes:Filter>The result is a feature collection with four ProtectedSite_Water (AX_SchutzgebietNachWasserrecht) features and one ProtectedZone (AX_Schutzzone) feature in each site.
5.2.3. Select the owners of cadastral parcels in an area
This use case is similar to the previous one, but uses value references along multiple associations.
The following aspects are covered by this use case:
-
Querying features based on properties of related or nested objects or structured data types (several levels)
Data
The dataset is the same as in the previous use case.
The example query uses the following feature types. This is simplified, the actual schema and data is much more complex and reflects the legal requirements of the German land register.
- CadastralParcel (AX_Flurstueck)
-
A cadastral parcel.
- Record (multiple feature types)
-
An entry in the land register.
- Person (AX_Person)
-
A person that has some rights or responsibilities related to one or more parcels.
Query
The following WFS query selects all Person (AX_Person) features, that are
related to cadastral parcels in a bounding box, e.g. own the parcel or
have some rights. The filter uses a value reference along
multiple associations: partOf/Record/relatedTo/CadastralParcel/position
(the first value reference) or
partOf/Record/related/Record/relatedTo/CadastralParcel/position
(the second value reference).
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_Person&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Or>
<fes:Intersects>
<fes:ValueReference>
adv:weistAuf/adv:AX_Namensnummer/adv:istBestandteilVon/
adv:AX_Buchungsblatt/adv:bestehtAus/adv:AX_Buchungsstelle/
adv:grundstueckBestehtAus/adv:AX_Flurstueck/adv:position
</fes:ValueReference>
<gml:Envelope
srsName="http://www.opengis.net/def/crs/epsg/0/25832">
<gml:lowerCorner>361000 5610000</gml:lowerCorner>
<gml:upperCorner>362000 5620000</gml:upperCorner>
</gml:Envelope>
</fes:Intersects>
<fes:Intersects>
<fes:ValueReference>
adv:weistAuf/adv:AX_Namensnummer/adv:istBestandteilVon/
adv:AX_Buchungsblatt/adv:bestehtAus/adv:AX_Buchungsstelle/
adv:an/adv:AX_Buchungsstelle/adv:grundstueckBestehtAus/
adv:AX_Flurstueck/adv:position
</fes:ValueReference>
<gml:Envelope
srsName="http://www.opengis.net/def/crs/epsg/0/25832">
<gml:lowerCorner>361000 5610000</gml:lowerCorner>
<gml:upperCorner>362000 5620000</gml:upperCorner>
</gml:Envelope>
</fes:Intersects>
</fes:Or>
</fes:Filter>The result is a feature collection with the person features matching the query.
Due to privacy regulations, the land register data is not open data and no live query link can be provided.
5.2.4. Select versions of cadastral parcels based on their temporal validity
Often, the history of a dataset is important. The example that we are using here is a cadastral parcel dataset, where it can be important to know the state of the parcels at a point in the past.
There are two options for how this is typically handled in application schemas.
One approach is that the features are in fact feature versions. That is, different versions of the same feature / real-world entity are each represented as separate features. This is the approach we are considering in this use case. To avoid confusion we use the terms "version" and "real-world entity" in the description of this use case instead of "feature" which could mean the feature or a specific version of the feature.
The advantage of this approach is that no specific temporal support is required in clients processing the data. This pattern is therefore frequently used with data that is used in map-based GIS clients, for example, with dataset provided by mapping or cadastral agencies.
The other approach is to model the feature properties as timestamped sequences of values. GML supports this approach with the Dynamic Features pattern. The downside of this approach is that clients and servers must support this specific pattern, which typically requires customized software. A domain that is using this approach is the aviation domain.
The following aspects are covered by this use case:
-
Accessing different versions (including historic representations) of features
Data
The dataset is the same as in the first use case.
As described above, the features in the application schema are versions of a real-world entity, valid for a given time period.
All versions of the same real-world entity have the same gml:identifier.
If multiple versions occur in the same GML document, a timestamp will be added
to the gml:id attribute, otherwise the identifier of the real-world entity
will be used.
Each version has information about the lifespan of the version at hand. i.e., each version has a timestamp when this version has been added to the dataset. If the version is still valid, there is no timestamp for the end of the version validity. If the version (or the real-world entity) is no longer valid in the dataset, a timestamp for the end is added.
Each timestamp is given in Coordinated Universal Time (UTC), the granularity is seconds.
If a new version is added due to a change in a property, the new version will have a start timestamp that is one second after the end timestamp of the previous version.
The example query uses the following feature type. The actual schema and data is more complex and has been simplified to the relevant aspects for this use case.
- CadastralParcel (AX_Flurstueck)
-
A cadastral parcel.
Query
The following WFS query selects all CadastralParcel (AX_Flurstueck) versions that have been inserted into the dataset on July 1st, 2017.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_Flurstueck&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:During>
<fes:ValueReference>
adv:lebenszeitintervall/adv:AA_Lebenszeitintervall/adv:beginnt
</fes:ValueReference>
<gml:TimePeriod gml:id="TP1">
<gml:begin>
<gml:TimeInstant gml:id="TI1">
<gml:timePosition>2017-07-01T00:00:00Z</gml:timePosition>
</gml:TimeInstant>
</gml:begin>
<gml:end>
<gml:TimeInstant gml:id="TI2">
<gml:timePosition>2017-07-01T23:59:59Z</gml:timePosition>
</gml:TimeInstant>
</gml:end>
</gml:TimePeriod>
</fes:During>
</fes:Filter>The result is a feature collection with eight CadastralParcel (AX_Flurstueck) features.
Note that the dataset accessible via the WFS only includes valid versions, because WFS 2.0 does not include a simple mechanism to handle versions in queries and most users, especially those using a map-based GIS client, would be surprised to receive multiple features from the WFS representing the same real-world entity. All of those versions would be drawn on a map at the same time.
There is an opportunity with WFS 3.0 to support datasets with versions natively.
See also the related discussion in the W3C/OGC Spatial Data on the Web Best Practice document.
5.2.5. Select cadastral parcels for rendering with a specific style
A common requirement is to present features in a dataset on a map (or in a 3D scene). In this use case we look at rendering feature data on a 2D map, for display in a web browser.
This may be implemented using a WFS 2.0 as the backend, i.e. the rendering engine is a WFS client and then renders the data, either directly in the browser or in a server, for example, a WMS 1.3.
For server-side rendering, the data will typically be rendered closer to the database and not via a WFS 2.0 interface - for performance reasons. For client-side rendering, the data will typically not use GML, but a format that is optimized for the rendering purpose. Nevertheless, the use case is still relevant in the context of complex feature handling, for at least two reasons:
-
Style information in the OGC standards baseline uses Symbology Encoding and the feature selection mechanisms are the same as in WFS 2.0 - both use the Filter Encoding standard.
-
In this report, we are not limited to WFS only, but we want to consider other aspects that are relevant for spatial Web APIs, too. As NextGen services will have to be able to support API building blocks for providing maps, scenes, vector tiles, etc., the related query aspects need to be considered, too.
The following aspects are covered by this use case:
-
Querying features based on expressions built from complex predicates consisting of predicate groups and combinations of logical operators
-
Use of responses for display in a web browser
Data
The dataset is the same as in the first use case.
The example query uses the following feature types. The actual schema and data are more complex and have been simplified to the relevant aspects for this use case.
- CadastralParcel (AX_Flurstueck)
-
A cadastral parcel.
- Text (AP_PTO)
-
A map text for display on a map for a feature.
Query
Rich, standardized symbology rule sets exist for the cadastral datasets consisting of a large number of selection rules and feature styles.
We will use rules RUL06410 and RUL06420 from the ALKIS portrayal catalogue as an example. The rules select all cadastral parcels that meet the following criteria (for display of the parcel number on the map):
-
Parcels in a local district are identified using a numerator ("Zähler") and an optional denominator ("Nenner"). The example rules only apply to parcels with a denominator. The value reference is
numerator(adv:flurstuecksnummer/adv:AX_Flurstuecksnummer/adv:nenner). -
In addition, all of the following conditions must be met:
-
Another organization other than the land register may be legally responsible for some parcels. This is indicated in a boolean attribute for an alternative legal status ("abweichenderRechtszustand"). The example rules only apply to parcels for which the attribute is either missing or
false. The value reference isaltLegalStatus(adv:abweichenderRechtszustand). -
The application schema includes special feature types to capture map placement information. A typical example is a Text object (AP_PTO), which may be used to provide a fixed location for a text on the map ("position") or to provide a different text ("schriftinhalt") than the default text derived from the properties of the real-world thing. An association exists between the cadastral parcel and the Text objects that contain information overriding the default portrayal on the map ("inversZu_dientZurDarstellungVon_AP_PTO"). Since a map may contain multiple texts for a feature, there is also a type property ("art") to distinguish different text types. The example rules only apply to parcels that have an associated Text object for displaying the parcel number on the map (type is "ZAE_NEN"). The value reference is
textOnMap/Text[type = 'ZAE_NEN'](adv:inversZu_dientZurDarstellungVon_AP_PTO/adv:AP_PTO[adv:art = 'ZAE_NEN']).
-
The difference between the two rules RUL06410 and RUL06420 is whether the
text on the map is taken from the numerator attribute of the cadastral parcel
feature or from the text attribute of the associated Text object.
The following WFS query selects all CadastralParcel (AX_Flurstueck)
features that are rendered using the example portrayal rules. The <fes:Filter>
part would be the same in a portrayal rule according to the Symbology Encoding
standard as used in a WMS/SLD.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_Flurstueck&
filter=
<fes:Filter xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:And>
<fes:Not>
<fes:PropertyIsNull>
<fes:ValueReference>
adv:flurstuecksnummer/adv:AX_Flurstuecksnummer/adv:nenner
</fes:ValueReference>
</fes:PropertyIsNull>
</fes:Not>
<fes:And>
<fes:Or>
<fes:PropertyIsNull>
<fes:ValueReference>
adv:abweichenderRechtszustand
</fes:ValueReference>
</fes:PropertyIsNull>
<fes:PropertyIsEqualTo>
<fes:ValueReference>
adv:abweichenderRechtszustand
</fes:ValueReference>
<fes:Literal>false</fes:Literal>
</fes:PropertyIsEqualTo>
</fes:Or>
<fes:Not>
<fes:PropertyIsNull>
<fes:ValueReference>
adv:inversZu_dientZurDarstellungVon_AP_PTO/adv:AP_PTO[adv:art = 'ZAE_NEN']
</fes:ValueReference>
</fes:PropertyIsNull>
</fes:Not>
</fes:And>
</fes:And>
</fes:Filter>The result is a feature collection with more than 234,000 CadastralParcel (AX_Flurstueck) features.
5.2.6. Selection of building parts of a building
This use case has been added to include a query that - while not overly complex - cannot be executed with most WFS implementations as it would require support for spatial joins.
Including this use case does not imply that WFS 3.0 should include an extension that supports such a query. However, as spatial relations are an important aspect of spatial data, we should at least include it in our considerations, even if we recommend to include explicit spatial relations in the feature representations, consistent with the recommendations of the W3C/OGC Spatial Data on the Web Best Practice document.
Data
The AFIS-ALKIS-ATKIS application schema distinguishes between buildings and building parts, where a building part is a part of a building with different characteristics, for example, a different number of floors. The two-dimensional (2D) footprint geometry of a building part is within the footprint geometry of the building.
|
Note
|
The CityGML Building and BuildingPart features were originally modelled after the cadastral model in Germany. |
As the AFIS-ALKIS-ATKIS application schema is designed for maintaining the cadastral datasets, they do not contain a (redundant) association to identify the building parts within a build (as the relationship can be determined from the footprint geometries).
The queries use the following feature types:
- Building (AX_Gebaeude)
-
A permanent construction that must be recorded due its significance for the cadastre.
- BuildingPart (AX_Bauteil)
-
A part of a Building with distinct or special characteristics.
Query
Two subsequent queries are required.
The first query retrieves the building using its identifier (DENW45AL0000lxrJ)
in order to determine the footprint geometry of the building.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
resourceId=DENW45AL0000lxrJThe geometry can now be used to retrieve all building parts of that building.
https://www.wfs.nrw.de/geobasis/wfs_nw_alkis_aaa-modell-basiert?
service=WFS&
version=2.0.0&
request=GetFeature&
namespaces=xmlns(adv,http://www.adv-online.de/namespaces/adv/gid/6.0)&
typenames=adv:AX_Bauteil&
filter=
<fes:Filter
xmlns:adv="http://www.adv-online.de/namespaces/adv/gid/6.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Intersects>
<fes:ValueReference>
adv:position
</fes:ValueReference>
<gml:Polygon gml:id="o31001.id.29956334.position.Geom_0" srsName="urn:ogc:def:crs:EPSG::25832">
<gml:exterior>
<gml:LinearRing>
<gml:posList>
377034.58 5658143.873 377036.274 5658136.338 377036.438 5658135.613
377038.889 5658136.168 377039.429 5658136.291 377043.42 5658137.194
377043.262 5658137.895 377041.564 5658145.455 377041.193 5658145.371
377038.311 5658144.715 377034.58 5658143.873
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</fes:Intersects>
</fes:Filter>The result is a feature collection with two BuildingPart (AX_Bauteil) features.
5.3. Building heating demand simulation and visualization
5.3.1. Description
This section is about using 3D city models to simulate a building’s heating demand and visualize the results in a web-based 3D scene. Why is this relevant? The building sector has large potential for energy efficiency gains and CO2-reductions and is thus a priority area for achieving the ambitious climate and energy targets for 2020 and 2050 in the European Union [2]. In order to reach the 2% energy refurbishment rate promoted by the European Union and to realize long-term climate neutral communities, information about the current and future demand is necessary in order to develop strategies for policy making as well as to raise awareness of the citizens. Some pioneering work has already been done worldwide [3], [4], [5], [6]. As an input for the simulation, a building model in CityGML is usually used. The use case is split into several parts:
-
open a website to display a 3D map using 3D Portrayal Service and select a polygonal area / district
-
query 3D building geometry inside the polygonal area from a CityGML data store using WFS 3.0 as an input to the simulation
-
using 3D Portrayal Service and WFS 3.0 to query the simulation result and visualize it in a 3D scene by building Id, by address, and by polygonal area
-
extend the use case to the INSPIRE 3D building module in addition to CityGML
The following aspects are covered:
-
Querying features based on properties of related or nested objects or structured data types (one level / several levels)
-
Querying feature data and returning only parts of the features (selected properties, a single property only, etc.)
-
Querying feature data and returning additional features linked to the selected features
-
Access to and query of solid geometries and other geometries in a 3D CRS
-
Use of responses for display in a web browser
5.3.2. Data
-
Open data 3D city model New York as used in Testbed-13 S3D performance. CityGML LoD 1/2 Building Model, no Textures http://www1.nyc.gov/site/doitt/initiatives/3d-building.page; heating demand simulation is available (monthly energy balance) for Manhattan as "as is" simulation (simulated with SimStadt Software, HFT Stuttgart).
-
Open data 3D model of Essen as used in the Energy and Location Pilot of the the Joint Research Centre (JRC) of the European Commission. CityGML LoD 1/2 Building Model, no Textures; heating demand simulation is available (monthly energy balance) as "as is" simulation, medium refurbishment scenario, advanced refurbishment scenario (simulated with SimStadt Software, HFT Stuttgart).
-
Open data 3D model of Essen, a test area converted from CityGML to INSPIRE building model using HALE Studio.
5.3.3. Open a webpage to display a 3D map using 3D Portrayal Service and select a polygonal area / district
This has been showcased and implemented in Testbed-13 [7]. The implementation is available and could be further used and extended in Testbed-14 with the New York data set. The experiment evaluated the complete flow of data from its originating CityGML format to a web-enabled visualization with Cesium via OGC’s 3D Portrayal Service (3DPS). This data flow included the conversion from the CityGML data format served by GeoRocket, to 3D Tiles dataset, and the import of the 3D Tiles dataset to the 3DPS Framework.
A public demonstration is available at: http://tb13.igd.fraunhofer.de:8080/Apps/Sandcastle/index.html?src=3DPS_r.html&label=Showcases.
The following aspects are covered by this use case:
-
Use of responses for display in a web browser (3DPS getScene Region query)
Query
A 3DPS getScene request example from the New York showcase:
|
Caution
|
The link appears to be broken. |
In the existing implementation, 3D Tiles is used as content delivery format. See OGC Testbed-13 – 3D Tiles and I3S Interoperability and Performance Engineering Report [7], experiment 2 for further details.
5.3.4. Using 3D Portrayal Service and WFS to query the simulation result and visualize it in a 3D scene by building Id
In Testbed-13, the 3DPS getFeatureInfo request has been used to query heating demand (simulation result) per building from a server at HFT Stuttgart. See video on the Testbed-13 S3D Performance Experiment #2.
It would make sense to use the building id to retrieve additional attributes from a WFS. However, the building geometry is no longer required because as it is already available.
The following aspects are covered by this use case:
-
Use of responses for display in a web browser (3DPS getScene Region query)
-
Querying feature data and returning only parts of the features (selected properties, a single property only, etc.)
Query
A 3DPS getFeatureInfo request example from the New York showcase:
As this is requesting feature properties, such a request could also be directed
to a WFS 2.0 with the building model. The building would be selected based on its
identifier using the resourceId parameter. The property parameter could be
used to select only the desired properties (in the example below: the building
function, the measured height and heat information); properties that are not
needed, for example, the geometry, would be excluded from the response.
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
resourceId=uuid_2824afd6-00e5-42ac-ab95-ec868595dc5a&
propertyName=function,measuredHeight,heatWFS 3.0 should include an extension that supports such a capability, too.
5.3.5. Query a feature from a city model by id
Most important in this use case is that solids are supported as feature geometries.
In addition, it needs to be discussed how to deal with the Level of Detail (LoD) concept of CityGML. The CityGML model that is retrieved will typically be used by another process - in our example the simulation of the heating demand of that building.
Query
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
resourceId=TWINHOUSE1In WFS 3.0, the building would be identified by a URI, for example, http://www.example.com/my-city-model/collections/buildings/items/TWINHOUSE1.
As mentioned above, the most important aspect in this query is that the WFS supports solid geometries and is able to return features with such geometries.
A WFS 2.0 would return the building feature in a wfs:FeatureCollection.
<wfs:FeatureCollection xmlns:xAL="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" xmlns:gml="http://www.opengis.net/gml" xmlns:bldg="http://www.opengis.net/citygml/building/2.0" xmlns:wfs="http://www.opengis.net/wfs/2.0" xmlns:gen="http://www.opengis.net/citygml/generics/2.0" xmlns:core="http://www.opengis.net/citygml/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/citygml/building/2.0 http://schemas.opengis.net/citygml/building/2.0/building.xsd http://www.opengis.net/wfs/2.0 http://schemas.opengis.net/wfs/2.0/wfs.xsd http://www.opengis.net/citygml/generics/2.0 http://schemas.opengis.net/citygml/generics/2.0/generics.xsd" timeStamp="2018-03-28T15:01:47" numberMatched="2" numberReturned="2">
<wfs:member>
<wfs:FeatureCollection timeStamp="2018-03-28T15:01:47" numberMatched="1" numberReturned="1">
<wfs:member>
<bldg:Building gml:id="TWINHOUSE1">
<gml:boundedBy>
<gml:Envelope srsName="crs:EPSG::31468" srsDimension="3">
<gml:lowerCorner>-8.0E-15 0.0 0.0</gml:lowerCorner>
<gml:upperCorner>10.04 10.04 6.4</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<core:creationDate>2018-03-20</core:creationDate>
<bldg:lod1Solid>
<gml:Solid gml:id="UUID_836b4b28-24d9-4e83-906a-98f4364d351f">
<gml:exterior>
<gml:CompositeSurface gml:id="UUID_2ac22267-11d4-48f0-b63d-c417228d1968">
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_e379198f-7e10-43e8-8737-851cece07579">
<gml:exterior>
<gml:LinearRing gml:id="UUID_e379198f-7e10-43e8-8737-851cece07579_0_">
<gml:posList srsDimension="3">2.0E-15 10.04 0.0 4.0E-15 10.04 1.0E-13 -0.0 0.0 0.0 2.0E-15 10.04 0.0</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_0e264d5e-3034-43fc-b65f-2b231ef5907b">
<gml:exterior>
<gml:LinearRing gml:id="UUID_0e264d5e-3034-43fc-b65f-2b231ef5907b_0_">
<gml:posList srsDimension="3">4.0E-15 10.04 1.0E-13 4.0E-15 0.0 1.0E-13 -0.0 0.0 0.0 4.0E-15 10.04 1.0E-13</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_c8dbcf60-8f0e-43f1-a1ef-ed43620dbfb1">
<gml:exterior>
<gml:LinearRing gml:id="UUID_c8dbcf60-8f0e-43f1-a1ef-ed43620dbfb1_0_">
<gml:posList srsDimension="3">4.0E-15 10.04 1.0E-13 10.04 10.04 0.0 10.04 0.0 0.0 4.0E-15 0.0 1.0E-13 4.0E-15 10.04 1.0E-13</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_22c99934-a675-4b42-97af-f73874d1aabb">
<gml:exterior>
<gml:LinearRing gml:id="UUID_22c99934-a675-4b42-97af-f73874d1aabb_0_">
<gml:posList srsDimension="3">10.04 0.0 6.4 10.04 0.0 0.0 10.04 10.04 0.0 10.04 10.04 6.4 10.04 0.0 6.4</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_13db3bd0-6210-414c-b884-3bd2099c9680">
<gml:exterior>
<gml:LinearRing gml:id="UUID_13db3bd0-6210-414c-b884-3bd2099c9680_0_">
<gml:posList srsDimension="3">10.04 10.04 6.4 10.04 10.04 0.0 4.0E-15 10.04 1.0E-13 2.0E-15 10.04 0.0 -8.0E-15 10.04 6.39999999999999 10.04 10.04 6.4</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_024dfb16-831c-4404-9c94-cdda06aaca86">
<gml:exterior>
<gml:LinearRing gml:id="UUID_024dfb16-831c-4404-9c94-cdda06aaca86_0_">
<gml:posList srsDimension="3">2.0E-15 10.04 0.0 -0.0 0.0 0.0 -8.0E-15 10.04 6.39999999999999 2.0E-15 10.04 0.0</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_a9f8e079-5033-49ed-851a-aae7f9454dd8">
<gml:exterior>
<gml:LinearRing gml:id="UUID_a9f8e079-5033-49ed-851a-aae7f9454dd8_0_">
<gml:posList srsDimension="3">-8.0E-15 10.04 6.39999999999999 -0.0 0.0 0.0 -8.0E-15 0.0 6.39999999999999 -8.0E-15 10.04 6.39999999999999</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_a6d3c8c7-ace0-4e48-b8c1-ca18cd5a814d">
<gml:exterior>
<gml:LinearRing gml:id="UUID_a6d3c8c7-ace0-4e48-b8c1-ca18cd5a814d_0_">
<gml:posList srsDimension="3">10.04 0.0 6.4 -8.0E-15 0.0 6.39999999999999 -0.0 0.0 0.0 4.0E-15 0.0 1.0E-13 10.04 0.0 0.0 10.04 0.0 6.4</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
<gml:surfaceMember>
<gml:Polygon gml:id="UUID_c1b51c00-2dbc-45d2-9c93-c9b396382780">
<gml:exterior>
<gml:LinearRing gml:id="UUID_c1b51c00-2dbc-45d2-9c93-c9b396382780_0_">
<gml:posList srsDimension="3">-8.0E-15 10.04 6.39999999999999 -8.0E-15 0.0 6.39999999999999 10.04 0.0 6.4 10.04 10.04 6.4 -8.0E-15 10.04 6.39999999999999</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
</gml:CompositeSurface>
</gml:exterior>
</gml:Solid>
</bldg:lod1Solid>
<bldg:lod1TerrainIntersection>
<gml:MultiCurve>
<gml:curveMember>
<gml:LineString>
<gml:posList srsDimension="3">10.04 0.0 0.0 10.04 10.04 0.0</gml:posList>
</gml:LineString>
</gml:curveMember>
<gml:curveMember>
<gml:LineString>
<gml:posList srsDimension="3">-0.0 0.0 0.0 10.04 0.0 0.0</gml:posList>
</gml:LineString>
</gml:curveMember>
<gml:curveMember>
<gml:LineString>
<gml:posList srsDimension="3">2.0E-15 10.04 0.0 -0.0 0.0 0.0</gml:posList>
</gml:LineString>
</gml:curveMember>
<gml:curveMember>
<gml:LineString>
<gml:posList srsDimension="3">2.0E-15 10.04 0.0 10.04 10.04 0.0</gml:posList>
</gml:LineString>
</gml:curveMember>
</gml:MultiCurve>
</bldg:lod1TerrainIntersection>
</bldg:Building>
</wfs:member>
</wfs:FeatureCollection>
</wfs:member>INSPIRE recommends the use of wfs:FeatureCollection, too, but if the data
is not accessed via a WFS other feature collections may be used as well.
CityGML itself also includes a feature collection element, core:CityModel,
that may be used, if the service interface is not a WFS 2.0.
<core:CityModel xmlns:smil20="http://www.w3.org/2001/SMIL20/" xmlns:grp="http://www.opengis.net/citygml/cityobjectgroup/1.0" xmlns:smil20lang="http://www.w3.org/2001/SMIL20/Language" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:base="http://www.citygml.org/citygml/profiles/base/1.0" xmlns:luse="http://www.opengis.net/citygml/landuse/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:frn="http://www.opengis.net/citygml/cityfurniture/1.0" xmlns:dem="http://www.opengis.net/citygml/relief/1.0" xmlns:tran="http://www.opengis.net/citygml/transportation/1.0" xmlns:wtr="http://www.opengis.net/citygml/waterbody/1.0" xmlns:tex="http://www.opengis.net/citygml/texturedsurface/1.0" xmlns:core="http://www.opengis.net/citygml/1.0" xmlns:xAL="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0" xmlns:bldg="http://www.opengis.net/citygml/building/1.0" xmlns:sch="http://www.ascc.net/xml/schematron" xmlns:app="http://www.opengis.net/citygml/appearance/1.0" xmlns:veg="http://www.opengis.net/citygml/vegetation/1.0" xmlns:gml="http://www.opengis.net/gml" xmlns:gen="http://www.opengis.net/citygml/generics/1.0">
<core:cityObjectMember>
<bldg:Building gml:id="TWINHOUSE1">
...
</bldg:Building>
</core:cityObjectMember>
</core:CityModel>In WFS 3.0 the response will be determined by the encoding and the requirements of the conformance class for that encoding.
None of the WFS 3.0 Core conformance classes for encodings supports solid geometries.
However, for responses that are CityGML 2.0, the same wfs30:FeatureCollection
element could be used that is also used in the WFS 3.0 conformance classes for the GML Simple Feature encodings.
Another option could be a WFS 3.0 that returns CityJSON.
5.3.6. Select buildings in a 2D region from a city model
In this example, all buildings in a rectangular region are requested and the selected building features are returned in a feature collection.
Query
Here is an example of a WFS 2.0 query:
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
BBOX=-74,40.7,-73.96,40.8Using an instance of GeoRocket containing the New York City CityGML model developed in Testbed-13 the request could also be:
This link points to a live service, but returns a large response. A more manageable response can be retrieved with a smaller bounding box.
In WFS 3.0, the request is also supported by the query capabilities of the Core, for example:
5.3.7. Select buildings based on nested features or properties
These examples have been provided by Claus Nagel, virtualcitySYSTEMS. They cover the following query categories:
-
Querying features based on properties of related or nested objects or structured data types (several levels)
-
Access to and query of solid geometries and other geometries in a 3D CRS
Query 1: Select buildings based on their ground surface geometry
This query retrieves all buildings having one or more ground surfaces whose
LoD 2 geometry intersects with a given geometry. bldg:GroundSurface is a nested feature.
In this example, the query geometry is a multi-surface with 3D coordinate values.
https://www.example.com/wfs?
service=WFS&
version=2.0.2&
request=GetFeature&
namespaces=xmlns(bldg,http://www.opengis.net/citygml/building/2.0)&
typenames=bldg:Building&
filter=
<fes:Filter
xmlns:bldg="http://www.opengis.net/citygml/building/2.0"
xmlns:gml="http://www.opengis.net/gml/3.2"
xmlns:fes="http://www.opengis.net/fes/2.0">
<fes:Intersects>
<fes:ValueReference>
bldg:boundedBy/bldg:GroundSurface/bldg:lod2MultiSurface
</fes:ValueReference>
<gml:MultiSurface srsName="http://www.opengis.net/def/crs/EPSG/0/?????">
<gml:surfaceMember>
<gml:Polygon>
<gml:exterior>
<gml:LinearRing>
<gml:posList>
21498.400088101323 17386.16611967112 31.123
<!-- ... -->
</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
</gml:MultiSurface>
</fes:Intersects>
</fes:Filter>The result is shown as an image as the Extensible Markup Language (XML) response itself is too verbose to show, and is not open data.