CRUD

specdraftimplproposal

Create, replace, update and delete features.

Scope

New or updated features can be submitted in GeoJSON or JSON-FG.

In POST and PUT requests, the "Content-Type" header must be set to "application/geo+json".

In PATCH requests, the "Content-Type" header must be set to "application/merge-patch+json". The payload should include only the changed values (in the "geometry"/"place" and "properties" members). See RFC 7396 (JSON Merge Patch) for details.

The properties must be in the Receivables representation, that is, according to the schema of the collection excluding properties marked as readOnly. For feature references, the receivables representation is a JSON object with three properties (id, the foreign key, title, a descriptive text, and type, the name of the type in the feature schema). To update an existing feature, the current feature to be edited can be requested in the profile all-as-receivable.

If a new or updated feature includes a geometry, the URI of the coordinate reference system must be represented in the "Content-Crs" header of the request. To avoid coordinate transformations, the geometry should be in the storage CRS.

Features may only have a single geometry property with scope RECEIVABLES. The geometry has to be represented in the "geometry" or "place" member depending on the format (with or without the JSON-FG extensions), the coordinate reference system and the geometry type (see JSON-FG for details when "place" has to be used).

A new feature can be created in two ways, depending on the specification of the featureId. If the featureId is generated and assigned by ldproxy during the creation, POST on {landingPage}/collections/{collectionId}/items is used and the URI of the generated feature is in the "Location" header of the response. If the feature ID is assigned by the client, PUT on {landingPage}/collections/{collectionId}/items/{featureId} has to be used. Clients can determine the behavior from the OpenAPI document or by inspecting the supportsNonAutogeneratedResourceIds field in the collection. Any existing "id" member in a submitted feature is ignored in all requests.

To validate a new or updated feature submitted in a POST or PUT request against the schema of the collection, a header Prefer with the value "handling=strict" can be added to the request. If the validation fails, an error is returned.

If the feature in a POST or PUT request is GeoJSON without the JSON-FG extensions, include a header Link with the value "http://www.opengis.net/def/profile/OGC/0/rfc7946; rel=profile" in the request. For a feature with the JSON-FG extensions, use the value "http://www.opengis.net/def/profile/OGC/0/jsonfg; rel=profile".

Limitations

Only feature types from an SQL feature provider with dialect PGIS and datasetChanges.mode CRUD are supported.

The features may only have a single geometry property with scope RECEIVABLES.

Conformance Classes

The building block is based on the specifications of the conformance classes "Create/Replace/Delete", "Update", "Optimistic Locking using Timestamps" and "Features" from the Draft OGC API - Features - Part 4: Create, Replace, Update and Delete. The implementation will change as the draft will evolve during the standardization process.

Operations

Resource	Path	Methods	Media Types	Description
Features, Feature	collections/{collectionId}/items, collections/{collectionId}/items/{featureId}	DELETE, PATCH, POST, PUT		Create, Replace, Update and Delete features.

Path Parameters

Name	Resources	Description
collectionId	Features, Feature	The identifier of the feature collection.

Configuration

Options

Name	Default	Description	Type	Since
buildingBlock		Always CRUD.	string	v2.0
enabled	false	Enable the building block?	boolean	v2.0
optimisticLockingLastModified	false	Option to enable support for conditional processing of PUT, PATCH, and DELETE requests, based on the time when the feature was last updated. Such requests must include an If-Unmodified-Since header, otherwise they will be rejected. A feature will only be changed, if the feature was not changed since the timestamp in the header (or if no last modification time is known for the feature). The last modification time of a feature is determined from a feature property with type DATETIME for which isLastModified is set to true in the schema in the feature provider.	boolean	v3.5

Examples

- buildingBlock: CRUD
  enabled: true