nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Usando Dados NENA Para Criar Localizadores de Geocodificação - Sem Necessidade de ETL!

bharold

<\/HEAD>

A National Emergency Number Association<\/A> promulga padrões GIS para conjuntos de dados que suportam operações de segurança pública nos EUA. Um exemplo principal é o Formato de Troca de Dados de Localização Cívica<\/A> (CLDXF). Aprofundando, podemos encontrar um modelo de dados bem definido para pontos de endereço.<\/A> O problema que estamos abordando neste blog é como usar diretamente os dados mantidos neste esquema para criar localizadores de geocodificação ArcGIS sem que ninguém precise construir processos ETL complexos e copiar dados repetidamente.<\/P>

<\/P>

O fluxo de trabalho requer que seus dados NENA sejam mantidos em um Enterprise Geodatabase, e há um aviso - a granularidade completa<\/EM><\/STRONG> dos elementos de subendereço no esquema NENA não é suportada. No momento da redação (versão Pro 2.4.1) apenas um<\/STRONG> par de valores de tipo e identificador de subendereço é suportado, mas o exemplo demonstra como três<\/STRONG> pares de valores de tipo e identificador podem ser tratados, pois na versão Pro 2.5 os localizadores suportarão essa quantidade de campos de subendereço. Meus dados de teste (os condados de Kings, Queens, Nassau e Suffolk em Nova York, graças ao

NYS GIS Clearing House<\/A>) possuem unidades<\/STRONG> (apartamentos etc.), níveis<\/STRONG> (andares, porões etc.) e unidades do prédio<\/STRONG> (salas, anexos etc.). O nome do prédio também é utilizável, e o assento na sala e dados adicionais de localização são retidos e podem ser exibidos por um localizador, mas não usados para busca.<\/P><\/P>Antes de prosseguirmos, por que a Esri não projeta a ferramenta Create Locator<\/STRONG> para aceitar todos os campos NENA? A resposta curta é que precisamos ter parâmetros aplicáveis internacionalmente para não sobrecarregar a ferramenta.<\/P><\/P>Eu disse 'sem ETL necessário'. Bem, espero que isso seja verdade para você, e para meus dados de teste seria se eu tivesse acesso ao banco de dados, mas o que frequentemente vejo no campo são coisas como strings vazias e valores em branco em campos de caracteres, então gosto de impor valores nulos adequados e corrigir valores inválidos de data com um pouco de processamento usando a extensão Data Interoperability. Nas capturas abaixo (clique nas imagens para ampliar<\/STRONG>) estou garantindo que dados vazios sejam nulos ao importar meus dados de teste para meu EGDB.<\/P><\/P><\/P><\/P><\/P><\/P><\/P>A única outra coisa que fiz com meu ETL foi renomear campos para letras minúsculas (o que o PostgreSQL prefere, minha plataforma EGDB) e aumentar a largura de alguns campos (pretype, posttype) caso minhas concatenações ultrapassem esses campos. Certifique-se também que os domínios não causem problemas, você estará adicionando novos valores aos campos pretype e posttype. Dito isso, vejo na visualização dos dados da minha camada que os campos de caracteres têm larguras arbitrárias de 255 caracteres, então não tenho certeza se as definições dos campos de entrada são respeitadas ou se as visualizações têm algum conceito de domínios, isso pode depender da plataforma. De qualquer forma, isso me leva ao seu ponto inicial. Tenho pontos de endereço no esquema NENA no meu EGDB e quero criar um localizador.<\/P><\/P>A receita secreta aqui é criar uma view no meu DBMS que realiza todas as manipulações necessárias para renomear, converter tipo, extrair substring e concatenar dados em um esquema diretamente utilizável no ArcGIS Pro como uma camada feature para entrada na ferramenta Create Locator<\/STRONG>, usando o papel Point Address.<\/P><\/P>Raramente mergulho tão fundo em SQL então para desenvolver minha view eu a construí no pgAdmin (você precisará da ferramenta SQL do seu DBMS), campo por campo inspecionando o resultado no Pro conforme avançava. Dica: você pode recriar sua view no pgAdmin e deixá-la na tabela de conteúdos do Pro e apenas redefinir a fonte da camada cada vez que quiser visualizá-la - ela será atualizada no mapa.<\/P><\/P><\/P><\/P>O download do blog contém o código fonte SQL do pgAdmin - esri_view.sql<\/STRONG> - e você pode inspecionar os comentários para entender a lógica. Basicamente os campos específicos do NENA que não podem ser mapeados para entradas do papel Point Address têm seus valores passados para outros campos. Campos combinando valores tipo & identificador são divididos em campos separados para cada um. O SQL precisará ser adaptado ao seu ambiente, mas é algo bastante padrão.<\/P><\/P>Se você for um mago do SQL e puder ir direto a uma instrução SELECT<\/STRONG>, poderia usar a ferramenta Create Database View<\/STRONG> e inserir a definição da view. O código fonte editado (sem comentários) está no arquivo test_view.sql<\/STRONG> no download. Sem prêmios por design da interface do usuário mas funciona:<\/P><\/P><\/P><\/P>Tendo criado a view, adicione-a ao seu mapa e especifique o campo ObjectID como identificador único:<\/P><\/P><\/P><\/P>

Deixe indexar e você terá sua visão (dinâmica) dos dados NENA no seu mapa como uma camada feature:

Pode ver porque tive que aumentar os campos tipo, veja '1375 Sunrise Hwy Westbound Service Road, Islip, NY, 11706'

Enfim, execute Create Locator
(difícil fazer um gráfico empolgante mas espero útil):

arcpy.geocoding.CreateLocator("USA", "nena.sde.esri_view PointAddress", @\"\"\"PointAddress.ADDRESS_JOIN_ID 'nena.sde.esri_view'.address_id\"\";\"\"PointAddress.HOUSE_NUMBER 'nena.sde.esri_view'.house_number\"\";\"\"PointAddress.BUILDING_NAME 'nena.sde.esri_view'.building_name\"\";\"\"PointAddress.STREET_NAME_JOIN_ID 'nena.sde.esri_view'.street_id\"\";\"\"PointAddress.STREET_PREFIX_DIR 'nena.sde.esri_view'.prefix_direction\"\";\"\"PointAddress.STREET_PREFIX_TYPE 'nena.sde.esri_view'.prefix_type\"\";\"\"PointAddress.STREET_NAME 'nena.sde.esri_view'.street_name\"\";\"\"PointAddress.STREET_SUFFIX_TYPE 'nena.sde.esri_view'.suffix_type\"\";\"\"PointAddress.STREET_SUFFIX_DIR 'nena.sde.esri_view'.suffix_direction\"\";\"\"PointAddress.SUB_ADDRESS_UNIT 'nena.sde.esri_view'.unit\"\";\"\"PointAddress.SUB_ADDRESS_UNIT_TYPE 'nena.sde.esri_view'.unit_type\"\";\"\"PointAddress.NEIGHBORHOOD 'nena.sde.esri_view'.neighborhood\"\"]; \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n "C:\Work\Product_Management\Address_Management", style="display: block; margin-left: auto; margin-right: auto;" \/><\/P>

<\/P>

Ignore o aviso de chip no diálogo de captura, ele aparece apenas após a criação do locator para indicar que você sobrescreverá a saída se executar a ferramenta novamente.<\/P>

<\/P>

A sabedoria de coletar nomes alternativos de cidades de tantos campos quanto eu fiz pode ser debatida, mas espero que você entenda a ideia, os vários campos NENA para valores de zona podem ser visualizados adequadamente para uso como funções de nome alternativo. Em produção, seria mais eficiente criar uma tabela de nomes alternativos de cidades a partir dos dados do centerline e fazer junção nela pelo street_id.<\/P>

<\/P>

Aqui está a view usada como tabela de nomes alternativos de cidades:<\/P>

<\/P>

O endereço com address_id = 'KIN0000001' é '463 Maspeth Ave, New York, NY, 11211' Usar o alias da cidade 'Brooklyn' funciona com score = 100:<\/P>

<\/P>

Além disso, respondi uma pergunta off-line sobre manter todas as partes dos endereços definidas no padrão FGDC, como prefixo e sufixo das partes do número do endereço, elementos separadores do nome da rua, pré-modificadores e pós-modificadores. Se você quiser gerar esses elementos ao geocodificar, defina-os como campos de saída personalizados para seus locators. Essa funcionalidade está disponível na ferramenta como o último parâmetro, mas você também precisará fornecer campos fonte no mapa de campos para cada saída.<\/P>

Eu exporto seat e additional_location no meu locator, o que me permitiria trabalhar nos candidatos se isso fosse necessário.<\/P>

<\/P>

<\/P><\/BODY><\/HTML>

Encontre mais publicações marcadas com

Comentários

bharold

Tom, I updated the download to include the SQL source for an additional view that can be used in an alternate city name role. I probably went overboard on pulling names from available fields but you'll get the idea. Also, it would probably be a better design to create a city name alias table from NENA street centerlines and join to it from the points via street_id and not like I did from address_id as it blows out the locator size unnecessarily.

TomNeer

Bruce, Thanks for the quick response. Yes, we are just starting to work with migrating clients to NG9-1-1 schema. We are looking at ways to best integrate the standard with other Esri schema such as LGIM and with the Locator. Based on your post, we are going back to refactor our schema again so both ETL and SQL views do not need to be utilized. Lots going on here. Lots of unknowns. Honestly, haven't mucked around under the hood of ArcGIS Locators since 9.x. I remember it not being much fun...

bharold

Hi Tom, thanks for the feedback!

Scoring is a matter of agreement between the input address and the reference data, in itself moving values around input fields will not affect scoring.

In our new geocoding engine, all input fields can have alternate value tables, so allowing alternate city or postcode values for addresses will work provided you create the relevant lookup table and build it into your locator. There isn't any need to build composite locators for this sort of logic any more, or to include multiple geometry types, new locators ingest everything at once.

Looking at the data, say for alternate city names from the incorporated/unincorporated municipalities, it would be simple to generate an alternate name table from the distinct pairs of names, but if you did then you would allow alternates for cities that for the given address are actually clear across the other side of the city. You could build an alternate city table keyed on individual address ID, it would be a bigger table but give better results.

For neighborhood, district, postcode and city values, a proximity-based 'alias' is also automatically applied from a dissolve of the input points or street segments.

I haven't tackled centerline data yet, I just wanted to show a pattern for how to consume NENA data. I expect a small industry to spring up around this and there will be plenty of collaborators on details.

TomNeer

Thank you for the writeup.

So effectively, concatenate the fields down into something Esri's Locator can consume? Will this concatenation affect the quality of the scoring of the geocoder (e.g. "Main Street North" vs "Main Street North Extension")?

How do we resolve the issue of Postal City vs Incorporated City vs Unincorporated Community best? One of the issues the NENA standard resolves is the Postal Address vs Situs Address confusion. In some cases, their Situs Address falls under a different Postal Code but they use another Post Office. Set up a composite locator duplicate locators for both the Situs Address (using Incorporate City or Unincorporated Community and State) and Postal Address (using Postal Community and Postal Code) for both the RoadCenterlines and Site/StructureAddressPoints?

What is the best scenario for road centerlines along international borders? Do we hard code this value?

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.