Architektur der Geodateninfrastruktur Deutschland - Vorgaben der GDI-DE zur Bereitstellung von Downloaddiensten

WxS

WxS steht stellvertretend für die allgemein bekannten und weltweit verbreiteten OGC-Spezifikationen für den Austausch von und Zugriff auf Geodaten. Die Entwicklung dieser Spezifikationen begann schon Mitte der 90er Jahre und sie bilden heute noch die Basis für den Betrieb der meisten Geodateninfrastrukturen. Prinzipiell handelt es sich um spezielle Webservices mit XML-Binding. Eine Verallgemeinerung der maschinenlesbaren Service-Beschreibung findet sich in der OWS Common Spezifikation [[OGC OWS Common]]. Bei der Nutzung dieser Dienste wird grundsätzlich zunächst ein sogennantes OGC-Capabilities-Dokument abgefragt. Dieses beinhaltet unter anderem Metadaten über den Dienstprovider, eine Liste der Operationen sowie Informationen über die vom Dienst bereitgestellten Daten. Mithilfe der maschinenlesbaren Beschreibung lässt sich die Informationsquelle in andere IT-Systeme integrieren.

INSPIRE

Bei der Erarbeitung der EU INSPIRE-Richtlinie hat man die Standard OGC Architektur für den Aufbau von Geodateninfrastrukturen als Vorbild verwendet. Die Richtlinie selbst und die zugehörigen Rechtsverordnungen referenzieren jedoch nicht direkt konkrete OGC-Spezifikationen, sondern sprechen von sogenannten Download- und Darstellungsdiensten. Es wird gefordert, dass Geodaten über Downloaddienste herunterladbar sein müssen. Die Downloaddienste müssen dabei mindestens folgende Operationen unterstützen, um den Anforderungen der EU zu genügen:

• Get Download Service Metadata
• Get Spatial Dataset
• Describe Spatial Dataset
• Link Download Service

OGC API

Das OGC hat Ende 2019 begonnen seine Architektur neu auszurichten. Die speziellen WxS mit ihrem XML-Binding wurden als nicht mehr zeitgemäß erachtet und sollen sukzessive durch moderne REST APIs ersetzt werden. Die erste Spezifikation aus dieser neuen Reihe ist die im Jahr 2020 publizierte ISO19168:1. Sie definiert ein REST-Interface für den Zugriff auf Vektordaten und bietet eine moderne Alternative zur WFS-Schnittstelle. Allgemeine Anforderungen für diese REST-Interfaces sind in der OGC-API Common Spezifikation [[OGC-API Common - Part 1: Core]] definiert.

Auffinden und Nutzen von Diensten

In einer Geodateninfrastruktur verfügen Dienste in der Regel über eine Selbstbeschreibung der möglichen Operationen, sowie des zur Verfügung gestellten Contents (Daten). Um beispielsweise Downloaddienste nutzen zu können, benötigt man die URL auf die Selbstbeschreibung des jeweiligen Dienstes. Die aktuelle GDI-Architektur basiert darauf, dass sowohl die Daten als auch die Dienste jeweils mit standardisierten Metadaten (aktuelles Encoding [[ISO 19139:2007]]) beschrieben sind. Diese werden in Katalogen gesammelt und bis auf die europäische Ebene aggregiert. Der Zugriff auf die Kataloge der verschiedenen Verwaltungsebenen erfolgt über eine einheitliche Schnittstelle, den OGC Catalog Service [[OGC CAT 2.0.2]]. Der typische Prozess, um die Zugriffsadresse eines Dienstes zu erhalten, geht in der Regel von den Datensatz-Metadaten aus. Jeder Datensatz wird dabei über eine möglichst persistente URI identifiziert (Datensatzidentifikator). Diese URI wird vom Datenanbieter festgelegt und ist Bestandteil der Metadaten zum Datensatz.

                      sequenceDiagram
                          participant Nutzer
                          participant Katalog (CSW)
                          participant Dienst
                          Nutzer ->> Katalog (CSW): csw:GetRecords (Suche nach Datensätzen)
                          Katalog (CSW)->>Nutzer: Liste von Datensatz-Metadaten (ISO19139)
                          Nutzer->>Nutzer: wähle Datensatz / extrahiere Datensatzidentifikator
                          Nutzer->>Katalog (CSW): csw:GetRecords (Suche Dienste für Datensatzidentifikator)
                          Katalog (CSW)->>Nutzer: Liste von Dienst-Metadaten (ISO19139)
                          Nutzer->>Nutzer: wähle Dienst / extrahiere Zugriffsadresse
                          Nutzer->>Dienst: Aufruf Zugriffsadresse
                          Dienst->>Nutzer: Liefert Selbstbeschreibung
                          Nutzer->>Nutzer: Auswertung der Selbstbeschreibung
                          Nutzer->>Dienst: Nutzung des Dienstes
                

Beziehung zwischen Daten, Diensten und deren Metadaten

Da ein Dienst in der Regel den Zugriff auf mehrere Datensätze ermöglicht, ist es zusätzlich notwendig, die eindeutige Zuordnung zwischen den vom Dienst bereitgestellten Content und den jeweiligen Datensätzen in der Selbstbeschreibung (Capabilities-Dokument) des Dienstes zu hinterlegen. Die Art und Weise wie dies zu erfolgen hat, wurde von den Arbeitsgruppen auf europäischer Ebene zur Umsetzung von INSPIRE festgelegt. Die Beziehungen der einzelnen Objekte untereinander ist nicht trivial und wird durch das folgende Diagramm verdeutlicht.

                  flowchart TB
                    subgraph Daten-Dienste-Kopplung
                        direction BT 
                        subgraph service["fa:fa-network-wired Dienst"]
                            subgraph service-description[fa:fa-file-code Selbstbeschreibung / Capabilities]
                                direction LR
                                A[Dienst-Metadaten]
                                B[Operationen]
                                C[Content]
                                
                            end
                        end
                        subgraph metadata["Metadaten (ISO19139)"]
                            direction BT
                            E[fa:fa-file-code Dienst-Metadaten] & F[fa:fa-file-code Datensatz-Metadaten]
                        end
                    end
                    subgraph Daten
                        direction LR
                        G[(Datensatz)] & H["Datensatzidentifikator {codesspace}/{code}"]
                    end
                    F-- beschreibt -->G
                    
                    C-- "fa:fa-link href [1..n]" -->F
                    E-- beschreibt -->service
                    E-- fa:fa-link href -->service-description
                    F-- beinhaltet -->H
                    C-. "referenziert [1..n]" .->H
                    E-. "referenziert [1..n]" .->H
                    E-- "fa:fa-link href [1..n]" -->F
                    service-- liest -->G
                    H-- identifiziert -->G
                

Art der Bereitstellung

Erläuterung

Es gibt zwei häufig verwendete Versionen des WFS-Standards mit unterschiedlichem Verbreitungsgrad: WFS Version 1.1.0 [[OGC WFS 1.1.0]] und WFS Version 2.0.0 [[iso-19142-2010]]. Die meisten Softwarekomponenten, die über eine WFS-Schnittstelle verfügen, unterstützen auch die neuere WFS-Version 2.0.0. Ein Vorteil der neueren Version ist der native Support für Paging. Mithilfe dieser Funktion lassen sich auch sehr umfangreiche Datensätze automatisiert herunterladen. Manche Softwarekomponenten bietet diese Funktion auch schon bei der WFS Version 1.1.0 an.

Empfehlung

Wird ein Downloaddienst auf Basis von WFS angeboten, so SOLL dieser die Version 2.0.0, 1.1.0 oder beide Versionen unterstützen.

Persistenz / Identität

Erläuterung

Bei einer SOA (service-oriented architecture) ist es systemrelevant, dass die Datenquellen dauerhaft referenzierbar sind. Im Falle von Downloaddiensten auf Basis von WFS gibt es für jeden Service eine URL, über die weitere Informationen zum Dienst in Form von Capabilities-Dokumenten verfügbar gemacht werden. Diese Capabilities-Dokumente beinhalten zum einen die Zugriffsadressen (URLs) zu den jeweiligen technischen Operationen (DescribeFeatureType, GetFeature etc.), zum anderen enthalten sie Metadaten über den Inhalt, welcher über den Dienst publiziert wird (Schema des FeatureTypes, Liste des FeatureTypes, etc.).

Downloaddienste können über die URL zum Capabilities-Dokument in Geschäftsprozesse und Applikationen eingebunden werden. Die Anwendung kommuniziert selbständig über das Netzwerk mit der jeweiligen Datenquelle und erhält als Antwort die benötigten Informationen bzw. Objekte.

Die eindeutige Referenzierung des Contents (FeatureType) erfolgt dabei durch eine Kombination der URL des Servers mit dem <Name> - Element des jeweiligen FeatureType. Dienst-URL und <Name> von FeatureTypes sollen nach Veröffentlichung eines Dienstes nicht mehr verändert werden. Die Änderung des Wertes hätte zur Folge, dass alle abhängigen Prozesse und Applikationen angepasst werden müssten. Für den Betrieb und die Funktionsfähigkeit einer Geodateninfrastruktur (GDI) ist die Persistenz dieser Identifikatoren von hoher Bedeutung.

Um die Nutzer in die Lage zu versetzen, sich über Änderungen von verteilten Diensten zu informieren, sehen die zugrundeliegenden Spezifikationen den optionalen Parameter UPDATESEQUENCE bei einem GetCapabilities Request vor, dessen Unterstützung aus dem zuvor genannten Grund empfohlen wird.

Empfehlung

Der UPDATESEQUENCE Parameter der GetCapabilities Operation SOLL unterstützt werden.

Empfehlung

Der Wert des UPDATESEQUENCE Parameters SOLL als String in Form eines ISO 8601:2004 Zeitstempels - CCYY-MM-DDThh:mm:ss.sssZ - implementiert werden.

Objektartennamen / Identifikatoren

Erläuterung

Das FeatureType <Name> - Element beim WFS ist ein Identifikator, der grundsätzlich von Software genutzt wird (Maschine-Maschine-Kommunikation). Um Fehler beim Auslesen eines Capabilities-Dokumentes auszuschließen, sollten sich diese Identifikatoren nur aus Zeichen zusammensetzen, deren Verwendung in unterschiedlichen Programmiersprachen unbedenklich ist. Außerdem sollte die Zahl der verwendeten Zeichen nicht zu groß sein, da es sonst bei Clients, die Datenanfragen nur über HTTP GET umsetzen, zu Fehlern bei der Übertragung der Anfragen kommen kann.

Anforderung

FeatureType-Namen MÜSSEN innerhalb eines Dienstes eindeutig sein und folgendem regulären Ausdruck entsprechen: [0-9a-zA-Z\.\-_:+]

Empfehlung

Die Länge der Zeichenkette des FeatureType-Namens bzw. -Identifikators SOLL möglichst kurz sein.

Einschränkung der Objektzahl

Anforderung

Werden umfangreiche Daten publiziert, die sich nicht mit einem einzelnen Request herunterladen lassen, so MUSS die WFS-Schnittstelle Paging unterstützen.

Empfehlung

Zur Vermeidung von Überlastungen von Client und Server soll die maximal auslieferbare Zahl von Objekten mit einem Request beschränkt werden. Die Obergrenze ist dabei abhängig von der Leistungsfähigkeit des Servers und der Komplexität der Objekte.

Bei einfachen Objekten, wie z.B. Flurstücken, sind 100.0000 Objekte pro Request in der Regel kein Problem.

Empfehlung

Die Information über die maximale Zahl der abfragbaren Objekte eines WFS SOLL im Capabilities-Dokument in Form eines Constraints angegeben werden.

Metadaten in Capabilities- und ISO-Dokumenten

Bei den Metadaten des Dienstes (Capabilities-Dokument) wird zwischen Service Level und Content Level unterschieden. Die Service Level Informationen beziehen sich auf Informationen zum Dienst und zum Dienstanbieter, die Content Level Informationen beschreiben die bereitgestellten FeatureTypes. Zusätzlich zu den Metadaten in den Capabilities-Dokumenten des Dienstes ist ein ISO 19139-Dokument zu erstellen und im Internet zu publizieren. Das Mapping zwischen den Elementen des Capabilities-Dokumentes und des ISO-Dokumentes wird im Folgenden dargelegt.

                    
                    flowchart LR
                      subgraph WFS 1.1.0 / 2.0.0
                          subgraph Capabilities
                              A[INSPIRE Extension]
                              B[FeatureType 1]
                              C[FeatureType n]
                          end
                      end
                      direction LR
                      subgraph Geodaten
                          D[Datensatz 1]
                          E[Datensatz n]
                      end
                      subgraph CSW 2.0.2        
                          F[Dienste-Metadatensatz]
                          G[Daten-Metadatensatz 1]
                          H[Daten-Metadatensatz n]
                      end
                      A-- MetadataURL -->F
                      F-- connectPoint -->A
                      A-- SpatialDataSetIdentifier 1  -->D
                      A-- SpatialDataSetIdentifier 2  -->E
                      B-- MetadataURL  -->G
                      C-- MetadataURL  -->H
                      G-- MD_Identifier -->D
                      H-- MD_Identifier -->E
                      F-- operatesOn -->G
                      F-- operatesOn -->H
                

Art der Bereitstellung

Erläuterung

Der Weg zur Bereitstellung von Geodaten über INSPIRE ATOM-Feeds wurde bei der Umsetzung von INSPIRE als Möglichkeit für den einfachen Download von vordefinierten Datensätzen (oder vordefinierten Teilen eines Datensatzes) entwickelt. Eine Option zur Abfrage von Dateninhalten oder dem Auswählen von benutzerdefinierten Teilmengen von Datensätzen ist nicht gegeben.

Ein Grund für die Verwendung des Atom-Standards [[RFC4287]] war die Möglichkeit der direkten Interpretation der Feeds durch verschiedene Browser. Die Feeds können direkt durch die Nutzer der Daten abonniert werden. Der Nutzer kann sich somit über die Aktualisierung der Daten automatisiert informieren lassen. Das von der damaligen INSPIRE Initial Operating Capability Task Force (IOC-TF) vorgeschlagene Verfahren zur Bereitstellung von Geodaten mittels ATOM-Feeds basiert auf einer zweistufigen Lösung, die die gesetzlichen Anforderungen der Durchführungsbestimmungen zu den Netzdiensten [[INS VO Netzdienste]] erfüllt.

Die INSPIRE-Richtlinie sieht grundsätzlich die Bereitstellung von Geodaten über Downloaddienste vor. Eine für diese Dienste geforderte Operation ist die Beschreibung des Dienstes selbst (Get Download Service Metadata).

Da sich die Art und Weise, Geodaten über dieses Verfahren bereitzustellen, in den letzten Jahren europaweit etabliert hat, und auch einige Softwareprodukte die ATOM-Feeds automatisch generieren können, macht es Sinn, das Verfahren auch in Deutschland einzusetzen. Eine Alternative zu INSPIRE ATOM-Feeds bieten in Zukunft möglicherweise STAC [[STAC]] bzw. OGC API Records [[OGC API Records - Part 1: Core]].

Im Kontext von INSPIRE wird bei der Bereitstellung von ATOM-Feeds eine OpenSearch-Schnittstelle erwartet. Diese kann bei einer Nutzung im rein deutschen Kontext entfallen, da diesbezüglich keine gesetzliche Anforderung existiert.

                flowchart LR
                G[ISO 19139 Metadaten für Downloaddienst]
                H[ISO 19139 Metadaten für Datensatz A]
                K[ISO 19139 Metadaten für Datensatz B]
                subgraph I[Service Feed]
                    direction RL
                    A[Entry A]
                    B[Entry B]
                end
                I--"/feed/link[@rel='describedby]/@href'"-->G
                A--"/entry/link[@rel='describedby']/@href"-->H
                B--"/entry/link[@rel='describedby']/@href"-->K
                subgraph L[Dataset Feed A]
                    C[Entry A]
                    D[Entry B]
                end
                subgraph M[Dataset Feed B]
                    E[Entry A]
                    F[Entry B]
                    N[Entry C]
                end
                O["Datensatz A (GML)"]
                P["Datensatz A (GML, anderes CRS)"]
                Q["Datensatz B (ZIP-Archiv)"]
                R["Datensatz B (Shape)"]
                S["Datensatz B (Shape, anderes CRS)"]
                A--"/entry/link[@rel='alternate]/@href'"-->L
                B--"/entry/link[@rel='alternate]/@href'"-->M
                C--"/entry/link[@rel='alternate]/@href'"-->O
                D--"/entry/link[@rel='alternate]/@href'"-->P
                E--"/entry/link[@rel='alternate]/@href'"-->Q
                F--"/entry/link[@rel='alternate]/@href'"-->R
                N--"/entry/link[@rel='alternate]/@href'"-->S
              

<entry>

Multi-Part Datensätze

Erläuterung

Datensätze können bei Bedarf auch in mehreren Einzelteilen bereitgestellt werden.

Anforderung

Werden Datensätze in mehreren einzelnen Teilen über ein ATOM Dataset Feed abgegeben, so MÜSSEN die Referenzen als href Attribute in <link> - Elementen angegeben werden. Die Elemente werden durch das Attribut rel="section" identifiziert und haben ein weiteres Attribut bbox mit der Angabe ihres geographischen Extents im Format "min_lat min_lon max_lat max_lon".

Art der Bereitstellung

Erläuterung

In den [[OGC Web API Guidelines]] sind grundsätzliche Leitfäden für die Umsetzung schnittstellenorientierter Geodatendienste beschrieben. Aus einer ganzen Reihe an OGC APIs wurde der [[OGC API - Features-Part 1]] im November 2019 veröffentlicht. Dabei handelt es sich um eine komplette Überarbeitung des OGC Web Feature Service (WFS), weshalb dieser zunächst auch unter der Bezeichnung „WFS 3.0“ bekannt war. OGC API Features setzt auf die Nutzung gängiger Web-Standards wie beispielsweise REST (Representational State Transfer) mit dem Ziel den Zugriff auf Vektordaten zu vereinfachen und diese in beliebige Webanwendungen zu integrieren.

Anders als der WFS ist ein Downloaddienst auf OGC API - Feature Basis nicht an starre XML-Strukturen gebunden, da für diesen kein Encoding verpflichtend ist (HTML und GeoJSON werden lediglich empfohlen). Zudem lassen sich Datensätze durch HTTP content negotiation in verschiedenen Repräsentationen/Rückgabeformaten abfragen und mittels „Paging“ seitenweise anzeigen, ohne den Dienst in einen GIS-Client einbinden zu müssen.

Die Bereitstellung der Daten erfolgt über eine vorgegebene Pfadstruktur. Das API-Wurzelelement, die „Landing Page“, muss Verlinkungen zu mindestens den Konformitätsangaben (/conformance), Objektgruppierungen (/collections) und einer API Definition (/api) aufweisen.

Ein technischer Ansatz für die Umsetzung der in den INSPIRE-Durchführungsbestimmungen für Netzdienste [[INS VO Netzdienste]] festgelegten Anforderungen auf der Grundlage des OGC-Standards API - Features ist unter [[INS GP OGC API - Features]] beschrieben.

                  graph TD
                    A("Landing Page") ~~~ B("Konformitätsangaben")
                    A("Landing Page")--- |"/conformance"| B("Konformitätsangaben")
                    A--- |"/api"| C(API Definition)
                    A--- |"/collections"| D(Datensätze)
                    D--- |"/collectionid"| E(Datensatz)
                    E--- |"/items"| F(Features)
                    F--- |"/id"| G(Feature)
              

Persistenz / Identität

Erläuterung

Grundsätzlich verfolgen die OGC API-Standards einen modernisierten RESTful Ansatz, sodass mit OGC API - Features Vektordaten direkt über eine URL abgefragt werden können. Der Zugriff auf Geodaten erfolgt mittels der oben genannte Pfadhierarchie. Somit sind Objektsammlungen (collections) und deren Features (items) referenzierbar, solange Sie den Pfad und die ID der Ressource kennen.

Koordinatenreferenzsysteme

Erläuterung

Wird ein Downloaddienst über OGC API - Features bereitgestellt, ist zu beachten, dass der Standard [[OGC API - Features-Part 1]] bereits die Unterstützung für die zwei folgenden Referenzsysteme definiert:

• WGS 84 longitude, latitude
• WGS 84 longitude, latitude, ellipsoidal height

Objektartennamen / Identifikatoren

Erläuterung

Damit Ressourcen direkt über eine URL abgerufen werden können, setzt dies Identifikatoren voraus, die sowohl für die Datensätze (collections) als auch deren Einzelobjekte (items) eindeutig sind. Requests erfolgen über folgenden Pfad: /collections/{collectionId}/items/{featureId}.

Nachfolgend wird dies am API-Beispiel Verwaltungsgrenzen in Brandenburg und Berlin veranschaulicht. Mit dem Beispiel-Request sollen die Verwaltungsgrenzen des Kreises Potsdam abgefragt werden. Hierzu wird zuerst aus den Datensätzen (collections) die entsprechende eindeutige ID (collectionId) für die Kreise ("krs") und im Weiteren dann aus den Einzelobjekten der Kreise (items) die eindeutige ID (featureId) der Stadt Potsdam ("krs_417") referenziert.

Metadaten

Erläuterung

Grundsätzlich gibt es im OGC Standard keine Vorgaben für die Kopplung einzelner Ressourcen mit Metadatenbeschreibungen, das heißt diese stellen lediglich eine Empfehlung dar. Im Zuge des Good-Practice-Projektes "INSPIRE download services based on OGC API - Features" [[INS GP OGC API - Features]] wurde die Empfehlung schließlich als Anforderung formuliert. Dementsprechend müssen Feature Collections bei INSPIRE-Umsetzungen einen Link zum Metadatensatz für den Datensatz enthalten. Metadatenangaben für Feature Collections sollen laut Spezifikation im Link-Parameter rel als describedby angegeben werden. Außerdem soll ein weiterer Link-Parameter type als application/xml gesetzt werden.

Bei diesem vereinfachten Ansatz ergeben sich unter anderem folgende Probleme:

• Datensatz-Metadaten lassen sich nur auf der Ebene der collections verknüpfen - einzelne Objektarten bzw. FeatureTypes sind nicht aufgelösbar.
• Der Wert des Attributes rel - describedby ist mehrdeutig besetzt. Grundsätzlich sieht der Standard hierüber eine Verlinkung des Datenmodells vor.

Service Level Metadaten

Erläuterung

Bei den WxS wird der Service-Metadatensatz im Capabilities-Dokument verlinkt. Bei der OGC API Features Schnittstelle gibt es kein einzelnes Capabilities-Dokument, vielmehr sind die Informationen auf zwei verschiedene Endpunkte verteilt (Landing page und collections).

Anforderung

Die json-Variante der Landing page eines OGC API Features Dienstes, MUSS einen Link auf einen entprechenden ISO19139 Dienst-Metadatensatz enthalten. Die Angabe des Links erfolgt dabei entsprechend des nachfolgenden Beispiels, wobei das Attribut title frei wählbar ist.

Dataset Level Metadaten

Erläuterung

Bei den WxS werden die Datensatz-Metadaten ebenfalls im Capabilities-Dokument auf Ebene der jeweiligen Ressourcen (FeatureType/Coverage) verlinkt. Bei der OGC API Features Schnittstelle entpricht diese Informationsebene weitestgehend Response für den Pfad collections. In der json-Variante gibt es ein Array collections das der FeatureType- bzw. Coverage-List der WxS entspricht.

Anforderung

Die json-Variante der Response auf den collections-Pfad eines OGC API Features Dienstes, MUSS einen oder mehrere Links auf verknüpfte ISO19139 Daten-Metadatensätze enthalten. Die Angabe der Links erfolgt dabei entsprechend des nachfolgenden Beispiels, wobei das Attribut title frei wählbar ist.

Allgemeines

Erläuterung

Mit dem OGC Web Coverage Service (WCS) wird ein Standard definiert, um Coverage Daten (z.B. Satellitenbilder oder digitale Geländemodelle) webbasiert zugänglich zu machen. Im Gegensatz zu anderen OGC-Webdiensten, wie dem Web Mapping Service (WMS), ermöglicht ein WCS Zugriff zu Coverage-Daten in Formen, die für die client-seitige Verarbeitung nutzbar sind. Es werden also keine gerenderten Kartenbilder bereitgestellt, sondern die originären Daten inklusive detaillierten Beschreibungen.

Im WCS-Standard ist eine reiche Syntax für Anfragen auf multidimensionale Daten und deren Metadaten definiert. Damit können Clients spezifische Bereiche von räumlichen/multidimensionalen Daten anfordern, die als "Coverage" bezeichnet werden. Ein Coverage kann eine zweidimensionale oder mehrdimensionale Abbildung eines Gebiets sein.

Versionen

Version 2.0.1

Erläuterung

Der WCS 2.0.1 besteht aus einer Core-Spezifikation und weiteren zum Teil verpflichtenden bzw. optionalen Erweiterungen:

flowchart BT
    subgraph service
    direction BT


    subgraph Extensions service
    direction BT

    I1[WCS-T] --> J(Service Model)
    I2[Processing] --> J(Service Model)
    I3[Range Subsetting] --> J(Service Model)
    I4[Scaling] --> J(Service Model)
    I5[CRS] --> J(Service Model)
    I6[Interpolation] --> J(Service Model)
    I7[WQS] --> J(Service Model)

    K1[GET-KVP] --> L(Protocol Binding)
    K2[POST-XML] --> L(Protocol Binding)
    K3[SOAP] --> L(Protocol Binding)
    K4[OAPI?] --> L(Protocol Binding)

    end

    subgraph Core service
    direction BT
    J[Service Model] --> M(WCS Core)
    L[Protocol Binding] --> M(WCS Core)
    end

    subgraph Application Profiles
    direction BT
    I11[EO-WCS]
    I12[MetOcean-WCS]
    end
    
    end

    M(WCS Core) --> N(OWS Common)
    M(WCS Core) --> E(Coverage Implementation Schema)
              

flowchart BT
    subgraph data
    direction BT

    subgraph Extensions data
    direction BT
 
    A1[GeoTIFF] --> B(Format Encoding)
    A2[netCDF] --> B(Format Encoding)
    A3[JPEG2000] --> B(Format Encoding)
    A4[GMLJP2] --> B(Format Encoding)
    A5[JPIP] --> B(Format Encoding)
    A6[GRIB2] --> B(Format Encoding)
    C[Referenceable Grid] --> D(Data Model)
    end

    subgraph Core data
    direction BT
    D[Data Model] --> E(Coverage Implementation Schema)
    B[Format Encoding] --> E(Coverage Implementation Schema)

    end
    

    E[Coverage Implementation Schema] --> F(GML)
    E[Coverage Implementation Schema] --> G(SWE Common)
	
    end
    E[Coverage Implementation Schema] --> M(WCS Core)
              

Anforderung

Der Web Coverage Service muss mindestens WCS 2.0.1 Core mit KVP-Binding unterstützen. [[INS TG Web Coverage Services]] (Anforderungen 1-2)

Version 2.1

Erläuterung

Für Web Coverage Services (WCS) gibt es gegenwärtig Inkonsistenzen zu Anforderungen aus OGC und INSPIRE:

Während die OGC WCS 2.0.1 Spezifikation für den Geodatendienst an sich umgesetzt werden kann, fehlen für die Ausgabedatei (GML Coverage oder GeoTIFF) die Möglichkeiten für das Unterbringen und Übermitteln von Elementen aus den INSPIRE-Datenmodellen aus Annex II (Orthophotos und Höhe). Vorschläge zur Auflösung dieser Inkonsistenzen finden sich bei [WCS Baumann 2019]. Die MIG des JRC hat diesen Vorschlag als Best Practice anerkannt, eine abschließende Regelung seitens INSPIRE steht jedoch noch aus.

Ungeachtet dessen besteht Regelungsbedarf um die Interoperabilität von WCS-Diensten in Deutschland zur gewährleisten:

WCS 2.1 beschreibt die Unterstützung von CIS 1.1 (OGC Coverage Implementation Schema). Für die Implementierung eines WCS nach [[INS TG Web Coverage Services]] wäre ein WCS 2.0.0 oder 2.0.1 ausreichend. Die Konformität zur INSPIRE TG ist jedoch nur mit einem WCS 2.1 gegeben, der CIS spezifiziert. Derzeit ist die serverseitige Implementierung von WCS 2.1 noch unzureichend unterstützt.

Empfehlung

Der Web Coverage Service SOLL WCS 2.1 Core mit KVP-Binding unterstützen.

Empfehlung

Aufgrund der geringen Unterstützung des WCS 2.0.1 durch gängige Clients, SOLL für zweidimensionale Coverages mit maximal drei Farbkanälen auch ein WCS der Version 1.0.0 angeboten werden.

Extensions

Erläuterung

Der WCS 2.0.1 beinhaltet eine große Anzahl an verpflichtenden bzw. optionalen Erweiterungen (vgl. und )

Empfehlung

Aus Gründen der OGC-Konformität SOLLEN weiterhin folgende Extensions unterstützt werden:

Daten-Service-Kopplung

Anforderung

Im Capabilities-Dokument SOLLEN ein Dienst- und alle verwendeten Datensatz-Metadatensätze verlinkt werden. Die Verlinkung SOLL entsprechend der INSPIRE-Vorgaben erfolgen.

Schlüsselwörter

Empfehlung

Im Capabilities-Dokument sollen folgende Schlüsselwörter enthalten sein:

Ausgabeformate

Erläuterung

In den INSPIRE-TG-WCS werden keine konkreten Spezifizierungen bzgl. Ausgabeformate gemacht. GML ist bereits als Teil des WCS-Core inkludiert. Sofern kein Output-Format bei der GetCoverage-Anfrage spezifiziert wird, wird das Range-Set als XML ausgeliefert. Dies ist insbesondere für sehr große Datensätze ineffizient und nicht sinnvoll. In den konkreten INSPIRE Daten-Spezifikationen oder Profilen werden zum Teil weitere Conformance-Requirements bzgl. Ausgabeformate definiert.

Anforderung

Als Ausgabeformat MUSS der WCS mindestens das Format GeoTIFF (image/tiff) ausliefern.

Empfehlung

Für das Format GeoTIFF DARF zusätzlich die Erweiterungen GEOTIFF:COMPRESSION=compression sowie GEOTIFF:JPEG_QUALITY=1-100 angeboten werden.

Empfehlung

Das native Format der Datengrundlage, die über den WCS angeboten wird, KANN in der DescribeCoverage-Datei angegeben werden.

Koordinatenreferenzsysteme

Anforderung

Angaben zu den unterstützten Koordinatenreferenzsystemen MÜSSEN in der opengis.net-Notation angegeben werden.

CoverageID

Erläuterung

Die CoverageID beim WCS ist ein Identifikator, der grundsätzlich von Software genutzt wird (Maschine-Maschine-Kommunikation). Um Fehler beim Auslesen eines Capabilities-Dokumentes auszuschließen, sollten sich diese Identifikatoren nur aus Zeichen zusammensetzen, deren Verwendung in unterschiedlichen Programmiersprachen unbedenklich ist. Außerdem sollte die Zahl der verwendeten Zeichen nicht zu groß sein, da es sonst bei Clients, die Kartenanfragen nur über HTTP GET umsetzen, zu Fehlern bei der Übertragung der Anfragen kommen kann.

Innerhalb eines Dienstes darf die gleiche CoverageID nicht mehrfach vorkommen, da diese ansonsten vom Client nicht mehr unterschieden werden kann. Die CoverageID muss einen W3C konformen NCName aufweisen. Das bedeutet konkret, dass die CoverageID nicht mit einer Zahl beginnen darf, sondern mit einem Namespacenamen oder zumindest mit einem Underscore. Der Namespacename wird durch Underscore _ oder Doppelpunkt : vom eigentlichen Coverage-Namen abgetrennt.

Anforderung

CoverageIDs MÜSSEN innerhalb eines Dienstes eindeutig sein und folgendem regulären Ausdruck entsprechen: [a-zA-Z][0-9a-zA-Z\.\-_:+]*.

Anforderung

CoverageIDs der WCS-Version 2.0.1 MÜSSEN einen W3C konformen NCName aufweisen.

Empfehlung

Die Länge der Zeichenkette des CoverageID SOLL so kurz wie möglich sein.

Coverage Subtype

Anforderung

Der WCS MUSS mindestens den CoverageSubtype RectifiedGridCoverage unterstützen.

Sonstiges

Art der Bereitstellung

Erläuterung

Durch das OGC wurde die SensorThings API (STA) Spezifikation in den Versionen 1.0 und 1.1 veröffentlicht. Die Spezifikation besteht aus zwei Teilen: einem zu "Sensing" (Version 1.1 und 1.0), in dem Methoden zum Verwalten und Abrufen von Observations (Beobachtungen) sowie Metadaten beschrieben sind, und einem zu "Tasking" (bisher nur Version 1.0), in dem Methoden für die Parametrierung von IoT-Geräten standardisiert werden.

Der "Sensing"-Teil wurde auf der Grundlage des OGC/ISO "Observation and Measurement" (O&M) Modells entwickelt. Der Schlüssel zu diesem Modell ist, dass eine "Observation" als eine Handlung modelliert wird, die ein Ergebnis ("result") erzeugt, dessen Wert eine Schätzung einer Eigenschaft des Beobachtungsziels oder "FeatureOfInterest" ist. Eine "Observation"-Instanz wird durch ihren Ereigniszeitpunkt (z. B. "resultTime" und "phenonmenonTime"), "FeatureOfInterest", "ObservedProperty" und das verwendete Verfahren (häufig ein "Sensor") klassifiziert. Darüber hinaus werden "Things" auch in der SensorThings-API modelliert, und ihre Definition folgt der ITU-T-Definition: „ein Objekt der physischen Welt (physische Dinge) oder der Informationswelt (virtuelle Dinge), das identifiziert und in Kommunikationsnetze integriert werden kann“.

                  classDiagram
                    Datastream -- Thing
                    Datastream -- ObservedProperty
                    Datastream -- Sensor
                    Observation -- Datastream
                    Observation -- FeatureOfInterest
                    Thing -- Location
                    HistoricalLocation -- Thing
                    Location -- HistoricalLocation
                    class Datastream{
                      +name: CharacterString
                      +description: CharacterString
                      +observationType: ValueCode
                      +unitOfMeasurement: JSON_Object
                      +observedArea: GM_Envelope
                      +phenomenonTime: TM_Period
                      +resultTime: TM_Period
                      +properties: JSON_Object
                    }
                    class Thing{
                      +name: CharacterString
                      +description: CharacterString
                      +properties: JSON_Object
                    }
                    class ObservedProperty{
                      +name: CharacterString
                      +definition: URI
                      +description: CharacterString
                      +properties: JSON_Object
                    }
                    class Sensor{
                      +name: CharacterString
                      +description: CharacterString
                      +encodingType: ValueCode
                      +metadata: Any
                      +properties: JSON_Object
                    }
                    class Location{
                      +name: CharacterString
                      +description: CharacterString
                      +encodingType: ValueCode
                      +location: Any
                      +properties: JSON_Object
                    }
                    class HistoricalLocation{
                      +time: TM_Instant
                    }
                    class Observation{
                      +phenomenonTime: TM_Object
                      +resultTime: TM_Instant
                      +result: Any
                      +resultQuality: DQ_Element
                      +validTime: TM_Period
                      +parameters: JSON_Object
                    }
                    class FeatureOfInterest{
                      +name: CharacterString
                      +description: CharacterString
                    }
                    class ValueCode{
                    }
                

Empfehlung

Die STA SOLL die Version 1.1 unterstützen. Eine wichtige Neuerung ist die Möglichkeit, für jede Entität ein properties Objekt zu definieren, in dem weitere Informationen, wie z.B. Links auf Metadaten, hinterlegt werden können. In der Version 1.0 ist dies nur für die Entität Thing möglich.

Persistenz / Identität

Erläuterung

Wie zuvor schon an verschiedenen Stellen erläutert, ist es in einer Geodateninfrastruktur (GDI) systemrelevant, dass die Datenquellen dauerhaft referenzierbar sind. Im Falle der STA handelt es sich um einen RESTful Ansatz, d.h. alle Entitäten sind über eine URI referenzierbar und aufrufbar. Die eindeutige Referenzierung erfolgt dabei durch eine Kombination der URI der entsprechenden Entität (z.B. Datastream) mit der @iot.id des jeweiligen Objekts. Beispiel: https://sta.host.de/v1.1/Datastreams({@iot.id})

Koordinatenreferenzsysteme

Erläuterung

Bei der Bereitstellung der STA ist zu beachten, dass sich der Standard (OGC SensorThings API Part 1: Sensing Version 1.1) bei der Angabe von Koordinaten nur auf das verwendete Encoding (hier GeoJSON) bezieht. Die GeoJSON Spezifikation (The GeoJSON Format) wiederum erlaubt nur die Verwendung von WGS84/urn:ogc:def:crs:OGC::CRS84 (Länge/Breite) Koordinaten.

Objektartennamen / Identifikatoren

Erläuterung

Alle Entitäten besitzen das Attribut @iot.id, das vom Typ Integer oder UUID sein kann und als primärer Identifikator verwendet wird. Zusätzlich besitzt jede Entität ein Attribut name, das jedoch eher die Funktion eines Titels hat. Da der name über Filterabfragen verwendet werden kann, sollten hier keine Sonderzeichen verwendet werden, die zu Problemen bei der URL-Auflösung führen. Für den Betrieb und die Funktionsfähigkeit einer GDI ist die Persistenz dieser Identifikatoren von großer Bedeutung.

Empfehlung

Das Attribut name SOLL innerhalb der API eindeutig sein und folgendem regulären Ausdruck entsprechen: [0-9a-zA-Z\.\-_: ].

Metadaten (properties Objekt)

Erläuterung

Weder über den OGC Standard noch aus INSPIRE-Spezifikationen gibt es Vorgaben zur Kopplung einzelner Entitäten mit Metadatenbeschreibungen. Die folgenden Empfehlungen bieten Vorschläge, wie Metadaten im Datenmodell integriert werden können. Die STA ab Version 1.1 bietet die Möglichkeit, für alle Entitäten ein frei konfigurierbares properties Objekt zu definieren. Es kann verwendet werden, um Links zu Metadaten in einem Metadatenkatalog bereitzustellen, OpenData-Kategorien zu benennen oder Informationen über den Zeitpunkt der letzten Aktualisierung zu transportieren. Auch Informationen über Datenaggregationen können hier abgelegt werden. Beispiel (https://iot.hamburg.de/v1.0/Datastreams(15864)):

Empfehlung

Über das Attribut topic SOLLEN Kategorien (z.B. OpenData) zugeordnet werden.

Empfehlung

Das Attribut metadata SOLL den Aufruf eines API ISO Metadatendokumentes einer Datensatzbeschreibung enthalten.

Empfehlung

Über die Attribute layerName und serviceName KÖNNEN weitere Untergliederungen definiert werden.

Empfehlung

Im Attribut resultNature SOLL angegeben werden, ob es sich um Primärdaten, prozessierte Daten oder simulierte Daten handelt. Hierfür sind folgende Schlagworte vorgesehen: primary, processed, simulated.

Empfehlung

Im Attribut infoLastUpdate SOLL der Zeitpunkt der letzten Aktualisierung dieser Entität in Form eines ISO 8601:2004 Zeitstempels - CCYY-MM-DDThh:mm:ss.sssZ - angegeben werden.

Empfehlung

Wenn es sich bei den Daten um Aggregate handelt, KÖNNEN über die Attribute aggregateDuration (Aggregationszeitraum) aggregateSource.Datastream@iot.id (ID des Datastreams der Quelldaten) sowie aggregateSource.Datastream@iot.navigationLink (Link auf den Datastream der Quelldaten) weitere Angaben hierzu hinterlegt werden.