Sélectionner une page

Du plan DWG vers un

SIG topologique sous Postgres

Retour sur l’expérience conduite avec l’Espace Communautaire Lons Agglomération (ECLA)

SIG PAYS IROISE

Avoir ses réseaux en base de manière topologique ouvre la porte à de nombreuses possibilités telles que la modélisation du fonctionnement des réseaux, la diffusion via des cartes web interactives, l’automatisation de certains processus, …

Lorsque les plans que l’on possède sont au format DWG, on hésite à franchir le pas ; à cause de la difficulté de la procédure, du risque de perte d’information, du manque de ressources et/ou d’outils, de la complexité d’accompagner les utilisateurs dans ce changement. Et pourtant, nous faisons ça très bien aujourd’hui, avec des outils Open Source et à moindre coûts.

Nous vous présentons dans cet article l’une des migrations que nous avons réalisée et qui sait, nous espérons vous donner l’envie de vous lancer dans l’aventure !

Cas d’Etude : ECLA, Réseaux d’eau potable et d’assainissement

ECLA (Espace Communautaire Lons Agglomération) est une communauté d’agglomération composée de 32 communes et 34 000 habitants dans le département du Jura. Son territoire se comporte de territoires dont la densité de population varie : de communes très peu denses (comme Baume-les-Messieurs ; 12 hab/km²) à des communes de densité intermédiaire (telles que Lons-le-Saunier ; 2 226 hab/km²).

Les réseaux humides de distribution d’eau potable et de collecte des eaux usées et pluviales sur le territoire communautaire sont gérés par une régie dédiée. Le périmètre d’exploitation de la régie compte 750 km de réseaux d’assainissement et 310 km de réseaux d’eau potable.

Ces réseaux étaient cartographiés sous la forme de plans géoréférencés au format DWG :

AEP :

  • 6 fichiers DWG regroupants plusieurs communes,
  • structuration des DWG hétérogène mais typologie et symbologie plutôt similaire,
  • topologie à reconstruire (pas de continuité des canalisations sous les symboles des ponctuels, croisement non découpants, …)
  • étiquettes à consolider et non associées à leurs objets,
  • doublons sur un fichier,
  • présence de loupes.

ASST :

  • 1 fichier DWG par commune,
  • structuration homogène des DWG,
  • topologie plutôt correcte,
  • étiquettes à consolider et non associées à leurs objets,
  • point d’accrochage de certains blocks ne se trouvent pas au centre du symbole,
  • différenciation entre réseau public et privé à prendre en compte,
  • géométrie des ouvrages à reconstruire (bassins pluviaux, …),
  • présence de légende sans calque spécifique.
DETAILS PAYS IROISE BMG

Nos méthodes

Soucieux de proposer à nos clients des solutions sur mesure, intéropérables et avec de fortes capacités évolutives, nous privilégions l’approche Open Source dans nos prestations.

Des outils de conversion Open Source

Pour cette prestation, nous avons tout d’abord convertit les fichiers DWG (format proriétaire) au format DXF (format ouvert) grâce à ODA File Converter, pour pouvoir les manipuler plus facilement.

Les données contenues dans les DXFs ont ensuite été transformées en tables dans PostgreSQL/Postgis grâce au module ogr2ogr de GDAL. Chaque objet du DXF est donc devenu une entité de type POINT / LIGNE / POLYGONE dans une table Postgres, toutes les informations associées ont été récupérées : géométrie, nom de la couche, style de ligne, type de bloc …

Exemple de données « brutes » issues des DWG sous Postgres

Le Noyau Topologique : TOP’EAU

Afin de faciliter la saisie des réseaux et de maintenir une cohérence à la fois topologique mais également métier des données, le noyau topologique Open Source dans PostgreSQL / Postgis : TOP’EAU que nous avons développé a été utilisé.

Ce noyau topologique est autonome, il peut être édité via l’application QGIS mais également par une application tierce. Les fonctionnalités standard de QGIS sont utilisées pour la consultation et l’édition. Un plugin avec une barre d’outils QGIS a été développé pour étendre les fonctionnalités, chaque outil s’appuyant sur des fonctions stockées dans la base de données, ils sont donc réplicables sur du web ou toute autre interface. TOP’EAU est bâti sur le principe ARC – NOEUDS. Sur la base de ce principe, 6 types de comportements sont déclinés.

Différents types de comportements du noyau topologique TOP’EAU

D’un point de vue fonctionnel, ce noyau permet d’assurer lors du déplacement d’un élément de type nœud que tous les arcs connectés seront modifiés afin de maintenir la connectivité avec ce nœud. Inversement, lors de la modification d’un élément de type arc, tous les nœuds qu’il supporte seront repositionnés sur celui-ci.

D’autres objets non connectés au noyau topologique de type point / lignes / polygones sont également pris en charge.

Une notion de niveau permet de gérer l’archivage des éléments du réseau mais également les différents étages d’un bâtiment par exemple. Ici, cette notion de niveau a également été utilisée pour séparer le réseau public du réseau privé.

Configuration du noyau TOP’EAU

Le modèle de données du noyau topologique TOP’EAU a été configuré selon le standard RAEPA. L’utilisation de ce standard permet de faciliter les échanges entre les différents acteurs (collectivités, délégataires, usagers) des services publics de distribution d’eau potable, d’assainissement collectif et d’évacuation des eaux pluviales.

Il a néanmoins été adapté aux besoins d’ECLA, pour notamment ajouter des champs spécifiques.

Exemple de fichier de configuration avec les champs supplémentaires

Pour les regards d’assainissement, nous retrouvons par exemple les notions de regard visitable, de tampon articulé, de présence d’échelon, de présence de cunette, …

Nous avons également adapté les listes de valeurs du RAEPA pour prendre en compte les différents cas rencontrés.

Exemple d’ajout d’occurences à une liste de valeurs RAEPA ( type : ‘Matériau’)

L’ajout de valeurs aux listes issues du standard RAEPA se fait selon une procédure : au lieu de coder le champ sur deux caractères, nous le codons sur trois. Cela nous permet d’ajouter des « sous-valeurs » en quelque sorte.

Par exemple, la valeur ‘Eternit’ – 131 est rattachée à la valeur ‘Grès’ – 13. Lors d’un export de données, le champ materiau est tronqué sur deux caractères ce qui nous permet de nous remettre automatiquement au format du standard. La différenciation entre Grès et Eternit est ainsi effective dans la base du client, mais disparaît lors d’un export au format RAEPA, les deux valeurs étant mappées vers ‘Grès’ (la valeur ‘Eternit’ n’existant pas dans le standard RAEPA).

Migration des données vers le noyau TOP’EAU

La migration des données vers une base de données telle que TOP’EAU est l’occasion de :

  • de trier /corriger les données,
  • de structurer les données selon les couches, attributs, et listes de valeurs définies,
  • de valider et corriger la topologie des réseaux, ouvrages et équipements (cf Traitements spécifiques des données DAO ci après).

Le noyau TOP’EAU est ensuite chargé de maintenir l’intégrité attributaire et topologique des données dans le temps.

Une fois les données récupérées dans Postgres, des scripts SQL ont donc permis de répartir chaque entité selon ses caractéristiques (la couche, le style et/ou le type de bloc) vers des tables d’objets métiers définies lors de la configuration.

Au vu de l’hétérogénéité des fichiers (surtout en AEP), nous avons mis en place une table de configuration pour faciliter la gestion des données. Elle nous a permis de lister les layers à utiliser, ainsi que la table de destination des objets à traiter.

Exemple de la table de configuration pour les branchements AEP

Exemple de mapping pour le champ typeequip (AEP)

Traitements spécifiques des données DAO

Vous trouverez ci-après les différentes problèmatiques rencontrées sur les données de type DAO et le résultat qui a été obtenu après traitements.

Reconstruction de la topologie

Sur certains DWG, les canalisations d’AEP s’arrêtaient aux limites des blocs des ponctuels (vannes, ventouses, …) et ne continuaient pas jusqu’au point d’accrochage. Il a donc fallut prolonger automatiquement le tracé des canalisations sous les symboles.

Visualisation DWG

Visualisation DXF chargé sous Postgres

Visualisation Top’Eau

La qualification des différents objets selon les 6 types de comportement de Top’EAU nous a amené faire quelques modifications lorsque le cas s’y prêtait : certaines conduites ont été découpées au niveau des intersections, des branchements ont été prolongés jusqu’aux conduites principales, des ponctuels ont été raccrochés au réseau, …

Visualisation DWG

Visualisation DXF chargé sous Postgres

Visualisation Top’Eau

Un autre cas concernait les ouvrages polygonaux, dont la majorité était « éclatée » en de nombreux éléments sans lien entre eux. Il a fallut re-consolider cette géométrie pour obtenir en sortie un seul polygone dont le visuel était comparable à la donnée en entrée.

Visualisation DWG

Visualisation DXF chargé sous Postgres

Visualisation Top’Eau

Gestion des étiquettes

Récupération des étiquettes flottantes sans lien avec l’objet (avec ligne de rappel), notamment les numéros des hydrants et des vannes.

Visualisation DWG

Visualisation DXF chargé sous Postgres

Visualisation Top’Eau

Récupération des étiquettes flottantes sans lien avec l’objet (sans ligne de rappel). Il a notamment fallut retravailler les étiquettes d’assainissement, qui se composaient des plusieurs textes sans lien, ni au sein de l’étiquette, ni par rapport à l’objet auquel elle se rapportait. Une première phase a consisté à consolider l’étiquette en elle-même avant de l’associer au bon objet.

Visualisation DWG

Visualisation DXF chargé sous Postgres

Visualisation Top’Eau

Récupération des informations contenues dans les attributs des blocks. Par exemple ici, le numéro des déversoirs d’orage.

Visualisation DWG

Visualisation DXF chargé sous Postgres

Visualisation Top’Eau

Vers de nouvelles possibilités…

La finalité du SIG étant aussi le partage des informations collectées, ECLA a déployé en interne une carte WEB dès la livraison du nouvel SIG ! Cette solution est déployée sur QGIS Server / LizMap est connectée en direct sur la base de données Postgres. Elle permet de diffuser des données à jour en temps réel de façon sécurisée, et permet une modification attributaire.

Thématique Réseau AEP (carte WEB)

Thématique Secteur AEP (carte WEB)

Visualisation des attributs sur la carte WEB d’ECLA avec possibilité de mise à jour

{

« Avec une grande hétérogénéité de plan, notre collectivité était face un défi de taille avec la transformation de ces plans DWG sous format SIG.
Continuellement à l’écoute de nos besoins, l’entreprise BeMapGuest a su nous accompagner  et s’adapter face à nos particularités.
Leur grande compétence dans la constitution de base de données a clairement été un atout majeur dans la bonne réalisation de ce chantier.« 

M. Nicolas

Chef de projet SIG, ECLA

Nous sommes très heureux d’avoir participé à l’élaboration du SIG d’ECLA. Ce projet complet nous a permis de mettre à l’épreuve nos compétences et de repenser à la meilleure façon de travailler les fichiers DWG pour aboutir à un résultat de qualité. La solution mise en place peut sans aucun doute se répliquer sur d’autres fichiers CAD, et nous sommes enthousiastes à l’idée d’accompagner d’autres collectivités sur une démarche similaire.

Vous avez un projet ? />

Nous sommes impatients d’en savoir plus !