CrunchyData
OGC API Features - Part 4: Create Replace Delete
Part4 - Create, Replace, Delete
Related issue: https://github.com/CrunchyData/pg_featureserv/issues/4
Support for Part4 Create, Replace, Delete
Create feature
POST query to the path /collections/{collid}/items allows to create
a new feature in a feature collection.
The geojson feature must be part of the request body. If the geometry geometry crs is different from the storage crs, the geometry will be transformed. Missing properties will be ignored and the table default value for the column will be applied. The id specified in the body is ignored and the database default value is used to create the feature.
Example
curl -i --request "POST" 'http://localhost:9000/collections/public.tramway_stations/items' -d '{"type":"Feature","id":"129","geometry":{"type":"Point","coordinates":[-71.222868058,46.836016945,0]},"properties":{"description":null,"diffusion":"Publique","niveau_rstc":"Tramway","nom":"Hôpital Enfant-Jésus","objectid":129,"type_station":"Reguliere"}}'
Replace feature
PUT query to the path /collections/{collid}/items/{fid} allows to replace
a feature in a feature collection.
The geojson feature must be part of the request body. If the geometry geometry crs is different from the storage crs, the geometry will be transformed. Missing properties will be replaced with null (unless a database trigger is applied) The id specified in the body is ignored.
Example
curl -i --request "PUT" 'http://localhost:9000/collections/public.tramway_stations/items/129.json' -d '{"type":"Feature","id":"129","geometry":{"type":"Point","coordinates":[-71.222868058,46.836016945,0]},"properties":{"description":null,"diffusion":"Publique","niveau_rstc":"Tramway","nom":"Hôpital Enfant-Jésus","objectid":129,"type_station":"Reguliere"}}'
Delete feature
DELETE query to the path /collections/{collid}/items/{fid} allows to delete
a feature in a feature collection.
Example
curl -i --request "Delete" 'http://localhost:9000/collections/public.tramway_stations/items/129.json'
This needs a better title.
Have you looked at PR #127?
In particular, see this requirement about enabling update capabilites via a config setting.
This needs a better title.
Have you looked at PR #127?
In particular, see this requirement about enabling update capabilites via a config setting.
Yes, looked at the PR. It was openned 1 year ago, only supports create and introduces a dependency on github.com/paulmach/orb which does not support 3d geometries and add gml support. I analysed the changes and experimented with paulcharch/orb, yet decided to go another way.
As for configuration requirement to enable transactions, it is a valid observation. My understanding is that pg_featureserv phylosophy is to rely on the database to handle acces control. I think it goes beyond simple on/off, and requires configuration to enforce optimistic locking.
This needs a better title. Have you looked at PR #127? In particular, see this requirement about enabling update capabilites via a config setting.
Yes, looked at the PR. It was openned 1 year ago, only supports create and introduces a dependency on github.com/paulmach/orb which does not support 3d geometries and add gml support. I analysed the changes and experimented with paulcharch/orb, yet decided to go another way.
This does seem simpler. And fewer (or no) dependencies is better.
As for configuration requirement to enable transactions, it is a valid observation. My understanding is that pg_featureserv phylosophy is to rely on the database to handle acces control.
Yes, and ideally pg_featureserv will be deployed with a read-only user if not being used for update. But a configuration flag (with default being No Update) ensures backward compatibility for existing installations, and gives more flexiblity for deployment.
I think it goes beyond simple on/off, and requires configuration to enforce optimistic locking.
Can you elaborate?
Hi @fredmorin, I am wondering the status of this PR. I'm hoping to implement a WFS-T server for QGIS editing, and this PR looks like it might be almost there.
It looks from the linked issue that there might be a problem on their end blocking editing on the QGIS platform. Is that the current status? Is the WFS-T implementation here complete on its own terms? Thanks.
