Spécification initiale#

Contexte#

Script de conversion de données stockée vecteur en donnée stockée vecteur (pivot pour itinéraire).

Ce script sera exécuté afin de “dériver” une donnée stockée vecteur en bdd vers une donnée stockée vecteur qui correspond au format pivot pour générer des graphe itinéraires.

Idéalement ce script devrait se baser sur des mécanismes générique de dérivation; mais la cible temporelle nous obligera surement à aller vers un script custom.

Données en entrée#

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

Donnée en sortie#

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

Paramètres#

  • conversion : Script de conversion à utiliser. Représenté par une string ayant comme valeur possible : bdtopo_v3.3 , bduni_bdtopo_v3.3, bdtopo_v3.2. Optionnel : valeur par défaut bdtopo_v3.3

  • bbox: bounding box en EPSG:4326 pour utilisation d’un extrait de la donnée en entrée. Représentée via {"west" : x_min, "east": x_max, "south" : y_min, north": y_max} Optionnel : valeur par défaut {"west" : -180, "east": 180, "south" : -90, north": 90}

Étapes et régles métier#

  1. Contrôler les paramètres :

    • voir les paramètres ci-dessus

  2. Identifier les données dans en entrée à traiter :

    • les paramètres de connection à la base de donnée pour la récupération des données en entrée sont issus des variables globales du parameters.json (infos de connexion à la BDD), et également du storage de la donnée en input (serveur BDD concerné, port d’accès, nom de la BDD) et de la livraison en elle même (nom de schéma à reconstruire à partir de l’id)

  3. Insertion des données :

    • les paramètres de connection à la base de donnée pour l’écriture des données en sortie sont issus des variables globales du parameters.json (infos de connexion à la BDD), et également du storage de la donnée en output (serveur BDD concerné, port d’accès, nom de la BDD) et de la livraison en elle même (nom de schéma à reconstruire à partir de l’id)

    • 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 donnée en entrée sinon.

    • transformation et écriture des donnée en sortie :

      • utilisation du paquet python route-graph-generator pour la transformation pour l’instant possibilité de transformation de 3 types de base de données :

        • BDTOPO v3.3

        • BDUNI en provenance d’une BDTOPO V3.3

        • BDTOPO v3.2

      • les paramètres attendus sont:

        • conversion : issu du paramètre du processing

        • bbox : issu du paramètre du processing

  4. Calculer les informations sur la donnée en sortie :

    • 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

      • ancestors : liste vide

    • Dans pipeline_status : Une ligne indiquant le status du script :

      • SUCCESS : L’intégration n’a pas rencontré de problème

      • FAILURE : Une erreur est intervenu lors de l’intégration des données en base :

        • Erreur lors de la conversion des données (données en entrée incompatibles avec la transformation)

      • TECHNICAL_ERROR : En cas d’erreur technique :

        • Mauvaise composition du parameters.json

        • Valeur inatendue dans le schéma JSON

        • Erreur de lecture / écriture dans la BDD (déconnection, indispo, full bdd)