Du 15 au 17 novembre 2021, l'OGC et l'ISO/TC 211 ont organisé conjointement la Sprint de code virtuel de l'API géospatiale de novembre 2021. Le sprint de code s'est concentré sur le raffinement de la OGC API – Features Norme et sa version ISO, ISO 19168.

OGC API – Features offre la possibilité de servir, de créer, de modifier et d'interroger des données spatiales sur le Web. La norme spécifie les exigences et les recommandations pour la création d'API qui suivent une méthode standard et cohérente de partage des données d'entités. La norme est divisée en plusieurs parties afin qu'un service n'ait à utiliser que les parties pertinentes pour ses offres, ce qui la rend légère et plus facile à développer et à maintenir. 

OGC API – Features – Partie 1 : Core (la version ISO étant ISO 19168-1:2020 Geospatial API for Features) se concentre sur la diffusion de contenu d’entités. OGC API – Features – La partie 2 : Systèmes de référence de coordonnées par référence (ISO/DIS 19168-2) ajoute la prise en charge de systèmes de référence de coordonnées autres que le seul SCR spécifié dans la partie 1, WGS84.

Un OGC Code Sprint est un événement collaboratif et inclusif, axé sur une programmation innovante et rapide, avec des contraintes organisationnelles et de processus minimales, afin de soutenir le développement de nouvelles applications et de normes candidates.

Au cours des trois dernières années, nous avons perfectionné le processus d'organisation et d'animation des sprints de code OGC. Pour le sprint de code virtuel de novembre 2021 consacré à l'API géospatiale, une nouvelle approche a été testée : l'utilisation de Discord pour la visioconférence, l'audio et le chat. Autre nouveauté pour ces sprints : nous avons organisé une session de mentorat en parallèle des ateliers en petits groupes pour les développeurs experts. Ces sessions de mentorat visaient à aider les développeurs à se familiariser avec les fonctionnalités de l'API OGC et la norme ISO 19168-1:2020.

La première journée a débuté par les discours de bienvenue du Dr Joana Simoes (OGC DevRel) et de Peter Parslow (président élu de l'ISO/TC 1). Après les discours de bienvenue, Clemens Portele (instruments interactifs) et Panagiotis « Peter » Vretanos (CubeWerx) ont présenté les objectifs du sprint. Le premier jour, nous avons également eu des discussions sur interrogeables et simplification de la géométrie, et des sessions Mentor Stream sur Partage de données via OGC API – Features dirigée par le Dr Joana Simoes (OGC), ainsi qu'une autre session sur Introduction aux catalogues d'actifs spatio-temporels (STAC) et à son utilisation des fonctionnalités de l'API OGC animé par Chris Holmes (Planet), Rob Emanuele (Microsoft) et Matthew Hanson (Element 84). Entre les discussions et les sessions de mentorat, il y avait beaucoup de codage.

Le deuxième jour, nous avons eu des sessions Mentor Stream sur Comment charger des données de fonctionnalités dans votre application frontale dirigé par Antonio Cerciello (EarthPulse) et Tester les implémentations de OGC API – Features pour la conformité à la norme dirigé par le Dr Gobe Hobona (OGC). Il y a eu des démonstrations préliminaires de simplification géométrique grâce à OGC API – FeaturesDe même, entre les discussions et les séances de mentorat, il y avait beaucoup plus de codage.

Le troisième jour, nous avons poursuivi le codage, ainsi qu'une conférence JSON Lightning sur les fonctionnalités et la géométrie animée par Clemens Portele (instruments interactifs) et Peter Vretanos (CubeWerx), et une séance de démonstration finale. Consultez les captures d'écran de la démonstration finale à la fin de cet article.

 

Leçons apprises

  • Il est nécessaire de proposer une géométrie de secours JSON-FG pour prendre en charge différentes situations, c'est-à-dire quand elle doit être présente et quand elle ne doit pas l'être.
  • Pour simplifier la géométrie, les participants au sprint ont commencé avec le niveau de zoom, le dénominateur d'échelle et un certain nombre d'autres paramètres, puis à la fin du sprint de code, il y a eu un accord sur le fait que nous devrions utiliser le niveau de zoom.
  • Les participants au sprint souhaitaient prendre en charge les situations dans lesquelles, en fonction du niveau de zoom, le serveur pouvait renvoyer certaines fonctionnalités et pas toutes.
  • Un cas d'utilisation du découpage a également été démontré. Par exemple, si vous regardez New York, vous n'aurez pas besoin d'obtenir l'intégralité du littoral américain.
  • Les participants au sprint ont également progressé sur la façon de gérer les schémas JSON.
  • Les participants au sprint déposeront un problème dans le dépôt JSON-FG pour rechercher une extension permettant de marquer quelque chose avec la clipbox (segment artificiel). MapML a ajouté cette capacité. L'alternative est toujours d'exiger une bordure supplémentaire. Il s'agit de savoir si une clipbox doit être autorisée à être plus grande que les données. Par exemple, si une géométrie réelle dans un shapefile peut aller au-delà des limites de -180 à 180 degrés.
  • Le sprint de code a été bon pour JSON-FG et OGC API – Features.
  • JSON-FG pourrait être considéré comme une classe de conformité pour OGC API – Features seulement après que JSON-FG ait été adopté comme norme officielle de l'OGC.
  • STAC possède un certain nombre de modèles de déploiement. L'un des modèles expose un OGC API – Features interface, utilisée pour la recherche.
  • L'idée est d'avoir un alignement entre STAC et OGC API – Features. Cet alignement bénéficiera également à l’API OGC – Records.
  • Certaines des questions sont de savoir comment documenter/décrire les métadonnées des ressources proposées par OGC API – Features, ISO 19168-1 et leurs normes candidates associées telles que STAC et OGC API – Records.
  • STAC sera un profil des enregistrements API OGC. La communauté STAC travaille sur une définition d'un enregistrement de jeu de données pour STAC qui serait aligné sur le concept d'enregistrement des enregistrements API OGC.
  • Le sprint de code virtuel de l'API géospatiale de novembre 2021 a également démontré le mode de compatibilité. Exemple de scénario : si vous avez un bâtiment en 3D, vous pouvez utiliser JSON-FG, mais si vous souhaitez afficher une géométrie plus simple, le serveur fournira GeoJSON.

Travaux futurs

Les participants ont formulé les recommandations suivantes pour les travaux futurs.

Programme d'innovation

  • À propos de la livraison MUDDI données à l'aide OGC API – Features et JSON-FG
  • Développement d’un projet de spécifications pour de nouvelles capacités envisagées pour les versions futures.
  • Implémentations des nouvelles fonctionnalités envisagées pour les extensions futures : Common Query Language (CQL), CRUD (Créer Remplacer Mettre à jour Supprimer), sélection de propriété, OpenAPI 3.1, requêtes conditionnelles, mise en cache Web.
  • Sécurité pour le pilote des normes API OGC (cela peut impliquer les différents niveaux de sécurité, par exemple DCS, OpenAPI). Cela pourrait être une bonne combinaison avec l'extension CRUD.
  • Autres tâches de génération de code dans les futurs sprints de code.

Programme de normes

  • Compléter le CQL
  • Alignement supplémentaire entre les API STAC et OGC – Enregistrements
  • Un vote est en cours au sein de l'ISO pour la partie 2. Il pourrait donc être possible d'organiser un événement dans le cadre du programme de normalisation une fois que la norme ISO 19168-2 aura été approuvée.

Conclusions

Le sprint de code a atteint ses objectifs avec succès. Les participants au sprint ont pu discuter et prototyper de nouvelles fonctionnalités. Les participants au sprint ont également trouvé que les tutoriels et Lightning Talk fournis dans le Mentor Stream étaient utiles.

Concernant la nouvelle approche des OGC Code Sprints, les participants au sprint ont proposé les recommandations suivantes :

  • Enregistrez les tutoriels, de sorte que si un participant en manque un, il puisse le rattraper plus tard
  • Organisez un programme de mentorat de niveau débutant à expert qui accompagne un développeur tout au long de sa formation, depuis la mise en route jusqu'à des sujets plus avancés. Cela nécessiterait un programme de 3 jours.
  • L’idée de Discord était vraiment cool !
  • À l’avenir, nous pourrions utiliser les autres canaux de texte. Le premier message devrait peut-être expliquer que « nous allons utiliser ce canal d’une manière particulière… »

Pour en savoir plus sur le Sprint, consultez le dépôt GitHub du Sprint de code de l'API géospatiale de novembre 2021.