Evolution de "SDI CONSISTENCE CHECK (SDI CC)" : synthèse travaux GeoCom 2024

[gryckelynck]

Document visant à proposer des pistes d'évolution de l'application SDI CC (cf. https://github.com/georchestra/sdi-consistence-check).
Il fait suite aux travaux du GeoCom 2024 sur le sujet (échanges du 20/06/2024)

Rappels

Application réalisée en 2016 par la société Camptocamp suite à une commande de Rennes Métropole.
L'objectif était de pouvoir analyser la cohérence d'une IDG en matière de données et métadonnées.
Le langage de programmation utilisé est Python.

Un développement complémentaire permet de corriger automatiquement certaines erreurs en synchronisant les informations de la fiche de métadonnées avec celles des données (via API GS et GN - à confirmer).

Pour des raisons d'interopérabilité, le choix a été fait de s'appuyer sur les services web CSW, WMS et WFS pour interroger la plateforme de données et de ne pas prendre en compte les API spécifiques des solutions utilisées (ex.: GeoServer et GeoNetwork).

Constats

1. L'application SDI CC est actuellement utilisée par plusieurs plateformes de données geOrchestra (Rennes Métropole, Géo2France, DataGrandEst, etc.).
2. L'application génère des rapports sous forme d'un log au format TXT, peu lisibles et difficilement réutilisables.
   A noter que des tests de conversion en CSV et de génération de tableaux de bords à la volée ont été réalisés (cf. https://github.com/datagrandest/sdi-cc-report).
3. Le code est peu structuré et peu documenté. Sa prise en main et sa réutilisation est complexe.
4. Des évolutions fonctionnelles sont attendues : export des rapports en CSV, historisation des données, consultation sous forme de tableau de bord, etc.

Enfin, il existe une forte attente de la part des utilisateurs geOrchestra, notamment les administrateurs de plateformes, pour disposer d'une vision intégrée de leur plateforme. Les travaux autour de SDI CC pourraient constituer un point de départ dans cette direction.

Propositions

1. Renommer l'application avec un nom plus cours et facile à prononcer ("SDI CHECKER" ?)
2. Développer une nouvelle application en apportant une réponse aux problèmes identifiés précédemment. L’existant constitue une base intéressante de épart, de réflexion et de travail.

Choix du langage de développement

Le langage Python initialement choisi pour développer SDI CC fait sens.
En effet, il est bien adapté au traitement de données et à l'exploitation de services web issues d'une IDG. Des modules robustes et reconnus sont disponibles pour faciliter le développement et la maintenance d'une telle application.

Par ailleurs, ce langage est globalement bien connu des administrateurs et utilisateurs de plateformes de données (profil de type "data scientist"), ce qui élargi les possibilités de contributions. Il ne nécessite pas de mettre en place des environnements de développement complexes et le déploiement des applications reste globalement simple côté serveur.

Certains développeurs confirmés soulignent les faibles performances du langage Python et expriment une crainte à ce sujet. Cela nécessite, le cas échéant une analyse et confirmation au regard des usages envisagés.

Architecture

L’architecture globale envisagée est la suivante :

Elle est actuellement imaginée autour de 4 éléments principaux :

1. SDI CHECKER : librairie cœur permettant de vérifier la cohérence des métadonnées et services web. ce composant devrait prendre la forme d'une librairie Python permettant d'interagir avec les services web pour générer en sortie une réponse structurée (objet).
2. CLI CHECKER : application CLI permettant d'interagir avec la librairie cœur pour tester un service web et générer des rapports dans différents formats (TXT, CSV, JSON, etc.).
3. STOCKAGE : système de persistance des données et rapports générées lors de l'exécution d'une vérification (gestion de l'historisation à prévoir).
4. API CHECKER : interface exposant les résultats des requêtes persistées au niveau du stockage. Elle facilite leur réutilisation dans différentes applications (SuperSet, tableau de bord custom, etc.). Elle doit aussi permettre de déclencher des opérations de vérification "à distance" sans passer par la ligne de commande.

NB:

1. Les éléments 1 et 2 devraient être packagés sous la forme d'un module Python facilement déployable et réutilisable (PyPi). L’intégration de l’API CHECKER à ce module reste à analyser et discuter.
2. L'élément 3 en tant que tel est hors du périmètre du projet. Cependant, il est essentiel de proposer différentes solutions de stockage via le CLI CHECKER et API CHECKER.
3. Le 5ème élément intitulé "APPLICATIONS" se situe hors du périmètre initial du projet et concerne plus la capacité de réutilisation des données générées. Il pourra faire l'objet de développements et valorisation complémentaires à définir.

Champ fonctionnel

Cette liste de fonctionnalité sert ici d'aide mémoire. Elle reste à compléter, réorganiser et détailler.
L'ordre de priorités est à préciser.

1. Reprendre les fonctionnalités proposées dans le cadre de SDI CC
2. Séparer la génération du rapport de la récupération des résultats d'une vérification
3. Stocker les résultats des vérifications de façon persistante (format à définir)
4. Etendre les formats d'export des rapports (CSV, JSON, TXT, HTML, etc.)
5. Proposer une API pour (1) accéder aux données et (2) déclencher des vérifications
6. Pouvoir générer un catalogue de vérifications pour faciliter les adaptations et les exécutions
7. Pouvoir réaliser une vérification sur une collection (catalogue ou espace de travail) ou sur un item, de façon unitaire (fiche de métadonnées ou layer)
8. Pouvoir réaliser une vérification à partir d'un URL ou un fichier (notamment une fiche de métadonnées)

Dans un premier temps, il est proposé de réutiliser les vérifications proposées par SDI CC sans modifier de façon notable "l'intelligence du code" (sauf pour restructurer le code ou corriger des erreurs).
Un travail complémentaire pourra être réalisé dans un second temps sur la nature et la pertinence des vérifications proposées. Cela pourra faire l'objet d'un groupe de réflexion spécifique.

Par ailleurs, à ce stade, il est proposé :

• Comme c’était déjà le cas pour SDI CC de s'appuyer prioritairement sur les services web CSW, WMS et WFS pour interroger la plateforme de données et de ne pas prendre en compte les API spécifiques des solutions utilisées (ex.: GeoServer et GeoNetwork). Ces API pourront être ajoutées ultérieurement.
• De ne pas tenir compte des scripts permettant de corriger automatiquement certaines erreurs en synchronisant les informations de la fiche de métadonnées avec celles des données. Il utilise les API spécifiques de GS et GN (à confirmer). Ils seront intégrés dans SDI CHECKER, CLI CHECKER et API CHECKER ultérieurement au besoin.

[landryb]

Merci @gryckelynck pour cette synthèse (désolé au geocom je n'ai pu y participer, trop de sujets..), j'en profite pour faire une petite synthèse sur ma 'vision' du besoin..

disclaimer: je ne connais pas très bien sdi-consistency-check, je viens de l'essayer et il a l'air d'avoir du mal a analyser mes liens entre GS et GN, alors que pourtant l'url pointe bien vers la version XML de la MD..

235
  Layer: rtge:avancement_pcrs
  Error: Metadata https://ids.craig.fr/geocat/srv/api/records/998a8feb-a71a-422d-9d57-9e94aa8eb6f7/formatters/xml
      not found or invalid for layer 'rtge:avancement_pcrs':
      Unable to parse the text/xml metadata: Type 'xml.etree.ElementTree.Element' cannot be serialized.

j'ai aussi regardé https://github.com/datagrandest/sdi-cc-report et les exemples sur https://www.datagrandest.fr/public/sdi-cc-report/

passif

il y'a quelques années j'avais eu un besoin similaire et j'avais pondu https://github.com/landryb/geoserver-datadir-checker qui avait un objectif similaire, avec ces spécificités:

• pouvait runner offline sur une copie/backup du datadir GS/export des MDs GN, afin de ne pas 'charger' les services de prod
• s'intéressait principalement a l'intégrité du datadir GS, donc n'utilisait pas les apis OGC ni REST, afin de pouvoir détecter plus d'incohérences (ce qui ne pouvait pas être fait avec les API):
  • fichiers 'perdus' non référencés
  • styles non utilisés
  • fichiers non existants
  • etc etc (voir le README du projet)

il n'est actuellement pas utilisé en prod au craig, mais les premiers résultats m'avaient permis de corriger une foule d'erreurs dans notre geoserver. Donc le besoin existe toujours..

présent

avec le recul, les différentes discussions sur le sujet, et l'évolution des briques de georchestra, je vois plusieurs besoins (qui pourraient être remplis par le même outil ?)

• un dashboard web intégré a georchestra. Les utilisateurs/admins de pf sont rebutés par la CLI
• un besoin de garder une trace temporelle des checks, afin de montrer une évolution positive (j'ai corrigé telle erreur, mon 'score' a augmenté)
• une entrée user-centric qui pourrait etre une page d'accueil utilisateur/personnelle, avec:
  • mes cartes
  • mes métadonnées
  • les métadonnées de mon groupe
  • mon workspace geoserver ?
  • eg ... listant ce qui est lié a l'utilisateur/ce qu'il peut consulter/modifier (en utilisant les APIs de preférence ?)
  • pour le détail de chaque objet, beaucoup d'interliens, j'imagine p.ex qui a accès a cette carte, cette carte utilise ces ressources, etc...
  • donc evidemment derrière le s-p, utilisant les headers pour connaitre le 'profil' de l'utilisateur actuel (mais on peut imaginer un accès anonyme renseigné uniquement depuis les API OGC ?)
• une entrée specifique pour le profil platform admin avec une vue d'ensemble de toute la pf a l'instant T, avec tout ce qui est a corriger (l'equivalent de SDI-CC donc)
• un lien éventuel/souhaité avec ce qui est fait pour analytics afin de savoir par ressource son utilisation ?

dans le détail

Le besoin ici revient avec l'arrivée de mapstore - qui stocke tout dans le geostore qui a une API et un schéma de BDD - et j'imagine ainsi de nouveaux checks pour lesquels il faudrait lier fortement les objets de mapstore aux objets de GS, eg:

• pouvoir aller d'une couche dans geoserver a la liste des cartes MS2 l'utilisant
• pouvoir aller d'une carte MS2 a toutes les couches qu'elle qu'elle utilise (en distinguant les BG des layers, les layers des la PF des layers externes..)
• pour pouvoir rapidement trouver:
  • les cartes utilisant des couches inexistantes/cassées
  • les couches utilisées par aucune carte de la PF (ce qui ne veut pas dire qu'elles ne sont pas utilisées pour autant)

pareil pour le lien GS/GN qui est actuellement fait par SDI CC en mode offline, on voudrait pouvoir rapidement lier/aller d'une couche GS a sa MD et vice-versa.. en mode vision/preview et en mode édition

Donc pour le dashboard admin, j'envisage des entrées 'tabulaires' pour chacun des composants listant:

• pour GN, les MD
• pour GS, les workspaces, couches et styles (interliés, et pour les couches liés avec les MD)
• pour MS2, les contextes et cartes, interliés avec les couches GS (je ne crois pas que les liens vers les MD soient stockés dans la base MS2, plutot pris a la volée depuis le getcapabilities OGC..)

digressions

• evidemment, toutes les PFs ne renseignent pas leurs MD/uploadent pas leurs données de la meme manière, et donc un check qui est attendu pour la PF1 (et considéré comme 'bloquant') pourrait ne pas l'être pour la PF2 .. ca rentre dans la configurabilité d'un tel outil ?

• parlant de configuration, j'imagine très bien qu'un tel outil tournant au meme endroit que l'IDS devrait pouvoir s'autoconfigurer en autodécouvrant depuis /etc/georchestra:

  • les params de cnx aux bdd (mapstore, GN..)
  • l'url de la PF (eg https://github.com/georchestra/datadir/blob/master/default.properties#L12)
  • les urls de base des différentes applis:
    • ne pas hardcoder /geonetwork/, /geoserver/ et mapstore/
    • lire le localConfig.json de mapstore
    • inférer l'url de geonetwork depuis l'entrée avec l'id local
    • inférer l'url de geoserver depuis l'entrée avec l'id localgs..

• je pense qu'on a besoin de qqch d'asynchrone, car cela prend du temps de faire tourner des checks, et plus on en rajoute dans le temps plus ca prend de temps..

• donc il faut pouvoir:

  • afficher 'le dernier status connu' de la PF/ressource donnée,
  • faire tourner les checks de manière périodique et automatique la nuit
  • avoir une bouton permettant de rafraichir le status de la ressource consultée..
  • et donc stocker cette 'état/historique' dans une/la BDD georchestra ?

ca pose rapidement un pbm de synchro/cache en cas de modification/correction coté GS/GN l'état est a maj dans le dashboard..

technique

ca n'est pas la priorité, mais il faut en parler a un moment. Je suis d'accord sur l'utilisation de python, qui reste accessible au plus grand nombre et a des libs de base pour tout (json..), et on trouve un certain nombre de briques utiles:

• owslib
• gsconfig-py3 (meme s'il a l'air peu actif, il est déja utilisé par SDI CC)
• requests permet de taper facilement sur des APIs
• si il y'a besoin d'un accès a une DB (ex pour analyse du json des cartes MS2 et récupérer les ACLs dessus), sqlalchemy semble le standard
• pour faire des 'jobs' asynchrones (checks qui prennent du temps), celery a l'air bien (J'ai déjà gratté dans le passé)
• pour ce qui est du web, je ne connais pas bottle mais j'ai pu faire du flask et ca semble être pas mal utilisé

pour moi on ne peut pas se restreindre aux APIs OGC, car les APIs spécifiques GS/GN/MS2 et l'accès a la bdd pour MS2 et au datadir GS permettent de faire beaucoup plus de choses que les APIs standard...

Voila, c'est peut-être un peu décousu, mais c'est l'idée que je me fais du périmètre d'un tel outil... je n'ai pas fait cette synthèse sur la liste de discussion car github permet de mieux formatter, et on retrouve cette 'discussion' plus facilement ?

Ceci étant dit, je vais voir a bricoler un prototype flask/sqlalchemy/requests/owslib pour évaluer la faisabilité d'une 'surcouche' a l'API/BDD de mapstore pour naviguer dans les objets de la BDD MS et les lier aux couches GS, on verra ce qu'il en sort...

[gryckelynck]

Intéressant, bien que très ambitieux il me semble.
Avec @jeanpommier on était dans l'idée de repartir de l'existant et prévoir des jalons intermédiaires accessibles afin d'avoir des résultats concrets à courts ou moyens termes.
J'avais commencé à travailler sur quelques "améliorations" il y a quelques mois : https://gitea.datagrandest.net/guillaume_ryckelynck/sdi-checker il y a peut-être des choses à reprendre.
A voir comment construire une road map réaliste avec tout cela...

[jeanpommier]

Ben en fait, tu sais, je partage l'analyse de Landry. Cette perspective d'un dashboard qui ferait, en pratique, de la gestion des données, c'est mon moteur sur ce sujet. Je maintiens qu'en l'état actuel, il manque à geOrchestra un module de gestion des données: savoir ce qu'on a, dans quel état, répertorier les différentes manifestations d'une même donnée (mtd, couche carto, carte etc) afin que la consistence des données ne soit plus un truc qu'on découvre et corrige après coup, mais une pratique intégrée dans l'IDS.

Reste à voir d'où on part, où on va et comment. Merci @landryb pour cette analyse bien documentée, comme d'habitude. Il me semble que tu as bien résumé et rassemblé les différents aspects à prendre en compte, presque une feuille de route déjà rédigée ;o)

[landryb]

Ceci étant dit, je vais voir a bricoler un prototype flask/sqlalchemy/requests/owslib pour évaluer la faisabilité d'une 'surcouche' a l'API/BDD de mapstore pour naviguer dans les objets de la BDD MS et les lier aux couches GS, on verra ce qu'il en sort...

mon prototype actuel est sur https://github.com/landryb/dashboard/ - il ne reprend pas encore ce que fait SDI-CC mais ca fait partie de mes objectifs.

[gryckelynck]

je ne connais pas bottle...

C'est très similaire à Flask mais avec moins de fonctionnalités. C'est installable via pip ou utilisable sous la forme d'un "simple" fichier Python à importer. Je ne sais pas si j'irais jusqu'à faire tourner un site en prod avec Bottle, mais en local ou avec peu de charge ça passe très bien.

[bchartier]

Salut,

On voit bien qu'il y a pas mal d'attentes autour d'outils comme SDI-CC par les administrateurs des plateformes car les liens entre les ressources proposées par la plateforme sont administrés la plupart du temps manuellement et sont sous la responsabilité d'une multitude d'outils disposant de leurs propres mécanismes de gestion.

Comme le dit @gryckelynck si l'on groupe l'ensemble des propositions qui sont mentionnées ici on a sans doute quelque chose d'ambitieux. Comme le dit @landryb c'est décousu car ont été abordés à la fois les besoins, des propositions relevant de l'architecture et des solutions techniques particulières.

Puisque certains d'entre vous pensent qu'une remise à plat de SDI-CC est préférable à une simple évolution, je suis assez d'accord avec @f-necas qui faisait remarquer la semaine dernière à @gryckelynck et moi qu'il faudrait sans doute se limiter, dans un premier temps, au besoin. Les autres aspects viendront naturellement ensuite.

Sinon à titre individuel, partir sur un outil qui contrôle des liens de multiples natures en exploitant des API spécifiques d'outils me fait plutôt peur. Créer des dépendances/adhérences à des outils enfonce le projet dans une niche. À moins que son architecture soit modulaire et extensive. Mais ça risque d'en faire tout de même une usine à gaz. L'avantage actuel de SDI-CC c'est que c'est assez simple à mettre en œuvre et qu'il n'y a quasiment rien de spécifique aux outils déployés sur la plateforme (mis à part les standards avec lesquels les ressources sont exposées).

[gryckelynck]

Salut,

Je partage tout à fait ce qui a été indiqué ci-dessus par @bchartier, @landryb et @jeanpommier.

Comme nous avons pu l'évoquer avec @fvanderbiest, @f-necas, et @bchartier la semaine dernière:

• C'est un sujet qui doit être porté au niveau global par la communauté (et PCS ?) de geOrchestra. Il porte en effet une vision stratégique en terme de fonctionnalités, d'architecture, de technologie, de financement... ;-)
• C'est un sujet à inscrire dans le temps (court, moyen et long). En effet l'évolution de SDI-CC me semble bien plus abordable (surtout si on se recentre sur les besoins essentiels et réels) que la construction d'une UI intégrée au niveau de nos plateformes.

Pour ne pas se perdre et être opérationnel, je pense que l'on peut travailler en // sur 2 documents type "CCTP" qui peuvent s'alimenter l'un l'autre et converger à un moment:

• La définition d'une v2 pour SDI-CC (en partant du constat et de l'existant +/- et du besoin réel)
• La définition d'un module central de gestion et administration des données

Mélanger les 2 dès à présent risque selon moi de nous empêcher d'avancer (cf. l'usine à gaz évoquée par Benjamin).
Pour ce qui est du "module intégré", ne faut-il pas aussi étudier la possibilité de s'appuyer sur le travail réalisé sur le nouvel éditeur de métadonnées GN-UI. Sans en être réellement convaincu, je me dit qu'Il peut être un point de départ en matière de connaissance et de gestion du patrimoine de données des acteurs d'une plateforme...