<\/HEAD>
De National Emergency Number Association<\/A> stelt GIS-standaarden vast voor datasets die openbare veiligheidsoperaties in de VS ondersteunen. Een belangrijk voorbeeld is het Civic Location Data Exchange Format<\/A> (CLDXF). Verder graven we dieper en vinden we een goed gedefinieerd datamodel voor adrespunten.<\/A> Het probleem dat we in deze blog aanpakken, is hoe we direct data die in dit schema wordt onderhouden kunnen gebruiken om ArcGIS geocoding locators te maken zonder dat iemand complexe ETL-processen hoeft te bouwen en data herhaaldelijk hoeft te kopiëren.<\/P><\/P>
De workflow vereist dat uw NENA-data wordt onderhouden in een Enterprise Geodatabase, en er is een disclaimer - de volledige<\/EM><\/STRONG> granulariteit van subadres-elementen in het NENA-schema wordt niet ondersteund. Op het moment van schrijven (Pro 2.4.1 release) wordt slechts één<\/STRONG> paar van subadres type & identifier waarden ondersteund, maar het voorbeeld toont aan hoe drie<\/STRONG> paren van type & identifier waarden kunnen worden verwerkt, aangezien bij de Pro 2.5 release locators dit aantal subadresvelden zullen ondersteunen. Mijn testdata (de counties Kings, Queens, Nassau en Suffolk in New York, dankzij
NYS GIS Clearing House<\/A>) bevat units<\/STRONG> (appartementen enz.), levels<\/STRONG> (verdiepingen, kelders enz.) en building units<\/STRONG> (kamers, annexen enz.). Gebouwnaam is ook bruikbaar, en zitplaats in de kamer en aanvullende locatiegegevens worden behouden en kunnen door een locator worden uitgegeven maar niet gebruikt voor zoeken.<\/P><\/P>Voordat we verder gaan, waarom ontwerpt Esri niet gewoon de Create Locator<\/STRONG>-tool om alle NENA-velden te accepteren? Het korte antwoord is dat we internationaal toepasbare parameters moeten hebben zodat de tool niet overbelast raakt.<\/P><\/P>Ik zei 'geen ETL vereist'. Hopelijk is dat waar voor u, en voor mijn testdata zou dat zo zijn als ik toegang had tot de database, maar wat ik vaak zie in de praktijk zijn dingen zoals lege strings en blanco waarden in tekenvelden, dus ik vind het prettig om correcte null-waarden af te dwingen en ongeldige datumwaarden te corrigeren met een beetje verwerking met de Data Interoperability-extensie. In de onderstaande schermafbeeldingen (klik op afbeeldingen om te vergroten<\/STRONG>) zorg ik ervoor dat lege data null is terwijl ik mijn testdata importeer naar mijn EGDB.<\/P><\/P><\/P>
<\/P><\/P>
<\/P><\/P>Het enige andere dat ik met mijn ETL deed was velden hernoemen naar kleine letters (wat PostgreSQL prettig vindt, mijn EGDB-platform) en een paar velden breder maken (pretype, posttype) voor het geval mijn concatenaties die velden overschrijden. Zorg ervoor dat domeinen u ook niet tegenwerken, u zult nieuwe waarden toevoegen aan pretype- en posttype-velden. Dat gezegd hebbende zie ik in de dataview van mijn laag dat de tekenvelden willekeurige breedtes van 255 tekens hebben, dus ik weet niet zeker of de invoervelddefinities worden gerespecteerd, of dat views enig concept van domeinen hebben, dit kan platformafhankelijk zijn. Hoe dan ook, dat brengt me bij wat uw startpunt zou moeten zijn. Ik heb NENA-schema adrespunten in mijn EGDB en ik wil een locator maken.<\/P><\/P>Het geheime ingrediënt hier is het creëren van een view in mijn DBMS die alle noodzakelijke manipulaties uitvoert om data te hernoemen, casten, substringen en samenvoegen tot een schema dat direct bruikbaar is in ArcGIS Pro als feature layer input voor de Create Locator<\/STRONG>-geoprocessingtool, gebruikmakend van de Point Address datarol.<\/P><\/P>Ik duik zelden zo diep in SQL dus om mijn view te ontwikkelen bouwde ik deze op in pgAdmin (u heeft welke SQL-authoringtool dan ook nodig die bij uw DBMS hoort), veld voor veld en inspecteerde het resultaat in Pro terwijl ik bezig was. Tip: u kunt uw view opnieuw creëren in pgAdmin en deze in Pro's inhoudstabel laten staan en gewoon elke keer de laagbron resetten als u hem wilt bekijken - hij wordt ververst op de kaart.<\/P><\/P>
<\/P><\/P>De blogdownload bevat de pgAdmin SQL-bron - esri_view.sql<\/STRONG> - en u kunt de opmerkingen inspecteren om de logica te begrijpen. In principe worden velden specifiek voor NENA die niet kunnen worden gemapt naar Point Address rol inputs hun waarden doorgegeven aan andere velden. Velden die type & identifier waarden combineren worden geparseerd naar aparte velden voor elk. De SQL moet worden aangepast aan uw omgeving, maar het is vrij standaard spul.<\/P><\/P>Als u een SQL-tovenaar bent en direct naar een SELECT<\/STRONG>-statement kunt gaan dan kunt u de Create Database View<\/STRONG>-tool gebruiken en de viewdefinitie invoeren. De bewerkte bron (zonder opmerkingen) is het bestand test_view.sql<\/STRONG> in de download. Geen prijzen voor gebruikersinterfaceontwerp maar het werkt:<\/P><\/P>
<\/P><\/P>Nadat u de view hebt gemaakt, voegt u deze toe aan uw kaart en specificeert u het ObjectID-veld als unieke identifier:<\/P><\/P>
Laat het indexeren en u heeft uw (dynamische) view van NENA-data in uw kaart als feature layer:
U kunt zien waarom ik de typevelden moest verbreden, bekijk '1375 Sunrise Hwy Westbound Service Road, Islip, NY, 11706'
Hoe dan ook, voer Create Locator <\strong>(moeilijk om een spannende afbeelding te maken maar hopelijk nuttig):
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\"\");
Doe dan geocoding!
Units werken:
285 Asharoken Ave, #1, Huntington, NY, 11768
<\/P>
<\/P>
Negeer de waarschuwingschip in de dialoogopname, die verschijnt alleen na het aanmaken van de locator om aan te geven dat je de uitvoer overschrijft als je het gereedschap opnieuw uitvoert.<\/P>
<\/P>
De wijsheid van het verzamelen van alternatieve stadsnamen uit zoveel velden als ik deed kan worden betwist, maar hopelijk begrijp je het idee, de verschillende NENA-velden voor zonewaarden kunnen geschikt worden bekeken voor gebruik als alternatieve naamrollen. In productie zou het efficiënter zijn om een alternatieve stadsnaamtabel te maken van centerline-gegevens en deze te koppelen op street_id.<\/P>
<\/P>
Hier is de view die wordt gebruikt als de alternatieve stadsnaamtabel:<\/P>
<\/P>
<\/P>
<\/P>
Het adres met address_id = 'KIN0000001' is '463 Maspeth Ave, New York, NY, 11211' Het gebruik van de stadsalias 'Brooklyn' werkt met score = 100:<\/P>
<\/P>
<\/P>
<\/P>
Daarnaast heb ik offline een vraag beantwoord over het behouden van alle onderdelen van adressen gedefinieerd in de FGDC-standaard zoals prefix- en suffixdelen van het adresnummer, scheidingselementen van straatnamen, pre-modifiers en post-modifiers. Als je deze elementen wilt weergeven bij geocoderen, definieer ze dan als aangepaste uitvoervelden voor je locators. Deze functionaliteit is beschikbaar in het gereedschap als de laatste parameter, maar je moet ook bronvelden leveren in de veldmap voor elke uitvoer.<\/P>
Ik geef seat en additional_location uit in mijn locator, wat me zou laten werken aan kandidaten als dat nodig was.<\/P>
<\/P>
<\/P><\/BODY><\/HTML>
