Dans cet article, nous examinerons certaines des configurations plus avancées qui peuvent être appliquées aux réseaux basés sur la gravité pour répondre à des questions plus sophistiquées et améliorer la qualité des données. Nous verrons comment le utility network aborde ces défis grâce à l'utilisation de subnetworks, de terminals et de règles.
Tout est-il connecté ?
Pouvoir exécuter des traces pour identifier la direction du flux dans notre système est un outil analytique utile, mais une question courante à laquelle nous devons répondre est de savoir si toutes nos entités sont correctement connectées. La manière la plus simple, mais la moins efficace, de déterminer cela est de placer un emplacement de trace dans votre carte et d'exécuter une trace connectée. Cette trace identifiera toutes les entités accessibles à cet emplacement. Cela fonctionne bien pour les petits réseaux où tout est connecté, mais si votre jeu de données est très volumineux, cette trace prendra plus de temps et si vos données ne sont pas toutes connectées à un système connecté unique, vous devez fournir plusieurs emplacements de départ pour couvrir l'ensemble de votre réseau.
Ci-dessous, vous pouvez voir un exemple d'un jeu de données d'eaux pluviales. Parce que seules les zones de captage sont modélisées, et non les rivières et canaux qui les relient, une seule trace de connectivité ne peut pas être utilisée pour identifier les entités déconnectées.
Une des façons dont le utility network peut aider à identifier les entités déconnectées est en configurant des subnetworks. Un subnetwork représente un sous-ensemble nommé de notre utility network avec un ensemble d'appareils responsables du contrôle des ressources dans cette zone. Dans le cas d'un réseau d'eaux pluviales, ce sont généralement les outfalls qui contrôlent chaque zone de captage.
Si nous transformions tous les outfalls de nos zones de captage en contrôleurs de subnetwork, nous pourrions exécuter une trace pour trouver tout ce qui était connecté à notre réseau. Nous pouvons simuler cela en exécutant une trace connectée en utilisant chaque outfall dans notre réseau comme emplacement de départ.
Si nous créions un seul subnetwork appelé « Stormwater System », avec chacun de ces appareils comme contrôleur de subnetwork, les entités sélectionnées dans le graphique ci-dessus représenteraient ce à quoi ressemblerait le subnetwork. Bien que cela soit utile d'un point de vue initial d'assurance qualité, il serait beaucoup plus utile si nous modélisions chaque groupe d'outfalls qui gouverne une zone comme contrôleurs pour une zone de captage spécifique. Les ingénieurs qui s'appuient sur les données GIS pour maintenir les modèles de planification et d'ingénierie suivent déjà ces informations en dehors du GIS. En modélisant les zones de captage dans le GIS, nous pouvons valider que les modifications que nous apportons ne sont pas seulement topologiquement correctes, mais qu'elles valident également les informations requises par les ingénieurs ou planificateurs pour produire leurs modèles.
Selon la qualité, la complexité et le volume des données que vous maintenez, vous pouvez décider de modéliser un seul subnetwork pour l'ensemble de votre système, ou vous pouvez décider de créer des subnetworks séparés pour chaque zone de captage. Nous discuterons de la tâche plus difficile consistant à configurer des subnetworks séparés. Ces instructions supposeront que lorsque vous avez exécuté l'outil Migrate to Utility Network et identifié une ou plusieurs couches comme ayant des contrôleurs en leur sein ; sinon, vous devrez effectuer une configuration supplémentaire pour permettre à une entité d'être un contrôleur de subnetwork.
Règles et Terminals
Par défaut, l'outil Migrate to Utility Network configurera les contrôleurs de subnetwork dans un réseau basé sur un puits (sink-based) pour ne se connecter aux entités qu'en utilisant leur terminal Upstream. Si vous ne modélisez rien en aval de vos outfalls, vous pouvez passer à la section suivante où vous verrez comment créer vos contrôleurs de subnetwork.
La première chose que nous devrions faire est d'examiner les règles dans notre réseau en utilisant la boîte de dialogue des propriétés du réseau. Ci-dessous, nous pouvons voir un sous-ensemble des règles pour nos points de décharge. Si nous regardons attentivement, nous pouvons voir que les points de décharge ont été configurés pour se connecter à tous les types de lignes dans notre modèle en utilisant leur terminal upstream.
Nous pouvons affiner ces règles afin qu'elles reflètent plus précisément la manière dont nos décharges doivent être connectées aux autres entités du réseau.
- Outfall – Ces entités permettent à un tuyau de se déverser dans un drain ouvert
- Overflow – Ces entités permettent à un tuyau ou une ligne virtuelle de drain débordante vers un drain ouvert
- Standard Outlet – Ces entités permettent à un tuyau de se décharger dans une ligne virtuelle de drain
- Terminal Discharge – Ces entités permettent à un tuyau ou drain ouvert de sortir du système
Nous devons exécuter les outils Add Rule et Delete Rule pour configurer les règles afin qu'elles correspondent à ces exigences. Une fois que nous avons configuré les règles et activé notre topologie réseau, il est probable que nous voyions des erreurs de connectivité (les lignes rouges dans le graphique ci-dessous) dans notre base de données pour beaucoup de nos points de décharge.
Selon vos données et comment vous ajustez vos règles, vous verrez deux types différents d'erreurs : Connectivité invalide – Il n'y a pas de règle qui permet aux deux entités de se connecter.
Connectivité ambiguë – Il y a plus d'une règle qui permet aux entités de se connecter.
Bien que nous puissions examiner chaque erreur individuellement et déterminer comment les corriger une par une, s'il y a plus que quelques erreurs, il est plus efficace d'utiliser l'outil Analyze Network Data pour obtenir un résumé de tous les types d'erreurs.
En plus de créer un fichier couche pouvant être utilisé pour examiner nos erreurs, l'outil génère également un fichier RuleCandidates.csv. Ce fichier contient toutes les règles qui pourraient être ajoutées au réseau pour résoudre les erreurs de connectivité. Vous voudrez examiner attentivement la liste des règles avant l'importation et n'importer que celles concernant des entités qui devraient être autorisées à se connecter. Vous devrez peut-être consulter un ingénieur ou un travailleur sur le terrain pour déterminer ce qui est approprié. Vous pouvez en apprendre davantage sur ce processus dans l'article Refining connectivity rule.
Une fois que vous avez déterminé quelles règles vous souhaitez ajouter, utilisez l'outil Import Rules pour ajouter ces règles à votre utility network. N'oubliez pas qu'avant d'ajouter des règles, vous devez désactiver la topologie du réseau.
Une fois que vous avez ajouté les règles manquantes et réactivé la topologie du réseau, vous devrez ensuite utiliser l'outil Modify Terminal Connections pour résoudre toute connectivité ambiguë. Cela n'est nécessaire que si vous avez une ligne autorisée à se connecter à plus d'un terminal sur un appareil.
Si vous souhaitez plus d'exemples sur la façon de traiter ce type d'erreurs de connectivité, vous pouvez trouver trois tutoriels pour vous guider dans ce processus décisionnel dans la série d'apprentissage Editing and connectivity.
Une fois que notre topologie réseau est activée et sans erreur, nous sommes prêts à avancer avec la création de nos subnetworks.
Créer un subnetwork simple
La première chose que nous devons faire est d'identifier les outfalls qui agissent comme contrôleurs du subnetwork pour chaque zone de captage dans notre réseau. Cela peut être fait en exécutant une trace connectivité pour une zone du réseau et en s'arrêtant chaque fois que nous atteignons un outfall, qui a été configuré comme contrôleur du subnetwork. Bien que nous puissions sélectionner manuellement et ajouter des barrières pour ces entités, il est souvent plus facile d'utiliser une barrière conditionnelle pour identifier automatiquement ces entités lors du traçage. Pour ce faire, nous ajoutons une barrière conditionnelle à notre trace pour les entités ayant une catégorie Subnetwork Controller.
Cela fera arrêter la trace sur toute entité dont le type d'actif a une catégorie Subnetwork Controller, dans ce cas les outfalls. Cette catégorie réseau est initialement remplie par l'outil Migrate to Utility Network pour toutes les correspondances que vous avez désignées comme étant contrôleur. Vous pouvez également ajuster cela ultérieurement en utilisant l'outil Set Network Category. Nous pouvons voir ci-dessous les résultats d'une telle trace.
Dans ce cas précis, nous avons une zone entièrement connectée à un seul outfall. Utilisez l'outil Modify Subnetwork Controller pour définir le terminal upstream (le côté qui reçoit le matériau) d'un contrôleur subnetwork sur cet outfall vers une nouvelle zone de captage. Le contrôleur subnetwork doit avoir un nom unique et cette zone doit également avoir son propre nom unique. Si nous discutons nos zones de captage et outfalls avec l'ingénierie ou l'exploitation, ils peuvent déjà avoir des identifiants spécifiques qu'ils souhaitent que nous utilisions. Utiliser ces mêmes identifiants uniques facilitera également la collaboration et la communication entre départements.
Après avoir validé le changement avec le réseau, nous pouvons maintenant exécuter une trace subnetwork pour voir toutes les entités connectées à cet outfall.
Nous pouvons également utiliser l'outil update subnetwork pour stocker le nom de la zone de captage sur ces entités. Cela facilite l'identification des entités appartenant à une zone donnée et celles qui n'en font pas partie.
Après avoir exécuté cet outil, nous pouvons voir que toutes les entités dans ce subnetwork ont leur nom subnetwork renseigné.
Et nous pouvons voir qu'il y a maintenant une entité ligne subnetwork représentant toutes les lignes dans cette zone de captage.
Une fois que vous avez utilisé l'outil Update Subnetwork pour créer une ligne subnetwork, ce subnetwork apparaîtra désormais dans le volet Find Subnetwork lorsque cette ligne sera dans l'étendue actuelle.
Maintenant que nous avons vu comment créer un simple subnetwork avec un seul contrôleur, examinons comment gérer une zone avec plusieurs outfalls.
Subnetworks avec plusieurs contrôleurs
Tous les subnetworks n'ont pas un seul contrôleur. Les réseaux d'eaux pluviales ont souvent plusieurs outfalls responsables du déchargement d'eau depuis une zone donnée selon la quantité d'eau présente dans le système à un moment donné.
Nous commençons le processus pareillement ; en effectuant une trace connectivité dans notre réseau en traitant les contrôleurs du subnetwork comme barrière ; cela fera arrêter la trace aux outfalls. Envisagez créer et utiliser une configuration trace spécifique pour faciliter ce processus.
Dans ce cas précis, nous avons une zone avec trois outfalls. Nous répétons le même processus qu'auparavant : nommer chaque outfall individuellement mais leur donner tous le même nom subnetwork car ils partagent tous la responsabilité du déchargement d'eau depuis cette même zone.
Remarque : Si vous ne fournissez pas un nom au contrôleur du subnetwork, l'outil utilisera automatiquement l'id global (global id) de l'entité.
Encore une fois, validez la topologie du réseau et exécutez la mise à jour du sous-réseau pour terminer la création du deuxième bassin versant.
Répétez ce processus jusqu'à ce que toutes les entités du réseau appartiennent à un sous-réseau. Cela semble facile, mais examinons certains des problèmes les plus courants qui peuvent survenir.
Contrôleurs manquants
Utiliser ce processus fournit une méthode fiable, mais manuelle, pour identifier tous vos sous-réseaux. Le problème le plus courant que vous rencontrerez est que les contrôleurs de sous-réseau peuvent manquer dans vos données, ou des problèmes de données peuvent faire apparaître une zone de bassin versant beaucoup plus grande qu'elle ne devrait l'être. En regardant l'exemple ci-dessous, nous pouvons voir qu'une petite zone de bassin versant apparaît comme une zone beaucoup plus grande.
Si nous zoomons sur la région indiquée dans l'image ci-dessus, nous pouvons voir que le problème est qu'il n'y a pas de déversoir entre les tuyaux du bassin versant et le canal ouvert dans lequel il se déverse. Cela est indiqué dans le graphique ci-dessous.
Pour corriger cette erreur, nous travaillerions avec un ingénieur ou une équipe sur le terrain pour s'assurer que le SIG correspond à ce qui est actuellement installé sur le terrain. Dans ce cas, nous créerions un déversoir entre le tuyau et le canal de la rivière. Nous ferions ensuite de ce nouveau déversoir un contrôleur de sous-réseau pour notre troisième bassin versant.
Si nous regardons de près la capture d'écran ci-dessus, nous pouvons voir qu'il y a encore un problème potentiel dans cette zone. Certains des tuyaux au nord de ce bassin versant n'ont aucune forme de sortie. Si nous zoomons, nous pouvons voir que cette zone devrait probablement être connectée au bassin versant. Nous devrions confirmer avec un ingénieur ou une équipe sur le terrain que c'est bien le cas, mais une fois que nous aurons déterminé comment/si elle est connectée, nous pourrons alors mettre à jour nos données SIG pour refléter cela.
Conclusion
Dans cet article, vous avez appris comment utiliser les sous-réseaux, les règles et les terminaux pour améliorer la qualité de vos données. Vous avez vu comment cela vous a permis d'identifier des entités manquantes, des entités mal connectées et comment identifier des emplacements dans votre réseau sans aucune sortie. Si vous êtes intéressé par des tâches d'analyse plus avancées comme la gestion des bassins versants ou des réseaux d'égouts ou la gestion des sous-bassins et bassins versants, faites-le nous savoir ! Si vous avez des questions sur le utility network, assurez-vous de les poser sur le Esri Community site.
Si vous souhaitez en savoir plus sur l'utilisation du utility network pour gérer des réseaux gravitaires, comme les données d'égouts et d'eaux pluviales, veuillez explorer la Learn ArcGIS Utility Network for Sewer and Stormwater série d'apprentissage. Cette série d'apprentissage comprend des tutoriels et des articles qui démontrent comment répondre aux besoins de l'industrie des égouts et des eaux pluviales en utilisant le utility network.
