Transaction API specification

[dr-jts]

OGC API does not yet define transactions semantics.

• OGC has notes on possible implementation
• STAC has a proposal here.
• For some issues see this pygeoapi issue

[fredmorin]

Part-4 draft is looking good.

It may tike a little time before it is adopted but it should not change much according to comments in this issue. https://github.com/opengeospatial/ogcapi-features/issues/366

I would love to see a pg_featureserv implementation. starting with create-replace-delete requirement class.

ideally, this implementation should not introduce new dependencies and rely on postgres/postgis to take care of everything. It must stay aligned with the philosophy behind pg_featureaerv documented here: https://access.crunchydata.com/documentation/pg_featureserv/1.2.0/introduction/

[fredmorin]

Here is my attempt at fixing this issue https://github.com/CrunchyData/pg_featureserv/pull/152 https://github.com/CrunchyData/pg_featureserv/pull/153

[fredmorin]

I am analyzing how to implement optimistic locking.

ETags is fairly easy to implement using an MD5 hash for the feature.

Implemening Last-Modified require enabling track_commit_timestamp on the database and querying pg_xact_commit_timestamp(xmin) for one feature.

The specification mentions "A requirements class is specified for each field, because the two options have different characteristics and API providers need to decide which option they can support."

I believe ETags is they ideal choice for pg_featureserv.