Support for 3D, complex data structures, rich queries, data visualisation in a browser

[cportele]

An activity in OGC Testbed 14 is called "Complex Feature Handling". It looks at how the capabilities in the issue title could be implemented in WFS 3.0 extensions or other API building blocks outside of WFS 3.0, but in an "OGC Next Generation services" architecture that follows the approach taken by WFS 3.0.

Like the WFS 3.0 repository, all the work is done in a public repository. The result will be an OGC Engineering Report and that repository is the home of the report:

https://github.com/opengeospatial/D040-Complex_Feature_Handling_Engineering_Report

The latest draft of the report is always available here:

https://rawgit.com/opengeospatial/D040-Complex_Feature_Handling_Engineering_Report/master/18-021.html

This is work in progress. A release candidate of the report should be ready in October/November 2018. The idea is to develop recommendations for discussion within this group (working on WFS 3.0) and within OGC in general.

Comments are welcome as outlined in the readme of the report repository.

[cportele]

A draft of the Engineering Report is now available for review.

The document analyses how 3D and other complex data, queries on such data as well as visualization in a browser could be supported in the world of Web APIs and OpenAPI which are the basis for WFS 3.0.

So far, the work has mostly been discussed within OGC Testbed-14. Anyone interested in these topics is invited to provide feedback / additional ideas before we finalize the report. The preferred way is to submit comments as issues in the public GitHub repository. Or use the Gitter chat.

• GitHub: https://github.com/opengeospatial/D040-Complex_Feature_Handling_Engineering_Report/blob/master/README.md
• Gitter: https://gitter.im/opengeospatial/T14-ComplexFeatureHandling

The document will be finalised by mid-November and then be submitted to the OGC for discussion at the OGC Technical Committee meeting in December.

Here is a brief overview of the key sections of the draft report:

• Section 1 is the summary.
• Section 5 documents real-world use cases and requirements with references to implementations based on WFS 2.0, GML, CityGML, 3DPS, etc.
• Section 6 identifies requirements that would require more complex interactions than those supported by the current draft of the WFS 3.0 Core.
• Section 7 assesses current OGC standards and community standards how they could help. The list includes JSON-based encodings like GeoJSON or CityJSON as well as query/filter languages including WFS/FES 2.0, CQL, OpenSearch, GraphQL, Falcor or the search discussion in STAC. Additional resource types as they are used in WMTS or 3DPS are discussed, too.
• Section 8 summarizes the results by providing recommendations to OGC for future work and how to support the use cases in a "Next Generation" service/API architecture for spatial data.

[royrathbun]

Section 7.3.6 states 'Conclusion: Before any decision is made for WFS 3.0 query extensions, the plans should be discussed with the STAC community to check for additional opportunities to align the specifications.' However, there is no recommendation in Sect 8 for any efforts to align; should there be?:

[cportele]

@royrathbun - Recommendation 1 includes the STAC JSON approach as an option. That said, at this point I would not goes as far as recommending alignment. Yes, alignment would clearly be good, if the typical implementation context and scope are similar, but that I do not think it is a must.

In the discussions in March during the hackathon/sprints we discussed searching, too, and we agreed to "reserve" /search as a base path for queries as STAC was moving towards a JSON encoding for queries and predicates (under /search/stac). Whether this is something that can be reused as a general WFS query extension is clearly something to discuss with the STAC community before making a decision, but at this point I have no clear opinion if that would work or not. Hence the language in the first recommendation. If we can come to a clearer view in the next weeks I would be happy to update the language.

@cholmes @hgs-msmith Any views on this?

I think that supporting (a subset of) CQL would be relatively straightforward for some of the existing WFS 3.0 implementations and it is a language that is quite straightforward to use for the simpler cases.

Of course, it would also be possible to specify two extensions for "intermediate" queries and let implementations decide what their users need (Core is enough, CQL, STAC JSON search, or both).

[nmtoken]

Obviously not in scope for WFS 3.0, but what about WCS and WCPS as a means to query 3+D data, and create 2.5+D models in a web environment. For example as was done by the EarthServer project?

[cportele]

@nmtoken - We have not looked into coverages as this was/is not in scope of the work, so I cannot answer your question. However, there was a discussion about these topics at the last OGC TC meeting in Stuttgart in the Met Ocean DWG (link for OGC members).

PS: The work in Testbed-14 is not restricted to WFS 3.0, some of the API elements we discussed are not WFS 3.0 extensions, but other resources. An example are scenes as currently provided by 3DPS. However, the scope was restricted to resources created from 2D/3D "vector" features.

[nmtoken]

@cportele oops I realise I thought I was posting to another GitHub project that we both contribute too, not WFS 3.0, so my WCS comment is even less relevant here.