<\/HEAD>
Die National Emergency Number Association<\/A> erlässt GIS-Standards für Datensätze, die öffentliche Sicherheitsoperationen in den USA unterstützen. Ein Hauptbeispiel ist das Civic Location Data Exchange Format<\/A> (CLDXF). Wenn man tiefer gräbt, findet man ein gut definiertes Datenmodell für Adresspunkte.<\/A> Das Problem, das wir in diesem Blog angehen, ist, wie man Daten, die in diesem Schema gepflegt werden, direkt verwenden kann, um ArcGIS-Geokodierungs-Lokatoren zu erstellen, ohne dass jemand komplexe ETL-Prozesse konstruieren und Daten wiederholt kopieren muss.<\/P><\/P>
Der Workflow erfordert, dass Ihre NENA-Daten in einer Enterprise Geodatabase gepflegt werden, und es gibt einen Haftungsausschluss - die volle<\/EM><\/STRONG> Granularität der Subaddress-Elemente im NENA-Schema wird nicht unterstützt. Zum Zeitpunkt des Schreibens (Pro 2.4.1 Version) wird nur ein<\/STRONG> Paar von Subaddress-Typ- & Identifikatorwerten unterstützt, aber das Beispiel zeigt, wie drei<\/STRONG> Paare von Typ- & Identifikatorwerten gehandhabt werden können, da mit der Pro 2.5 Version Lokatoren so viele Subaddress-Felder unterstützen werden. Meine Testdaten (die Countys Kings, Queens, Nassau und Suffolk in New York, dank
NYS GIS Clearing House<\/A>) enthalten Units<\/STRONG> (Wohnungen usw.), Levels<\/STRONG> (Stockwerke, Keller usw.) und Building Units<\/STRONG> (Räume, Anbauten usw.). Der Gebäudename ist ebenfalls verwendbar, und Sitz im Raum sowie zusätzliche Standortdaten werden beibehalten und können von einem Lokator ausgegeben werden, aber nicht für die Suche verwendet werden.<\/P><\/P>Bevor wir weitergehen: Warum gestaltet Esri nicht einfach das Create Locator<\/STRONG>-Werkzeug so, dass alle NENA-Felder akzeptiert werden? Die kurze Antwort ist, dass wir international anwendbare Parameter haben müssen, sodass das Werkzeug überladen wäre.<\/P><\/P>Ich sagte „kein ETL erforderlich“. Nun, hoffentlich trifft das für Sie zu, und für meine Testdaten wäre es so, wenn ich Zugriff auf die Datenbank hätte. Aber was ich oft in der Praxis sehe, sind Dinge wie leere Strings und leere Werte in Zeichenfeldern. Deshalb setze ich gerne korrekte Nullwerte durch und korrigiere ungültige Datumswerte mit etwas Verarbeitung durch die Data Interoperability-Erweiterung. In den untenstehenden Bildschirmfotos (Klicken Sie auf die Bilder zum Vergrößern<\/STRONG>) stelle ich sicher, dass leere Daten beim Import meiner Testdaten in meine EGDB als Null gesetzt werden.<\/P><\/P>
<\/P><\/P>
<\/P><\/P>Das Einzige andere, was ich mit meinem ETL gemacht habe, war Felder in Kleinbuchstaben umzubenennen (was PostgreSQL bevorzugt, meine EGDB-Plattform) und ein paar Felder breiter zu machen (pretype, posttype), falls meine Verkettungen diese Felder überlaufen. Achten Sie auch darauf, dass Domains Ihnen keine Probleme bereiten – Sie werden neue Werte zu pretype- und posttype-Feldern hinzufügen. Allerdings sehe ich in der Datenansicht meiner Ebene, dass die Zeichenfelder willkürliche Breiten von 255 Zeichen haben. Daher bin ich mir nicht sicher, ob die Eingabefelddefinitionen eingehalten werden oder ob Ansichten ein Konzept von Domains haben – das könnte plattformabhängig sein. Wie dem auch sei, das bringt mich zu Ihrem Ausgangspunkt. Ich habe NENA-Schema-Adressenpunkte in meiner EGDB und möchte einen Lokator erstellen.<\/P><\/P>Das Geheimnis hier ist die Erstellung einer Ansicht in meinem DBMS, die alle notwendigen Manipulationen durchführt – Umbenennen, Casten, Substring und Verkettung von Daten – in ein Schema, das direkt in ArcGIS Pro als Feature-Layer-Eingabe für das Create Locator<\/STRONG>-Geoverarbeitungswerkzeug verwendet werden kann und dabei die Point Address-Datenrolle nutzt.<\/P><\/P>Ich tauche selten so tief in SQL ein. Um meine Ansicht zu entwickeln, habe ich sie in pgAdmin aufgebaut (Sie benötigen das SQL-Autorentool Ihres DBMS), Feld für Feld vorgegangen und das Ergebnis jeweils in Pro überprüft. Tipp: Sie können Ihre Ansicht in pgAdmin neu erstellen und sie im Inhaltsverzeichnis von Pro belassen und einfach die Layerquelle zurücksetzen jedes Mal wenn Sie sie ansehen wollen – sie wird dann auf der Karte aktualisiert.<\/P><\/P>
<\/P><\/P>Der Blog-Download enthält den pgAdmin-SQL-Quellcode - esri_view.sql<\/STRONG> - und Sie können die Kommentare lesen um die Logik zu verstehen. Grundsätzlich werden Felder spezifisch für NENA, die nicht auf Point Address-Rollen-Eingaben abgebildet werden können, ihre Werte an andere Felder weitergegeben. Felder mit kombinierten Typ- & Identifikatorwerten werden in separate Felder für jeden geparst. Das SQL muss an Ihre Umgebung angepasst werden, aber es ist ziemlich Standardkram.<\/P><\/P>Wenn Sie ein SQL-Zauberer sind und direkt zu einer SELECT<\/STRONG>-Anweisung gehen können, könnten Sie das Create Database View<\/STRONG>-Werkzeug verwenden und die Ansichtdefinition eingeben. Die bearbeitete Quelle (ohne Kommentare) ist die Datei test_view.sql<\/STRONG> im Download. Kein Preis für Benutzeroberflächendesign aber es funktioniert:<\/P><\/P>
<\/P><\/P>Nachdem Sie die Ansicht erstellt haben, fügen Sie sie Ihrer Karte hinzu und geben das ObjectID-Feld als eindeutigen Bezeichner an:<\/P><\/P>
Lassen Sie es indexieren und Sie haben Ihre (dynamische) Ansicht der NENA-Daten als Feature-Layer in Ihrer Karte:
Sie sehen warum ich die Typfelder verbreitern musste – schauen Sie sich '1375 Sunrise Hwy Westbound Service Road, Islip, NY, 11706' an
Egal wie – führen Sie Create Locator < \/strong>(schwer eine aufregende Grafik zu machen aber hoffentlich nützlich):
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;PointAddress.CITY 'nena.sde.esri_view'.city;PointAddress.METRO_AREA 'nena.sde.esri_view'.metro_area;PointAddress.SUBREGION 'nena.sde.esri_view'.county;PointAddress.REGION 'nena.sde.esri_view'.state;PointAddress.POSTAL 'nena.sde.esri_view'.zipcode;PointAddress.COUNTRY 'nena.sde.esri_view'.country", r "C:\Work\Product_Management\Address_Management\Nena", "ENG", None,None,None)
Anschließend geokodieren!
Units funktionieren:
285 Asharoken Ave, #1, Huntington, NY, 11768
Spezielle Hausnummern funktionieren:
5 1 \/ 2 Locust Ave , Brookhaven , NY , 11790
Gebäudenamen funktionieren:
Building 22A , John F Kennedy Airport , New York , NY , 11430
Also haben Sie es – pflegen Sie Ihre Daten NENA-konform und verwenden Sie sie zum Geokodieren.
Aber warten Sie, es gibt mehr!
<br>
The blog download has been updated to add the SQL source esri_views.sql, which creates an alternate city name table used as below in Create Locator - see the Alternate Name Tables section:
style="display: block; margin-left: auto; margin-right: auto;" \/><\/P>
<\/P>
Ignorieren Sie den Warnhinweis im Dialogfenster, der erscheint, nachdem der Locator erstellt wurde, um anzuzeigen, dass die Ausgabe überschrieben wird, wenn Sie das Tool erneut ausführen.<\/P>
<\/P>
Die Weisheit, alternative Stadtnamen aus so vielen Feldern zu ernten, wie ich es getan habe, kann diskutiert werden, aber hoffentlich verstehen Sie die Idee: Die verschiedenen NENA-Felder für Zonenwerte können geeignet als alternative Namensrollen verwendet werden. In der Produktion wäre es effizienter, eine Tabelle mit alternativen Stadtnamen aus Centerline-Daten zu erstellen und diese über street_id zu verknüpfen.<\/P>
<\/P>
Hier ist die Ansicht, die als Tabelle für alternative Stadtnamen verwendet wird:<\/P>
<\/P>
<\/P>
<\/P>
Die Adresse mit address_id = 'KIN0000001' ist '463 Maspeth Ave, New York, NY, 11211' Die Verwendung des Stadtalias 'Brooklyn' funktioniert mit einem Score von 100:<\/P>
<\/P>
<\/P>
<\/P>
Außerdem habe ich eine Frage offline aufgenommen bezüglich der Beibehaltung aller Teile von Adressen, die im FGDC-Standard definiert sind, wie Präfix- und Suffix-Adressnummernteile, Trennzeichen für Straßennamen, Prä- und Postmodifikatoren. Wenn Sie diese Elemente beim Geokodieren ausgeben möchten, definieren Sie sie als benutzerdefinierte Ausgabefelder für Ihre Locator. Diese Funktionalität ist im Tool als letzter Parameter verfügbar, aber Sie müssen auch Quellfelder in der Feldzuordnung für jede Ausgabe angeben.<\/P>
Ich gebe seat und additional_location in meinem Locator aus, was mir erlauben würde, bei Bedarf an Kandidaten zu arbeiten.<\/P>
<\/P>
<\/P><\/BODY><\/HTML>
