Ausgangslage

In den Konventionen des AK Metadaten (Kap. 4.3.2) steht:

"Für jeden Dienst-Metadatensatz gilt, dass die URL zum Dienst in einem connectPoint-Element ([ISO 19119], Table C.2 No. 6) geführt werden muss. Hier ist die URL einzutragen, unter der das Capabilities-Dokument bzw. der Service Feed des Dienstes (Atom) bezogen werden kann (siehe auch Kapitel 5)."

Fragestellungen

Wie funktioniert das für OGC API-Features? Was für einen "Endpunkt" zum Dienst wird hier erwartet (sicher keine ISO 19119)?

Kann der Link auf eine FeatureCollection oder Landingpage verwendet werden? Wie ist die Meinung des AK Geodienste zu dieser Frage?

Wie müsste der AK Metadaten aus unserer Sicht das Konventionen-Dokument fortschreiben?

Diskussion und weiteres Vorgehen

 auf der Sitzung des AK Geodienste vom  


Ergebnis

Die Umsetzung ist gegebenenfalls unterschiedlich in den Bundesländern geregelt. Es gibt Diskussionen dazu auch in der MIG-T: https://github.com/INSPIRE-MIF/helpdesk/discussions/161

Aus Sicht des AK Geodienste, wäre es daher wünschenswert, eine europäische Regelung zu finden. Um diesen Prozess zu unterstützen, sammelt der AK auf dieser Site Umsetzungsbeispiele und vergleicht dabei Vor- und Nachteile.



Bundesland

Bundesbehörde

Wie ist die Umsetzung bisher geregelt? Welche Vorgaben bestehen?

Beispiele für die Umsetzung

Vorteile

(Plus)

Nachteile

(Minus)

Gesamtbewertung / Fragen

(Frage)  

1BKG (Eintrag von Schütze, GDI-DE AK Metadaten)URL der landing page: pathohne Beispiel, bisher nur Template für MD für geplanten Dienst
  • jeder Dienst führt diese URL, weil Pflichtangabe, siehe OGC API - Features - Part 1: Core: Kapitel 7.2. API landing page, 7.2.1 Operation, "The server SHALL support the HTTP GET operation at the path /."

  • wenn API definition vorhanden, dann hierin aufgeführt bzw. unter path/api

  • Inhalt für Entwickler bedeutsamer als API definition, siehe 7.3.2. Response"The idea is that any OGC API Features implementation can be used by developers that are familiar with the API definition language(s) supported by the server. For example, if an OpenAPI definition is used, it should be possible to create a working client using the OpenAPI definition. The developer may need to learn a little bit about geometry data types, etc., but it should not be required to read this standard to access the data via the API."

kein direkter Zugriff auf die API definition


2Landesvermessung und Geobasisinformation Brandenburg (Eintrag: Noack, GDI-BB AK Geodienste)

URL der landing page

(siehe auch Beitrag im GitHub-Issue)

Verwaltungsgrenzen Brandenburg mit Berlin

Bodenrichtwerte Brandenburg





3





4





5





6





7





8





9





10





Empfehlung des AK Geodienste

In der Sitzung des AK Geodienste am 08.03. wurde entschieden, dass auf Standard Landing-Page verwiesen werden sollte (Empfehlung des AK-Geodienste an den AK Metadaten), da bei unterschiedlichen Clients über Content-Negotiation eine geeignete Kommunikation sichergestellt ist. Die Verlinkung sollte daher nach folgendem Beispiel erfolgen:

srv service info:

<srv:serviceType>
    <gco:LocalName>download</gco:LocalName>
</srv:serviceType>
<srv:serviceTypeVersion>
    <gco:CharacterString>OGC API-Features</gco:CharacterString>
</srv:serviceTypeVersion>

srv contains operation:

<srv:containsOperations>
    <srv:SV_OperationMetadata>
        <srv:operationName>
            <gco:CharacterString>apiDescription</gco:CharacterString>
        </srv:operationName>
        <srv:DCP>
            <srv:DCPList codeList="./resources/codelist/gmxCodelists.xml#DCPList" codeListValue="WebServices"/>
        </srv:DCP>
        <srv:connectPoint>
            <gmd:CI_OnlineResource>
                <gmd:linkage>
                    <gmd:URL>https://www.geoportal.rlp.de/spatial-objects/575</gmd:URL>
                </gmd:linkage>
            </gmd:CI_OnlineResource>
        </srv:connectPoint>
    </srv:SV_OperationMetadata>
</srv:containsOperations>

gmd transfer options:

<gmd:transferOptions>
    <gmd:MD_DigitalTransferOptions>
        <gmd:onLine>
            <gmd:CI_OnlineResource>
                <gmd:linkage>
                    <gmd:URL>
https://www.geoportal.rlp.de/spatial-objects/575
                   </gmd:URL>
               </gmd:linkage>
               <gmd:protocol>
                   <gco:CharacterString>OGC API-Features</gco:CharacterString>
               </gmd:protocol>
          </gmd:CI_OnlineResource>
      </gmd:onLine>
    </gmd:MD_DigitalTransferOptions>
</gmd:transferOptions>

Es fehlt noch eine Vorgabe für die Daten-Service-Kopplung in der API Description. --> sollte europäischer Ebene geregelt werden!


4 Kommentare

  1. Renate Zweer sagt:

    Guten Abend,

    ich möchte der Diskussion keinesfalls vorgreifen. Hier nur zur Information: Im AK Metadaten beschäftigen wir uns gerade mit der Frage, wie OGC API Feature in den Dienste-Metadaten abgebildet werden kann. Wir freuen uns auf die Gedanken aus dem Nachbar-AK.

    1. Sabine Schütze sagt:

      Ich bekräftige die Aussage von Frau Zweer. Wir, AK MD, sind gespannt auf die Meldungen des AK Geodienste. Als Anstoß habe ich die BKG-seitige Meinung, die sich aus der Arbeit am Ticket https://redmine.gdi-de.org/issues/8403 entwickelte, auf dieser Seite hinterlassen.

  2. Daniela Witter sagt:

    siehe https://github.com/INSPIRE-MIF/helpdesk/discussions/161

    1. Sabine Schütze sagt:

      Stand heute erfolgte der letzte Eintrag am 25.Sept.2023
      Zusammenfassend: für INSPIRE-MD bietet sich eine zu dritt abgestimmte Möglichkeit der Beschreibung des OGC API-Features im Datensatz-MD via "Vereinfachte Daten-Dienste-Kopplung": "... the landing page should be the most appropriate link to use in the Resource Locator metadata element." (Kommentar von faviovinci, 4.Sep.2023)
      Weiterhin ein Verweis auf die INSPIRE-Codelist mit dem Listeintrag "OGC API-Features".
      Die Beschreibung des Dienstes mit den bisher üblichen Service-Metadaten wurde nicht behandelt. 2 Beispiele mit Meinungen aus Deutschland blieben unkommentiert.