In dit artikel zullen we enkele van de meer geavanceerde configuraties onderzoeken die kunnen worden toegepast op gravity-based netwerken om meer verfijnde vragen te beantwoorden en de datakwaliteit te verbeteren. We zullen bekijken hoe het utility network deze uitdagingen aanpakt door het gebruik van subnetworks, terminals en regels.
Is alles verbonden?
Het kunnen uitvoeren van traces om de stroomrichting in ons systeem te identificeren is een nuttig analytisch hulpmiddel, maar een veelgestelde vraag is of al onze features correct verbonden zijn. De eenvoudigste, maar minst efficiënte manier om dit te bepalen is door een trace-locatie op uw kaart te plaatsen en een connected trace uit te voeren. Deze trace identificeert alle features die naar die locatie begaanbaar zijn. Dit werkt goed voor kleine netwerken waar alles verbonden is, maar als uw dataset erg groot is, zal deze trace meer tijd kosten en als uw data niet allemaal verbonden is met één enkel verbonden systeem, moet u meerdere startlocaties opgeven om uw hele netwerk te dekken.
Hieronder ziet u een voorbeeld van een stormwater dataset. Omdat alleen de opvanggebieden zijn gemodelleerd, en niet de rivieren en kanalen die ze verbinden, kan een enkele connectivity trace niet worden gebruikt om niet-verbonden features te identificeren.
Een van de manieren waarop het utility network kan helpen bij het identificeren van niet-verbonden features is door subnetworks te configureren. Een subnetwork vertegenwoordigt een benoemde subset van ons utility network met een set apparaten die verantwoordelijk zijn voor het beheren van de bronnen in dat gebied. In het geval van een stormwater netwerk zijn dit meestal de uitlaten die elk opvanggebied beheren.
Als we alle uitlaten voor onze opvanggebieden zouden omzetten in subnetwork controllers, zouden we een trace kunnen uitvoeren om alles te vinden dat verbonden is met ons netwerk. We kunnen dit simuleren door een connected trace uit te voeren waarbij elke uitlaat in ons netwerk als startlocatie wordt gebruikt.
Als we een enkel subnetwork zouden creëren genaamd "Stormwater System", met elk van deze apparaten als subnetwork controller, dan zouden de geselecteerde features in de bovenstaande afbeelding eruitzien als het subnetwork. Hoewel dit nuttig is vanuit een eerste kwaliteitscontroleperspectief, zou het veel nuttiger zijn als we elke verzameling uitlaten die een gebied beheersen modelleren als controllers voor een specifiek opvanggebied. De ingenieurs die afhankelijk zijn van GIS-data om plannings- en ingenieursmodellen te onderhouden volgen deze informatie al buiten GIS. Door opvanggebieden binnen GIS te modelleren, kunnen we valideren dat de wijzigingen die we aanbrengen niet alleen topologisch correct zijn, maar ook dat ze de informatie valideren die ingenieurs of planners nodig hebben om hun modellen te produceren.
Afhankelijk van de kwaliteit, complexiteit en hoeveelheid data die u onderhoudt, kunt u besluiten slechts één enkel subnetwork voor uw hele systeem te modelleren, of u kunt besluiten aparte subnetworks te creëren voor elk opvanggebied. We zullen de moeilijkere taak bespreken van het configureren van aparte subnetworks. Deze instructies gaan ervan uit dat wanneer u de Migrate to Utility Network tool hebt uitgevoerd en u één of meer lagen hebt geïdentificeerd als zijnde controllers, anders moet u extra configuratie uitvoeren om toe te staan dat een feature een subnetwork controller kan zijn.
Regels en Terminals
Standaard configureert de Migrate to Utility Network tool subnetwork controllers in een sink-based netwerk zodat ze alleen verbinding maken met features via hun Upstream terminal. Als u niets downstream van uw uitlaten modelleert, kunt u doorgaan naar de volgende sectie waar u ziet hoe u uw subnetwork controllers maakt.
Het eerste wat we moeten doen is de regels in ons netwerk bekijken via het dialoogvenster netwerk eigenschappen. Hieronder zien we een subset van de regels voor onze discharge points. Als we goed kijken zien we dat discharge points zo zijn geconfigureerd dat ze verbinding maken met elk type lijn in ons model via hun upstream terminal.
We kunnen deze regels verfijnen zodat ze nauwkeuriger weergeven hoe onze lozingen verbonden moeten zijn met andere features in het netwerk.
- Outfall – Deze features laten toe dat een pijp afwatert in een open afvoer
- Overflow – Deze features laten toe dat een pijp of virtuele afvoerleiding overstroomt in een open afvoer
- Standard Outlet – Deze features laten toe dat een pijp loost in een virtuele afvoerleiding
- Terminal Discharge – Deze features laten toe dat een pijp of open afvoer het systeem verlaat
We moeten de Add Rule en Delete Rule tools gebruiken om de regels zo te configureren dat ze aan deze vereisten voldoen. Zodra we de regels hebben geconfigureerd en onze netwerktopologie hebben ingeschakeld, zullen we waarschijnlijk connectiviteitsfouten (de rode lijnen in onderstaande afbeelding) zien in onze database voor veel van onze discharge points.
Afhankelijk van uw data en hoe u uw regels aanpast zult u twee verschillende soorten fouten zien: Ongeldige connectiviteit – Er is geen regel die toestaat dat de twee features verbinden.
Ambigue connectiviteit – Er is meer dan één regel die toestaat dat de features verbinden.
Hoewel we elke fout individueel kunnen beoordelen en bepalen hoe we ze één voor één oplossen, is het efficiënter om bij meer dan enkele fouten de Analyze Network Data tool te gebruiken om ons een overzicht te geven van alle soorten fouten.
Naast het creëren van een laagbestand dat kan worden gebruikt om onze fouten te beoordelen, genereert de tool ook een RuleCandidates.csv bestand. Dit bestand bevat alle regels die aan het netwerk kunnen worden toegevoegd om connectiviteitsfouten op te lossen. U wilt zorgvuldig de lijst met regels beoordelen voordat u importeert en alleen regels importeren voor features waarvan mag worden toegestaan dat ze verbonden zijn. Mogelijk moet u overleggen met een ingenieur of veldwerker om te bepalen wat gepast is. U kunt meer leren over dit proces in het artikel Refining connectivity rule.
Zodra u hebt bepaald welke regels u wilt toevoegen, gebruikt u de Import Rules tool om deze regels aan uw utility network toe te voegen. Vergeet niet dat voordat u regels kunt toevoegen, u eerst de netwerktopologie moet uitschakelen.
Nadat u de ontbrekende regels hebt toegevoegd en de netwerktopologie weer hebt ingeschakeld, moet u vervolgens de Modify Terminal Connections tool gebruiken om eventuele ambigue connectiviteit op te lossen. Dit is alleen nodig als u een lijn hebt die mag verbinden met meer dan één terminal op een apparaat.
Als u meer voorbeelden wilt van hoe u dit soort connectiviteitsfouten oplost, vindt u drie tutorials die u begeleiden bij dit besluitvormingsproces in de Bewerken en connectiviteit leerserie.
Zodra onze netwerktopologie is ingeschakeld en foutloos is, zijn we klaar om verder te gaan met het creëren van onze subnetworks.
Maak een eenvoudig subnetwork
Het eerste wat we moeten doen is de uitlaten identificeren die fungeren als subnetwork controllers voor elk opvanggebied in ons netwerk. Dit kan worden gedaan door een connectivity trace uit te voeren voor een gebied in ons netwerk en te stoppen zodra we bij een uitlaat komen, die geconfigureerd zijn als subnetwork controllers. Hoewel we deze features handmatig kunnen selecteren en barrières kunnen toevoegen, is het vaak gemakkelijker om een condition barrier te gebruiken om deze features automatisch te identificeren tijdens het tracen. Hiervoor voegen we aan onze trace een condition barrier toe voor features met een Category van Subnetwork Controller.
Dit zorgt ervoor dat de trace stopt bij elke feature waarvan het asset type categorie Subnetwork Controller heeft, in dit geval uitlaten. Deze netwerkcategorie wordt aanvankelijk gevuld door de Migrate to Utility Network tool voor alle mappings die u hebt aangewezen als controller. U kunt dit later ook aanpassen met behulp van de Set Network Category tool. Hieronder zien we de resultaten van zo'n trace.
In dit geval hebben we een gebied dat allemaal verbonden is met één enkele uitlaat. Gebruik de Modify Subnetwork Controller tool om de upstream terminal van de uitlaat, de zijde die materialen ontvangt, als subnetwork controller aan een nieuw opvanggebied toe te wijzen. De subnetwork controller heeft een unieke naam nodig en dit gebied heeft ook zijn eigen unieke naam nodig. Als wij onze opvanggebieden en uitlaten bespreken met engineering of operations, hebben zij mogelijk al specifieke identificaties die zij willen dat wij gebruiken. Het gebruik van dezelfde unieke identificaties als andere afdelingen zal ook samenwerking en communicatie vergemakkelijken.
Na validatie van de wijziging met het netwerk kunnen we nu een subnetwork trace uitvoeren om alle features verbonden aan deze uitlaat te zien.
We kunnen ook de update subnetwork tool gebruiken om de naam van het opvanggebied op deze features op te slaan. Dit maakt het gemakkelijk voor ons om te identificeren welke features tot welk opvanggebied behoren en welke niet.
Na het uitvoeren van deze tool zien we dat alle features in dit subnetwork hun subnetwerknaam ingevuld hebben.
En we zien dat er nu een subnetwork lijnfeature is die alle lijnen in dit opvanggebied vertegenwoordigt.
Zodra u de Update Subnetwork tool hebt gebruikt om een subnetwork lijn aan te maken, verschijnt dat subnetwork nu in het Find Subnetwork paneel wanneer die lijn binnen het huidige bereik ligt.
Nu we hebben gezien hoe je een eenvoudig subnetwork maakt met één enkele controller, laten we eens kijken hoe je omgaat met een opvanggebied met meerdere uitlaten.
Subnetworks met meerdere controllers
Niet elk subnetwork heeft één enkele controller. Stormwater netwerken hebben vaak meerdere uitlaten die verantwoordelijk zijn voor het lozen van water uit één opvanggebied, afhankelijk van hoeveel water er op dat moment in het systeem zit.
We beginnen hetzelfde proces; door een connectivity trace uit te voeren in ons netwerk waarbij subnetwork controllers als barrière worden behandeld; hierdoor stopt de trace bij uitlaten. Overweeg het maken en gebruiken van een traceconfiguratie voor deze trace om het proces gemakkelijker te maken.
In dit geval hebben we één opvanggebied met drie uitlaten. We herhalen hetzelfde proces als hierboven: elke uitlaat krijgt uniek naamgegeven, maar ze krijgen allemaal dezelfde subnetwerknaam omdat ze samen verantwoordelijk zijn voor het lozen van water uit hetzelfde gebied.
Opmerking: Als u geen naam opgeeft voor de subnetwork controller, zal de tool automatisch gebruikmaken van het global id van de feature.
Valideer opnieuw de netwerktopologie en voer update subnetwork uit om het maken van het tweede opvanggebied te voltooien.
Herhaal dit proces totdat alle functies in het netwerk tot een subnetwork behoren. Dit klinkt eenvoudig, maar laten we eens kijken naar enkele van de meest voorkomende problemen die kunnen optreden.
Ontbrekende Controllers
Het gebruik van dit proces biedt een betrouwbare, maar handmatige methode om al uw subnetwerken te identificeren. Het meest voorkomende probleem dat u zult tegenkomen is dat de subnetwork controllers mogelijk ontbreken in uw gegevens, of dat gegevensproblemen ervoor kunnen zorgen dat een opvanggebied veel groter lijkt dan het zou moeten zijn. In het onderstaande voorbeeld zien we dat wat een klein opvanggebied had moeten zijn, verschijnt als een veel groter gebied.
Als we inzoomen op de regio die in de afbeelding hierboven wordt aangegeven, zien we dat het probleem is dat er geen uitlaat is tussen de leidingen van het opvanggebied en het open kanaal waar het in afwatert. Dit wordt aangegeven in de onderstaande grafiek.
Om deze fout te corrigeren zouden we samenwerken met een ingenieur of veldploeg om ervoor te zorgen dat de GIS overeenkomt met wat momenteel in het veld is geïnstalleerd. In dit geval zouden we een uitlaat creëren tussen de leiding en het rivierkanaal. We zouden deze nieuwe uitlaat vervolgens maken tot een subnetwork controller voor ons derde opvanggebied.
Als we goed kijken naar de bovenstaande screenshot, zien we dat er nog steeds een potentieel probleem is in dit gebied. Sommige leidingen ten noorden van dit opvanggebied hebben geen enkele vorm van uitlaat. Als we inzoomen, zien we dat dit gebied waarschijnlijk verbonden zou moeten zijn met het opvanggebied. We zouden moeten bevestigen met een ingenieur of veldploeg dat dit inderdaad het geval is, maar zodra we hebben vastgesteld hoe/als het verbonden is, kunnen we onze GIS-gegevens bijwerken om dit weer te geven.
Conclusie
In dit artikel hebt u geleerd hoe u subnetworks, regels en terminals kunt gebruiken om uw gegevenskwaliteit te verbeteren. U zag hoe dit u in staat stelde ontbrekende functies te identificeren, onjuist verbonden functies en hoe locaties in uw netwerk zonder enige uitlaten te identificeren. Als u geïnteresseerd bent in meer geavanceerde analysetaken zoals waterscheiding of rioleringsbeheer of het beheren van subbekkens en opvanggebieden, laat het ons weten! Als u vragen heeft over het utility network, stel ze dan zeker op de Esri Community site.
Als u meer wilt weten over het gebruik van het utility network voor het beheren van zwaartekracht-gebaseerde netwerken, zoals riool- en regenwatergegevens, verken dan de Learn ArcGIS Utility Network for Sewer and Stormwater leerserie. Deze leerserie bevat tutorials en artikelen die demonstreren hoe aan de behoeften van de riool- en regenwaterindustrie kan worden voldaan met behulp van het utility network.
