Hug-A-Panorama: Towards an AI inference service for Panoramax

Version française ci-dessous.

Hi all,

I am a member of the Geoinformation for Humanitarian Aid team at HeiGIT, and I think it’s about time to share some of our experiences with Panoramax here. First of all, thanks a lot for the amazing work! As an applied research institution that provides its partners with open geoinformation and open software, we have been observing the development of Panoramax for quite some time with great interest.

Last year, we have set up a non-federated, restricted access instance of Panoramax for our AILAS project that aims at creating a weather-adaptive, AI-supported routing system for regions with unpaved roads by extracting relevant features from street-level imagery to assess the passability of roads under different meteorological conditions. In this context, it was wonderful to see how swiftly the Panoramax developers took up our partners’ (and others’) requirement for the possibility to restrict sequence/image visibility to logged-in users.

We also started to develop a proof of concept of a service that can run AI inference on entire regions of interests or entire sequences in Panoramax. The goal is to be able to automatically trigger detection, segmentation, or classification (e.g. of road surfaces, building materials, POI like pharmacies) with any Panoramax upload, in order to generate actionable data for (among others) disaster preparedness and anticipatory humanitarian action. Most importantly, the service would push the results of the inference back to Panoramax as annotations, in compliance with the annotations scheme.

For some first experimentation, we implemented the service so that it could run inference with different (configurable) detection, instance segmentation, and classification models from HuggingFace. The match between the generated labels with the appropriate Panoramax annotation is made through a YAML config file, so that e.g. the road surface classification output label “asphalt” is written to Panoramax as “osm|surface=asphalt” plus the metadata.

We continued to add other experimental features such as geolocalisation of instance segmentation via depth estimation, configurable inference with zero-shot models and grounded SAM, as well as vision-language model (VLM) based attribute extraction for road surfaces. Here’s an example of a street scene from Antananarivo after performing power pole and road segmentation, road surface classification, and VLM road smoothness estimation:

All of this is still very much at the early stage and still far from being a productive service. We would be very interested in hearing about current Panoramax developers’ and users’ thoughts on this, and how to potentially take it further.

Some of our ideas for next steps in the development:

  • Flexible, configurable definition of pipelines of chained inference and processing steps, e.g.:
    Zero-shot detection

    Instance segmentation

    ├─→ Depth estimation → Geolocalisation → OSM element matching
    └─→ Classification / VLM-based attribute extraction
  • Integration with Panoramax web GUI: Possibility to trigger inference pipelines on images/sequences/uploads on demand (by button click), if a Panoramax instance has a Hug-A-Panorama API defined.

Version française: Hug-A-Panorama : Vers un service d’inférence IA pour Panoramax

Salut,

Je fais partie de l’équipe Geoinformation for Humanitarian Aid chez HeiGIT, et je pense qu’il est temps de partager ici quelques-unes de nos expériences avec Panoramax. Tout d’abord, un grand merci pour l’excellent travail réalisé ! En tant qu’institut de recherche appliquée qui met à disposition de ses partenaires des géodonnées ouvertes et des logiciels libres, nous suivons avec beaucoup d’intérêt le développement de Panoramax depuis un certain temps.

L’année dernière, nous avons mis en place une instance Panoramax non fédérée, à accès restreint, dans le cadre de notre projet AILAS. Celui-ci vise à créer un système de calcul d’itinéraires adaptatif aux conditions météorologiques et assisté par l’IA pour des régions comportant des routes non revêtues, en extrayant des caractéristiques pertinentes à partir d’images au niveau de la rue afin d’évaluer la praticabilité des routes selon différentes conditions météorologiques. Dans ce contexte, nous avons été ravis de voir avec quelle rapidité les développeurs de Panoramax ont pris en compte la demande de nos partenaires (ainsi que d’autres utilisateurs) concernant la possibilité de limiter la visibilité des séquences et des images aux seuls utilisateurs connectés.

Nous avons également commencé à développer une preuve de concept d’un service capable d’exécuter des inférences IA sur des régions d’intérêt entières ou sur des séquences complètes dans Panoramax. L’objectif est de déclencher automatiquement des tâches de détection, de segmentation ou de classification (par exemple des revêtements routiers, des matériaux de construction ou de points d’intérêt tels que les pharmacies) pour chaque nouvel téléchargement dans Panoramax, afin de produire des données exploitables pour, entre autres, la préparation aux catastrophes et l’action humanitaire anticipative. Plus important encore, le service réinjecterait les résultats de l’inférence dans Panoramax sous forme d’annotations, conformément au schéma d’annotations.

Pour nos premières expérimentations, nous avons implémenté ce service de manière à pouvoir exécuter des inférences avec différents modèles (configurables) de détection, de segmentation d’instances et de classification issus de Hugging Face. La correspondance entre les étiquettes produites par les modèles et les annotations Panoramax appropriées est définie dans un fichier de configuration YAML. Ainsi, par exemple, le résultat de classification du revêtement routier “asphalt” est enregistré dans Panoramax sous la forme “osm|surface=asphalt”, accompagné des métadonnées correspondantes.

Nous avons ensuite ajouté d’autres fonctionnalités expérimentales, telles que la géolocalisation des segments d’instances à l’aide de l’estimation de profondeur, l’utilisation configurable de modèles zero-shot et de Grounded SAM, ainsi que l’extraction d’attributs des revêtements routiers à l’aide de modèles vision-langage (VLM).

La figure (:index_pointing_up: ) montre un exemple de scène de rue à Antananarivo après segmentation des poteaux électriques et de la chaussée, classification du revêtement routier et estimation de la régularité de la chaussée par un VLM.

Tout cela en est encore à un stade très précoce et reste loin d’être un service prêt pour la production. Nous serions très intéressés de connaître l’avis des développeurs et des utilisateurs actuels de Panoramax sur cette approche, ainsi que les pistes permettant de la faire évoluer.

Voici quelques idées pour les prochaines étapes du développement :

  • Définition flexible et configurable de pipelines composés de plusieurs étapes d’inférence et de traitement, par exemple :
    Détection zero-shot

    Segmentation d’instances

    ├─→ Estimation de profondeur → Géolocalisation → Appariement avec les éléments OSM
    └─→ Classification / Extraction d’attributs basée sur un VLM
  • Intégration avec l’interface web de Panoramax : possibilité de lancer des pipelines d’inférence à la demande sur des images, des séquences ou des imports (par simple clic sur un bouton), lorsqu’une instance Panoramax dispose d’une API Hug-A-Panorama configurée.
4 Likes

Some more resources / ressources supplémentaires :

Bonjour et bienvenu,

Je contribue à OSM pour Madagascar depuis longtemps. Dans cette optique, j’ai essayé de mettre les infos sur les routes et pistes pour pouvoir déterminer leur praticabilité en saison des pluies, voir après cyclones/fortes pluies. J’ai structuré les informations dans le wiki, ce qui a par la suite donné la page Highway Tag Africa.

D’un point de vue pratique, sur le terrain, je constate qu’il est difficile de maintenir les informations à jour, typiquement quand une route goudronnée se dégrade. On parle de centaines voir de milliers de kilomètres (600 km pour mon trajet habituel). Je soutiens pleinement votre démarche d’automatisation de détermination de l’état des routes mais aussi de détection des passages submersibles.

Par ailleurs, d’autres informations peuvent aussi être très utiles après une catastrophe : pharmacies, dépôts de médicaments, centres de santé… Certains vont être plus difficiles que d’autres à détecter. :sweat_smile:

Bon voyage.

Bonjour Oliver,

Merci pour ce partage très intéressant ! Je travaille à Gironde Numérique (syndicat mixte, Gironde, France) sur un projet qui recoupe (il me semble) le vôtre, donc voici un retour d’expérience de terrain:

Notre projet, Vigie, audite l’infrastructure de poteaux du réseau fibre en croisant l’imagerie Panoramax 360° avec les données réseau GraceTHD (le modèle de données standard des réseaux FttH français). L’objectif : identifier les poteaux et zones nécessitant une inspection terrain (cassés, penchés…), les résultats sortent dans une couche annexe (GeoPackage) revue dans QGIS.

Une différence d’approche qui pourrait vous intéresser : comme nous connaissons déjà la position des poteaux (GraceTHD) et la pose caméra (métadonnées Panoramax), nous avons inversé le problème. Plutôt que de détecter « à l’aveugle » puis géolocaliser, nous projetons les positions connues dans l’espace image et cherchons à confirmer la présence. Concrètement : appariement poteaux/photos dans un rayon de 30 m, reprojection de l’équirectangulaire en 8 vues perspectives, détection YOLO fine-tuné, puis triangulation multi-photos qui attribue à chaque poteau un statut (CONFIRMÉ / VU 1 FOIS / AMBIGU / ABSENT). Les visées humaines et machine sont réconciliées avec typage explicite des conflits, l’annotation humaine n’est jamais écrasée silencieusement.

Deux retours d’expérience qui rejoignent directement vos pistes :

  1. Zero-shot et VLM : nous avons testé plusieurs VLM (dont qwen2.5-vl et gemma3) pour la détection et la caractérisation de l’état des poteaux. À la qualité d’imagerie street-level typique, la précision n’a pas atteint un niveau exploitable en production. Nous avons dû passer par trois cycles de fine-tuning supervisé sur un jeu annoté maison pour arriver à un rappel utile acceptable. Le zero-shot est excellent pour prototyper, mais d’après notre expérience le passage en production sur des objets fins comme les poteaux passe par l’annotation. Après, on est vraiment sur une thématique ou la confusion et l’ambigüité des situations peuvent poser des problèmes de détection très spécifiques il me semble.

  2. Géolocalisation par profondeur : nous nous apprêtons justement à évaluer l’estimation de profondeur monoculaire 360° (type DA360) pour lever les ambiguïtés quand un poteau n’est vu que sur une seule photo. Nos poteaux confirmés (position GraceTHD + pose caméra) nous donnent une vérité terrain de distance gratuite pour mesurer l’erreur réelle. Avez-vous des chiffres de précision sur votre géolocalisation par profondeur ? Ce serait précieux pour calibrer nos attentes.

Enfin, votre réinjection des résultats dans Panoramax via le schéma d’annotations nous intéresse beaucoup : c’est un bon exemple de maillon d’interopérabilité qui nous manque actuellement. Votre mapping YAML étiquettes → annotations est-il pensé pour être partagé entre instances ?

Très volontiers pour échanger plus en détail si utile, nos cas d’usage (poteaux électriques chez vous à Antananarivo, poteaux fibre chez nous en Gironde) sont assez proches pour qu’une convergence sur le schéma d’annotations ait du sens.

Léo Huerta
Gironde Numérique

2 Likes

Bonjour Eric et Léo,

Merci beaucoup pour le partage de vos experiences!

Concernant zero-shot et VLM, c’est effectivement la flexibilité de ces modèles qui nous intéresse, car nous envisageons Hug-A-Panorama comme un service générique pouvant être utilisé et testé pour tout nouveau cas d’usage à venir. Pour des projets plus spécifiques et concrets, nous privilégierions néanmoins toujours des modèles plus légers et conçus sur mesure.

La méthode de géolocalisation actuellement utilisée dans Hug-A-Panorama est encore expérimentale et ne serait pas suffisamment précise pour positionner correctement les poteaux détectés, en particulier lorsqu’elle est combinée aux incertitudes liées au géoréférencement de l’image et à son orientation.

La correspondance entre les résultats de l’inférence et le schéma d’annotations de Panoramax est définie dans un fichier YAML qui configure l’ensemble des modèles disponibles. Dans cet exemple-ci, nous définissons que l’étiquette de sortie « traffic_light » sera enregistrée dans Panoramax sous la forme « osm|highway=traffic_signals » :

object_detection:
  facebook/detr-resnet-50:
    threshold: 0.5
    labels:
      traffic light:
        - osm|highway
        - traffic_signals

Nous essayons d’appliquer la syntaxe proposée dans Syntax - Panoramax - Docs ; ainsi, tout ce qui peut être exprimé à l’aide de tags OSM établis ou en suivant le schéma Wikidata devrait être relativement interopérable.