nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

NENAデータを使用してジオコーディングロケーターを作成する - ETLは不要！

bharold

<\/HEAD>

National Emergency Number Association<\/A>は、米国の公共安全業務を支援するデータセットのGIS標準を制定しています。主な例としては Civic Location Data Exchange Format<\/A>(CLDXF)があります。さらに掘り下げると、住所ポイントのための明確に定義されたデータモデル<\/A>が見つかります。このブログで取り組んでいる問題は、このスキーマで管理されているデータを直接使用して、誰も複雑なETLプロセスを構築したりデータを繰り返しコピーしたりすることなくArcGISジオコーディングロケーターを作成する方法です。<\/P>

<\/P>

このワークフローでは、NENAデータがEnterprise Geodatabaseに保持されている必要があり、免責事項があります。NENAスキーマのサブアドレス要素の完全な<\/EM><\/STRONG>粒度はサポートされていません。執筆時点（Pro 2.4.1リリース）では、サブアドレスタイプと識別子のペアは1つ<\/STRONG>のみサポートされていますが、サンプルではPro 2.5リリースでロケーターがこの数のサブアドレスフィールドをサポートするため、3つ<\/STRONG>のタイプと識別子のペアを処理する方法を示しています。私のテストデータ（ニューヨーク州キングス、クイーンズ、ナッソー、サフォーク郡、

NYS GIS Clearing House<\/A>のおかげ）には、units<\/STRONG>（アパートなど）、levels<\/STRONG>（階数、地下など）、およびbuilding units<\/STRONG>（部屋、付属建物など）があります。建物名も使用可能で、部屋内の座席や追加の位置情報も保持されており、ロケーターによって出力される場合がありますが検索には使用されません。<\/P><\/P>先に進む前に、なぜEsriは単にツールを設計してすべてのNENAフィールドを受け入れないのでしょうか？簡単な答えは、国際的に適用可能なパラメーターが必要であり、それがツールに過剰な負荷をかけるためです。<\/P><\/P>「ETL不要」と言いました。まあ、それがあなたにとって本当であることを願っていますし、私のテストデータの場合はデータベースにアクセスできればそうですが、実際には文字列フィールドに空文字や空白値があることが多いので、Data Interoperability拡張機能で適切なnull値を強制し、不正な日付値を修正する処理を行うのが好きです。以下のスクリーンショット（画像をクリックすると拡大します<\/STRONG>）では、テストデータをEGDBにインポートするときに空データがnullになるようにしています。<\/P><\/P><\/P><\/P><\/P><\/P>ETLで行った唯一の他のことはフィールド名を小文字に変更すること（PostgreSQLが好む形式で私のEGDBプラットフォーム用）と、一部フィールド（pretype, posttype）を幅広くしたことです。これは連結処理でこれらのフィールドが溢れる可能性があるためです。またドメインにも注意してください。pretypeとposttypeフィールドに新しい値を追加することになります。ただし、レイヤーのデータビューを見ると文字列フィールドは任意の幅255文字になっているので、入力フィールド定義が尊重されているかどうかやビューにドメインの概念があるかどうかはプラットフォーム依存かもしれません。ともあれ、それがあなたの出発点となるべきです。私はEGDBにNENAスキーマ住所ポイントを持ち、それでロケーターを作成したいと思っています。<\/P><\/P>ここでの秘訣は、DBMS内でビューを作成し、名前変更・型変換・部分文字列抽出・連結など必要なすべての操作を行い、その結果ArcGIS Proでジオプロセシングツールへのフィーチャレイヤ入力として直接使用可能なスキーマに変換することです。この場合Point Addressデータロールを使用します。<\/P><\/P>私はめったにここまでSQLを書きませんので、このビュー開発にはpgAdmin（DBMS付属のSQL作成ツール）でフィールドごとに構築しながらProで結果を確認しました。ヒント：pgAdminでビューを再作成し、それをProの目次に残しておけば、表示したいたびにレイヤーソースだけリセットすればマップ上で更新されます。<\/P><\/P><\/P><\/P>ブログダウンロードにはpgAdmin SQLソースファイル esri_view.sql<\/STRONG> が含まれており、そのコメントからロジックをご理解いただけます。基本的にはPoint Addressロール入力にマッピングできないNENA固有フィールドは他のフィールドへ値が渡されます。タイプと識別子値を組み合わせたフィールドはそれぞれ別々のフィールドへ解析されます。このSQLは環境に合わせて移植する必要がありますが、ごく標準的な内容です。<\/P><\/P>もしSQLマスターなら直接 SELECT<\/STRONG> 文を書いて Create Database View<\/STRONG> ツールへビュー定義として入力できます。編集済みソース（コメントなし）はダウンロード内ファイル test_view.sql<\/STRONG> にあります。ユーザーインターフェイスとしては賞賛できませんが動作します：<\/P><\/P><\/P><\/P>ビュー作成後、それをマップへ追加しObjectIDフィールドを一意識別子として指定します：<\/P><\/P><\/P><\/P>

インデックス作成後、マップ上でNENAデータの(動的)ビューとして表示されます：

タイプフィールド幅拡大理由はこちら、「1375 Sunrise Hwy Westbound Service Road, Islip, NY, 11706」をご覧ください

さて、Create Locator を実行してください（派手なグラフィックではありませんが役立つことを願います）：

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"4Work5Product_Management5Address_Management5Nena", "ENG", None, None, None)

その後ジオコードしてください！

Units は機能します：

285 Asharoken Ave, #1, Huntington, NY, 11768

<\/P>

ダイアログキャプチャの警告チップは無視してください。これはロケーター作成後に表示され、ツールを再実行すると出力が上書きされることを示しています。<\/P>

<\/P>

私が行ったように多くのフィールドから代替都市名を収集することの賢明さは議論の余地がありますが、要点は理解していただけると思います。ゾーン値のさまざまなNENAフィールドは、代替名の役割として適切に使用できると見なせます。生産環境では、centerlineデータから代替都市名テーブルを作成し、street_idで結合する方が効率的です。<\/P>

<\/P>

こちらが代替都市名テーブルとして使用したビューです:<\/P>

<\/P>

address_id = 'KIN0000001' の住所は「463 Maspeth Ave, New York, NY, 11211」です。都市エイリアスとして「Brooklyn」を使うとスコア=100で機能します:<\/P>

<\/P>

さらに、FGDC標準で定義されているプレフィックスやサフィックスの住所番号部分、通り名の区切り要素、前修飾語や後修飾語など、住所のすべての部分を維持することについてオフラインで質問を受けました。ジオコーディング時にこれらの要素を出力したい場合は、それらをロケーター用のカスタム出力フィールドとして定義してください。この機能はツールの最後のパラメーターとして利用可能ですが、各出力に対してフィールドマップでソースフィールドも指定する必要があります。<\/P>

私はロケーターでseatとadditional_locationを出力しており、必要なら候補に対して作業できます。<\/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.

TomNeer

Bruce, Thanks for the quick response. Yes, we are just starting to work with migrating clients to NG9-1-1 schema. We are looking at ways to best integrate the standard with other Esri schema such as LGIM and with the Locator. Based on your post, we are going back to refactor our schema again so both ETL and SQL views do not need to be utilized. Lots going on here. Lots of unknowns. Honestly, haven't mucked around under the hood of ArcGIS Locators since 9.x. I remember it not being much fun...

bharold

Hi Tom, thanks for the feedback!

Scoring is a matter of agreement between the input address and the reference data, in itself moving values around input fields will not affect scoring.

In our new geocoding engine, all input fields can have alternate value tables, so allowing alternate city or postcode values for addresses will work provided you create the relevant lookup table and build it into your locator. There isn't any need to build composite locators for this sort of logic any more, or to include multiple geometry types, new locators ingest everything at once.

Looking at the data, say for alternate city names from the incorporated/unincorporated municipalities, it would be simple to generate an alternate name table from the distinct pairs of names, but if you did then you would allow alternates for cities that for the given address are actually clear across the other side of the city. You could build an alternate city table keyed on individual address ID, it would be a bigger table but give better results.

For neighborhood, district, postcode and city values, a proximity-based 'alias' is also automatically applied from a dissolve of the input points or street segments.

I haven't tackled centerline data yet, I just wanted to show a pattern for how to consume NENA data. I expect a small industry to spring up around this and there will be plenty of collaborators on details.

TomNeer

Thank you for the writeup.

So effectively, concatenate the fields down into something Esri's Locator can consume? Will this concatenation affect the quality of the scoring of the geocoder (e.g. "Main Street North" vs "Main Street North Extension")?

How do we resolve the issue of Postal City vs Incorporated City vs Unincorporated Community best? One of the issues the NENA standard resolves is the Postal Address vs Situs Address confusion. In some cases, their Situs Address falls under a different Postal Code but they use another Post Office. Set up a composite locator duplicate locators for both the Situs Address (using Incorporate City or Unincorporated Community and State) and Postal Address (using Postal Community and Postal Code) for both the RoadCenterlines and Site/StructureAddressPoints?

What is the best scenario for road centerlines along international borders? Do we hard code this value?

会話に参加する

サインインしたメンバーは投稿、更新のフォローなどができます。初めてですか？無料アカウントを登録してください。

クイックリンク

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.