Sie zeigen eine alte Version dieser Seite an. Zeigen Sie die aktuelle Version an.

Unterschiede anzeigen Seitenhistorie anzeigen

« Vorherige Version anzeigen Version 10 Nächste Version anzeigen »

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


2





3





4





5





6





7





8





9





10





  • Keine Stichwörter