<\/HEAD>
La National Emergency Number Association<\/A> promulga estándares GIS para conjuntos de datos que apoyan las operaciones de seguridad pública en los EE. UU. Un ejemplo principal es el Formato de Intercambio de Datos de Ubicación Cívica <\/A>(CLDXF). Profundizando más, podemos encontrar un modelo de datos bien definido para puntos de dirección.<\/A> El problema que abordamos en este blog es cómo usar directamente los datos mantenidos en este esquema para crear localizadores de geocodificación ArcGIS sin que nadie tenga que construir procesos ETL complejos y copiar datos repetidamente.<\/P><\/P>
El flujo de trabajo requiere que sus datos NENA se mantengan en una Geodatabase Empresarial, y hay un descargo de responsabilidad: la granularidad completa<\/EM><\/STRONG> de los elementos de subdirección en el esquema NENA no está soportada. Al momento de escribir (versión Pro 2.4.1) solo se soporta un<\/STRONG> par de valores de tipo e identificador de subdirección, pero el ejemplo demuestra cómo se pueden manejar tres<\/STRONG> pares de valores de tipo e identificador, ya que en la versión Pro 2.5 los localizadores soportarán esta cantidad de campos de subdirección. Mis datos de prueba (los condados de Kings, Queens, Nassau y Suffolk en Nueva York, gracias a
NYS GIS Clearing House<\/A>) tienen unidades<\/STRONG> (apartamentos, etc.), niveles<\/STRONG> (pisos, sótanos, etc.) y unidades del edificio<\/STRONG> (habitaciones, anexos, etc.). El nombre del edificio también es utilizable, y el asiento en la habitación y datos adicionales de ubicación se retienen y pueden ser emitidos por un localizador pero no usados para búsqueda.<\/P><\/P>Antes de continuar, ¿por qué Esri no diseña simplemente la herramienta Create Locator<\/STRONG> para aceptar todos los campos NENA? La respuesta corta es que debemos tener parámetros aplicables internacionalmente para no sobrecargar la herramienta.<\/P><\/P>Dije 'no se requiere ETL'. Bueno, espero que eso sea cierto para usted, y para mis datos de prueba lo sería si tuviera acceso a la base de datos, pero lo que a menudo veo en la práctica son cosas como cadenas vacías y valores en blanco en campos de caracteres, así que me gusta imponer valores nulos adecuados y corregir valores inválidos de fecha con un poco de procesamiento con la extensión Data Interoperability. En las capturas de pantalla a continuación (haga clic en las imágenes para ampliar<\/STRONG>) me aseguro que los datos vacíos sean nulos mientras importo mis datos de prueba a mi EGDB.<\/P><\/P><\/P>
<\/P><\/P>
<\/P><\/P>Lo único más que hice con mi ETL fue renombrar campos a minúsculas (lo que PostgreSQL prefiere, mi plataforma EGDB) y hacer un par de campos más anchos (pretype, posttype) por si mis concatenaciones exceden esos campos. Asegúrese también que los dominios no le causen problemas, tendrá que agregar nuevos valores a los campos pretype y posttype. Dicho esto, veo en la vista de datos de mi capa que los campos de caracteres tienen anchos arbitrarios de 255 caracteres, así que no estoy seguro si las definiciones del campo de entrada se respetan o si las vistas tienen algún concepto de dominios, esto podría depender de la plataforma. De todos modos, eso me lleva a cuál debería ser su punto de partida. Tengo puntos de dirección con esquema NENA en mi EGDB y quiero crear un localizador.<\/P><\/P>La clave aquí es crear una vista en mi DBMS que realice todas las manipulaciones necesarias para renombrar, convertir tipos, extraer subcadenas y concatenar datos en un esquema directamente utilizable en ArcGIS Pro como una capa feature para la herramienta Create Locator<\/STRONG>, usando el rol Point Address.<\/P><\/P>Pocas veces bajo a SQL a este nivel así que para desarrollar mi vista la construí en pgAdmin (necesitará cualquier herramienta para autoría SQL que venga con su DBMS), campo por campo e inspeccionando el resultado en Pro conforme avanzaba. Consejo: puede recrear su vista en pgAdmin y dejarla en la tabla de contenidos de Pro y simplemente restablecer la fuente capa cada vez que quiera verla - se actualizará en el mapa.<\/P><\/P>
<\/P><\/P>La descarga del blog tiene el código fuente SQL para pgAdmin - esri_view.sql<\/STRONG> - y puede inspeccionar los comentarios para entender la lógica. Básicamente los campos específicos a NENA que no pueden mapearse a entradas del rol Point Address tienen sus valores pasados a otros campos. Los campos combinando valores tipo e identificador se analizan en campos separados para cada uno. El SQL necesitará ser adaptado a su entorno, pero es bastante estándar.<\/P><\/P>Si usted es un mago SQL y puede ir directo a una sentencia SELECT<\/STRONG>, entonces podría usar la herramienta Create Database View<\/STRONG> e ingresar la definición vista. El código fuente editado (sin comentarios) está en el archivo test_view.sql<\/STRONG> en la descarga. No hay premios por diseño UI pero funciona:<\/P><\/P>
<\/P><\/P>Habiendo creado la vista, agréguela a su mapa y especifique el campo ObjectID como identificador único:<\/P><\/P>
Deje indexar y tendrá su vista (dinámica) de datos NENA en su mapa como una capa feature:
Puede ver por qué tuve que ampliar los campos tipo, vea '1375 Sunrise Hwy Westbound Service Road, Islip, NY, 11706'
De todos modos, ejecute Create Locator < \/strong>(difícil hacer un gráfico emocionante pero esperemos ú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\"\");\ style="display: block; margin-left: auto; margin-right: auto;" \/><\/P>
<\/P>
Ignore la advertencia chip en la captura del diálogo, eso solo aparece después de la creación del locator para indicar que sobrescribirás la salida si vuelves a ejecutar la herramienta.<\/P>
<\/P>
Se puede debatir la sabiduría de recolectar nombres alternativos de ciudades de tantos campos como lo hice, pero con suerte entiendes la idea, los varios campos NENA para valores de zona pueden verse adecuadamente para usarse como roles de nombre alternativo. En producción, sería más eficiente crear una tabla de nombres alternativos de ciudades a partir de datos centerline y unirla mediante street_id.<\/P>
<\/P>
Aquí está la vista usada como tabla de nombres alternativos de ciudades:<\/P>
<\/P>
<\/P>
<\/P>
La dirección con address_id = 'KIN0000001' es '463 Maspeth Ave, New York, NY, 11211' Usar el alias de ciudad 'Brooklyn' funciona con score = 100:<\/P>
<\/P>
<\/P>
<\/P>
Además, respondí una pregunta fuera de línea sobre mantener todas las partes de las direcciones definidas en el estándar FGDC tales como prefijo y sufijo de número de dirección, elementos separadores del nombre de calle, pre-modificadores y post-modificadores. Si quieres mostrar estos elementos al geocodificar entonces defínelos como campos personalizados de salida para tus locators. Esta funcionalidad está disponible en la herramienta como el último parámetro, pero también necesitarás proporcionar campos fuente en el mapa de campos para cada salida.<\/P>
Yo muestro seat y additional_location en mi locator, lo que me permitiría trabajar con candidatos si eso fuera lo que necesitara.<\/P>
<\/P>
<\/P><\/BODY><\/HTML>
