In diesem Artikel werden wir einige der fortgeschritteneren Konfigurationen untersuchen, die auf gravity-based networks angewendet werden können, um anspruchsvollere Fragen zu beantworten und die Datenqualität zu verbessern. Wir werden betrachten, wie das utility network diese Herausforderungen durch die Verwendung von subnetworks, terminals und rules angeht.
Ist alles verbunden?
Die Möglichkeit, Traces auszuführen, um die Flussrichtung in unserem System zu identifizieren, ist ein nützliches Analysewerkzeug, aber eine häufige Frage, die wir beantworten müssen, ist, ob alle unsere Features richtig verbunden sind. Die einfachste, aber am wenigsten effiziente Methode, dies zu bestimmen, besteht darin, einen Trace-Standort in Ihrer Karte zu platzieren und einen connected trace auszuführen. Dieser Trace identifiziert alle Features, die zu diesem Standort durchquerbar sind. Dies funktioniert gut für kleine Netzwerke, in denen alles verbunden ist, aber wenn Ihr Datensatz sehr groß ist, dauert dieser Trace länger und wenn Ihre Daten nicht alle mit einem einzigen verbundenen System verbunden sind, müssen Sie mehrere Startorte angeben, um Ihr gesamtes Netzwerk abzudecken.
Unten sehen Sie ein Beispiel für einen stormwater dataset. Da nur die Einzugsgebiete modelliert sind und nicht die Flüsse und Kanäle, die sie verbinden, kann ein einzelner connectivity trace nicht verwendet werden, um getrennte Features zu identifizieren.
Eine der Möglichkeiten, wie das utility network helfen kann, getrennte Features zu identifizieren, besteht darin, subnetworks zu konfigurieren. Ein subnetwork stellt eine benannte Teilmenge unseres utility network dar mit einer Reihe von Geräten, die für die Steuerung der Ressourcen in diesem Bereich verantwortlich sind. Im Fall eines stormwater network sind dies typischerweise die outfalls, die jedes Einzugsgebiet steuern.
Wenn wir alle outfalls für unsere Einzugsgebiete zu subnetwork controllers machen würden, könnten wir einen Trace ausführen, um alles zu finden, was mit unserem Netzwerk verbunden ist. Wir können dies simulieren, indem wir einen connected trace ausführen und jeden outfall in unserem Netzwerk als Startort verwenden.
Wenn wir ein einzelnes subnetwork namens „Stormwater System“ erstellen würden, mit jedem dieser Geräte als subnetwork controller, würden die ausgewählten Features in der obigen Grafik so aussehen wie das subnetwork. Während dies aus einer anfänglichen Qualitätssicherungs-Perspektive nützlich ist, wäre es viel nützlicher, wenn wir jede Sammlung von outfalls modellieren würden, die ein Gebiet regeln als Controller für ein bestimmtes Einzugsgebiet. Die Ingenieure, die auf GIS-Daten angewiesen sind, um Planungs- und Ingenieurmodelle zu pflegen, verfolgen diese Informationen bereits außerhalb von GIS. Durch das Modellieren von Einzugsgebieten innerhalb von GIS können wir validieren, dass die Änderungen nicht nur topologisch korrekt sind, sondern auch die Informationen validieren, die Ingenieure oder Planer benötigen, um ihre Modelle zu erstellen.
Abhängig von der Qualität, Komplexität und dem Volumen der Daten, die Sie pflegen, entscheiden Sie sich möglicherweise dafür, nur ein einzelnes subnetwork für Ihr gesamtes System zu modellieren oder separate subnetworks für jedes Einzugsgebiet zu erstellen. Wir werden die schwierigere Aufgabe der Konfiguration separater subnetworks besprechen. Diese Anweisungen gehen davon aus, dass Sie beim Ausführen des Migrate to Utility Network tools eine oder mehrere Layer als Controller identifiziert haben; falls nicht, müssen Sie zusätzliche Konfigurationen vornehmen, damit ein Feature ein subnetwork controller sein kann.
Rules und Terminals
Standardmäßig konfiguriert das Migrate to Utility Network tool subnetwork controllers in einem sink-basierten Netzwerk so, dass sie nur über ihr Upstream terminal mit Features verbunden werden. Wenn Sie nichts stromabwärts Ihrer outfalls modellieren, können Sie zum nächsten Abschnitt übergehen und sehen, wie Sie Ihre subnetwork controllers erstellen.
Das Erste, was wir tun sollten, ist die Regeln in unserem Netzwerk mit dem Dialogfeld für Netzwerkeigenschaften zu überprüfen. Unten sehen wir einen Teil der Regeln für unsere discharge points. Wenn wir genau hinschauen sehen wir, dass discharge points so konfiguriert wurden, dass sie sich mit jedem Typ von Leitung in unserem Modell über ihr upstream terminal verbinden.
Wir können diese Regeln verfeinern, damit sie genauer widerspiegeln, wie unsere discharges mit anderen Features im Netzwerk verbunden sein sollten.
- Outfall – Diese Features erlauben es einem Rohr in einen offenen Abfluss zu entwässern
- Overflow – Diese Features erlauben es einem Rohr oder virtuellen Abflussrohr in einen offenen Abfluss überzulaufen
- Standard Outlet – Diese Features erlauben es einem Rohr in eine virtuelle Abflussleitung zu entladen
- Terminal Discharge – Diese Features erlauben es einem Rohr oder offenen Abfluss das System zu verlassen
Wir müssen die Werkzeuge Add Rule und Delete Rule ausführen um die Regeln so zu konfigurieren dass sie diesen Anforderungen entsprechen. Sobald wir die Regeln konfiguriert und unsere Netzwerktopologie aktiviert haben sehen wir wahrscheinlich Konnektivitätsfehler (die roten Linien in der Grafik unten) in unserer Datenbank für viele unserer discharge points.
Abhängig von Ihren Daten und wie Sie Ihre Regeln anpassen sehen Sie zwei verschiedene Arten von Fehlern: Ungültige Konnektivität – Es gibt keine Regel die erlaubt dass sich zwei Features verbinden.
Mehrdeutige Konnektivität – Es gibt mehr als eine Regel die erlaubt dass sich die Features verbinden.
Während wir jeden Fehler einzeln überprüfen und einzeln beheben könnten ist es bei mehr als wenigen Fehlern effizienter das Analyze Network Data tool zu verwenden um uns eine Zusammenfassung aller Fehlertypen zu geben.
Zusätzlich zur Erstellung einer Layer-Datei zur Überprüfung unserer Fehler gibt das Tool auch eine RuleCandidates.csv Datei aus. Diese Datei enthält alle Regeln die dem Netzwerk hinzugefügt werden könnten um Konnektivitätsfehler zu beheben. Sie sollten die Liste der Regeln sorgfältig überprüfen bevor Sie importieren und nur Regeln importieren für Features deren Verbindung erlaubt sein sollte. Möglicherweise müssen Sie einen Ingenieur oder Feldarbeiter konsultieren um festzustellen was angemessen ist. Mehr über diesen Prozess erfahren Sie im Artikel Refining connectivity rule.
Sobald Sie bestimmt haben welche Regeln Sie hinzufügen möchten verwenden Sie das Import Rules tool um diese Regeln Ihrem utility network hinzuzufügen. Denken Sie daran dass Sie vor dem Hinzufügen von Regeln die Netzwerktopologie deaktivieren müssen.
Nachdem Sie die fehlenden Regeln hinzugefügt und die Netzwerktopologie wieder aktiviert haben müssen Sie das Modify Terminal Connections tool verwenden um mehrdeutige Konnektivität aufzulösen. Dies ist nur erforderlich wenn eine Leitung erlaubt ist sich mit mehr als einem Terminal an einem Gerät zu verbinden.
Wenn Sie weitere Beispiele zur Bearbeitung solcher Konnektivitätsfehler wünschen finden Sie drei Tutorials zur Unterstützung bei diesem Entscheidungsprozess in der Editing and connectivity Lernserie.
Sobald unsere Netzwerktopologie aktiviert und fehlerfrei ist sind wir bereit mit der Erstellung unserer subnetworks fortzufahren.
Erstellen eines einfachen subnetworks
Das Erste was wir tun müssen ist die outfalls zu identifizieren welche als subnetwork controllers für jedes Einzugsgebiet unseres Netzwerks fungieren. Dies kann durch Ausführen eines connectivity trace für einen Bereich unseres Netzwerks erfolgen und Stoppen sobald wir einen outfall erreichen welcher als subnetwork controller konfiguriert wurde. Während wir diese Features manuell auswählen und Barrieren hinzufügen könnten ist es oft einfacher eine condition barrier zu verwenden um diese Features beim Tracing automatisch zu identifizieren. Dazu fügen wir unserem Trace eine condition barrier für Features mit einer Category von Subnetwork Controller hinzu.
Dies bewirkt dass der Trace bei jedem Feature stoppt dessen asset type eine Kategorie Subnetwork Controller hat in diesem Fall outfalls. Diese network category wird initial vom Migrate to Utility Network tool für alle Zuordnungen befüllt welche als controller gekennzeichnet wurden. Später können Sie dies auch mit dem Set Network Category tool anpassen. Unten sehen wir das Ergebnis eines solchen Traces.
In diesem Fall haben wir ein Gebiet das alle mit einem einzigen outfall verbunden ist. Verwenden Sie das Modify Subnetwork Controller tool um das upstream terminal des outfalls festzulegen - die Seite welche Materialien empfängt - als subnetwork controller für ein neues Einzugsgebiet. Der subnetwork controller benötigt einen eindeutigen Namen ebenso wie dieses Gebiet seinen eigenen eindeutigen Namen benötigt. Wenn wir unsere Einzugsgebiete und outfalls mit Ingenieuren oder Betrieb besprechen haben diese möglicherweise bereits spezifische Bezeichner welche sie möchten dass wir verwenden. Die Verwendung derselben eindeutigen Bezeichner wie andere Abteilungen erleichtert auch Zusammenarbeit und Kommunikation.
Nach Validierung der Änderung mit dem Netzwerk können wir nun einen subnetwork trace ausführen um alle Features zu sehen welche mit diesem outfall verbunden sind.
Wir können auch das update subnetwork tool verwenden um den Namen des Einzugsgebiets auf diesen Features zu speichern. Dies macht es einfach für uns zu erkennen welche Features zu einem Einzugsgebiet gehören und welche nicht.
Nach Ausführung dieses Tools sehen wir dass alle Features in diesem subnetwork ihren subnetwork Namen befüllt haben.
Und wir sehen dass es jetzt ein subnetwork line feature gibt welches alle Leitungen in diesem Einzugsgebiet repräsentiert.
Sobald Sie das Update Subnetwork tool verwendet haben um eine subnetwork line zu erstellen erscheint dieses subnetwork nun im Find Subnetwork Bereich wenn diese Linie im aktuellen Ausschnitt sichtbar ist.
Nachdem wir gesehen haben wie man ein einfaches subnetwork mit einem einzelnen Controller erstellt schauen wir uns an wie man ein Einzugsgebiet mit mehreren outfalls handhabt.
Subnetworks mit mehreren Controllern
Nicht jedes subnetwork hat einen einzelnen Controller. Stormwater networks haben oft mehrere outfalls welche verantwortlich sind Wasser aus einem Einzugsgebiet abzuführen abhängig davon wie viel Wasser sich zum jeweiligen Zeitpunkt im System befindet.
Wir beginnen den Prozess auf dieselbe Weise; indem wir einen connectivity trace in unserem Netzwerk durchführen und subnetwork controllers als Barriere behandeln wodurch der Trace bei outfalls stoppt. Erwägen Sie eine trace configuration für diesen Trace zu erstellen und verwenden um den Prozess zu erleichtern.
In diesem Fall haben wir ein Einzugsgebiet mit drei outfalls. Wir wiederholen denselben Prozess wie oben wobei jeder outfall eindeutig benannt wird aber allen derselbe subnetwork Name gegeben wird. Dies liegt daran dass sie alle gemeinsam verantwortlich sind Wasser aus demselben Gebiet abzuführen.
Hinweis: Wenn Sie keinen Namen für den subnetwork controller angeben verwendet das Tool automatisch die global id des Features.
Validieren Sie erneut die Netzwerktopologie und führen Sie "update subnetwork" aus, um die Erstellung des zweiten Einzugsgebiets abzuschließen.
Wiederholen Sie diesen Vorgang, bis alle Features im Netzwerk zu einem Subnetz gehören. Das klingt einfach, aber schauen wir uns einige der häufigsten Probleme an, die auftreten können.
Fehlende Controller
Die Verwendung dieses Prozesses bietet eine zuverlässige, aber manuelle Methode zur Identifizierung aller Ihrer Subnetze. Das häufigste Problem, auf das Sie stoßen werden, ist, dass die Subnetz-Controller in Ihren Daten fehlen können oder Datenprobleme dazu führen können, dass ein Einzugsgebiet viel größer erscheint als es sein sollte. Im folgenden Beispiel sehen wir, dass ein eigentlich kleines Einzugsgebiet als viel größeres Gebiet dargestellt wird.
Wenn wir in die Region hineinzoomen, die im obigen Bild hervorgehoben ist, sehen wir, dass das Problem darin besteht, dass es keinen Auslass zwischen den Rohren des Einzugsgebiets und dem offenen Kanal gibt, in den es entwässert. Dies wird in der Grafik unten dargestellt.
Um diesen Fehler zu korrigieren, würden wir mit einem Ingenieur oder einem Außenteam zusammenarbeiten, um sicherzustellen, dass das GIS mit dem übereinstimmt, was derzeit vor Ort installiert ist. In diesem Fall würden wir einen Auslass zwischen dem Rohr und dem Flusskanal erstellen. Wir würden dann diesen neuen Auslass zum Subnetz-Controller für unser drittes Einzugsgebiet machen.
Wenn wir uns den obigen Screenshot genau ansehen, erkennen wir, dass in diesem Bereich noch ein potenzielles Problem besteht. Einige der Rohre nördlich dieses Einzugsgebiets haben keinen Auslass. Wenn wir hineinzoomen, sehen wir, dass dieser Bereich wahrscheinlich mit dem Einzugsgebiet verbunden sein sollte. Wir müssten mit einem Ingenieur oder Außenteam bestätigen, ob dies tatsächlich der Fall ist. Sobald wir festgestellt haben, wie bzw. ob eine Verbindung besteht, können wir unsere GIS-Daten entsprechend aktualisieren.
Fazit
In diesem Artikel haben Sie gelernt, wie man Subnetze, Regeln und Terminals verwendet, um die Datenqualität zu verbessern. Sie haben gesehen, wie dies Ihnen ermöglicht hat, fehlende Features, falsch verbundene Features und Standorte im Netzwerk ohne Auslässe zu identifizieren. Wenn Sie an fortgeschritteneren Analyseaufgaben wie Wassereinzugsgebiets- oder Kanalisationsmanagement oder der Verwaltung von Teilbecken und Einzugsgebieten interessiert sind, lassen Sie es uns wissen! Wenn Sie Fragen zum utility network haben, stellen Sie diese unbedingt auf der Esri Community site.
Wenn Sie mehr darüber erfahren möchten, wie man das utility network zur Verwaltung von gravitationsbasierten Netzwerken wie Kanal- und Regenwasserdaten verwendet, erkunden Sie bitte die Learn ArcGIS Utility Network for Sewer and Stormwater Lernreihe. Diese Lernreihe enthält Tutorials und Artikel, die zeigen, wie man die Anforderungen der Kanal- und Regenwasserbranche mit dem utility network adressiert.
