Použití dat NENA k vytvoření geokódovacích lokalizátorů - není potřeba ETL!

bharold

<\/HEAD>

National Emergency Number Association<\/A> vydává standardy GIS pro datové sady, které podporují operace veřejné bezpečnosti v USA.  Hlavním příkladem je Civic Location Data Exchange Format <\/A>(CLDXF).  Při dalším zkoumání najdeme dobře definovaný datový model pro adresní body.<\/A> Problém, kterému se v tomto blogu věnujeme, je, jak přímo použít data udržovaná v tomto schématu k vytvoření ArcGIS geokódovacích lokalizátorů, aniž by kdokoli musel vytvářet složité ETL procesy a opakovaně kopírovat data.<\/P>

<\/P>

Pracovní postup vyžaduje, aby vaše NENA data byla udržována v Enterprise Geodatabase, a je zde upozornění - plná<\/EM><\/STRONG> granularita subadresních prvků ve schématu NENA není podporována.  V době psaní (verze Pro 2.4.1) je podporován pouze jeden<\/STRONG> pár hodnot typu a identifikátoru subadresy, ale ukázka demonstruje, jak lze zpracovat tři<\/STRONG> páry hodnot typu a identifikátoru, protože od verze Pro 2.5 lokalizátory tuto kapacitu subadresních polí podpoří.  Moje testovací data (okresy Kings, Queens, Nassau a Suffolk v New Yorku, díky

NYS GIS Clearing House<\/A>) obsahují jednotky<\/STRONG> (byty atd.), úrovně<\/STRONG> (patra, sklepy atd.) a budovy jednotky<\/STRONG> (místnosti, přístavby atd.).  Název budovy je také použitelný a sedadlo v místnosti a další lokalizační data jsou uchovávána a mohou být lokalizátorem vypsána, ale nejsou použita pro vyhledávání.<\/P><\/P>Předtím než půjdeme dál, proč Esri jednoduše nenavrhne nástroj Create Locator<\/STRONG>, aby přijímal všechna pole NENA?  Krátká odpověď je, že musíme mít mezinárodně použitelné parametry, takže by to nástroj přetížilo.<\/P><\/P>Řekl jsem „žádný ETL není potřeba“.  Doufejme, že to platí i pro vás, a pro moje testovací data by to platilo, kdybych měl přístup k databázi, ale co často vidím v praxi jsou například prázdné řetězce a prázdné hodnoty v znakových polích, takže rád vynucuji správné null hodnoty a opravím neplatné datumové hodnoty pomocí trochu zpracování s rozšířením Data Interoperability.  Na snímcích obrazovky níže (klikněte na obrázky pro zvětšení<\/STRONG>) se ujistím, že prázdná data jsou null při importu mých testovacích dat do mé EGDB.<\/P><\/P><\/P><\/P><\/P><\/P>Jediné další co jsem udělal s mým ETL bylo přejmenování polí na malá písmena (což PostgreSQL preferuje, moje platforma EGDB) a rozšíření několika polí (pretype, posttype) pro případ přetečení mých konkatenací těchto polí.  Ujistěte se také, že vás domény nepřekvapí, budete přidávat nové hodnoty do polí pretype a posttype.  Nicméně vidím ve zobrazení dat mé vrstvy, že znaková pole mají libovolnou šířku 255 znaků, takže si nejsem jistý jestli jsou definice vstupních polí respektovány nebo zda pohledy mají nějaký koncept domén – to může záviset na platformě.  Každopádně to mě vede k tomu, co by měl být váš výchozí bod.  Mám adresní body ve schématu NENA v mé EGDB a chci vytvořit lokalizátor.<\/P><\/P>Tajemstvím je vytvoření pohledu v mém DBMS, který provede všechny nezbytné manipulace k přejmenování, převodu typů, výřezu podřetězců a spojení dat do schématu přímo použitelného v ArcGIS Pro jako vstup vrstvy prvků pro nástroj Create Locator<\/STRONG>, používající roli dat Point Address.<\/P><\/P>Zřídka se dostávám do SQL takto hluboko, takže jsem svůj pohled vyvíjel v pgAdmin (budete potřebovat jakýkoli SQL autorovací nástroj dodávaný s vaším DBMS), pole po poli a kontroloval výsledek v Pro průběžně.  Tip:  můžete svůj pohled znovu vytvořit v pgAdmin a nechat ho v obsahu tabulek Pro a pokaždé jen resetovat zdroj vrstvy – aktualizuje se v mapě.<\/P><\/P><\/P><\/P>Blog ke stažení obsahuje SQL zdroj pgAdmin - esri_view.sql<\/STRONG> - můžete si přečíst komentáře k pochopení logiky.  Základní myšlenkou je předání hodnot specifických pro NENA, které nelze namapovat na vstupy role Point Address do jiných polí.  Pole kombinující typ & identifikátor jsou rozděleny do samostatných polí pro každý z nich.  SQL bude třeba přenést do vašeho prostředí, ale jedná se o poměrně standardní věci.<\/P><\/P>Pokud jste SQL kouzelník a můžete rovnou napsat příkaz SELECT<\/STRONG>, můžete použít nástroj Create Database View<\/STRONG> a zadat definici pohledu.  Upravený zdroj (bez komentářů) je soubor test_view.sql<\/STRONG> ke stažení.  Uživatelské rozhraní není žádný skvost ale funguje:<\/P><\/P><\/P><\/P>Po vytvoření pohledu jej přidejte do své mapy a určete pole ObjectID jako jedinečný identifikátor:<\/P><\/P>

Nechte jej indexovat a máte svůj (dynamický) pohled na data NENA ve své mapě jako vrstvu prvků:

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

<\/P>

Ignorujte varovný čip v dialogovém záznamu, který se objeví po vytvoření lokalizátoru, aby naznačil, že přepíšete výstup, pokud nástroj spustíte znovu.<\/P>

<\/P>

Moudrost sběru alternativních názvů měst z tolika polí, kolik jsem použil, může být diskutabilní, ale doufejme, že pochopíte myšlenku, různé NENA pole pro hodnoty zón lze vhodně použít jako role alternativních názvů.  V produkci by bylo efektivnější vytvořit tabulku alternativních názvů měst z dat centerline a připojit se k ní přes street_id.<\/P>

<\/P>

Zde je pohled použitý jako tabulka alternativních názvů měst:<\/P>

<\/P>

<\/P>

<\/P>

Adresa s address_id = 'KIN0000001' je '463 Maspeth Ave, New York, NY, 11211'  Použití aliasu města 'Brooklyn' funguje se skóre = 100:<\/P>

<\/P>

<\/P>

<\/P>

Navíc jsem offline dostal otázku ohledně udržování všech částí adres definovaných ve standardu FGDC, jako jsou prefixy a suffixy čísel adres, oddělovače názvů ulic, předmodifikátory a postmodifikátory.  Pokud chcete tyto prvky zobrazit při geokódování, definujte je jako vlastní výstupní pole pro vaše lokalizátory.  Tato funkce je v nástroji dostupná jako poslední parametr, ale také budete muset dodat zdrojová pole ve field map pro každý výstup.<\/P>

Ve svém lokalizátoru jsem vyexportoval seat a additional_location, což by mi umožnilo pracovat s kandidáty, pokud bych to potřeboval.<\/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.