ldproxy

Features - JSON-FG

specdraftimplcandidate

Kodierung von Features als JSON-FG.

Umfang

GeoJSON ist eine beliebte Kodierung für Features. Es ist die Standardkodierung für Features in ldproxy. GeoJSON hat jedoch bewusste Einschränkungen, die seine Verwendung unter Umständen verhindern oder einschränken. So ist GeoJSON beispielsweise auf WGS 84-Koordinaten beschränkt, unterstützt keine volumetrischen Geometrien und hat kein Konzept zur Klassifizierung von Features nach ihrem Typ.

OGC Features and Geometries JSON (JSON-FG) ist ein Entwurf für einen OGC-Standard für GeoJSON-Erweiterungen, die Standardwege zur Unterstützung solcher Anforderungen bieten.

Die Rolle PRIMARY_GEOMETRY dient zur Auswahl der primären räumlichen Eigenschaft für das Mitglied "place" oder "geometry".

Für das Profil JSON-FG+, d. h. mit Geometrien sowohl in "place" als auch in "geometry", muss eine separate räumliche Eigenschaft mit der Rolle SECONDARY_GEOMETRY angegeben werden, die in OGC:CRS84 oder OGC:CRS84h im Element "geometry" dargestellt wird. Diese Eigenschaft wird nicht dargestellt, wenn das Profil nicht JSON-FG+ ist.

Die Rollen PRIMARY_INSTANT, PRIMARY_INTERVAL_START und PRIMARY_INTERVAL_END werden zur Auswahl der zeitlichen Eigenschaften für das Mitglied "time" verwendet.

Die Rolle TYPE kann verwendet werden, um eine Eigenschaft, die den Typ des Features enthält, mit Anmerkungen zu versehen. Der Wert der Eigenschaft wird im Member "type" des Features dargestellt.

Die drei GeoJSON-Profile gemäß der JSON-FG-Spezifikation werden unterstützt. Die GeoJSON-Profile gelten nur, wenn der Media Type der Antwort "application/geo+json" ist.

  • Das Standardprofil "rfc7946" liefert GeoJSON ohne jegliche JSON-FG-Erweiterungen.
  • Das Profil "jsonfg" liefert GeoJSON mit allen anwendbaren JSON-FG-Erweiterungen.
  • Das Profil "jsonfg-plus" liefert GeoJSON mit JSON-FG-Erweiterungen mit der zusätzlichen
    Einschränkung, dass das Element "geometry" nicht null ist, um GeoJSON-Clients zu
    unterstützen, die JSON-FG nicht kennen. Das Profil ist nur aktiv, wenn eine Eigenschaft mit der Rolle SECONDARY_GEOMETRY angegeben ist.

Konformitätsklassen

Der Baustein implementiert die Requirements Classes "Core", "Polyhedra" und "Feature Types and Schemas", "GeoJSON Profiles" und "JSON-FG in Web APIs" aus JSON-FG 0.3.0 (DRAFT)open in new window. Die Implementierung kann sich im Zuge der weiteren Standardisierung der Spezifikation noch ändern.

Konfiguration

Optionen

NameDefaultBeschreibungTypSeit
buildingBlock
Immer JSON_FG.
string
v2.0
enabled
false
Soll der Baustein aktiviert werden?
boolean
v2.0
transformations
{}
Property-Transformationen erfolgen bei der Aufbereitung der Daten für die Rückgabe über die API. Die Datenhaltung selbst bleibt unverändert. Alle Filterausdrücke (siehe queryables in Features) wirken unabhängig von etwaigen Transformationen bei der Ausgabe und müssen auf der Basis der Werte in der Datenhaltung formuliert sein - die Transformationen sind i.A. nicht umkehrbar und eine Berücksichtigung der inversen Transformationen bei Filterausdrücken wäre kompliziert und nur unvollständig möglich. Insofern sollten Eigenschaften, die queryable sein sollen, möglichst bereits in der Datenquelle transformiert sein. Eine Ausnahme sind typischerweise Transformationen in der HTML-Ausgabe, wo direkte Lesbarkeit i.d.R. wichtiger ist als die Filtermöglichkeit.
object
v2.0
supportPlusProfile
true
Aktiviert die Unterstützung für das "jsonfg-plus"-Profil. In diesem Profil enthalten JSON-FG-Features mit einem JSON-Member "place" auch eine GeoJSON-Geometrie im JSON-Member "geometry" im Koordinatenreferenzsystem WGS 84. Andernfalls ist "geometry" eines JSON-FG-Features null, wenn "place" vorhanden ist.
boolean
v4.5
geojsonCompatibility
true
Deprecated (ersetzt durch supportPlusProfile).
boolean
v3.3
featureType
[]
Deprecated (ersetzt durch featureTypeV1). Nur der erste Wert der Liste wird verwendet.
array
v3.1
featureTypeV1
see description
Ersetzt featureType, wird in v5.0 zu featureType umbenannt. Features werden oft nach der Objektart kategorisiert. In der Regel haben alle Features derselben Art dasselbe Schema und dieselben Eigenschaften. Viele GIS-Clients sind bei der Verarbeitung von Features auf das Wissen über den Objektart angewiesen. Zum Beispiel, wenn einem Feature ein Stil zugeordnet wird, um das Feature auf einer Karte darzustellen. Diese Option fügt ein JSON-Member "featureType" mit dem angegebenen Wert hinzu. Der Wert kann ein Template {{type}} enthalten, das durch den Wert der Objekteigenschaft mit role: TYPE im Provider-Schema der Objektart der Collection ersetzt wird. Die Eigenschaft muss vom Typ STRING sein. Wenn der Objekttyp im Provider-Schema einen Wert für objectType hat, dann ist dieser Wert der Default. Ansonsten ist der Default null.
string
v3.1
links
[]
Ergänzt den "links"-Array von Features um die angegebenen Links. Alle Werte des Arrays müssen ein gültiges Link-Objekt mit href und rel sein.
array
v3.1

Beispiele

Beispiel für die Angaben in der Konfigurationsdatei für die gesamte API (aus der API für Topographische Daten in Daraa, Syrienopen in new window):


- buildingBlock: JSON_FG
  enabled: true
  featureType:
  - nas:{{type}}

Ergänzende Angaben pro Feature Collection mit einem Attribut F_CODE (für das in der Provider-Konfiguration role: TYPE gesetzt wurde), um die Objektart zu setzen:


- buildingBlock: JSON_FG
  featureType:
  - nas:{{type}}

Hierdurch wird bei einem Wert von "GB075" im Attribut F_CODE die Objektart wie folgt ausgegeben:


{
  "type": "Feature",
  "id": 1,
  "featureType": "nas:GB075",
  ...
}
ImpressumDatenschutzerklärung