Utilisation des données NENA pour créer des localisateurs de géocodage - Aucun ETL requis !

bharold

<\/HEAD>

La National Emergency Number Association<\/A> promulgue des normes SIG pour les jeux de données qui soutiennent les opérations de sécurité publique aux États-Unis.  Un exemple principal est le Civic Location Data Exchange Format<\/A> (CLDXF).  En creusant davantage, nous pouvons trouver un modèle de données bien défini pour les points d'adresse.<\/A> Le problème que nous abordons dans ce blog est comment utiliser directement les données maintenues dans ce schéma pour créer des localisateurs de géocodage ArcGIS sans que personne n'ait à construire des processus ETL complexes et à copier les données de manière répétitive.<\/P>

<\/P>

Le flux de travail nécessite que vos données NENA soient maintenues dans une Geodatabase d'entreprise, et il y a une clause de non-responsabilité - la granularité complète<\/EM><\/STRONG> des éléments de sous-adresse dans le schéma NENA n'est pas prise en charge.  Au moment de la rédaction (version Pro 2.4.1), seule une<\/STRONG> paire de valeurs de type et d'identifiant de sous-adresse est prise en charge, mais l'exemple montre comment trois<\/STRONG> paires de valeurs de type et d'identifiant peuvent être gérées, car à la sortie de Pro 2.5, les localisateurs prendront en charge autant de champs de sous-adresse.  Mes données test (les comtés de Kings, Queens, Nassau et Suffolk à New York, grâce à

NYS GIS Clearing House<\/A>) contiennent des unités<\/STRONG> (appartements etc.), des niveaux<\/STRONG> (étages, sous-sols etc.) et des unités de bâtiment<\/STRONG> (pièces, annexes etc.).  Le nom du bâtiment est également utilisable, et le siège dans la pièce ainsi que les données supplémentaires sur l'emplacement sont conservés et peuvent être fournis par un localisateur mais ne sont pas utilisés pour la recherche.<\/P><\/P>Avant d'aller plus loin, pourquoi Esri ne conçoit-il pas simplement l'outil Create Locator<\/STRONG> pour accepter tous les champs NENA ?  La réponse courte est que nous devons avoir des paramètres applicables internationalement afin qu'il ne surcharge pas l'outil.<\/P><\/P>J'ai dit « pas besoin d'ETL ».  Eh bien, j'espère que c'est vrai pour vous, et pour mes données test ce le serait si j'avais accès à la base de données, mais ce que je vois souvent sur le terrain ce sont des chaînes vides et des valeurs blanches dans les champs caractères, donc j'aime appliquer des valeurs nulles appropriées et corriger les valeurs de date invalides avec un peu de traitement avec l'extension Data Interoperability.  Dans les captures d'écran ci-dessous (cliquez sur les images pour agrandir<\/STRONG>) je m'assure que les données vides sont nulles lors de l'importation de mes données test dans mon EGDB.<\/P><\/P><\/P><\/P><\/P><\/P><\/P>La seule autre chose que j'ai faite avec mon ETL a été de renommer les champs en minuscules (ce que PostgreSQL préfère, ma plateforme EGDB) et d'élargir quelques champs (pretype, posttype) au cas où mes concaténations dépasseraient ces champs.  Assurez-vous aussi que les domaines ne vous posent pas problème, vous ajouterez de nouvelles valeurs aux champs pretype et posttype.  Cela dit, je vois dans la vue des données de ma couche que les champs caractères ont une largeur arbitraire de 255 caractères, donc je ne suis pas sûr si les définitions des champs d'entrée sont respectées, ou si les vues ont un concept quelconque des domaines, cela pourrait dépendre de la plateforme.  Quoi qu'il en soit, cela m'amène à ce qui devrait être votre point de départ.  J'ai des points d'adresse au schéma NENA dans mon EGDB et je veux créer un localisateur.<\/P><\/P>L'ingrédient secret ici est la création d'une vue dans mon SGBD qui effectue toutes les manipulations nécessaires pour renommer, caster, sous-chaîner et concaténer les données dans un schéma directement utilisable dans ArcGIS Pro comme couche d'entités en entrée à l'outil géotraitement Create Locator<\/STRONG>, utilisant le rôle Point Address.<\/P><\/P>Je descends rarement aussi profondément dans SQL donc pour développer ma vue je l'ai construite dans pgAdmin (vous aurez besoin de l'outil d'édition SQL fourni avec votre SGBD), champ par champ en inspectant le résultat dans Pro au fur et à mesure.  Astuce : vous pouvez recréer votre vue dans pgAdmin et la laisser dans le contenu table de Pro puis simplement réinitialiser la source de la couche chaque fois que vous voulez la voir - elle se rafraîchira dans la carte.<\/P><\/P><\/P><\/P>Le téléchargement du blog contient la source SQL pgAdmin - esri_view.sql<\/STRONG> - et vous pouvez inspecter les commentaires pour comprendre la logique.  Fondamentalement, les champs spécifiques à NENA qui ne peuvent pas être mappés aux entrées du rôle Point Address ont leurs valeurs transférées vers d'autres champs.  Les champs combinant type & identifiant sont analysés en champs séparés pour chacun.  Le SQL devra être adapté à votre environnement, mais c'est assez standard.<\/P><\/P>Si vous êtes un expert SQL et pouvez aller directement à une instruction SELECT<\/STRONG>, alors vous pourriez utiliser l'outil Create Database View<\/STRONG> et saisir la définition de la vue.  La source éditée (sans commentaires) est le fichier test_view.sql<\/STRONG> dans le téléchargement.  Pas très esthétique côté interface utilisateur mais ça fonctionne:<\/P><\/P><\/P><\/P>Ayant créé la vue, ajoutez-la à votre carte et spécifiez le champ ObjectID comme identifiant unique:<\/P><\/P>

Laissez-le indexer et vous avez votre vue (dynamique) des données NENA dans votre carte comme couche d'entités:

style="display: block; margin-left: auto; margin-right: auto;" \/><\/P>

<\/P>

Ignorez la puce d'avertissement dans la capture de dialogue, elle apparaît juste après la création du locator pour indiquer que vous écraserez la sortie si vous relancez l'outil.<\/P>

<\/P>

La sagesse de récolter des noms alternatifs de villes à partir d'autant de champs que je l'ai fait peut être débattue, mais j'espère que vous comprenez l'idée, les différents champs NENA pour les valeurs de zone peuvent être vus comme appropriés pour être utilisés comme rôles de noms alternatifs.  En production, il serait plus efficace de créer une table de noms alternatifs de villes à partir des données centerline et de la joindre via street_id.<\/P>

<\/P>

Voici la vue utilisée comme table de noms alternatifs de villes :<\/P>

<\/P>

<\/P>

<\/P>

L'adresse avec address_id = 'KIN0000001' est '463 Maspeth Ave, New York, NY, 11211'  Utiliser l'alias de ville 'Brooklyn' fonctionne avec un score = 100 :<\/P>

<\/P>

<\/P>

<\/P>

De plus, j'ai répondu hors ligne à une question concernant le maintien de toutes les parties des adresses définies dans la norme FGDC telles que les parties préfixes et suffixes du numéro d'adresse, les éléments séparateurs du nom de rue, les pré-modificateurs et post-modificateurs.  Si vous souhaitez afficher ces éléments lors du géocodage, définissez-les comme champs de sortie personnalisés pour vos locators.  Cette fonctionnalité est disponible dans l'outil en tant que dernier paramètre, mais vous devrez également fournir des champs source dans la carte des champs pour chaque sortie.<\/P>

Je sors seat et additional_location dans mon locator, ce qui me permettrait de travailler sur les candidats si c'est ce dont j'avais besoin.<\/P>

<\/P>

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

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.