Visualisation interactive de datacubes Zarr

La prestation vise à évaluer des approches de visualisation web interactive de données massives d’observation de la Terre stockées dans des formats cloud-natifs. Elle comprend l’analyse des technologies, un benchmark, le développement d’un démonstrateur fonctionnel et son déploiement dans les environnements CNES et DestinE.

Analyse et benchmark

L’état de l’art porte notamment sur GeoZarr, éventuellement CoG, les données vecteur (GeoParquet ou équivalent), les serveurs de tuiles, l’accès direct, les pyramides et le chunking. Il documente les compromis entre performance, duplication, latence et coût S3, flexibilité, complexité et interopérabilité, puis identifie des solutions candidates.

Le périmètre et la méthode du benchmark sont définis au démarrage et enrichis avec le CNES. Des prototypes de code servent à mesurer objectivement les approches. Les critères peuvent être qualitatifs ou quantitatifs : temps de réponse et d’affichage, coût, scalabilité, interopérabilité, complexité d’implémentation et documentation. Un récapitulatif des solutions les plus pertinentes est fourni.

Démonstrateur et déploiements

Le démonstrateur, pleinement fonctionnel et au minimum une version simplifiée du cas cible, met en œuvre un ou plusieurs dashboards web. Le cas principal concerne les inondations à Nouméa, notamment en situation de tempête ou d’alerte de submersion. Il doit permettre :

• d’afficher des couches de données indépendamment ou simultanément sur une carte ;
• de lancer des requêtes interactives d’intersection entre données, par exemple entre inondations et routes, et d’en afficher les résultats ;
• de présenter des résultats de calcul dans des widgets graphiques, comme des histogrammes de bâtiments ou de population touchés selon la date, ou une série temporelle du niveau d’eau moyen ;
• de synchroniser les affichages cartographiques et graphiques dans les deux sens.

Des données plus simples d’accès, par exemple Sentinel en Zarr, peuvent servir aux tests fonctionnels et comparaisons technologiques. Après validation du démonstrateur par le CNES, deux déploiements sont demandés : l’un sur les services CNES (JupyterHub/Datalabs ou DTF Cockpit ; si leurs contraintes sont trop complexes, Trex avec serveur web local aux nœuds de calcul, puis en dernier recours Scaleway connecté au SI du CNES) ; l’autre sur les services DestinE, notamment DESP, dont le titulaire identifie les plus pertinents. Un rapport de mise en œuvre pour les environnements CNES et DestinE présente les moyens utilisés, les difficultés rencontrées et les recommandations.

Organisation et livrables

Le titulaire propose une organisation permettant au CNES de suivre et orienter les travaux. Sont prévus un kickoff, un point de suivi hebdomadaire ou bimensuel d’environ 30 minutes avec rapide bilan écrit des activités de la semaine, puis une réunion de bilan, restitution et démonstration. Le code est stocké sur le GitLab du CNES ou sur GitHub en accès public, documenté et accompagné de README explicatifs. Un rapport est attendu pour chaque phase ; un PDF rassemblant les éléments demandés est remis à la fin, ainsi qu’en version préliminaire après chaque étape. Le CNES fournit un compte d’accès à son SI scientifique et les jeux de données associés au cas d’usage.

Sobriété des ressources

Le code et les plateformes proposés doivent être optimisés en consommation de ressources, éviter les serveurs et services inutiles et limiter les transferts de données pour la visualisation.