OGC API - Features (Neue Chancen für die GDI-DE)

front

Armin Retterath / GDI-RP

Überblick

  1. OGC API Features - Was ist das?
  2. Implementierungen
  3. Wichtige Konzepte
  4. Ansatz in Rheinland-Pfalz
  5. Ergebnisse
  6. Extensions
  7. Live Präsentation

OGC API Features (1) - Was ist das?

  • 2019-11-06 - Pressemitteilung des OGC - First of new OGC APIs approved as an OGC standard: OGC API - Features - Part 1: Core
  • War zunächst als Nachfolger der WFS 2.0.2 Spec vorgesehen (Arbeitstitel WFS 3.0 - 2018-04-07)
  • Es soll ein neues Zeitalter für die Nutzung von Geoinformationen im Internet eingeläutet werden ;-)
  • Das Teilen und der Zugriff auf Geodaten soll viel einfacher werden, ausserdem sollen moderne Webtechnologien verwendet werden

OGC API Features (2) - Was ist das?

  • Es handelt sich dabei auch um einen Paradigmenwechsel. Bisherige OGC Bindings werden durch durch OpenAPI Bindings ersetzt.
  • OpenAPI ist der Ansatz REST APIs standardisiert zu beschreiben.
  • Man setzt auf Standard-Webtechnologien und reduziert den Geo-spezifischen Anteil auf ein Minimum

OGC API Features (3) - Was ist das?

OpenAPI Description (HTML):

Implementierungen (1)

front

Implementierungen (2)

LD Proxy (Interactive Instruments):

Implementierungen (3)

    Unterscheidung:
  • Proxy Lösungen wie z.B. LD-Proxy
  • Direkte Umsetzungen wie z.B. Geoserver

Wichtige Konzepte

  • Paging
  • Direkte Adressierbarkeit einzelner Objekte
  • Nutzung von HTTP content negotiation
  • Direkte HTML Ausgabe (Client wird für viele Dinge überflüssig)
  • featuretype -> collection
  • feature -> item

Ansatz in Rheinland-Pfalz (1)

Voraussetzungen:

  • WFS seit 2008 in der GDI integriert (jeder WFS und jeder Featuretype hat eine persistente ID)
  • WFS sind nach Lizenzen klassifiziert
  • GeoPortal.rlp hat einen OWS Security Proxy
  • Daten-Service Kopplung intrinsisch im Informationsmodell abgebildet (Dataset<->Layer<->Featuretype)

Ansatz in Rheinland-Pfalz (2)

Erweiterter Anwendungsfall:

  • Einfachere Integration von Vektordatennutzung in GeoPortal.rlp
  • Für sichtbare WMS Layer soll eine Tabelle mit Objekten für Selektion und Navigation angezeigt werden können

Umsetzung von WFS 3.0 / OGC API Features war der nächste konsequente Schritt

Ansatz in Rheinland-Pfalz (3)

Vorgehensweise:

  1. Sichtung der Spezifikation
  2. Prüfung der serverseitigen Voraussetzungen (welche WFS Implementierungen sind nutzbar / welche Anpassungen sind notwendig)
  3. Nutzung des HTML Frontends des LD Proxy als Vorbild für das Layout
  4. Umsetzung des Interfaces / Proxy
  5. Export von Metadaten (OpenData & ISO!)

Ergebnisse (1)

Für alle OpenData WFS 2.0+ gibt es automatisch ein OGC API Features Interface

Ergebnisse (2)

API Definition

Ergebnisse (3)

Die Metadaten für das REST Interface werden an den GDK-DE abgegeben

REST im GDK

Ergebnisse (4)

Es gibt für jedes Objekt eine persistente URI zur Referenzierung

Ergebnisse (5)

Export von Metadaten für das neue Interface ins OpenData Portal (dcat - distribution) inkl. CKAN resource_view

OGDP Resource View

Extensions (1)

Nutzung von JSON Schema für das Mapping von Attributbezeichnern

{
  "definitions": {}, 
  "$schema": "http://json-schema.org/draft-07/schema#", 
  "$id": "https://geoportal.trier.de/trier/config/jsonschema/pois.json", 
  "type": "object", 
  "title": "POIs Stadt Trier", 
  "description": "Points of Interest (Pois) im Stadtgebiet Trier", 
  "readOnly": true, 
  "writeOnly": false, 
  "required": [
	"gid",
    "bez", 
    "str_hsnr", 
	"plz_ort",
	"beschr",
    "internet",	
	"x",
	"y"
  ], 
  "properties": {
    "gid": {
      "$id": "#/properties/gid", 
      "type": "integer", 
      "title": "Objektschlüssel", 
      "description": "Ein eindeutiger Objektschlüssel des POIs", 
      "examples": [
        "22534"
      ] 
    }, 
    "bez": {
      "$id": "#/properties/bez", 
      "type": "string", 
      "title": "Name", 
      "description": "Name des POIs", 
      "examples": [
        "SHG"
      ] 
    },
    "str_hsnr": {
      "$id": "#/properties/str_hsnr", 
      "type": "string", 
      "title": "Straße / Hsnr.", 
      "description": "Straße und Hausnummer des Ortes", 
      "examples": [
        "Mainz"
      ] 
    },
	"plz_ort": {
      "$id": "#/properties/plz_ort", 
      "type": "string", 
      "title": "PLZ / Ort", 
      "description": "Postleitzahl und Name des Ortes", 
      "examples": [
        "Mainz"
      ] 
    },
	"beschr": {
      "$id": "#/properties/plz_ort", 
      "type": "string", 
      "title": "Infos und Beschreibung", 
      "description": "Beschreibungen und weitere Informationen zum POI (auch HTML Content)", 
      "examples": [
        "Mainz"
      ] 
    },
	"internet": {
      "$id": "#/properties/internet", 
      "type": "string", 
      "title": "Internet", 
      "description": "Webadresse mit weiteren Infos", 
      "examples": [
        "Mainz"
      ] 
    },
	"x": {
      "$id": "#/properties/x", 
      "type": "integer", 
      "title": "X-Koordinate", 
      "description": "X-Koordinate im UTM Zone 32 System", 
      "examples": [
        "22534"
      ] 
    },
	"y": {
      "$id": "#/properties/y", 
      "type": "integer", 
      "title": "Y-Koordinate", 
      "description": "Y-Koordinate im UTM Zone 32 System", 
      "examples": [
        "22534"
      ] 
    }
  }
}


						

Extensions (2)

Nutzung von JSON Schema für das Mapping von Attributbezeichnern

Extensions (3)

Nutzung von JSON-LD für das semantische Mapping des Datenmodells

TBD - ist aber schon vorbereitet ;-)

Live Präsentation

front

Fragen?

THE END


Armin Retterath

Zentrale Stelle GDI-RP

armin.retterath@vermkv.rlp.de

0261/492-466