OGC API - Features - Part 4: Create

[benoitdm-oslandia]

implements CREATE feature from OGC API - Features - Part 4

DELETE UPDATE REPLACE will come in separated PR.

This is the simplest version without optimistic locking.

[dr-jts]

Because this PR opens the door to changing server data, I think it needs a way to control if it is enabled (and the default must be disabled, since otherwise this exposes existing installations to change). Of course, database security can be used to do this as well, but it is sometimes convenient to control this via configuration (and that is essential to avoid changing current behaviour).

This could be done via a configuration parameter. The simplest thing would be a single parameter (say [Database] EnableWrite = true with default false.

It might be nice to allow finer-grained control over which tables can be changed as well. This could be done via additional config parameters similar to the current TableIncludes and TableExcludes.

[benoitdm-oslandia]

Adding an option to enable/disable the write access is a good idea. We will bring a fix asap. But the table filtering will be done in a separated PR.

[Guts]

Hello @dr-jts,

Any chance to see this one merged or reviewed again in next days?

Thanks!

[dr-jts]

What is the extent of support for Coordinate Reference Systems?

I see the following levels of capability (feel free to amend):

1. Data in geodetic, target table in geodetic CRS (no reprojection)
2. Data in non-geodetic CRS (implicit), target table has same CRS (no reprojection;
3. Data in geodetic, target table with any CRS (reprojection potentially required)
4. Data in non-geodetic CRS (explicit in GeoJSON), table in different CRS (reprojection potentially required)

This is the kind of non-obvious functionality which needs to be documented for users.