Forum GéoCommuns

Spécification commune pour API photos

Bonjour à tous,

J’ouvre ce sujet un peu technique pour faire un récapitulatif et amorcer les échanges sur une spécification commune d’API pour mettre à disposition des photos.

Objectif : permettre l’interopérabilité entre plusieurs solutions clients/serveurs qui pourraient arriver prochainement.

Quelques ressources :

J’invite toutes les personnes motivées par le sujet à venir échanger ici, on peut à court terme faire une séance de travail en visio pour poser les premières briques.

Cordialement.

1 Like

STAC est sûrement la voie la plus intéressante à explorer car déjà adoptée par une partie des industriels du secteur de l’imagerie.

Pour faire simple, il y a 3 niveaux dans STAC:

  • les catalogues (ce qui est disponible sur un serveur)
  • les collections (des séries de contenus)
  • les items (la description granulaire d’un contenu)

Dans notre cas, les items pourraient être les photos une à une.
Les collections, des séquences de photos provenant d’une même prise de vue et d’un même contributeur.
Le catalogue permet d’exposer le tout, de façon hiérarchique.

De mon point de vue, ce qui manque à STAC c’est la gestion d’un grand nombre d’items, par exemple sous la forme d’un catalogue consolidé ou des collections consolidées qui seraient un plus.

STAC propose déjà des API standardisé, et il y a pas mal de code et d’outils existants.

1 Like

Je vois qu’il y a également une extension de STAC pour gérer des photos classiques : GitHub - stac-extensions/perspective-imagery: STAC extension for describing perspective imagery collected by photogrammetric or non-photogrammetric cameras

À priori on a donc tout ce qu’il faut avec ce modèle d’API. Est-ce que l’on se ferait pas un dépôt/snippet quelque part avec un modèle typique pour ces 3 niveaux d’objets ?

Quand tu parles de consolidation, c’est la fusion de catalogues à travers plusieurs serveurs, ou le fait qu’un catalogue va devenir trop lourd pour un serveur si on a des millions de photos ?

Ah bien, j’avais pas vu ça.

Je vais voir pour générer les json STAC à partir de mes catalogues actuels, en reprenant les infos EXIF pertinentes.

Je pensais plus à limiter le nombre de json pour les items et à les regrouper d’un façon ou d’une autre, sinon pour récupérer l’intégralité d’un catalogue, il faut faire plein de petites requêtes, ce qui ne facilite pas une indexation couvrant plusieurs dépôts STAC.

Trouvé !

Ceci permet de regrouper toute une collection en un seul fichier json.

Top, ça me permettra de faire le test en branchant la visionneuse web voir si c’est interopérable :wink:

1 Like

Voilà un essai de génération de STAC à l’aide de PyStac sur un lot d’une centaine de photos:

https://osm.cquest.org/LibresVues/stac/

J’ai voulu tenter une visualisation via l’outil STAC Browser, il râle un peu : https://radiantearth.github.io/stac-browser/#/external/osm.cquest.org/LibresVues/stac/catalog.json

CORS… comme d’habitude.

C’est bon maintenant !

1 Like

En commençant à creuser un peu sur l’utilisation, je me rends compte que pour que ça soit viable côté client (c’est à dire pas avoir à télécharger des métadonnées par milliers), ce serait intéressant d’avoir en frontal une STAC API : stac-api-spec/overview.md at master · radiantearth/stac-api-spec · GitHub

Notamment car un appel /search est disponible et gère ce que l’on attendrait d’une API classique : STAC API

À priori il y a plusieurs solutions logicielles qui permettent de transformer un catalogue STAC en API STAC, tu penses qu’il y aurait moyen d’en déployer une pour faire des tests ?

J’ai fait ma propre petite API maison avant de découvrir STAC et son API.

Ma prochaine étape consistera à déployer une STAC API vu que du code existe déjà pour ça :slight_smile:

As-tu pu quand même exploiter mes fichiers STAC ?

OK ça marche. J’ai commencé à les exploiter (tous petits bouts de code ici https://gitlab.com/PanierAvide/geovisio/-/compare/develop...feature%2Fstac?from_project_id=34672569 ) mais le gros problème c’est l’absence de code pré-existant pour lire/parser des catalogues/items STAC en JavaScript, donc tout à réimplémenter. Au-delà du fait que ce serait long, il y a le côté qu’on est obligé de récupérer tout le catalogue et faire le tri côté client pour trouver une photo proche d’une position… Viable sur un petit catalogue, mais ça ne passera pas à l’échelle.

C’est pour ça que je pense que je vais basculer la brique serveur sur laquelle je bosse en API STAC, mais ce serait intéressant d’en avoir une tierce pour vérifier la bonne compatibilité de la visionneuse :wink:

1 Like

Bonjour,

Petite avancée côté GeoVisio, la spécification STAC est implémentée côté serveur, visible sur l’instance de test : https://360-dev.pavie.info/stac/

La suite c’est de finaliser le support côté visionneuse :wink:

Cordialement.

2 Likes

Salut,

La visionneuse est désormais compatible STAC API Item Search, donc à priori si le stock de photos que tu as de ton côté peut être interrogé via une route /search, la visionneuse peut s’y brancher sans soucis.

Pour référence : visionneuse sur NPM, doc d’utilisation

Je vais très probablement dès cette semaine bosser sur un site plus “clé en main”, avec une carte cliquable d’où l’on pourra activer la visionneuse.

6 Likes

Petite question : dans les propriétés gérées par STAC ou une de ses extensions, est-ce que tu avais repéré un champ qui pourrait permettre la distinction entre une photo 360° ou classique/plate ?

J’ai rien trouvé, le plus approchant serait GitHub - stac-extensions/perspective-imagery: STAC extension for describing perspective imagery collected by photogrammetric or non-photogrammetric cameras avec la longueur de focale, mais il manque un attribut de type fov.

Vu que c’est à l’état de proposition, une issue/PR pourrait peut être compléter cette extension.

OK, j’ai ouvert un ticket pour lancer la discussion, ce serait idéal de voir ça documenté/intégré dans cette extension même si elle n’est qu’à l’état de proposition.

1 Like

Petite réflexion de retour de SotM… et suites aux rélfexions sur les autres fonds d’images qui pourraient potentiellement être intégrées au commun.
A quel point cela serait problématique d’ajouter la notion d’altitude de prise de vue de la photo ? Cela pourrait permettre d’ajouter un paramètre permettant d’affiner l’affichage et d’améliorer la compréhension que nous pourrions avoir des objets observés.
Possible que ce soit particulièrement pénible à implémenter à exploiter et que partir d’une hypothèse Z = altitude minimale d’un MNT est la plus pertinente à ce stade…

Oui, on va avoir besoin du Z, sous sa forme métrique, et peut-être sous une autre pour distinguer des photos prises en intérieur, à différents niveaux d’un bâtiment.

En tout cas aucun problème niveau spécification STAC, comme la géométrie associée à une photo est en GeoJSON, elle peut intégrer la dimension Z (cf stac-spec/item-spec.md at master · radiantearth/stac-spec · GitHub ).

2 Likes