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

(question)  

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!


9 Comments

  1. Renate Zweer

    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

      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

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

    1. Sabine Schütze

      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.

  3. Sabine Schütze

    Fragen des AK Metadaten an AK Geodienste

    Kommentar 1 : obenstehende Angabe für ServiceTypeVersion="OGC API-Features" ist nachvollziehbar > übernommen. Dennoch Nachfrage, ob Versionierungen des Diensttyps erwartbar, denn dann sollte der Eintrag dem Muster "[Kurzbezeichnung des Dienstes]+[Versions-Nr.]" folgen, wie z.B. "OGC:WMS 1.3.0"

  4. Sabine Schütze

    Kommentar 2 : ist die Angabe in connectPoint tatsächlich die URL der Standard Landing-Page? > wenn ja, aus unserer Sicht nachvollziehbar. Ist demnach die Bezeichnung "Standard Landing-Page" die korrekte Bezeichnung für die URL?

  5. Sabine Schütze

    Kommentar 3 : Ist die Schreibweise des Eintrags "apiDescription" in operationName begründet? Wodurch? Bitte um Begründung zur Wahl dieser Bezeichnung.

  6. Sabine Schütze

    Kommentar 4 : Was bezweckt der Eintrag protocol in transferOptions? Das Beispiel enthält keine spezifische Information, sondern wiederholt den Eintrag aus serviceTypeVersion. Dieses MD-Element ist lt. ISO-Standard optional. Wird diese Angabe auch für andere Dienste benötigt?

    Auf Hinweis von D.Thalheim wird dieses Element durch das INSPIRE Good practice Dokument zur Vereinfachung der Daten-Dienste-Kopplung eingeführt, siehe https://inspire.ec.europa.eu/metadata-codelist/ProtocolValue. Bisher übernimmt die GDI-DE diese Regelung nicht, daher wäre auch die Regelung zum Element protocol nicht notwendig.

  7. Sabine Schütze

    ergänzend zum Kommentar 1:

    Kommentar 1b : Wie sieht es mit MD aus, die nicht im INSPIRE-Kontext stehen? Können die Felder wie bisher üblich entsprechend den Erwartungen der ISO19119 befüllt werden, also serviceType ="[Kurzbezeichnung des Dienstes]" und serviceTypeVersion ="[Versions-Nr.]"?