Datalakes geospatiaux : Un pas de plus pour faire face à l’augmentation des volumes de données brutes

Dans le cadre de ses activités pour les acteurs du domaine Spatial et de l’Observation de la Terre, Geomatys a structuré ses activités selon trois axes : 

  • La mise en place et l’exploitation de Datalakes Geospatiaux (basé sur des infrastructure Cloud et exploitant des volumes massifs de donnée)
  • La (Geo)Datascience
  • La visualisation de données incluant la 3D et la réalité augmentée

Cet article présente un retour d’expérience sur la mise en place de traitements à la volée sur un DataLake pour les besoins d’une agence spatiale.

Que l’on soit en charge de la production et la collecte de données où en charge d’un DataLake et de l’analyse ultérieure de ces mêmes données, force est de constater que la quantité d’information produite ne cesse d’augmenter. Les segments sols et centres de mission scientifiques, n’échappent pas à cette tendance, en raison notamment des nouveaux instruments scientifiques avec de très hautes résolutions, entraînant des volumes de données à produire, stocker et transmettre toujours plus conséquents.

Cependant, combien de données seront réellement utilisées au regard du volume de données brutes acquises ? Si l’on prend le cas du satellite optique Sentinel 2, une recherche sur la plateforme SciHub sur l’année 2020, indique que, tous types de produits confondus, un peu moins de 11 Millions de produits ont été générés cette année là et qu’ environ 1,7 millions possèdent une couverture nuageuse supérieure à 95 % soit la quasi totalité de l’image. Il est donc probable que plus de 15% des données acquises en 2020 ne soient jamais utilisées. Ce pourcentage peut varier en fonction du capteur à l’origine de la mesure (radar, optique…) mais le constat reste valable pour tous, un nombre non négligeable de données brutes ne sera pas utilisé pour produire des analyses. A ce pourcentage de données “non utilisables” s’ajoutent les données pour lesquelles la mesure est exploitable mais qui ne seront simplement pas utilisées par manque d’utilisateurs pour la zone ou la période.

Pour le producteur (et le gestionnaire de DataLake) cela représente une quantité de données non négligeable (environ 1,7 PetaOctet de données par an. dans le cas de Sentinel 2). Dans le cas de chaînes de production complexes telles que les segments sols de satellite ce nombre peut être multiplié par le nombre de post-traitements que subit la donnée depuis la mesure brute (L0 ou L1) jusqu’à devenir un produit prêt à l’utilisation (L2 à L4). Toujours dans le cas Sentinel 2, trois post-traitements sont appliqués (niveau L1A, L1B et L1C) à la donnée avant d’obtenir une donnée de niveau L2, produite systématiquement. Finalement, ce sont donc plusieurs dizaines de Po de données qui ont été traitées et stockées et qui ne serviront pas. Outre que cela ne s’inscrit pas vraiment dans une démarche “GreenIT”, cela impacte également le coût de l’infrastructure matérielle. Passer d’un traitement systématique à une donnée prête à l’emploi (dans la mouvance de la démarche Analysis Ready Data) et produite à la demande, permettrait d’éviter cette sur-production inutile (note pour l’aspect GreenIT : nous laissons au futur résultat d’une étude ACV le soin de déterminer le point d’équilibre entre traiter deux fois une même image ou mettre le résultat en cache après la première demande, l’un consommant plus d’énergie ou l’autre nécessitant plus de disque dur).

Aujourd’hui, cette approche “à la demande” est de plus en plus mise en œuvre pour des traitements à partir des données post-traités (production à la demande d’occupation des sols, de taux d’humidité comme pour le projet européen Phidias sur lequel Geomatrys est impliqué au côté de nombreux partenaires dont le CNES le CINES et l’IRD …), évitant ainsi tout ou partie de la production systématique. Cependant, la plupart des segments sols (du niveau L0 au niveau L2 dans le cas de Sentinel 2) reste sur une approche systématique malgré les quantités de données inutiles. Pourquoi ? Une raison possible, sans doute pas la seule, est qu’un des post-traitements essentiels consiste à projeter sur une grille régulière les mesures dérivées du signal capté par le satellite.

La projection des données consiste à associer des valeurs du signal (le signal pour chaque pixels) de manière directe ou indirecte à des coordonnées géospatiales distribuées selon une grille régulière. Cela rend les données beaucoup plus faciles à exploiter que des valeurs distribuées de manière irrégulière. Or, l’algorithme de re-échantillonage  à partir de ces simples valeurs est complexe et peut s’avérer coûteux en termes de performances. Depuis 2018, RESTEC (Remote Sensing Technology Center of Japan) société affiliée à l’Agence Spatiale Japonaise (JAXA), travaille avec Geomatys sur l’application de cette projection à la volée pour les données issues des satellites GCOM-C et W.

Exemple de donnée brute GCOM-W (GCOM-W1 AMSR2 Total Precipitable Water and Wind Speed products)

Exemple de sortie d’un service Analysis Ready Data – WMS via Examind

Dans l’exemple du GCOM-W, la donnée brute à laquelle est appliquée la projection à la volée correspond à une partie conséquente de l’orbite du satellite. La position de chaque pixel est exprimée en latitude et longitude pour chaque pixel, ainsi de l’équateur au pôle existe t’il une très grande variabilité dans la taille des pixels.

L’objectif est donc de fournir à l’utilisateur un accès à la volée à des données prêtes à l’emploi (approche Analysis Ready Data), moins dépendant de la structure initiale des produits et, dans le cas de GCOM-W, de l’orbite du satellite. 

Pour cela, l’ensemble des données est indexé comme une couche spatio-temporelle unique (ou cube de données). Ainsi l’utilisateur peut télécharger l’emprise spatio-temporelle des données qu’il souhaite via des services standards (WCS ici) indépendamment de la structure des données acquises par le satellite.

Proposer un tel service à la volée nécessite de disposer d’une opération de projection efficace. C’est sur cet aspect que nous avons concentré le gros de nos travaux durant 2 ans.

Il est assez facile de déterminer les coordonnées géographiques (latitude et longitude) de chaque pixel lorsque ces coordonnées sont déclarées dans le fichier. Il est beaucoup plus difficile d’effectuer le cheminement inverse, c’est-à-dire de trouver le pixel auquel correspond des coordonnées géographiques, lorsque ces pixels ne sont pas distribués sur une grille régulière. L’approche brute (inapplicable pour les grandes images) consisterait à itérer sur chaque pixel jusqu’à trouver le plus proche. L’approche présentée ci-dessous, et mise en œuvre par Geomatys permet de résoudre la problématique à la volée avec une précision et des performances maîtrisées.

D’un point de vue technique, la démarche est la suivante :

  1. Tout d’abord, les coordonnées géographiques de chaque pixels sont projetées vers une projection Mercator universelle (UTM). La zone de la projection UTM est sélectionnée de manière à contenir le pixel qui se trouve au centre de l’image. Cette projection est appliquée parce que la distribution des pixels des images GCOM se rapproche grandement d’une grille régulière lorsqu’on utilise cette projection.
  2. Ensuite, les coefficients d’une transformation affine sont calculés par la méthode des moindres carrées moyens. Cette transformation affine est un ensemble d’équations linéaires permettant de convertir les coordonnées UTM de chaque pixel par une estimation de ses coordonnées pixels dans le fichier GCOM. Les transformations affines étant linéaires alors que la relation entre les coordonnées pixels et les coordonnées géospatiales dans un fichier GCOM est non-linéaire, l’utilisation d’une transformation affine induit une erreur. Le Datacube calcule les coefficients qui font que la moyenne de (coordonnées pixels réelles − coordonnées pixels estimées)² soit le plus petit possible.
  3. Une grille des résidus est construite. Cette grille contient, pour chaque pixel, la valeur de (coordonnées pixels réelles − coordonnées pixels estimées). Pour rappel, les étapes 1 et 2 ci-haut ont chacune contribué à ce que les résidus soient les plus petits possibles.
  4. Pour calculer les coordonnées du pixel correspondant à des coordonnées UTM données, on applique d’abord la transformation affine pour avoir une première estimation puis on calcule les coordonnées UTM réelles de cette première estimation en ajoutant les résidus. On trouvera une erreur par rapport aux coordonnées spécifiées. Cette erreur, exprimée en unités de la projection UTM, est convertie en erreur exprimée en unités pixels en multipliant le vecteur représentant l’erreur par l’inverse de la matrice Jacobienne de la fonction représentée par la grille des résidus; à la position du pixel estimée multipliée par la matrice Jacobienne de la transformation affine. On obtient une nouvelle estimation des coordonnées pixels, que l’on convertit à nouveau en coordonnées UTM afin de vérifier l’erreur et on répète le processus jusqu’à ce que l’erreur soit suffisamment faible. Cet algorithme est le même que celui appliqué pour les changements de référentiels utilisant les grilles NADCON, excepté qu’on y ajoute l’utilisation des matrices Jacobiennes pour mieux prendre en compte l’aspect non-linéaire de la transformation. A titre de comparaison, l’algorithme employé par NADCON suppose implicitement que les matrices Jacobiennes sont très proches de la matrice identitée. C’est une approximation raisonnable pour NADCON mais pas pour les images GCOM.
  5. Les étapes décrites ci-dessus fournissent un mécanisme nécessaire pour projeter l’image sur une grille régulière. Il nous reste à choisir une grille régulière. La transformation affine calculée à l’étape 2 fournit un bon point de départ puisqu’elle cherchait à se rapprocher le plus possible de la répartition des données originales. On prend l’inverse de cette matrice comme source des coefficients du fichier .TFW qui accompagne les images au format TIFF. IlN ne reste plus qu’à projeter les pixels de l’image GCOM vers le système de référence déterminée à l’étape 1 sur une grille inférée par le fichier TFW déterminé à cette étape 5 en utilisant la transformation non-linéaire décrite à l’étape 4.

Les tests de performances réalisés par RESTEC sur l’infrastructure de la JAXA ont permis de qualifier et valider la viabilité de l’outil et de l’approche, qui entrera en production en 2021. Bien conscient que la problématique lié au satellite GCOM est applicable à d’autre sources de données, Geomatys s’est employé au cours des deux dernières années à mettre en place un process générique via le logiciel Examind DataCube qui capitalisent cette expérience et permettront d’accélérer les prochaines mises en oeuvre de la solution.