Où n'écoutant que mon courage, je m'attaque à un standard CNIG...

Contrairement à ce que l'on pourrait croire, j'ai un vrai travail en dehors des internets. Et dans ce travail, j'ai besoin de d'échanger des données et de répondre à des trucs comme les DT-DICT. Je me suis donc poser la question de comment gérer un secteur qui n'est pas le mien : en l'occurence les câbles électriques.

Vu la sortie de STAR-DT (V1.0 du 19/11/2019), je me suis dit qu'il n'était pas la peine de réinventer la roue. Bon, bin finalement, c'est pas si simple. Petit tour dans la normalisation des échanges.

StaR-DT ?

Commençons par expliquer ce qu'est StaR-DT. Ce standard est lié à deux autres "Standards" : le PCRS et INSPIRE. Pour le néophyte, le PCRS (Plan Corps de Rue Simplifié) est le relevé topographique systématique des rues, permettant d'avoir un référentiel très précis (centimétrique) des éléments de voirie, des affleurants, signalisation...Et INSPIRE est une directive européenne d'échange entre pouvoirs publics, notamment pour l'opendata. C'est très court, je sais mais je vous laisse lire les sites en rapport.

Quel lien avec StaR-DT ? StaR-DT, je pense que le nom vient de STAndard Réseaux pour répondre au DT (déclaration de Travaux), mais je n'ai pas trouvé de confirmation. Bref, avec un référentiel précis servant de fond de plan, et une directive d'échange, il ne manquait plus qu'un standard permettant à tous les exploitants de réseaux de fournir leur tracé de conduites afin d'éviter les accidents, préjudiciables voire mortels dans le cas du gaz, de l'elect... Encore aujourd'hui, à la date de ce billet, les échanges se font essentiellement par des plans PDF ou autres, répondant à certains critères certes, mais produits suivant les habitudes de l'exploitant, Un fond de plan cadastral est sa précision légendaire. Le report sur des plans précis est donc parfois hasardeux et donc pas optimal pour faire des projets ou des travaux.

Le CNIG (Conseil national de l’information géographique)  est donc en charge de coordonner la mise en place de ses standards et de les distribuer. Sont alors constituer des groupes de travail, qui réunissent les acteurs du secteurs concernés pour se mettre d'accord sur les protocoles d'échange et de normalisation. Comme indiqué sur le site : Le sous-groupe commun PCRS/GP4 est devenu ce GT pour traiter des plans des réseaux fournis en réponse aux DT-DICT avec la création du standard StaR-DT. Le but est de dématérialisé les transmissions, mais pas seulement PDF, mais bien avec un format vectoriel.

Vous pouvez retrouver tous les travaux sur :

• http://cnig.gouv.fr/
• https://github.com/cnigfr/StaR-DT

Alors, voilà je me suis penché sur les livraisons du groupe afin de comprendre comment cela marche. Je vous livre mon ressenti, sans aucune critique (ou si peu), et sans aucune intention de dénigrer le travail, qui est encore finalement en cours.

Bien

Le travail est énorme, INSPIRE n'est pas si facile à appréhender. Le hic de ce type de format est de fédérer à un niveau très très général toutes les données européennes. Cela s'appuie donc sur des habitudes, des formats, des langues différentes. Tout cela ne peut qu'être très généraliste et ne peut contenter tout le monde. Mais cet effort de standardisation est nécessaire et salutaire pour harmoniser les pratiques. 

Pas bien

Quand j'ai regardé les fichiers et tous les documents, je ne suis rendu compte des quelques manques que je vous détaille plus bas. Mais d'un point de vue générale, mon point de vue, je regrette certaines choses :

• l'utilisation des listes en anglais : sans aucune forme de chauvinisme ou plus grave, pourquoi utiliser les termes anglais, même la liste des matériaux, avec des éléments qui ne seront pas reconnus par les professionnels du secteur, le PEX qui est plutôt appelé PER, le CPVC (PVC-C en français) qui sont plutôt des termes de plomberie que de canalisateur...Et en plus, il existe déjà de nombreuses listes de matériaux, y compris dans les normes européennes (exemple norme ITV). Bref, pourquoi utilisé 'functional' pour dire 'actif' ou 'en service' : pour être directement compatible INSPIRE. C'est peut-être le défaut, vouloir rester trop proche du modèle INSPIRE, au lieu de prévoir des tables de concordances.
• le GML, alors oui, format plat, standard, géographiquement adapté, mais au combien difficile à appréhender dans les logiciels, et même si les collections d'objet existe aussi dans POSTGIS, il est très difficile de travailler concrètement avec. Et puis, je pense à tout ces services qui n'ont pas la taille de grands groupes qui peuvent se payer des développeurs et des géomaticiens à temps pleins, et surtout qui ne peuvent se payer des FME et autres pour faire de la transformation et surtout en 1 seul fichier qui répond aux critères INSPIRE. Il faudra sans doute passer par des logiciels ou des prestations spécifiques, à grand frais, pour pouvoir sortir le GML attendu, mais peut-être est-ce fait exprès ? Bon, je ne suis pas penché sur les extensions QGIS pour faire du GML, il existe peut-être déjà des solutions simples et peu onéreuses. Ou il y a des trucs que je n'ai pas compris.
• Les listes en XML, même avec leur XSD.
• Les fichiers .shp (dont vous connaissez mon aversion) fournis dans le standard, qui sont par nature tronqué dans les champs, et ne correspondent pas aux documents. Si je le rejoins au point d'avant, la génération d'un fichier d'échange va être compliqué.

Partant de ces constats, je n'ai décidé de m'adapter.

Ma version

Pour décomposer tout ça, je m'y suis pris en 3 temps :

1 les codelistes

D'abord, les fichiers XML ne sont pas le format le plus pratique pour moi. En tout cas, je ne sais pas comment les intégrer facilement dans une base de données ou dans les formulaires QGIS (j'ai sans doute des lacunes là dessus), j'ai donc transformé tout ces fichiers en .csv

Comment j'ai fait : j'ai importé le XML dans Libreoffice et enregistrer en .csv. Oui, à la main...Je n'ai pas trouvé ou chercher correctement un parser, et la flemme de faire un code pour ça. Et puis cela m'occupe en regardant un film le soir.

En examinant, les fichiers j'ai trouvé plusieurs soucis, comme par exemple des fichiers en double, des listes non traduites (alors que le fichier accompagnant l'est), sans description ou sans 'identifier', et pour l'eau des traductions littérales (un catchbasin est une décantation, pas un bassin de stockage, et un barscreen un dégrilleur....). Ou je n'ai pas trouvé UtilityDeliveryTypeValue nécessaire pour les canalisations...

J'ai donc décidé, en accord avec moi-même de reprendre ces listes. En indiquant les traductions, les listes complètes et avec un identifiant et une description, tout en suivant le standard au plus près.

Vous trouverez les sorties des fichiers XML en CSV dans le répertoire Codelistes_Modele, et mes listes modifiées dans Codelistes_on_steroids

2 le modèle de données

Dans cette étape, j'ai suivi le modèle global. Là encore, j'ai essayé de coller au plus près du modèle. Pour cela, je suis passé par un montage POSTGIS, je vous fournis le fichier SQL. Ce montage m'a permis de mettre en place les héritages et quelques liaisons. 

Cependant des adaptations sont nécessaires, notamment à cause des table avec des collections (géométrie décrite comme GM_OBJET), que je suis obligé de créer en 3 couches point, ligne, surface pour pouvoir travailler dessus. Par ailleurs, certaines tables semblent comprises avec une relation, mais le nom des clés ne sont pas indiquées.

Ceci étant, j'ai sauvegarder les tables POSTGIS en couches GPKG, via QGIS et l'empaquetage de couches.

3 Dans QGIS

Enfin, dernière étape, mettre tout cela dans un projet QGIS (version 3.16.16-Hannover sous Linux) . Ceci m'a permis de suivre la symbologie définit dans le standard, une fois de plus, je suis normalement très très proche du modèle mais il existe quelques questions.

J'ai défini une palette de couleurs, que vous pouvez importer dans les options QGIS

J'ai dessiné vite fait les symboles sous inkscape (dans le dossier symboles), qui devront sûrement évoluer avec le travail d'autres groupes de travail, et je pense dans le sens de la simplification (un carré à la place du dessin batimenttechnique par exemple). Les lignes peuvent être importées dans le gestionnaire de style :

Et enfin, j'ai donc défini tous les formulaires de saisie, en récupérant mes Codelistes_on_steroids, exemple :

J'ai rangé les champs suivant leurs table d'origine, ce n'est pas le plus évident pour la saisie, mais j'ai manqué d'idées...

J'ai aussi rangé les différents style dans les couches du projet et souvent un style par défaut dans le geopackage, mais vous retrouvez tous les fichiers .qml dans les dossiers.

Les fichiers

Donc voilà, maintenant après toutes ces descriptions, et pas mal d'heures de nuit depuis 1 semaine, j'ai tout mis dans mon suivi git préféré :

https://codeberg.org/pasq_fr/Star-Dt_with_QGIS

Le suivi se fera dans les tickets de codeberg, car il y a encore des modifications ou améliorations à faire ou finir. Je vous laisse essayer et commenter.