Vom 15. bis 17. November 2021 veranstalteten OGC und ISO/TC 211 gemeinsam die Virtueller Code Sprint zur Geospatial-API im November 2021Der Code Sprint konzentrierte sich auf die Verfeinerung der OGC API – Features Standard und seine ISO-Version, ISO 19168.

OGC API – Features bietet die Möglichkeit, räumliche Daten im Web bereitzustellen, zu erstellen, zu ändern und abzufragen. Der Standard gibt Anforderungen und Empfehlungen für die Erstellung von APIs an, die einer standardisierten und konsistenten Methode zum Teilen von Feature-Daten folgen. Der Standard ist in mehrere Teile unterteilt, sodass ein Dienst nur die für sein Angebot relevanten Teile verwenden muss. Dadurch bleibt er leicht und die Entwicklung und Wartung ist einfacher. 

OGC API – Features – Teil 1: Kern (die ISO-Version ist ISO 19168-1:2020 Geospatial API for Features) konzentriert sich auf die Bereitstellung von Feature-Inhalten. OGC API – Features – Teil 2: Koordinatenreferenzsysteme durch Referenz (ISO/DIS 19168-2) fügt Unterstützung für andere Koordinatenreferenzsysteme als das einzige in Teil 1 angegebene CRS, WGS84, hinzu.

An OGC-Code-Sprint ist eine kollaborative und integrative Veranstaltung, die auf innovativer und schneller Programmierung mit minimalen prozessualen und organisatorischen Einschränkungen basiert, um die Entwicklung neuer Anwendungen und Kandidatenstandards zu unterstützen. 

In den letzten drei Jahren haben wir den Prozess zur Organisation und Durchführung von OGC-Code-Sprints verfeinert. Für diesen Geospatial API Virtual Code Sprint im November 2021 wurde ein neuer Ansatz erprobt: die Verwendung Discord um Video-, Sprach- und Chat-Funktionen bereitzustellen. Ebenfalls erstmals für die Code-Sprints haben wir parallel zu Breakout-Räumen für erfahrene Entwickler einen Mentor-Stream durchgeführt. Die Mentor-Streams wurden entwickelt, um Entwicklern den Einstieg in die OGC-API-Funktionen und die ISO 19168-1:2020-Standards zu erleichtern.

Tag 1 begann mit Begrüßungsworten von Dr. Joana Simoes (OGC DevRel) und Peter Parslow (gewählter Vorsitzender von ISO/TC 211). Nach den Begrüßungsworten stellten Clemens Portele (interactive instruments) und Panagiotis „Peter“ Vretanos (CubeWerx) die Ziele des Sprints vor. Am ersten Tag diskutierten wir auch über abfragbare und Geometrievereinfachungund Mentor Stream-Sitzungen am Weitergabe von Daten durch OGC API – Features unter der Leitung von Dr. Joana Simoes (OGC) sowie eine weitere Sitzung zum Thema Einführung in SpatioTemporal Asset Catalogs (STAC) und dessen Verwendung von OGC-API-Funktionen geleitet von Chris Holmes (Planet), Rob Emanuele (Microsoft) und Matthew Hanson (Element 84). Zwischen den Diskussionen und den Mentor-Streams wurde viel programmiert.

Am zweiten Tag gab es Mentor Stream-Sitzungen über So laden Sie Featuredaten in Ihre Frontend-Anwendung unter der Leitung von Antonio Cerciello (EarthPulse) und Testen von Implementierungen von OGC API – Features für die Einhaltung des Standards unter der Leitung von Dr. Gobe Hobona (OGC). Es gab vorläufige Demos zur Geometrievereinfachung durch OGC API – FeaturesAuch zwischen den Diskussionen und den Mentor-Streams wurde viel mehr programmiert.

Am dritten Tag gab es weitere Programmierarbeiten sowie einen Features and Geometry JSON Lightning Talk unter der Leitung von Clemens Portele (Interactive Instruments) und Peter Vretanos (CubeWerx) und eine abschließende Demonstrationssitzung. Die Screenshots der abschließenden Demo finden Sie am Ende dieses Artikels.

 

Stunden gelernt

  • Es besteht die Notwendigkeit, eine JSON-FG-Fallback-Geometrie anzubieten, um unterschiedliche Situationen zu unterstützen, d. h. wann sie vorhanden sein sollte und wann nicht.
  • Zur Vereinfachung der Geometrie begannen die Sprint-Teilnehmer mit der Zoomstufe, dem Maßstabsnenner und einer Reihe anderer Parameter. Am Ende des Code-Sprints herrschte Einigkeit darüber, dass wir die Zoomstufe verwenden sollten.
  • Die Sprint-Teilnehmer wollten Situationen unterstützen, in denen der Server je nach Zoomstufe einige, aber nicht alle Funktionen zurückgeben könnte.
  • Außerdem wurde ein Anwendungsfall für das Clipping demonstriert. Wenn Sie beispielsweise New York betrachten, müssen Sie nicht die gesamte US-Küstenlinie erfassen.
  • Auch im Umgang mit JSON-Schemas machten die Sprint-Teilnehmer Fortschritte.
  • Die Sprint-Teilnehmer werden im JSON-FG-Repository ein Problem melden, um nach einer Erweiterung zu suchen, mit der etwas mit der Clipbox (künstliches Segment) markiert werden kann. MapML hat diese Funktion hinzugefügt. Die Alternative ist immer die Anforderung eines zusätzlichen Rahmens. Das heißt, ob eine Clipbox größer als die Daten sein darf. Beispielsweise, ob eine tatsächliche Geometrie in einem Shapefile über die Grenzen von -180 bis 180 Grad hinausgehen kann.
  • Der Code-Sprint war gut für JSON-FG und OGC API – Features.
  • JSON-FG könnte als Konformitätsklasse für OGC API – Features erst nachdem JSON-FG als offizieller OGC-Standard übernommen wurde.
  • STAC verfügt über eine Reihe von Bereitstellungsmustern. Eines dieser Muster stellt ein OGC API – Features Schnittstelle, die für die Suche verwendet wird.
  • Die Idee ist, eine Abstimmung zwischen STAC und OGC API – Features. Von dieser Ausrichtung werden auch OGC API-Records profitieren.
  • Einige der Fragen lauten: Wie dokumentieren/beschreiben wir Metadaten für die von OGC API – Features, ISO 19168-1 und die zugehörigen Kandidatenstandards wie STAC und OGC API – Records.
  • STAC wird ein Profil von OGC API Records sein. Die STAC-Community arbeitet an einer Definition eines Dataset-Records für STAC, der mit dem Record-Konzept von OGC API Records übereinstimmt.
  • Der Geospatial API Virtual Code Sprint im November 2021 demonstrierte auch den Kompatibilitätsmodus. Beispielszenario: Wenn Sie ein 3D-Gebäude haben, könnten Sie JSON-FG verwenden, aber wenn Sie eine einfachere Geometrie anzeigen möchten, stellt der Server GeoJSON bereit.

Future Work

Die Teilnehmer gaben folgende Empfehlungen für die zukünftige Arbeit.

Innovationsprogramm

  • Über die Lieferung MUDDI Daten verwenden OGC API – Features und JSON-FG
  • Entwicklung eines Spezifikationsentwurfs für neue Funktionen, die für zukünftige Versionen in Betracht gezogen werden.
  • Implementierungen der neuen Funktionen, die für zukünftige Erweiterungen in Betracht gezogen werden: Common Query Language (CQL), CRUD (Create Replace Update Delete), Eigenschaftsauswahl, OpenAPI 3.1, bedingte Anforderungen, Web-Caching.
  • Sicherheit für OGC API Standards Pilot (dies könnte die verschiedenen Sicherheitsebenen betreffen, z. B. DCS, OpenAPI). Dies könnte eine gute Kombination mit der CRUD-Erweiterung sein.
  • Weitere Codegenerierungsaufgaben in zukünftigen Code-Sprints.

Normenprogramm

  • CQL abschließen
  • Weitere Abstimmung zwischen STAC und OGC API – Aufzeichnungen
  • In der ISO wird derzeit über Teil 2 abgestimmt. Daher besteht möglicherweise die Möglichkeit, im Rahmen des Normungsprogramms eine Veranstaltung durchzuführen, sobald ISO 19168-2 genehmigt wurde.

Schlussfolgerungen

Der Code-Sprint hat seine Ziele erfolgreich erreicht. Die Sprint-Teilnehmer konnten neue Funktionen diskutieren und Prototypen entwickeln. Die Sprint-Teilnehmer fanden auch die Tutorials und Lightning Talks im Mentor Stream hilfreich.

In Bezug auf den neuen Ansatz für OGC Code Sprints gaben die Sprint-Teilnehmer die folgenden Empfehlungen:

  • Zeichnen Sie die Tutorials auf, damit Teilnehmer, die eines verpassen, es später nachholen können.
  • Organisieren Sie einen Mentor-Stream vom Anfänger bis zum Experten, der einen Entwickler von den ersten Schritten bis hin zu fortgeschritteneren Themen begleitet. Dies würde ein 3-tägiges Programm erfordern.
  • Die Discord-Idee war echt cool!
  • In Zukunft könnten wir die anderen Textkanäle nutzen. Vielleicht sollte die erste Nachricht erklären, dass „wir diesen Kanal auf eine bestimmte Weise nutzen werden …“

Weitere Informationen zum Sprint finden Sie im Geospatial API Code Sprint-GitHub-Repository vom November 2021.