Contactez-nous
 

Système d’information des réseaux d’eaux (SIRE) : Modélisation, contrôle topologique et export pour simulation hydraulique


Session Infrastructures et Réseaux
 


Christophe SCHWAAR, ingénieur EPFL
Courriel : christophe.schwaar@vd.ch
Etat de Vaud, Service de la consommation et des affaires vétérinaire (SCAV)
Ch. des Boveresses 155
1066 Epalinges
Suisse            

Paulo De Souza, ingénieur
Courriel : paulo.de-souza@vd.ch
Etat de Vaud, Direction des systèmes d’information (DSI)
Av. Recordon 1
1014 Lausanne
Suisse

 

Mots-clés, logiciels ESRI utilisés et publics visés
 


Mots-clés : SIRE, ArcGIS, réseaux d’eau, modèle de donnée, topologie, Export pour simulation hydraulique, Epanet, script python géotraitement.

Logiciels ESRI utilisés :

Public visé : Tout public

 

1. Introduction


Dans le canton de Vaud (Suisse), le Service de la Consommation et des Affaires Vétérinaires (SCAV) ainsi que l’Etablissement Cantonal d’Assurance (ECA) sont les deux instances cantonales concernées par les réseaux de distribution d’eau potable et de lutte contre le feu. Leurs objectifs principaux sont d’assurer un développement coordonné et harmonieux des réseaux d’eau potable à l’échelle de tout le canton et de subventionner de manière optimale les infrastructures nécessaires à la défense incendie. Le SCAV est l’instance délivrant le permis de construire pour les infrastructures du réseau principal tandis que l’ECA délivre les subventions.
Afin de pouvoir réaliser efficacement leurs tâches, l’ECA et le SCAV mettent sur pied un système d’information des réseaux d’eau nommé SIRE, développé sur les outils d’ESRI (ArcGIS). Il constituera un plan général des réseaux d’eau potable à l’échelon cantonal.
SIRE offrira une vision globale et constamment à jour des réseaux. Ceux-ci devenant de plus en plus complexes, cette vision est un préalable indispensable aux autorités cantonales pour l’accomplissement  de leurs tâches et l’approbation de projets conduisant à une planification optimale et durable des réseaux. SIRE sert également à optimiser les interventions dans le domaine de la distribution de l’eau (en cas de pollutions, incendies, …).


2. Concept général du projet


Un modèle de donnée spécifique nommé ModoSire a été développé. Celui-ci est disponible en tout temps et utilisable par quiconque le désire. Ce modèle permet de répondre aux besoins spécifiques de production de cartes thématiques pour l’ECA et le SCAV et de réaliser l’ensemble des requêtes et statistiques nécessaires.
Le projet SIRE intègre la possibilité d’export direct, via script de géotraitement (script python), des données issues d’une géodatabase depuis ArcGIS pour effectuer de la simulation hydraulique au sein du logiciel libre Epanet. Un tel export implique une qualité topologique irréprochable des données, celles-ci sont donc contrôlées et corrigées par un processus complet mélangeant divers outils de contrôle disponibles en standard avec une licence Arceditor.
Une interface web est prévue afin de permettre aux distributeurs d’eau d’avoir un accès sécurisé aux données SIRE de leur réseau.


Figure 1 : concept général de SIRE

Le règlement de l’ECA sur la participation au frais de prévention impose que les données relatives au Plan Directeur de la Distribution de l’Eau (PDDE) et aux projets de modification du réseau principal soient fournies dans un format informatique exploitable pour l’implémentation des données dans SIRE, cela est une condition de subventionnement.
Le règlement fait référence à des directives techniques ad hoc (direcSire et dictionnaire de données ModoSire) traitant du degré d’information minimal requis ainsi que des contraintes liées au type de logiciel utilisé et au format de donnée à transmettre. Les directives traitent aussi des contraintes de saisies géométriques garantissant une bonne qualité topologique permettant la reprise des données dans SIRE. La directive et le dictionnaire de donnée ModoSIRE sont téléchargeables à l’adresse : www.vd.ch/sire.


3. Modèle de données


Un modèle de données relationnel spécifique nommé ModoSire a été développé dans le cadre du projet SIRE. Celui-ci a été réalisé dans le formalisme UML sous Visio 2003.



Cliquez pour agrandir
Figure 2 : Modèle de donnée ModoSire, schéma général (Visio)

La création automatique de la géodatabase ESRI depuis Visio a été réalisée en utilisant la procédure suivante (Case tools) : 
1.      Export d’un fichier XMI depuis Visio en utilisant l’outil « UML to XMI tool ».
2.      Utilisation dans ArcCatalog de l’outil « Semantics Checker » permettant de vérifier l’intégrité du modèle.
3.      Utilisation de « Schema Wizard » dans ArcCatalog qui permet de générer la géodatabase.

La figure ci-dessous résume le processus de création de la géodatabase selon le modèle ModoSire.


Figure 3 : Création de la géodatabase à partir du modèle de donnée au formalisme UML sous Visio

L’avantage d’une telle méthodologie réside dans le fait de la nécessité de maintenir à jour un seul fichier (Visio) sous forme de schéma UML qui est intuitif et d’éviter de générer manuellement l’ensemble des classes d’entités et de relations au sein d’ArcCatalog. La génération manuelle présente de gros risques de biais, d’oubli et de mauvaise définition de format d’attributs. La méthodologie décrite ci-dessus (figure 3) s’est avérée efficace et rationnelle dans le cas du développement du modèle relativement conséquent qu’est ModoSire, notamment dans la phase de développement et de test durant laquelle des changements étaient régulièrement apportés.
Le modèle de données développé (ModoSire) comporte 14 classes d’entités et celui-ci a été conçu de façon à pouvoir répondre aux attentes des utilisateurs tant en terme d’affichage que de traitement de données.


4. Reprise de données


Les données relatives à des projets soumis au régime de subventionnement de l’ECA doivent être transmises, par les distributeurs d’eau et leurs mandataires, conformément à la directive technique DirecSire en vigueur. L’ensemble des projets de modification de réseau principal et les Plans directeurs de distribution d’eau (étude montrant le développement futur prévu du réseau) sont soumis à cette directive imposant notamment un degré minimal d’information requis.

Quatre cas ont été distingués :
1.      Utilisateurs d’ArcgGis d’ESRI : imposition de transmission des données selon la structure SIRE. La géodatabase étant disponible en tout temps auprès des instances compétentes.
2.      Utilisateurs de SIG vendus sans modèle de données : imposition de transmission des données selon la structure du modèle ModoSire, celui-ci est disponible dans des format standards permettant son implémentation au sein des logiciels utilisés (Interlis, UML…).
3.      Utilisateurs de logiciel «  clé en main » vendu avec un modèle de donnée eau : imposition de transmission des données dans le modèle brut courant du fournisseur de solution sans modification en respectant le degré d’information requis (table de correspondance attributaire SIRE - modèle fournisseur).
4.      Utilisateurs de logiciel de dessin (Autocad) : données issues de tel logiciel encore acceptées provisoirement moyennant l’utilisation d’une méthodologie de saisie spécifique définie au sein de la directive en vigueur (utilisation de blocs comportant des attributs selon structure SIRE déposés sur les objets de dessin).

Les données transmises sont ensuite traitées par des scripts FME (Safe software) soit pour introduction direct dans la base principale SIRE ou via changement de modèle de donnée (traitement spécifique via scripts FME)


Figure 4 : Processus de reprise de données et directives


5. Contrôles topologiques


Comme mentionné précédemment un des aspects du projet SIRE est l’export direct de donnée vers le logiciel de simulation hydraulique EPANET par script python de géotraitement. Un prérequis indispensable au bon fonctionnement des données exportées au sein du logiciel de simulation hydraulique Epanet est une qualité topologique irréprochable. Il est en effet nécessaire que les contraintes suivantes soient respectées :
 
Connectivité des objets les uns aux autres respectée
Pas d’objets auto-sécants
Pas de superposition d’objet
Tronçon de conduites coupé au droit de chaque intersection (outil découper les points par ligne disponible sur le site de support Esri France).

Afin de contrôler la topologie, une procédure mélangeant divers outils standards de contrôle disponibles avec une licence ArcEditor a été réfléchie et mise en place. Les notions de règle de topologie et de réseau géométrique ont été exploitées.
 
Règle de topologie

Par génération d’une topologie au sein de la géodatabase, en définissant l’ensemble des règles nécessaires, il est possible de contrôler et corriger la majeure partie des erreurs via l’inspecteur d’erreur de la barre d’outil topologie. L’outil standard disponible permet également de localiser les  erreurs sur le plan géographique dans ArcMap.

Cependant l’utilisation des règles de topologie ne permet pas de faire la distinction entre un nœud pendant correspondant à l’extrémité d’une conduite se terminant en cul de sac d’un nœud pendant correspondant à une erreur de connectivité. Afin de contrôler la connectivité des tronçons les uns aux autres il a donc fallu chercher une autre solution passant par l’utilisation de réseau géométrique.


Réseau géométrique

La génération d’un réseau géométrique au sein de la géodatabase puis l’utilisation de l’outil « Analyse du réseau de distribution» permet de rechercher et d’afficher de manière géographique dans ArcMap les entités déconnectées depuis un point de départ défini. Cette procédure permet de contrôler la connectivité des tronçons les uns aux autres et de corriger les erreurs. L’expérience a montré que le fait de ne plus avoir d’entités déconnectées à ce stade ne garantit encore pas une connectivité irréprochable. En  effet, du fait du maillage des réseaux, il peut encore subsister des points de non connexion au sein de mailles bien que l’ensemble soit considéré comme connecté lors du contrôle précédent. Il est de ce fait indispensable de rechercher aussi les boucles afin de vérifier que la connectivité est respectée dans l’ensemble des mailles.


Figure 5 : Contrôles topologiques


6. Export pour simulation hydraulique dans EPANET (script python)


L’objectif est de créer un fichier ASCII avec le suffixe « inp » selon la structure Epanet pour les réseaux ou parties de réseaux sur lesquels des simulations hydrauliques sont à réaliser. Les scripts Python de géotraitement  développés permettent d’exporter uniquement les conduites et les nœuds depuis le SIG vers Epanet. La disposition des autres ouvrages dans Epanet et la manière de les représenter (ex : réservoir infini ou non) implique une réflexion au cas à cas selon le type de simulation désirée (instantanée ou temporelle).


Figure 6 : Structure du fichier ASCII voulue pour Epanet

Le développement des outils d‘export a été réalisé à partir de scripts python générés par le Model Builder dans l’environnement ArcGIS et ensuite complété par programmation avec Pythonwin pour les aspects non réalisables au sein du Model Builder (utilisation des notions du Geoprocessor programming model).



Cliquez pour agrandir
Figure 7: Model builder et Geoprocessor programming model utilisé pour le develloppement des script python de géotraitement

6.1. Procédure


La procédure de création du fichier « inp » est organisée en quatre parties, nécessitant comme données en entrée une classe d’entité de conduites et une couche MNT raster ou de courbes de niveau. Le processus est le suivant :
 
1.    Calcul des coordonnées de début et fin de chacun des objets conduites (champs FROM_PT et TO_PT)
2.    Création d’une couche de nœuds correspondant aux points de début et de fin des conduites.
3.    Génération des correspondances « From » et « To » dans la classe d’entité des conduites, attribution des IDs des nœuds correspondant au point début et fin de chaque conduite.
4.    Attribution des altitudes aux neouds soit par jointure spatiale sur une couche de courbe de niveau ou sur la base d’un modèle numérique de terrain (raster). L’attribution des altitudes sur la base d’un MNT raster implique l‘utilisation d’une licence Spatial Analyst.
5.    Ecriture du fichier ASCII avec l’extension « inp »
L’étape 4 différencie les deux scripts développés. En effet l’attribution des altitudes sur la base d’une couche de MNT est une procédure, en générale, plus précise mais elle requiert l’extension Spatial Analyst. La volonté de fournir un script à usage le plus large possible, nous a amené à proposer également l’attribution des altitudes sur la base d’une jointure spatiale entre les nœuds et les courbes de niveau.  Cette procédure, moins précise, requiert uniquement licence Arcview.


Figure 8: Procédure de création du fichier ASCII pour Epanet via script Python de géotraitement


7. Informations complémentaires


Pour des informations complémentaires concernant le projet SIRE ainsi que l’accès à divers documents le site web suivant peut être consulté : www.vd.ch/sire.


© ESRI France
Accueil - Communications Utilisateurs - Plénière - Ateliers - Concours - Partenaires