Future work items (Part 6++)

[cportele]

The current work items of the OGC Features API working group are progressing well. At the same time there are questions or requests for additional capabilities. Since the OGC processes take time to get approval for the working group to work on new topics, it is time to identify and prepare the topics that should be addressed next. This issue is intended to discuss, identify and agree on the most important additional capabilities that we should work on next.

We need to present the identified topics to the OGC members to start the process, typically in a plenary (the next one would be in early December).

As a reminder, here is what the group charter says:

Standards are important for interoperability. At the same time, it is important that standards only state requirements that are important for a significantly large group of users. Proposals for new parts of OGC API Features or change requests to existing parts must identify the user group that will benefit from the proposal and include the commitment for three independent implementations for each proposed conformance class; otherwise the proposal will be considered out-of-scope.

In addition, we of course need to have at least one editor for each proposal to edit the document and drive the process.

Proposals for new tasks will only be considered, if these criteria are met.

Many extensions may be useful beyond Features and we should ask for input from members of the other OGC API working groups, too.

[cportele]

To start the discussion, here is a list of topics that I have seen requested most over the last months:

• Schemas: We have identified three different types of schemas for the features of a feature collection that we need and need to describe in a consistent way (at least in cases where the dataset has a schema) - the queryable properties of the features that may be used in filter expressions, the returnable properties included in feature representations retrieved from the API and the storage properties that are processed in requests mutating a feature. We already need the queryables schema for part 3 (so that clients know, what they can filter on) and the storage schema for part 4 (so that clients know, what data they have to provide for new or updated features), but it really should be a separate document, at least eventually. The returnables schema is important for clients that depend on schemas (many GIS clients do), currently they have to guess a schema for a subset of the instance data.
• Property selection: One or more query parameters to reduce the properties that are returned for each feature. This has been requested frequently to reduce the data volume that has to be transferred. For example, dropping the geometry from polygon data where only a table needs to be presented to a user can dramatically reduce the size of the response and the response time.
• Geometry simplification: A query parameter to indicate a scale or zoom level at which the features will be displayed. The returned curve/surface/solid geometries will be simplified accordingly. The capability reduces the size of the response and the transmission time plus the client can directly use the geometry without additional processing.
• Queries: An additional Query resource (path element search) supporting GET and POST. /search will support multi-collection queries, /collections/{collectionId}/search queries on a single collection. This could also include support stored/persistent queries or such a capability may be a separate extension. Many use cases will require data from multiple collections of a dataset and the query resource will avoid the need for clients to submit multiple requests in such cases. Supporting POST will enable filter expressions with large geometries that are too big for a URI, be more natural for filter expressions in CQL JSON, and address security concerns (filter expressions are no longer included in the access logs of web servers.

I have a personal interest in these extensions and would offer to contribute to the drafting of them and commit to implementing them in ldproxy (in fact, the first three capabilities are more or less already implemented).

Other capabilities that have been requested and discussed:

• Asynchronous execution: Return a 202 status and send a notification (email, webhook, etc) to a response handler that has been specified in a request.
• Many collections: Support for filtering and paging on the Collections resource. I don't think we need to work on this as I expect that the Records SWG will work on this.
• Themes (collection hierarchies): A separate resource (e.g., /theme) to organize the collections into one or more hierarchies or themes.
• Transactions: Multiple feature mutations are executed in a transaction with ACID semantics.
• Sorting: Return features sorted according to search criteria provided in the request. Again, the Records SWG is working on this and we should be able to reuse it.
• Offsets: A query parameter to request features starting with the nth feature.
• JSON-LD: Include a JSON-LD context in the feature responses.
• Versioned data: Support datasets where features change and multiple versions of the feature exist over time.
• HEAD: Require support for HEAD for all resources.
• CRS descriptions: In addition to CRS support by reference, also support CRSs provided by the client as WKT or PROJJSON.

I am sure, I have missed some of the extensions that we have discussed.

[pvretano]

@cportele my priority list would be: schemas, queries, property selection and geometry simplification from the first group. I would add OPTIONS to the second group.

[cholmes]

Has there been any progress on a lighterweight extension mechanism? Like just markdown/redoc description and an openapi fragment? Like where we can 'incubate' some of these, and have the community evolve them?

I'm working to align STAC API with Features, including extensions. And it'd be really nice to put our extensions somewhere with more visibility to features api implementors, and allow us to reference them externally. The leading ones we have are:

• fields - our version of Property Selection
• sort - happy to align with records, but haven't seen anything concrete.
• version - simply versioning semantics

And POST searches are important for us, though we don't do them as an 'extension' but part of our core, but could align to an extension.

We also have context for matched/limit/returned as its own object which seems to make more sense than just having those fields scattered in the response. It's the one change we'd actually like OGC to make - everything else we are just adopting the way OGC things (including ones still in draft) But we were told it needs to go in common, and now it's just hanging out there: https://github.com/opengeospatial/oapi_common/issues/82

The other one I'd add to the list is Aggregations - we have a draft PR on it https://github.com/radiantearth/stac-api-spec/issues/38 and an implementation (Astraea) in production.

[pvretano]

@cholmes Re: sort, see: https://htmlpreview.github.io/?https://github.com/opengeospatial/ogcapi-records/blob/master/20-004.html#core-query-parameters-sortby

[cholmes]

@pvretano - interesting. Any chance we can pull that out to be its own small building block extension that any features API can use? And then be able to iterate on it together?

Did you look at our sort? Would you consider our + / - notation instead of the :asc :desc? Also I couldn't figure out if yours had a default sort order? (is this conversation better to have in the records issue tracker?)

[pvretano]

@cholmes like many of the "building blocks" (e.g. CQL, CRS, transactions, etc.) created for OGC API they start life in one of the SWGs and if they are deemed to be generally useful, they will eventually move to OGC API Common; this will likely be the fate of sortBy but it is too early to say definitively right now. Certainly features could make use of this parameter ... Part B or requirement 14 states that the default sort order is ascending .

[cportele]

During the OGC Member Meeting we agreed to ask the OGC Technical Committee to add the following new tasks to the charter of the Features API SWG:

• Property Selection: One or more query parameters to reduce the properties that are returned for each feature.
• Geometry Simplification: A query parameter to indicate a scale or zoom level at which the features will be displayed. The returned curve/surface/solid geometries will be simplified accordingly.
• Schemas: Consolidate the requirements for schema resources (queryable properties in Part 3, returnables/response schema needed for Property Selection, mutables/transaction schema needed for Part 4, sortable properties needed for sorting extension under discussion in Records) in its own document.
• Queries: An additional Query resource (path element "search") supporting GET and POST. /search will support multi-collection queries, /collections/{collectionId}/search queries on a single collection. This could also include support stored/persistent queries.

Some related issues that are currently labeled as "Future Work":

• Ability to set no null/empty geometry in returned response
• Features API needs a zoom parameter
• Lack of DescribeFeatureType request
• Dynamically fetching features from multiple collections in a single request
• Dynamically fetching features from more than one collection at a time
• WFS3 Search extension

The new tasks are now out for comments in the OGC Technical Committee.

To add a new task to our charter, we not only need the support from the OGC membership, but we also need a commitment for three independent implementations for every conformance class. Cubewerx and interactive instruments have made commitments to implement each of the proposed new specifications. That means, that we need at least one additional implementation commitment for each of the proposed new extensions, otherwise we cannot add the extension to our charter. So, if you have an interest in any of these new tasks, please consider a commitment to implement the new capability (either add a comment in this issue or contact @pvretano or me directly). Thanks in advance for your consideration.

[cportele]

The OGC Technical Committee has approved the proposed four new tasks (Property Selection, Geometry Simplification, Schemas, Queries/Search). The charter document has been updated. There are initial proposals to start the discussion in the proposals folder. We will start the discussion in the Features API SWG meeting during the OGC member meeting tomorrow.

Before we assign a new part number to a new task and start to work on a new document, we need three implementations commitments. I will create issues for each part where we can record those commitments.

[maxcollombin]

Hello everyone,

I would find it interesting to propose a "Versioned data" (as cited in the current issue) or "incremental dataset request" extension in which the requirements classes of:

• Checkpoint identifier as mentioned in OGC Testbed-11 Multiple WFS-T Interoperability report
• Changeset as mentioned in Testbed-12 Web Feature Service Synchronization

could be defined.

The timing seems particularly interesting to me with the current RFI on the Open Science Persistent Demonstrator, the STAC Versioning Indicators Extension Specification as mentionned by @cholmes and the publication of the draft OGC API - Features - Part 4: Create, Replace, Update and Delete as mentioned by @cportele in the issue #764

I would also be happy to help

[cportele]

Meeting 2024-04-22: Next steps are to convert the following proposals to AsciiDoc:

• Part 6: Property Selection (from proposal) - @cportele
• Part 7: Geometry Simplification (from proposal) - @cportele
• Part 8: Sorting (from Records) - @pvretano
• Part 9: Text Search (from Records) - @pvretano
• Add query-by-ids (from Records/proposal) to Part 1: Core - @pvretano
• Add OpenAPI 3.1 requirements class to Part 1: Core - @cportele

Part 10: Search/Queries will follow once these simpler extensions have been initiated.