CRUD

specdraftimplproposal

Erzeugen, Ersetzen, Aktualisieren und Löschen von Features.

Umfang

Neue oder aktualisierte Features können in GeoJSON oder JSON-FG übermittelt werden.

In POST- und PUT-Anfragen muss der Header "Content-Type" auf "application/geo+json" gesetzt sein.

In PATCH-Anfragen muss der Header "Content-Type" auf "application/merge-patch+json" gesetzt sein. Der Payload sollte nur die geänderten Werte (in den Eigenschaften "geometry"/"place" und "properties") enthalten. Details dazu finden sich in RFC 7396 (JSON Merge Patch).

Die Eigenschaften müssen in der Repräsentation für Receivables vorliegen, also entsprechend dem Schema der Collection ohne die als readOnly gekennzeichneten Eigenschaften. Bei Objektverweisen ist die Repräsentation für Receivables ein JSON-Objekt mit drei Eigenschaften (id, dem Fremdschlüssel, title, einem beschreibenden Text, und type, dem Namen des Typs im Objektschema). Um ein bestehendes Feature zu aktualisieren, kann das aktuelle zu bearbeitende Feature im Profil all-as-receivable angefordert werden.

Wenn ein neues oder aktualisiertes Feature eine Geometrie enthält, muss die URI des Koordinatenreferenzsystems im Header "Content-Crs" der Anfrage angegeben werden. Um Koordinatentransformationen zu vermeiden, sollte die Geometrie im Storage-CRS vorliegen.

Features dürfen nur eine einzige Geometrieeigenschaft mit Scope RECEIVABLES haben. Die Geometrie muss in der Eigenschaft "geometry" oder "place" abhängig vom Format (mit oder ohne die JSON-FG-Erweiterungen), dem Koordinatenreferenzsystem und dem Geometrietyp dargestellt werden (Details dazu, wann "place" zu verwenden ist, finden sich in JSON-FG).

Ein neues Feature kann auf zwei Arten erstellt werden, abhängig von der Angabe der featureId. Wenn die featureId von ldproxy während der Erstellung generiert und zugewiesen wird, wird POST auf {landingPage}/collections/{collectionId}/items verwendet und die URI des generierten Features ist im Header "Location" der Antwort enthalten. Wenn die Feature-ID vom Client vergeben wird, ist PUT auf {landingPage}/collections/{collectionId}/items/{featureId} zu verwenden. Clients können das Verhalten aus dem OpenAPI-Dokument ermitteln oder durch Inspektion des Feldes supportsNonAutogeneratedResourceIds in der Collection. Eine bestehende "id"-Eigenschaft in einem übermittelten Feature wird in allen Anfragen ignoriert.

Um ein in einer POST- oder PUT-Anfrage übermitteltes neues oder aktualisiertes Feature gegen das Schema der Collection zu validieren, kann der Anfrage ein Header Prefer mit dem Wert "handling=strict" hinzugefügt werden. Wenn die Validierung fehlschlägt, wird ein Fehler zurückgegeben.

Wenn das Feature in einer POST- oder PUT-Anfrage GeoJSON ohne die JSON-FG-Erweiterungen ist, fügen Sie der Anfrage einen Header Link mit dem Wert "http://www.opengis.net/def/profile/OGC/0/rfc7946; rel=profile" hinzu. Für ein Feature mit den JSON-FG-Erweiterungen verwenden Sie den Wert "http://www.opengis.net/def/profile/OGC/0/jsonfg; rel=profile".

Limitierungen

Es werden nur Objektarten von einem SQL-Feature-Provider mit dialect PGIS und datasetChanges.mode CRUD unterstützt.

Die Features dürfen nur eine einzige Geometrieeigenschaft mit dem Geltungsbereich RECEIVABLES haben.

Konformitätsklassen

Der Baustein basiert auf den Vorgaben der Konformitätsklassen "Create/Replace/Delete", "Update", "Optimistic Locking using Timestamps" und "Features" aus dem Entwurf von OGC API - Features - Part 4: Create, Replace, Update and Delete. Die Implementierung wird sich im Zuge der weiteren Standardisierung der Spezifikation noch ändern.

Operationen

Ressource	Pfad	Methoden	Formate	Beschreibung
Features, Feature	collections/{collectionId}/items, collections/{collectionId}/items/{featureId}	DELETE, PATCH, POST, PUT		Erzeugen, Ersetzen, Aktualisieren und Löschen von Features.

Pfad-Parameter

Name	Ressourcen	Beschreibung
collectionId	Features, Feature	Der Identifikator der Feature Collection.

Konfiguration

Optionen

Name	Default	Beschreibung	Typ	Seit
buildingBlock		Immer CRUD.	string	v2.0
enabled	false	Soll der Baustein aktiviert werden?	boolean	v2.0
optimisticLockingLastModified	false	Option zur Aktivierung der Unterstützung für die bedingte Verarbeitung von PUT-, PATCH- und DELETE-Anfragen, basierend auf der Zeit, zu der das Feature zuletzt aktualisiert wurde. Solche Anfragen müssen einen If-Unmodified-Since-Header enthalten, andernfalls werden sie zurückgewiesen. Ein Feature wird nur dann geändert, wenn das Feature seit dem Zeitstempel im Header nicht geändert wurde (oder wenn kein letzter Änderungszeitpunkt für das Feature bekannt ist). Der Zeitpunkt der letzten Änderung eines Features wird anhand einer Objekteigenschaft mit Datentyp DATETIME ermittelt, für die isLastModified im Schema des Feature Providers auf true gesetzt ist.	boolean	v3.5

Beispiele

- buildingBlock: CRUD
  enabled: true