En este artículo, examinaremos algunas de las configuraciones más avanzadas que se pueden aplicar a las redes basadas en gravity para responder preguntas más sofisticadas y mejorar la calidad de los datos. Veremos cómo la red de servicios públicos aborda estos desafíos mediante el uso de subredes, terminales y reglas.
¿Está todo conectado?
Poder ejecutar trazas para identificar la dirección del flujo en nuestro sistema es una herramienta analítica útil, pero una pregunta común que necesitamos responder es si todas nuestras características están correctamente conectadas. La forma más simple, pero menos eficiente, de determinar esto es colocar una ubicación de traza en su mapa y ejecutar una traza conectada. Esta traza identificará todas las características que son transitables hasta esa ubicación. Esto funciona bien para redes pequeñas donde todo está conectado, pero si su conjunto de datos es muy grande esta traza tomará más tiempo y si sus datos no están todos conectados a un solo sistema conectado necesita proporcionar múltiples ubicaciones iniciales para cubrir toda su red.
A continuación puede ver un ejemplo de un conjunto de datos de aguas pluviales. Debido a que solo se modelan las áreas de captación, y no los ríos y canales que las conectan, no se puede usar una sola traza de conectividad para identificar características desconectadas.
Una de las formas en que la red de servicios públicos puede ayudar a identificar características desconectadas es configurando subredes. Una subred representa un subconjunto nombrado de nuestra red de servicios públicos con un conjunto de dispositivos que son responsables de controlar los recursos en esa área. En el caso de una red de aguas pluviales, esto suele ser las salidas que controlan cada área de captación.
Si convirtiéramos todas las salidas de nuestras áreas de captación en controladores de subred, podríamos ejecutar una traza para encontrar todo lo que estaba conectado a nuestra red. Podemos simular esto ejecutando una traza conectada usando cada salida en nuestra red como ubicación inicial.
Si creáramos una única subred llamada "Sistema de Aguas Pluviales", con cada uno de estos dispositivos como controlador de subred, las características seleccionadas en el gráfico anterior serían cómo se vería la subred. Aunque esto es útil desde una perspectiva inicial de aseguramiento de calidad, sería mucho más útil si modeláramos cada conjunto de salidas que gobiernan un área como controladores para un área específica de captación. Los ingenieros que dependen de datos GIS para mantener modelos de planificación e ingeniería ya rastrean esta información fuera del GIS. Al modelar áreas de captación dentro del GIS, podemos validar que los cambios que hacemos no solo son topológicamente correctos, sino que también validan la información requerida por ingenieros o planificadores para producir sus modelos.
Dependiendo de la calidad, complejidad y volumen de datos que mantenga, puede decidir modelar solo una subred para todo su sistema, o puede decidir crear subredes separadas para cada área de captación. Discutiremos la tarea más difícil de configurar subredes separadas. Estas instrucciones asumirán que cuando ejecutó la herramienta Migrate to Utility Network e identificó una o más capas como que tienen controladores en ellas; si no es así, necesitará realizar configuración adicional para permitir que una característica sea un controlador de subred.
Reglas y Terminales
Por defecto, la herramienta Migrate to Utility Network configurará los controladores de subred en una red basada en sumideros para conectarse solo a características usando su terminal Upstream. Si no modela nada aguas abajo de sus salidas, entonces puede pasar a la siguiente sección donde verá cómo crear sus controladores de subred.
Lo primero que debemos hacer es revisar las reglas en nuestra red usando el diálogo de propiedades de la red. A continuación podemos ver un subconjunto de las reglas para nuestros puntos de descarga. Si miramos detenidamente podemos ver que los puntos de descarga han sido configurados para conectarse a todos los tipos de líneas en nuestro modelo usando su terminal upstream.
Podemos refinar estas reglas para que reflejen con mayor precisión la forma en que nuestras descargas deben estar conectadas a otras características en la red.
- Salida – Estas características permiten que una tubería drene hacia un drenaje abierto
- Desbordamiento – Estas características permiten que una tubería o línea virtual de drenaje se desborde hacia un drenaje abierto
- Salida Estándar – Estas características permiten que una tubería descargue hacia una línea virtual de drenaje
- Descarga Terminal – Estas características permiten que una tubería o drenaje abierto salga del sistema
Necesitamos ejecutar las herramientas Add Rule y Delete Rule para configurar las reglas según estos requisitos. Una vez configuradas las reglas y habilitada la topología de nuestra red, probablemente veremos errores de conectividad (las líneas rojas en el gráfico a continuación) en nuestra base de datos para muchos puntos de descarga.
Dependiendo de sus datos y cómo ajuste sus reglas verá dos tipos diferentes de errores: Conectividad inválida – No hay una regla que permita conectar las dos características.
Conectividad ambigua – Hay más de una regla que permite conectar las características.
Aunque podríamos revisar cada error individualmente y determinar cómo solucionarlos uno por uno, si hay más que unos pocos errores es más eficiente usar la herramienta Analyze Network Data para obtener un resumen de todos los tipos de errores.
Además de crear un archivo layer file que puede usarse para revisar nuestros errores, la herramienta también genera un archivo RuleCandidates.csv. Este archivo contiene cualquier regla que podría añadirse a la red para resolver errores de conectividad. Querrá revisar cuidadosamente la lista antes importar e importar solo reglas para características que deberían permitirse conectar. Puede necesitar consultar con un ingeniero o trabajador en campo para determinar qué es apropiado. Puede aprender más sobre este proceso en el artículo Refining connectivity rule.
Una vez haya determinado qué reglas desea añadir, use la herramienta Import Rules para agregar las reglas a su red utility network. Recuerde que antes debe deshabilitar la topología del network antes poder añadir reglas.
Una vez haya añadido las reglas faltantes y habilitado nuevamente la topología del network, deberá usar la herramienta Modify Terminal Connections para resolver cualquier conectividad ambigua. Esto solo es necesario si tiene una línea permitida conectar a más de un terminal en un dispositivo.
Si desea más ejemplos sobre cómo resolver este tipo tipos errores conexión puede encontrar tres tutoriales para guiarlo durante este proceso decisorio en la serie educativa Editing and connectivity.
Una vez habilitada y sin errores nuestra topología del network estamos listos para avanzar creando nuestras subredes.
Crear una subred simple
Lo primero que necesitamos hacer es identificar las salidas que actúan como controladores subnetwork controllers para cada área catchment area of our network. Esto puede hacerse ejecutando una traza connectivity trace por un área catchment area of our network y deteniéndonos cuando lleguemos a una salida outfall , configurada como controlador subnetwork controller . Aunque podríamos seleccionar manualmente y añadir barreras barriers para estas características features , suele ser más fácil usar una condición barrier condition barrier para identificarlas automáticamente al trazar tracing . Para ello añadimos una condición barrier condition barrier a nuestra traza trace para características features con categoría Category Subnetwork Controller .
Esto hará que la traza trace se detenga stop por cualquier característica feature cuyo tipo asset type tenga categoría Category Subnetwork Controller , en este caso salidas outfalls . Esta categoría network category se llena inicialmente con la herramienta Migrate to Utility Network tool por cualquier asignación mapping designada como controlador controller . También puede ajustarse posteriormente usando Set Network Category tool . Podemos ver los resultados results of such a trace below .
En este caso tenemos un área catchment area all connected to a single outfall connected to a single outfall . Use Modify Subnetwork Controller tool to set the upstream terminal of the outfall , the side that receives materials , as a new catchment area subnetwork controller . El controlador subnetwork controller necesita un nombre único unique name , y esta área también necesita su propio nombre único unique name . Si discutimos nuestras áreas catchment areas y salidas outfalls con ingeniería engineering u operaciones operations , pueden ya tener identificadores específicos specific identifiers que quieren usar . Usar los mismos identificadores únicos unique identifiers facilita también colaboración collaboration y comunicación communication .
Después validar validating el cambio change con la red network , ahora podemos ejecutar run una traza subnetwork trace para ver todas las características features conectadas connected to this outfall .
También podemos usar update subnetwork tool para almacenar store el nombre name del área catchment area on these features . Esto facilita easy identification identificar qué características belong to an area catchment area , y cuáles no belong to any catchment area .
Después ejecutar running esta herramienta tool , podemos ver all the features in this subnetwork have their subnetwork name populated .
Y podemos ver that there is now a subnetwork line feature that represents all the lines in this catchment area .
Una vez usado Update Subnetwork tool to create a subnetwork line , esa subred aparecerá ahora aparecerá appear in the Find Subnetwork pane cuando esa línea esté dentro del extent actual current extent .
Ahora hemos visto cómo crear create a simple subnetwork with a single controller , veamos cómo manejar handle un área catchment con múltiples salidas multiple outfalls .
Subredes con múltiples controladores multiple controllers
No todas las subredes tienen un único controlador single controller . Las redes stormwater networks suelen tener múltiples salidas multiple outfalls responsables responsible for discharging water from an area catchment area , dependiendo how much water is in the system at any given time .
Comenzamos el proceso igual; realizando connectivity trace treating subnetwork controllers as barriers , lo cual hará stop the trace at outfalls . Considere crear create and use a trace configuration for this trace to facilitar make the process easier .
En este caso tenemos un área catchment area con tres salidas three outfalls . Repetimos repeat el mismo proceso anterior naming each outfall uniquely , pero damos give each of these outfalls el mismo nombre same subnetwork name . Esto porque comparten all share responsibility discharging water from the same area .
Nota: Si no proporciona provide un nombre name for the subnetwork controller , la herramienta tool usará automáticamente will automatically use el global id del feature.
Una vez más, valide la topología de la red y ejecute actualizar subred para terminar de crear la segunda cuenca.
Repita este proceso hasta que todas las características en la red pertenezcan a una subred. Esto parece fácil, pero veamos algunos de los problemas más comunes que pueden surgir.
Controladores faltantes
Usar este proceso proporciona un método confiable, pero manual, para identificar todas sus subredes. El problema más común que encontrará es que los controladores de subred pueden faltar en sus datos, o problemas de datos pueden hacer que un área de cuenca aparezca mucho más grande de lo que debería. Observando el ejemplo a continuación podemos ver que lo que debería haber sido un área de cuenca pequeña aparece como un área mucho más grande.
Si hacemos zoom en la región señalada en la imagen anterior, podemos ver que el problema es que no hay una salida entre las tuberías de la cuenca y el canal abierto al que drena. Esto se señala en el gráfico a continuación.
Para corregir este error trabajaríamos con un ingeniero o equipo de campo para asegurar que el GIS coincida con lo que está actualmente instalado en el campo. En este caso crearíamos una salida entre la tubería y el canal del río. Luego haríamos de esta nueva salida un controlador de subred para nuestra tercera área de cuenca.
Si observamos detenidamente la captura de pantalla anterior, podemos ver que todavía hay un problema potencial en esta área. Algunas de las tuberías al norte de esta cuenca no tienen ninguna forma de salida. Si hacemos zoom podemos ver que probablemente esta área debería estar conectada al área de cuenca. Necesitaríamos confirmar con un ingeniero o equipo de campo que este es realmente el caso, pero una vez que hayamos determinado cómo/si está conectada, entonces podemos actualizar nuestros datos GIS para reflejar esto.
Conclusión
En este artículo aprendió cómo usar subnetworks, reglas y terminales para mejorar la calidad de sus datos. Vio cómo esto le permitió identificar características faltantes, características mal conectadas y cómo identificar ubicaciones en su red sin ninguna salida. Si está interesado en tareas de análisis más avanzadas como gestión de cuencas hidrográficas o alcantarillado o gestión de subcuencas y áreas de captación, ¡háganoslo saber! Si tiene alguna pregunta sobre la utility network, asegúrese de hacerla en el sitio Esri Community.
Si desea saber más sobre cómo usar la utility network para gestionar redes basadas en gravedad, como datos de alcantarillado y aguas pluviales, por favor explore la serie de aprendizaje Learn ArcGIS Utility Network for Sewer and Stormwater Esta serie de aprendizaje incluye tutoriales y artículos que demuestran cómo abordar las necesidades de la industria del alcantarillado y aguas pluviales usando la utility network.
