support for transactions about pygeoapi

[tomkralidis]

Makes sense. I imagine that functionality will be provider specific/dependent and that our provider base class would throw NotImplementedError by default.

[jachym]

About the POST /item[s]/[uuid]

It IMHO should return 404, since the endpoint does not exist yet. I have nothing against having required [uu]id in the body of the request

[justb4]

POST /collections/{collectionID}/items with a body of Item or even FeatureCollection (have seen latter somewhere, MapFish API?). Item already has an id-field (cannot find back if id is indeed mandatory, seems not in OAPIF. "id is a local identifier of the feature" and ... that strictly only the URI needs to be unique.

Some sources indicate that PUT should be used to add (if Entity not exists) or replace (if exists) a specific Entity (in our case Item):
https://restfulapi.net/rest-put-vs-post/

So

POST /collections/{collectionID}/items [obj]

Adds (new) Item (Feature) to the collection.

and

PUT  /collections/{collectionID}/items/{featureId} [obj]

would add or replace an Item with specific URI (id?).

Update: saw a more recent link to the Stac spec in Gitter from @cholmes, the above aligns with this:
https://github.com/radiantearth/stac-spec/tree/master/api-spec/extensions/transaction

[jachym]

Create feature

POST /items/ [obj]

ID should not be forced while feature creation?

ID should be returned

[justb4]

My $2ct: The "id thing" requires some thinking-through: it needs to be unique within a Collection on one hand, so IMHO cannot be enforced on the client (think of multiple clients POST/PUTing at the same time), unless maybe with UUIDs. WFS2 had an idgen option, remember? "The idgen attribute control how a WFS generates identifiers from newly created feature instances using the Insert action. The default action is to have the WFS generate a new id for the features. This is also backward compatible with WFS 1.0 where the only action was for the WFS to generate an new id. Don't know if we need this flexibility/complexity, just wanted to mention.
A use case for client-supplied id's are e.g. Cadastral Parcel id's (or INSPIRE-ids brr). Or in SensorWeb: station-ids.

Another example: With SensorThings API Transactions, when POSTing a Thing, the server always generates a unique id (within the Things Collection), but at same time allows a client to set a client-unique field, e.g. a station id within a free-form properties hashmap. So a client can always find back its Things (this was a severe limitation in SOS). Best of both worlds but then again STA has a fixed abstract entity model like an appschema.

[justb4]

btw The STAC Pilot Transaction spec (to which OAPIF refers, see above) is IMHO not really clear on this: one POSTs an Item to a Collection and probably if the Item contains an id it is validated for uniqueness and used, otherwise generated (?), but id is mandatory in Item (?). That could be a simple solution without idgen...

[francbartoli]

@justb4 I would also consider PATCH to change only a feature property:

PATCH /collections/{collectionID}/items/{featureId} [obj]

would change the field value of an item, it could also be the geometry

[justb4]

@francbartoli thanks, yes PATCH for partial updates (except for id itself IMHO) should be considered.

[francbartoli]

Sure @justb4, except the feature identifier

[tomkralidis]

Note: transactions draft now at http://docs.opengeospatial.org/DRAFTS/20-002.html

[francbartoli]

Thanks @tomkralidis, very good reference to follow for the implementation

[p1d1d1]

What is the status here?

[tomkralidis]

For now, we continue to monitor the OGC draft for developments, contributions against are welcome.

[tomkralidis]

Implemented in #984