Spécification initiale¶

Voir le ticket JIRA

Contexte¶

Livraison de données vectorielles.

Description¶

Ce script sera exécuté afin d’intégrer en base des fichiers vecteur poussés au sein d’une livraison. Cette intégration permet de créer une nouvelle donnée stockée vecteur diffusable ou d’en mettre à jour une déjà existante.

Le script a pour but la seule intégration des données et ne procède à aucune vérification en entrée ; celles-ci étant assurées par les scripts en amont.

Il existe deux modes :

GENERATING : la table est créée
MODIFYING : on ajoute les données à une table existante

Les données ajoutées, sont écrites dans un schéma temporaire. Tandis que les données modifiées, sont d’abord copiées dans le schéma temporaire puis les nouvelles données sont ajoutées dans cette table. Une operation de bascule dans le schéma donnée est ensuite réalisée en une seule transaction. Le schéma temporaire est effacé à la fin de l’opération ou en cas d’erreurs.

Pour l’intégration des nouvelles données, le script ne fait qu’exécuter l’équivalent des commandes ogr2ogr. Il utilise l’api python de GDAL/OGR.

Pour la modification des données, des requêtes SQL de base sont exécutées via psycopg.

Mode GPU¶

Si on précise que le traitement est de type GPU (Géoportail de l’urbanisme, avec l’option -p GPU), des champs spécifiques non livrés sont mis à jour à partir des paramètres.

Données en entrée¶

Les données vectorielles possibles sont les suivantes :

CSV
ESRI ShapeFiles et DBase (.dbf)
GeoJSON
GeoPackage
Plain SQL (PostgreSQL)

Les fichiers de suppression et modification sont au format CSV, respectivement avec les extensions .delete et .update. Un fichier de suppression contient un ou plusieurs champs sur lesquels filtrer les lignes à supprimer. Un fichier de modification doit préciser au moins tous les attributs servant de clé primaire (servant au filtre de modification) et un champs supplémentaire (à modifier).

Données en sortie¶

une donnée stockée de type VECTOR-DB

Paramètres¶

srs : Un système de coordonnées cible. Optionnel
delete : Est ce que l’on prend en compte les CSV de suppression. Optionnel, faux par défaut
update : Est ce que l’on prend en compte les CSV de modification. Optionnel, faux par défaut
process_extent : Est ce que l’on calcule l’étendue des données après l’intégration. Optionnel, vrai par défaut

Règles métier¶

Contrôler les paramètres¶

si la donnée stockée en sortie existe déjà (statut MODIFYING), on vérifie que le paramètre srs demandé est bien identique à celui de la donnée stockée. Sinon ERROR.

Identifier les fichiers dans en entrée à traiter¶

les paramètres de connexion au S3 pour la récupération des fichiers sont issus des variables globales du fichier parameters.json (accès au S3), et également du storage de la livraison en entrée (nom de bucket) et de la livraison en elle même (identifiant pour accéder au bon “repertoire” dans le bucket)
Fichiers de type SQL, GeoJSON, CSV, GeoPackage, Shapefile.
On déduit de ces fichiers les tables de destination du contenu.
Si en sortie la donnée stockée est MODIFYING, on vérifie que les tables déduites existent bien déjà dans le schéma (nom du schéma : type_infos.schema_name)

Insertion des données¶

les paramètres de connexion à la base sont issus des variables globales du fichier parameters.json (user / mdp), et également du storage de la donnée stockée en sortie (url, port, datase_name)

Selon le mode :

si la donnée en sortie est GENERATING, on crée le schéma de destination et les tables dans ce schéma. Le nom du schéma est déduit de l’id de la donnée stockée (modifié en minuscule et avec les tirets remplacés par des underscores). la projection des données en base est le paramètre srs s’il a été renseigné, ou le srs de la livraison sinon.
dans le cas MODIFYING il est important de se positonner dans une transaction afin qu’en cas d’erreur, le schéma reprenne son état initial. Les suppressions sont faites en premier, puis les modifications, et enfin les insertions des nouvelles données
dans tous les cas les données sont insérées dans leur tables respectives au sein de ce schéma. dans le cas CSV, ne pas garder la colonne texte avec la géométrie d’origine
si le format ne permet pas de définir de clé primaire, en ajouter une (ogc_fid) automatiquement pour toujours en avoir une dans les tables de donnée

Informations à retourner en sortie du script¶

Dans `output.stored_data`¶

type_infos/relations : pour chaque table ou vue dans le schéma final, avec comme informations :
- le nom de la table / vue
- la liste des attributs de la vue (y compris geom, et les éventuels id générés)
- la liste des attributs qui composent la clé primaire
srs : la projection des données en base (format EPSG:XXXX ou équivalent)
extent : l’étendue des données (on calcule l’union des zones couvertes par toutes les tables géométriques dans le schéma final), en EPSG:4326
size : la taille complète du schéma en octets en fin de processus

Dans `pipeline_status`¶

Une ligne indiquant le statut du script :

SUCCESS : L’intégration n’a pas rencontré de problème, pour aucun des fichiers de la livraison.
FAILURE : Une erreur est intervenu lors de l’intégration des données en base :
- Données incorrectes
- attributs de la table incompatibles pour une donnée MODIFYING
- erreur de lecture d’un fichier en entrée
- paramètre srs inconnu (ne correspond à aucune projection connue du système)
TECHNICAL_ERROR : En cas d’erreur technique :
- Mauvaise composition du parameters.json
- Valeur inatendue dans le schéma JSON
- Erreur de lecture / écriture dans le répertoire de travail
- Erreur de lecture / écriture dans la BDD (déconnexion, indispo, full bdd)

Logs¶

Même régles que les autres scripts de vérification
Logs spécifiques à remonter aux USER :
- Les grandes étapes du processus (pas de log fichier par fichier)
- Les fichiers en erreur et la cause de l’erreur
- Les erreurs plus globales s’il y en a
Logs spécifiques à remonter aux ADMIN :
- Le traitement de chaque fichier et son résultat.
- Les erreurs techniques rencontrées

Points d’attention¶

RAS