Neste artigo, examinaremos algumas das configurações mais avançadas que podem ser aplicadas a redes baseadas em gravity para responder a perguntas mais sofisticadas e melhorar a qualidade dos dados. Veremos como a utility network aborda esses desafios por meio do uso de subnetworks, terminals e regras.
Está tudo conectado?
Ser capaz de executar rastreamentos para identificar a direção do fluxo em nosso sistema é uma ferramenta analítica útil, mas uma pergunta comum que precisamos responder é se todos os nossos recursos estão devidamente conectados. A maneira mais simples, mas menos eficiente, de determinar isso é colocar um local de rastreamento no seu mapa e executar um rastreamento conectado. Esse rastreamento identificará todos os recursos que são atravessáveis até esse local. Isso funciona bem para redes pequenas onde tudo está conectado, mas se seu conjunto de dados for muito grande, esse rastreamento levará mais tempo e, se seus dados não estiverem todos conectados a um único sistema conectado, você precisará fornecer vários locais iniciais para cobrir toda a sua rede.
Abaixo você pode ver um exemplo de um conjunto de dados de stormwater. Como apenas as áreas de captação são modeladas, e não os rios e canais que as conectam, um único rastreamento de conectividade não pode ser usado para identificar recursos desconectados.
Uma das maneiras pelas quais a utility network pode ajudar a identificar recursos desconectados é configurando subnetworks. Uma subnetwork representa um subconjunto nomeado da nossa utility network com um conjunto de dispositivos responsáveis por controlar os recursos naquela área. No caso de uma rede de stormwater, isso é tipicamente as outfalls que controlam cada área de captação.
Se transformássemos todas as outfalls das nossas áreas de captação em controladores de subnetwork, poderíamos executar um rastreamento para encontrar tudo o que estava conectado à nossa rede. Podemos simular isso executando um rastreamento conectado usando cada outfall em nossa rede como local inicial.
Se criássemos uma única subnetwork chamada "Stormwater System", com cada um desses dispositivos como controlador da subnetwork, os recursos selecionados na imagem acima seriam como a subnetwork pareceria. Embora isso seja útil do ponto de vista inicial de garantia de qualidade, seria muito mais útil se modelássemos cada conjunto de outfalls que governam uma área como controladores para uma área específica de captação. Os engenheiros que dependem dos dados GIS para manter modelos de planejamento e engenharia já acompanham essas informações fora do GIS. Ao modelar áreas de captação dentro do GIS, podemos validar que as mudanças feitas não são apenas topologicamente corretas, mas também validam as informações necessárias pelos engenheiros ou planejadores para produzir seus modelos.
Dependendo da qualidade, complexidade e volume dos dados que você mantém, pode decidir modelar apenas uma única subnetwork para todo o seu sistema ou criar subnetworks separadas para cada área de captação. Discutiremos a tarefa mais difícil de configurar subnetworks separadas. Essas instruções presumirão que quando você executou a ferramenta Migrate to Utility Network e identificou uma ou mais camadas como tendo controladores nelas; caso contrário, será necessário realizar configurações adicionais para permitir que um recurso seja um controlador de subnetwork.
Regras e Terminais
Por padrão, a ferramenta Migrate to Utility Network configurará controladores de subnetwork em uma rede baseada em sink para conectar-se apenas a recursos usando seu terminal Upstream. Se você não modelar nada a jusante das suas outfalls, então pode passar para a próxima seção onde verá como criar seus controladores de subnetwork.
A primeira coisa que devemos fazer é revisar as regras em nossa rede usando o diálogo de propriedades da rede. Abaixo podemos ver um subconjunto das regras para nossos pontos de descarga. Se olharmos atentamente, podemos ver que os pontos de descarga foram configurados para conectar-se a todos os tipos de linha em nosso modelo usando seu terminal upstream.
Podemos refinar essas regras para que reflitam com mais precisão a forma como nossas descargas devem estar conectadas a outros recursos na rede.
- Outfall – Esses recursos permitem que um tubo drene em um dreno aberto
- Overflow – Esses recursos permitem que um tubo ou linha virtual de drenagem transborde para um dreno aberto
- Standard Outlet – Esses recursos permitem que um tubo descarregue em uma linha virtual de drenagem
- Terminal Discharge – Esses recursos permitem que um tubo ou dreno aberto saia do sistema
Precisamos executar as ferramentas Add Rule e Delete Rule para configurar as regras conforme esses requisitos. Depois de configurar as regras e habilitar nossa topologia da rede, provavelmente veremos erros de conectividade (as linhas vermelhas na imagem abaixo) em nosso banco de dados para muitos dos nossos pontos de descarga.
Dependendo dos seus dados e como você ajusta suas regras, verá dois tipos diferentes de erros: Conectividade inválida – Não há uma regra que permita que os dois recursos se conectem.
Conectividade ambígua – Há mais de uma regra que permite que os recursos se conectem.
Embora pudéssemos revisar cada erro individualmente e determinar como corrigi-los um por um, se houver mais do que alguns erros, é mais eficiente usar a ferramenta Analyze Network Data para nos dar um resumo de todos os tipos de erros.
Além de criar um arquivo layer que pode ser usado para revisar nossos erros, a ferramenta também gera um arquivo RuleCandidates.csv. Este arquivo contém quaisquer regras que poderiam ser adicionadas à rede para resolver erros de conectividade. Você vai querer revisar cuidadosamente a lista antes de importar e importar apenas regras para recursos que deveriam ser permitidos conectar-se. Pode ser necessário consultar um engenheiro ou trabalhador de campo para determinar o que é apropriado. Você pode aprender mais sobre esse processo no artigo Refining connectivity rule.
Depois de determinar quais regras deseja adicionar, use a ferramenta Import Rules para adicioná-las à sua utility network. Lembre-se que antes de adicionar regras você deve desabilitar a topologia da rede.
Depois de adicionar as regras faltantes e habilitar novamente a topologia da rede, será necessário usar a ferramenta Modify Terminal Connections para resolver qualquer conectividade ambígua. Isso só é necessário se você tiver uma linha permitida conectar-se a mais de um terminal em um dispositivo.
Se quiser mais exemplos trabalhando com esses tipos de erros de conectividade, você pode encontrar três tutoriais para ajudar a guiá-lo nesse processo decisório na série learning Editing and connectivity.
Depois que nossa topologia da rede estiver habilitada e sem erros, estamos prontos para avançar na criação das nossas subnetworks.
Criar uma subnetwork simples
A primeira coisa que precisamos fazer é identificar as outfalls que atuam como controladores da subnetwork para cada área de captação da nossa rede. Isso pode ser feito executando um rastreamento de conectividade em uma área da nossa rede e parando sempre que alcançarmos uma outfall, configurada como controlador da subnetwork. Embora pudéssemos selecionar manualmente e adicionar barreiras para esses recursos, muitas vezes é mais fácil usar uma barreira condicional para identificar automaticamente esses recursos durante o rastreamento. Para isso adicionamos uma barreira condicional ao nosso rastreamento para recursos com Categoria Subnetwork Controller.
Isso fará com que o rastreamento pare em qualquer recurso cujo tipo asset tenha categoria Subnetwork Controller, neste caso outfalls. Essa categoria da network é inicialmente populada pela ferramenta Migrate to Utility Network para quaisquer mapeamentos designados como controller. Você também pode ajustar isso depois usando a ferramenta Set Network Category. Podemos ver os resultados desse rastreamento abaixo.
Neste caso, temos uma área toda conectada a uma única outfall. Use a ferramenta Modify Subnetwork Controller para definir o terminal upstream da outfall, o lado que recebe materiais, como controlador da subnetwork para uma nova área de captação. O controlador da subnetwork precisa ter um nome único e essa área também precisa ter seu próprio nome único. Se discutirmos nossas áreas de captação e outfalls com engenharia ou operações, eles podem já ter identificadores específicos que querem que usemos. Usar os mesmos identificadores únicos dos outros departamentos também facilitará colaboração e comunicação.
Após validar a mudança com a network, agora podemos executar um rastreamento da subnetwork para ver todos os recursos conectados a essa outfall.
Também podemos usar a ferramenta update subnetwork para armazenar o nome da área de captação nesses recursos. Isso facilita identificar quais recursos pertencem a uma área de captação e quais não pertencem.
Após executar essa ferramenta, podemos ver que todos os recursos nessa subnetwork têm seu nome preenchido na subnetwork.
E podemos ver agora há uma feature linha da subnetwork representando todas as linhas nessa área de captação.
Depois que você usar a ferramenta Update Subnetwork para criar uma linha da subnetwork, essa subnetwork aparecerá no painel Find Subnetwork quando essa linha estiver na extensão atual.
Agora que vimos como criar uma subnetwork simples com um único controlador, vamos ver como lidar com uma área com múltiplas outfalls.
Subnetworks com múltiplos controladores
Nem toda subnetwork tem um único controlador. Redes stormwater frequentemente têm múltiplas outfalls responsáveis por descarregar água de uma área de captação dependendo da quantidade água no sistema em dado momento.
Começamos o processo da mesma forma; realizando um rastreamento de conectividade na nossa network tratando controladores da subnetwork como barreira; isso fará o rastreamento parar nas outfalls. Considere criar e usar uma configuração do trace para esse rastreamento ajudar no processo.
Neste caso temos uma área com três outfalls. Repetimos o mesmo processo acima nomeando unicamente cada outfall mas damos o mesmo nome da subnetwork às três outfalls porque todas compartilham responsabilidade por descarregar água da mesma área.
Nota: Se você não fornecer um nome ao controlador da subnetwork, a ferramenta usará automaticamente o global id do recurso.
Mais uma vez, valide a topologia da rede e execute atualizar sub-rede para finalizar a criação da segunda bacia.
Repita este processo até que todos os recursos na rede pertençam a uma sub-rede. Isso parece fácil, mas vamos analisar alguns dos problemas mais comuns que podem surgir.
Controladores Ausentes
Usar este processo fornece um método confiável, porém manual, para identificar todas as suas sub-redes. O problema mais comum que você encontrará é que os controladores de sub-rede podem estar ausentes dos seus dados, ou problemas nos dados podem fazer com que uma área de bacia apareça muito maior do que deveria. Observando o exemplo abaixo, podemos ver que o que deveria ser uma pequena área de bacia está aparecendo como uma área muito maior.
Se ampliarmos a região destacada na imagem acima, podemos ver que o problema é que não há um ponto de saída entre os tubos da bacia e o canal aberto para o qual ela drena. Isso é destacado no gráfico abaixo.
Para corrigir esse erro, trabalharíamos com um engenheiro ou equipe de campo para garantir que o GIS corresponda ao que está atualmente instalado no campo. Neste caso, criaríamos um ponto de saída entre o tubo e o canal do rio. Em seguida, faríamos deste novo ponto de saída um controlador de sub-rede para nossa terceira área de bacia.
Se olharmos atentamente para a captura de tela acima, podemos ver que ainda há um problema potencial nesta área. Alguns dos tubos ao norte desta bacia não têm nenhuma forma de saída. Se ampliarmos, podemos ver que esta área provavelmente deveria estar conectada à área da bacia. Precisaríamos confirmar com um engenheiro ou equipe de campo se este é realmente o caso, mas uma vez determinado como/se está conectado, podemos então atualizar nossos dados GIS para refletir isso.
Conclusão
Neste artigo você aprendeu como usar subnetworks, regras e terminais para melhorar a qualidade dos seus dados. Você viu como isso permitiu identificar recursos ausentes, recursos conectados incorretamente e como identificar locais em sua rede sem quaisquer saídas. Se você estiver interessado em tarefas de análise mais avançadas como gestão de watershed ou sewershed ou gerenciamento de sub-bacias e bacias, avise-nos! Se você tiver alguma dúvida sobre a utility network, não deixe de perguntar no Esri Community site.
Se você quiser saber mais sobre como usar a utility network para gerenciar redes baseadas em gravidade, como dados de esgoto e águas pluviais, por favor explore a Learn ArcGIS Utility Network for Sewer and Stormwater série de aprendizado. Esta série inclui tutoriais e artigos que demonstram como atender às necessidades da indústria de esgoto e águas pluviais usando a utility network.
