opengeospatial
Create/Replace/Update/Delete extension available for review
Dear Colleagues,
The purpose of this message is to announce that preliminary drafts of the following documents are now available on github:
OGC API - Features - Part 4: Simple Transactions (http://docs.opengeospatial.org/DRAFTS/20-002.html)
The Simple Transaction extension defines how to insert, update (modify or replace) and delete single instances of features from a single collection. It uses the POST, PUT, PATCH and DELETE methods of HTTP. It also specifies JSON and XML payloads that allow parts of features to be modified via the PATCH method. More complex atomic or batch transactions will be defined in a subsequent part of the OGC API Features set of standards.
The OGC API - Feature SWG is requesting that interested parties review the document, provide feedback via the github issue tracker and most importantly implement!
Thanks you for your consideration.
Ciao.
Meeting 2020-07-06: More implementations needed before moving forward, a candidate for an OGC Sprint. Needs to be tested in combination with (multiple) security schemes.
@pvretano will try to get in contact with implementers and check plans for the transaction implementation.
2020-07-20: This part will be tested in the Sprint at the end of September. The SWG looks for feedback from implementations of the draft. We can distinguish two aspects where the SWG is looking for feedback for part 4: a) the pure HTTP method aspects and ab) the API level security aspects.
Do I understand correctly that the CRUD operations are only defined for items? How would I create a new collection or change/delete an existing collection?
@m-mohr that would be another extension ... the data definition extension ... our server supports this (actually did since WFS 2.x) but the extension for OGC API is out for scope for the SWG right now. That would require a charter update which we just completed for the next set of work items that includes the search extension, the geometry simplification extension, the property selection extension and the schema stuff.
Thanks, @pvretano. Are you aware of any WG that actually is going to define such an extension anytime soon? I guess the natural place would be Commons. (Same for collection-level search.)
Asking because I could see me writing a STAC API extension for both collection-level CRUD and search in the next year or so and would like to align with OGC APIs as much as possible.
@m-mohr - I am not aware of any group that has such an extension in their current charter (including Common).
@cportele common already supports bbox and datetime and OGC API - Records has the collections extension to make the /collections endpoint searchable. @m-mohr The data definition stuff is still just a todo item in my list. Might be a while before I have time to propose something. I am not aware of any WG that is chartered to work on that.
@pvretano - Yes, but the C/U/D operations for collections are not in any charter AFAIK.
@cportele correct. I am not aware of any WG that is working on C/U/D operations for collections either.
Thanks.
So then maybe the C/U/D operations for collections will evolve in openEO based on how they've been defined for items and be brought back from there to STAC and OGC APIs. Let's see...
Search: datetime/bbox are not enough in our use case, but maybe it's as simple as allowing CQL filter parameters and related things on the /collections endpoint. But that's clearly out of scope for this issue.
What's the status on this @pvretano? We are wondering when we can release the STAC API extension that is based on Part 4.
cc @philvarner
@m-mohr this will be after Filter/CQL2 for sure but now that Filter/CQL2 is coming to a conclusion, we will turn our attention to getting this one adopted. I think most of the technical contect is complete and solid. There is some tie in to the Schema stuff we are working on which may delay things a bit. I am not expecting adoption of this one till mid 2024 .... but take that with a grain of salt. I am notoriously bad at judging the time lines for these things. @cportele what's your view?
@m-mohr @pvretano - We have resolved most of the open issues, the main open issue is to draft the result of the discussion about schemas as Part 5: Schemas as there will be a dependency from Part 4 to Part 5 so we have to move both documents together through the process. I think the main open task is to write down Part 5, which should be largely an editorial task, but there are a few open topics for discussion. Again, I would hope that we can at least clarify these open topics no later than the London Code Sprint. If all goes well, we could be ready to submit the documents to the OAB for review around the end of the year. Once that review is done, the next step is the Public Review and we have to see what comments we get that need to be addressed. If all goes well, we should be able to start the approval process sometime in Q2/Q3 2024, I think.
Thanks. The timeline is too late for STAC, so we removed the official wording that our extension is based on OGC API - Features - Part 4, but it will still be very similar as it was based on an older draft.