R&D Isogeo - ENSG : Détection de la modification des tables géographiques

Cette année encore, Isogeo a eu la chance de collaborer avec l’École nationale des sciences géographiques (ENSG). À cette occasion, entre février et mai 2022, 4 élèves géomaticiens encadrés par Julie Grosmaire et Simon Sampère ont travaillé sur un sujet de R&D crucial pour l’évolution du Scan Isogeo : “la détection de la modification des tables géographiques”.

Cet article sera ainsi l’occasion de revenir sur une étape spécifique du fonctionnement du Scan (la “signature” des données), d’évoquer les pistes envisagées pour l’optimiser et de souligner la participation des étudiants de l’ENSG à l’exploration de ces pistes.

La signature du Scan Isogeo

Comme vous le savez peut-être, le Scan Isogeo fonctionne en 3 étapes :

Nous aborderons ici la deuxième étape, celle de la signature, au cours de laquelle le Scan “signe” les données recensées afin de pouvoir les reconnaître ultérieurement et de détecter les modifications apportées à celles-ci.

Comment fonctionne le calcul de la signature ?

L’étape “signer” consiste à calculer la “signature” de chaque donnée scannée.

Cette signature est une sorte d’empreinte numérique de la donnée à un instant t. Elle est calculée via une fonction de hachage, ou hashing en anglais (pour les plus courageux d’entre vous, voici de quoi rentrer dans les détails).

Pour faire simple, une fonction de hachage permet de générer une chaîne de caractères spécifique, dont la valeur dépend d’un ensemble de données fourni en entrée. C’est cette chaîne de caractères que nous appelons signature (ou hash).

Dans le cas des données stockées sous forme de fichiers, la signature est générée à partir du contenu brut du ou des fichiers.

Pour les tables de bases de données, la donnée est chargée dans FME et la signature est calculée à partir :

• du nom des champs
• de la valeur prise par chaque entité dans chaque champ
• pour les données géographiques uniquement :
  • du système de coordonnées (si défini)
  • de la géométrie de chaque entité

Si la valeur de la signature d’une donnée varie entre 2 dates, cela signifie que cette donnée a été modifiée entre ces 2 dates.

Pourquoi calculer la signature ?

Une grande partie de l'ingénierie du Scan repose sur la détection de la modification des données, et ce, pour 2 raisons :

1. La date de dernière modification d’une donnée est une information intéressante qu’il faut afficher dans la fiche de métadonnées.
2. Si une donnée n’a pas été modifiée depuis le précédent Scan, il est inutile de la documenter à nouveau, on peut donc passer l’étape de documentation et optimiser le temps de traitement.

Mais pourquoi utiliser  une “signature” pour savoir si une donnée a été modifiée ? On pourrait penser qu’il suffit simplement de comparer les métadonnées extraites à une date t, avec celles extraites à une date t+1 pour savoir si une donnée a été modifiée entre les 2 dates.

Cependant, certaines modifications ne se répercutent pas sur la valeur de ces métadonnées. Les métadonnées récupérées automatiquement lors de l’étape de documentation sont les suivantes :

• le nom de la donnée
• le format
• l’emplacement
• le système de coordonnées (si donnée géographique)
• le nombre d’entités (hors raster)
• le type de géométrie (si donnée géographique vectorielle)
• l’enveloppe convexe  (si donnée géographique)
• la liste des attributs (hors raster), comprenant :
  • le nom
  • le type
  • l’alias ou le commentaire si saisi en base de données

La valeur des métadonnées ne sera donc pas impactée lorsque (par exemple) :

• la valeur prise par une ou plusieurs entité(s) est modifiée dans un ou plusieurs champ(s),
• la géométrie d’une ou plusieurs entité(s) est modifiée sans déformer l’enveloppe convexe de la donnée.

En revanche, puisque la valeur de la signature dépend de celle de chaque entité (tous champs compris) et de leur géométrie, on peut détecter une modification de la donnée concernée en comparant sa signature avant et après le changement effectué.

Calculer la signature d’une donnée permet donc :

• d’optimiser la durée des scans en ne documentant pas les données qui n’ont pas été modifiées ;
• de détecter de manière fiable la modification d’une donnée et de remonter cette information dans sa fiche de métadonnées.

Détecter la modification des données autrement

Pourquoi ?

La durée de génération du hash dépend directement de la quantité d’informations fournies en entrée. Le temps de calcul de la signature d’une donnée dépend donc principalement :

• du nombre d’entités,
• du nombre de champs,
• de la quantité de coordonnées géographiques.

De manière générale, signer les données représente la majorité du temps de traitement du Scan. C’est donc principalement pour en améliorer les performances que nous avons entrepris de faire évoluer la manière dont le Scan détecte la modification des données.

Les élèves de l’ENSG se sont focalisés sur les tables de bases de données parce que leur signature prend nettement plus de temps à être calculée que celle des fichiers. Cela s’explique en partie par l’utilisation de l’ETL FME pour le chargement des tables de bases de données.

Différentes pistes

L’équipe Isogeo réfléchit à des alternatives consistant à détecter la modification des données sans les signer ou à signer les tables de bases de données en chargeant les données autrement qu’avec FME.

Requêter les tables systèmes

Cette première piste concerne spécifiquement les bases de données Oracle et PostgreSQL. Il s’agirait de consulter les “tables système de journalisation” de la base pour savoir à quelle date chaque table à été modifiée pour la dernière fois. Il suffirait ensuite de comparer la valeur récupérée à une date t avec celle récupérée à une date t+1 pour savoir s’il est nécessaire de documenter la donnée en question.

Fonctionner ainsi présenterait 2 avantages majeurs :

• exécuter une ou plusieurs requête(s) SQL sera probablement bien plus rapide que d'ouvrir l’intégralité de la donnée dans FME avant de la signer,
• la date de dernière modification de la donnée remontée dans sa fiche de métadonnée serait la date effective de mise à jour et non plus la date à laquelle le Scan a détecté une modification.

Même si cette piste semble prometteuse, le travail d’investigation des élèves de l’ENSG nous a permis de formuler plusieurs questions auxquelles il nous faudra répondre avant de s’engager sur cette voie :

• Nos clients accepteront-ils de nous accorder les droits permettant d’accéder aux tables système de journalisation ?
• La journalisation des bases de données est-elle configurée de manière homogène entre nos différents clients (ce qui nous permettrait d’utiliser le même traitement avec tous nos utilisateurs) ?

Ouvrir les données sans FME

Comme mentionné précédemment, une partie du temps de traitement de l’étape de signature des tables de bases de données s’explique par l’utilisation du logiciel FME pour le chargement de ces données. Il s’agit d’une technologie très puissante, compatible avec tous les formats de données pris en charge par le Scan Isogeo.

Néanmoins dans notre cas, elle est seulement utilisée pour ouvrir les données sans y appliquer de traitement particulier. Nous envisageons donc d’avoir recours à d’autres technologies moins lourdes pour l’étape de signature et pour certains formats spécifiques.

Pour les tables de bases Oracle et PostgreSQL, nous réfléchissons à utiliser GDAL. Il nous reste cependant à déterminer si le gain de performance justifierait le passage à une technologie open source. En effet, on peut s’attendre à y perdre en termes de qualité du support, d’exhaustivité de la documentation et aussi de compatibilité entre la version du logiciel et celle des formats de données.

Concernant les Géodatabases d’entreprise ESRI, nous avons choisi d’écarter GDAL pour des questions de compatibilité et de maintenabilité à long terme.

Nous nous sommes donc penchés sur les outils de développement ESRI et notamment sur les librairies Python. Encore une fois, le travail des élèves de l’ENSG nous a permis de progresser dans l’exploration de cette piste en démontrant qu’il était possible de calculer la signature d’une table de Géodatabase d’entreprise ESRI après l’avoir ouverte via un script Python utilisant une bibliothèque ESRI dédiée.

Faire évoluer l'ingénierie du Scan constitue donc une de nos priorités en matière de R&D. Plusieurs pistes sont envisagées et la participation des élèves de l’ENSG nous a permis de bien progresser dans leur exploration.

Insistons tout de même sur le fait qu’il ne s’agit pour l’instant que de R&D. Étant donné les nombreux atouts de FME, remettre en question l’utilisation de cette technologie dans l’étape de signature n’est pas une décision à prendre à la légère.

D’autre part, détecter la modification d’une donnée sans en calculer la signature implique une refonte en profondeur du fonctionnement actuel du Scan Isogeo.

‍

‍

Il reste encore du chemin à parcourir (étude de faisabilité, benchmark technique, implémentation…) avant de transformer ces pistes prometteuses en fonctionnalités fiables et stables. Je vous invite par ailleurs à lire ou à relire cet excellent article rédigé par Léo Darengosse sur la mise en œuvre d’une évolution produit chez Isogeo.