プライマリ ロケーター ロール

ロケーターを構築するために最初に行う手順は、ロケーターの構築に使用するデータのタイプを定義することです。 これには、データに適したロケーター ロールを選択します。 ロケーター ロールでは、使用するデータのタイプ (区画、ストリートの中心線、郵便番号、目標物 (POI) など) を定義し、ロケーターの構築時に使用する適切なフィールドを指定します。 作成したロケーターには、ジオコーディングに使用される参照データのスナップショットが含まれています。また、インデックスと地域住所情報も格納されており、これによってジオコーディング処理中に最適な一致が返されます。

ロケーターの構築に使用するプライマリ ロケーター ロールを選択する際には、参照データに含まれるジオメトリのタイプやジオコーディングするデータの形式など、考慮すべき点がいくつかあります。 ポイント住所ロケーター ロールは通常、単一の場所での住所のモデル化に使用されます。 POI ロールは、名前またはコードで特定されるフィーチャの検索に使用することができます。

ArcGIS Pro で提供されるそれぞれのプライマリ ロケーター ロールの基本特性のいくつかを次の表に示します。 このようなロールを使用して、「320 Madison St., 53606」や「329 Holiday Court, La Jolla, CA 92122」のように、追加のゾーン情報が含まれる住所をジオコーディングできます。 ロケーター ロールをさらに拡張して代替名テーブルを含めることもできます。これにより、プライマリ フィーチャの代替名に基づいて住所をジオコーディングできるようになります。

ポイント住所

ポイント住所ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ポイントまたはポリゴン

最適なリバース ジオコーディング結果を得るために推奨されるポリゴン

各フィーチャは住所を表す

各フィーチャはオプションのサブアドレス エレメント付きの住所を表す

単一フィールド内のすべての住所要素

71 Cherry Ln.

W1700 Rock Rd.

38-76 Carson Rd.

15 Lakeshore Dr. Apt. 24A

Laurel Cottage, 26 Pinhoe Rd.

ポイント住所、サブアドレス

パーセル、建物、住所ポイントの検索

集合住宅のユニット、タウンハウス、複層住宅、ショッピング モール内の店舗の検索

2.3; 10.6.1; Enterprise 10.7 より前では、サポートされていないロケーター機能もあります。

2.8; 10.8.1; リバース ジオコーディングでフィーチャ タイプとしてサブアドレスをサポートします。

ポイント住所ロケーター ロールを使用すると、建物名または番地とストリート名で構成された一般的な住所のロケーターを作成することができます。 住所に建物名と番地の両方を含めることができます。 このロケーター ロールでは、ポリゴン ジオメトリまたはポイント ジオメトリのフィーチャクラスがプライマリ参照データとして使用されます。 プライマリ参照データ内の各フィーチャは単一の住所に相当します。 たとえば、建物フットプリントまたはパーセルの重心 (パーセル ポリゴンの中心点) が含まれるフィーチャクラスをポイント住所ロケーターのプライマリ参照データとして使用することができます。 検索する各住所がプライマリ参照データ内に存在する必要があります。 次に示すように、ポイント住所ロケーター ロールでは、参照データ内の各フィーチャがパーセルや建物などの単一の住所の値に相当する必要があります。

パーセルまたは建物ごとに一意の住所があります
注意:

ポリゴン ジオメトリをプライマリ参照データに使用すると、最適なリバース ジオコーディング結果が返されます。

ポイント住所ロールは、番地の範囲でモデル化されたプライマリ参照データもサポートします。 複数の住所が関連付けられた単一の場所 (パーセルなど) では、番地の From フィールドと To フィールドに番地の値の範囲が保持されます。 番地の範囲が設定されたフィーチャが一部存在する場合は、すべてのフィーチャを範囲でモデル化する必要があります。 番地の値が番地の From フィールドまたは To フィールドに格納される場合、番地の範囲を持たないフィーチャはロケーターに含められます。 これは、参照データの両方のフィールドが同じ値である場合と同じように機能します。 番地の範囲では、パリティもサポートされています。

注意:

ポイント住所ロケーターを構築するとき、番地フィールドと番地の From フィールドと To フィールドがマッピングされている場合、番地フィールドの値は無視され、番地の From フィールドと To フィールドの値がロケーターの構築に使用されます。

ポイント住所ロールのために番地の範囲をモデル化する方法

さらに、ポイント住所ロールは番地エクステンションをサポートします。これは、メゾネットアパートと分割区画が持つことができますが、たとえば、2B Wingate Rd.20 1/2 Rocky Knoll Dr. など、番地または完全な番地として表される単一のフィールドに格納されます。20 Rocky Knoll Dr. は元の建物に割り当てられた住所でしたが、区画が分割されたときに隣接する建物に 20 1/2 が割り当てられました。 接尾辞のフィールドには、一般的に番地の接尾辞 (B や 1/2) を使用します。 一般的ではありませんが、接尾辞 (28R 17 Oak St の 28R の部分) が番地の接頭辞フィールドとして使用される場合もあります。 番地のすべてのコンポーネント (番地の接頭辞、番地、番地の接尾辞) を単一フィールドに連結して、このフィールドをロケーターの構築時に番地フィールドとして使用します。 英数字による番地を含む住所を検索する場合、住所の候補が返されるには 28R 17 Oak St の「28R」のように、完全な番地を入力する必要があります。

連結された番地コンポーネント

フィーチャクラスをポイント住所ロケーターの参照データとして使用するには、番地または建物名とストリート名で構成された個別のフィールド、ObjectID フィールド、および Shape フィールドに加えて、「代替番地または代替番地範囲」の代替名テーブルにリンクするために [住所の結合 ID] ロケーター ロール フィールドに割り当てることができるオプションの住所 JoinID フィールドをフィーチャクラスに含める必要があります。 たとえば、このフィールドを使用すると、キリル文字の番地の英語の字訳をモデル化できます。 また、ストリートの方位の接頭辞、接頭辞タイプ、ストリート タイプ、方位の接尾辞、郵便番号、郵便番号拡張 (米国での ZIP+4 など)、ゾーン (市や近郊などの行政区域) を格納するフィールドを指定することもできます。 マルチロール ロケーターでパーセル ロケーター ロールと組み合わせてポイント住所ロールを使用する場合は、参照データにオプションのパーセル JoinID フィールドも含める必要があります。 住所ポイントをパーセルにリンクするには、パーセル JoinID フィールドを [パーセルの結合 ID] ロケーター ロール フィールドに割り当てます。 ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (POINT_ADDRESS_ID など) にマッピングする必要があります。 さらに、代替ストリート名が関連付けられている重複フィーチャがある場合、どのフィーチャが優先ストリート名に使用されているかを示すインジケーター フィールドがフィーチャクラスに含まれている必要があります。 このインジケーター フィールドをロケーター ロールの「優先ストリート名インジケーター」フィールド (PRIMARY_STREET_NAMEPrimaryStreetFlag など) にマッピングする必要があります。 [優先ストリート名] プロパティが想定どおりに機能するようにするには、[フィーチャ ID] フィールドと [優先ストリート名インジケーター] フィールドのマッピングが必要です。

注意:

ポイント住所ロールでロケーターを構築する場合は、[建物名][番地][開始番地][終了番地][建物名][番地] のいずれかをマッピングする必要があります。

サブアドレス

ポイント住所ロケーター ロールでは、サブアドレス情報 (集合住宅の各区画、タウンハウス、複層住宅、複合商業施設の各店舗を表す識別子など) を含む住所を使用することができます。 サブアドレスは、住居用および商業用のさまざまな建物や、特殊な建造物 (空港、トレーラー パーク、桟橋と船着場、学校など) で使用されています。

ポイントまたはポリゴンのプライマリ参照データ内の各フィーチャは、サブアドレス情報を含む単一の住所に相当します。 建物のフットプリントや住所ポイントを含むフィーチャクラスを、参照データとして使用できます。 検索する各住所が参照データに存在する必要があります。 ポイント住所ロールのセクションで説明したように、参照データ内で番地の範囲によって番地の値がモデル化されていない限り、ストリートのどのような住所範囲からも、正確な位置を外挿または内挿することはできません。 次に示すように、サブアドレスでは、参照データ内の各フィーチャが建物や住所ポイントなどの単一の住所の値に相当する必要があります。

住所ポイントごとに、サブアドレスを含む住所があります

注意:

サブアドレスに対応したロケーターを使用して 36 Orchard Ct というベース アドレスを検索する場合は、プライマリ参照データのユニット フィールドに値がないそのベース アドレスのフィーチャが存在する必要があります。

サブアドレスは、ユニット番号の範囲でモデル化されたプライマリ参照データもサポートします。 複数のユニットが関連付けられた単一の場所 (ショッピング プラザの建物など) では、From フィールドと To フィールドにユニット番号の値の範囲が保持されます。 番地の範囲が設定されたフィーチャが一部存在する場合は、すべてのフィーチャを範囲でモデル化する必要があります。 ユニットの値がユニットの From フィールドまたは To フィールドに格納される場合、ユニット番号の範囲を持たないフィーチャはロケーターに含められます。 これは、参照データの両方のフィールドが同じ値である場合と同じように機能します。

注意:

サブアドレスをサポートするポイント住所ロケーターを構築するとき、ユニット フィールドとユニットの From フィールドと To フィールドがマッピングされている場合、ユニット フィールドの値は無視され、ユニットの From フィールドと To フィールドの値がロケーターの構築に使用されます。

ポイント住所ロールのためにサブアドレス ユニットの範囲をモデル化する方法

サブアドレスに対応したポイント住所ロケーターのプライマリ参照データを提供するフィーチャクラスには、ベース アドレス属性だけでなく、建物タイプ、建物ユニット名、レベル タイプ、レベル名、ユニット タイプ、ユニット名を表す各フィールドも含めることができます。

サブアドレス エレメント タイプ フィールド

注意:

このロケーター ロールでは、3 組のサブアドレス エレメント (Unit と Unit Type、Level と Level Type、Building Unit と Building Unit Type) がサポートされています。 必要に応じて、ロケーターでサブアドレス エレメントの各ペアを使用するか、1 つのペアだけを使用できます。 これらのペアは、Apt F や Building A や Floor 1 などが適用されるフィールドにマッピングできます。 プライマリ参照データ内の「住所要素」の詳細をご確認ください。

サブ住所情報を含む住所を検索するときに最適な結果を得るには、サブ住所ユニットの前にインジケーター (#、Apt、Suite、Bldg、Floor) を指定する必要があります。このように指定しないと、住所は最高スコアを返すデータ内のレコードと一致することになります。 サブユニットを含む住所を検索する場合、サブアドレスの場所の一致が返されるには 35 Orchard Ct, Unit 101 の「Unit 101」のように、完全なサブアドレス エレメントを入力する必要があります。 1 つの住所に複数のサブアドレスが存在する場合は、[ロケーターのプロパティ] ダイアログ ボックスでサブアドレス情報またはサブアドレス候補を候補として返す複数のオプションを利用できます。 デフォルトのサブアドレス候補の操作は、住所と完全なサブアドレスを入力することです。

  • ベース アドレスを入力した後で住所のサブアドレス ユニットのサマリーが返されるようにするには、[ベース アドレスの候補表示でサブアドレスのサマリーを表示] 設定を有効にする必要があります。 プライマリ参照データにベース アドレスのフィーチャ (ユニット フィールドに値がないフィーチャ) が存在しない場合は、サマリーが候補として表示されません。

    ベース アドレスを入力した後のオートコンプリートによる候補のサブアドレスのサマリー

  • インジケーターの有無に関係なくサブアドレス名の一部を入力した後で有効なサブアドレス候補が返されるようにするには、「部分的なユニットが入力されたときに候補を表示」候補設定を有効にする必要があります。

    サブアドレス名の一部を入力するとオートコンプリートによる候補が表示されます。

  • ベース アドレスを入力した後でサブアドレスのリストが返されるようにするには、「ベース アドレスが入力されたときに候補を表示」候補設定を有効にします。 プライマリ参照データにベース アドレスのフィーチャ (ユニット フィールドに値がないフィーチャ) が存在しない場合は、サブアドレス候補のリストが表示されません。

    ベース アドレスを入力した後のオートコンプリートによる候補の表示

パーセル

パーセル ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ポイントまたはポリゴン

最適なリバース ジオコーディング結果を得るために推奨されるポリゴン

各フィーチャはパーセルを表します。

各フィーチャはパーセル ID (番号や APN など) または住所で特定されます。

単一フィールド内のすべての住所要素

1760820300

1760820300, 935 Feather Ln.

935 Feather Ln.

パーセル

パーセルまたは住所ポイントの検索

2.5; 10.8

パーセル ロケーター ロールを使用すると、パーセル番号を含む住所、および番地とストリート名を含む一般的な住所のロケーターを作成できます。 このロケーター ロールはポイント住所ロールに似ていますが、サブアドレス情報を含む住所の検索をサポートしていません。 ただし、「POI ロールのサブアドレス サポート」と同様に機能するサブアドレスをサポートしています。 このロケーター ロールでは、ポリゴン ジオメトリまたはポイント ジオメトリのフィーチャクラスがプライマリ参照データとして使用されます。 プライマリ参照データ内の各フィーチャは単一の区画に相当します。 たとえば、パーセル ポリゴンまたはパーセルの重心 (パーセル ポリゴンの中心点) が含まれるフィーチャクラスをパーセル ロケーターのプライマリ参照データとして使用することができます。 検索する各パーセルまたは住所がプライマリ参照データ内に存在する必要があります。 次に示すように、パーセル ロケーター ロールでは、参照データ内の各フィーチャがパーセルやパーセルの重心などの単一のパーセルまたは住所の値に相当する必要があります。

パーセルごとに一意の値があります

フィーチャクラスをパーセル ロケーターの参照データとして使用するには、パーセル番号または番地とストリート名の情報を格納する個別のフィールド、ObjectID フィールド、および Shape フィールドに加えて、マルチロール ロケーターでポイント住所ロールにリンクするために [パーセルの結合 ID] ロケーター ロール フィールドに割り当てることができるオプションのパーセル JoinID フィールドがフィーチャクラスに含まれている必要があります。 また、ストリートの方位の接頭辞、接頭辞タイプ、ストリート タイプ、方位の接尾辞、郵便番号、郵便番号拡張 (米国での ZIP+4 など)、ゾーン (市や近郊などの行政区域) を格納するフィールドを指定することもできます。 ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (PARCEL_ID など) にマッピングする必要があります。 さらに、代替ストリート名が関連付けられている重複フィーチャがある場合、どのフィーチャが優先ストリート名に使用されているかを示すインジケーター フィールドがフィーチャクラスに含まれている必要があります。 このインジケーター フィールドをロケーター ロールの「優先ストリート名インジケーター」フィールド (PRIMARY_STREET_NAMEPrimaryStreetFlag など) にマッピングする必要があります。 「優先ストリート名」プロパティが想定どおりに機能するようにするには、[フィーチャ ID] フィールドと [優先ストリート名インジケーター] フィールドのマッピングが必要です。

パーセルの参照データの属性
注意:

ポリゴン ジオメトリをプライマリ参照データに使用すると、最適なリバース ジオコーディング結果が返されます。

パーセル ロールは、番地の範囲でモデル化されたプライマリ参照データもサポートします。 複数の住所が関連付けられた単一の場所 (パーセルなど) では、番地の From フィールドと To フィールドに番地の値の範囲が保持されます。 番地の範囲が設定されたフィーチャが一部存在する場合は、すべてのフィーチャを範囲でモデル化する必要があります。 番地の値が番地の From フィールドまたは To フィールドに格納される場合、番地の範囲を持たないフィーチャはロケーターに含められます。 これは、参照データの両方のフィールドが同じ値である場合と同じように機能します。 番地の範囲では、パリティもサポートされています。

注意:

ロケーターを構築するとき、番地フィールドと番地の From フィールドと To フィールドがマッピングされている場合、番地フィールドの値は無視され、番地の From フィールドと To フィールドの値がロケーターの構築に使用されます。

パーセル ロールのために番地の範囲をモデル化する方法

このロケーター ロールを使用してジオコーディングできる住所のテーブルには、パーセル番号またはパーセル住所と行政区域 (近郊、都市、郵便番号など) の両方を含める必要があります。 このロケーター ロールで作成されたロケーターは次の検索シナリオをサポートします。

  • ロケーターの構築時にパーセル番号だけがパーセル名ロケーター ロール フィールドに割り当てられている場合に正確なパーセル番号で検索します。

    パーセル番号のみの検索結果

  • ロケーターの構築時にパーセル番号と住所フィールドが割り当てられている場合にパーセルの住所で検索します。 この方法でロケーターの構築時にパーセル番号だけを検索することもできます。

    パーセルの住所の検索結果

  • ロケーターの構築時にパーセル番号と住所フィールドが割り当てられている場合にパーセル番号とパーセル住所で検索します。 この方法でロケーターの構築時にパーセル番号だけを検索することもできます。

    パーセル番号とパーセル住所の検索結果

ストリート住所

ストリート住所ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ライン

各フィーチャにはストリート セグメントの両側の住所範囲が指定されています。

各フィーチャにはストリート名とオプションのゾーン名が指定されています。

単一フィールド内のすべての住所要素

単一フィールド内で番地がない住所要素

320 Madison St.

N2W1700 County Rd.

105-30 Union St.

5th St. NE & Cherry St. NE

Raspberry Lane, San Antonio, TX

ストリート住所、交差点、ストリート名

ストリートまたはストリートの交差点のどちらかの側の家の検索

ストリート名でフィーチャを検索

2.3; 10.6.1; Enterprise 10.7 より前では、サポートされていないロケーター機能もあります。

ストリート住所ロケーター ロールを使用すると、ストリート名のみ、番地、ストリートの交差点で構成された一般的な住所の検索をサポートするロケーターを作成できます。 このロケーター ロールの利点の 1 つは、ストリート セグメントの両側に番地の値の範囲を設定できることです。 このスタイルにより、ロケーターはストリート セグメントに沿った場所を示すだけでなく、住所がストリート セグメントのどちら側にあるかを判断することができます。

このロケーター ロールでは、ライン ジオメトリのフィーチャクラスが使用されます。 プライマリ参照データ内の各フィーチャは、ストリート セグメントに沿って 2 つの住所範囲 (ストリートの各側に 1 つずつ) があるストリート セグメントを表します。

各道路セグメントには、ストリートの左右両方に住所範囲の開始住所と終了住所があります。

FieldName 列と DataType 列があるプライマリ参照データ

フィーチャクラスをストリート住所ロケーター ロールのプライマリ参照データとして使用するには、ストリートの各側の開始住所情報と終了住所情報を格納する 4 つのフィールド、ストリート名の情報を格納するフィールド、ObjectID フィールド、Shape フィールド、および参照データ内の代替名テーブルにリンクするために [ストリートの結合 ID] ロケーター ロール フィールドに割り当てることができる ID を格納するオプションの JoinID フィールドがフィーチャクラスに含まれている必要があります。 さらに、ストリートの方向の接頭辞、種類の接頭辞、ストリートの種類、方向の接尾辞、ゾーンなどを格納するフィールドを指定することができます。 ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (STREET_SEGMENT_ID など) にマッピングする必要があります。 さらに、代替ストリート名が関連付けられている重複フィーチャがある場合、どのフィーチャが優先ストリート名に使用されているかを示すインジケーター フィールドがフィーチャクラスに含まれている必要があります。 このインジケーター フィールドをロケーター ロールの「優先ストリート名インジケーター」フィールド (PRIMARY_STREET_NAMEPrimaryStreetFlag など) にマッピングする必要があります。 [優先ストリート名] プロパティが想定どおりに機能するようにするには、[フィーチャ ID] フィールドと [優先ストリート名インジケーター] フィールドのマッピングが必要です。

このロケーター ロールは、通常のブロック範囲、グリッド ゾーンを使用した英数字による住所、交差ストリート情報が番地に含まれるハイフン付きの住所をサポートしています。 ストリートの交差点も、このロケーター ロールで使用できます。 参照フィーチャクラスに含まれる ZIPLZIPR (ストリートの各側の郵便番号)、市の右側と左側、州の略語のフィールドなどのオプション フィールドを使用することができます。

参照データには、追加のゾーン情報のフィールドが必要です。

このロケーター ロールで作成されたロケーターに対してジオコーディングできる住所のテーブルには、ストリートの方向の接頭辞、接頭辞タイプ、ストリート タイプ、方向の接尾辞 (存在する場合) に加えて、番地とストリート名を格納する住所フィールドも必要です。 交差点の説明 (Eureka Blvd. & Vine St. など) もこのフィールドに格納することができます。 ストリート名の検索はストリート住所ロケーター ロールで作成されたロケーターのオプションとしても使用されるため、ストリートの方位の接頭辞、接頭辞タイプ、ストリート タイプ、方位の接尾辞 (存在する場合) に加えて、ストリート名も住所のテーブル内の住所フィールドに格納する必要があります。 少なくとも 1 つの行政区域 (市や郵便番号など) を別々のフィールドに含めて、同じストリート名を含む住所を照合した場合のジオコーディング品質を高める必要があります。

住所のテーブル

ハイフン付き範囲

ストリート住所ロケーター ロールには、ハイフン付きの番号範囲のサポートが含まれます。これは、通常は交差ストリートの番号の後にハイフンを付け、続いてそのストリート沿いの実際の番地を示します (例: 76-20 34th Ave)。 このタイプの住所スタイルを使用している地域の 1 つが New York 市の Queens です。 最初の数字は、北または西のいずれかで交差するストリートを示します。 2 つ目の数字は、建物がブロックのどちら側に位置するかを示します。

ライン フィーチャクラスの開始住所フィールドと終了住所フィールドでは、番地がハイフン付きの数字になる場合と、単純な番地になる場合があります。 たとえば、次のテーブルに示すように、住所範囲 95-1000 ~ 95-1018 と 95-1001 ~ 95-1019 には、交差ストリートと実際の番地を区切るためのハイフンが必要です。 このロケーター ロールは、ハイフンの右側の番地範囲のみをサポートするため、以下のテーブルに基づき、Mahea St に対して 95-1000 ~ 95-1018 の左側の範囲と 95-1001 ~ 96-1019 の右側の範囲を設定できず、住所「96-1013 Mahea St」に一致するものが返されます。

ハイフン付きの番地範囲のテーブル

ストリート名

ストリート住所ロケーター ロールには、ストリート名のサポートが含まれています。 ストリート名のみに基づいて検索された住所 (たとえば、「Orchard Court, Lansing MI」) は、StreetName の一致を返します。 検索対象の住所に番地が含まれている場合は、他のオプションが使用できない場合にのみ StreetName の一致が返されます。 このような状況は、参照データ内にストリート セグメントに関連付けられた番地がない場合に発生します。 ストリート名の一致にのみ対応したロケーターを作成するには、番地の範囲フィールド内の各レコードが NULL または空の文字列になるように参照データを設定するか、ロケーター ロールから開始番地と終了番地の各範囲フィールドに NULL または空の文字列が割り当てられる単一のフィールドを参照データに含める必要があります。 住所が見つかると、該当する場所がストリート セグメントの中央に配置されます。

ストリート ブロック

ストリート住所ロケーター ロールでは、1 つ以上の街区を表す番地のグループの検索がサポートされます。 この検索のタイプに対して返される Addr_type 値は StreetMidBlock です。 このようなフィーチャの位置は、ブロック番号またはブロック範囲で表される番地を含むストリート セグメントのおおよその中間点です。 StreetMidBlock の一致の精度は、StreetName の一致よりも高く、StreetAddress の一致よりも低くなります。 「<number or range> block | block of <street name>」という構文を使用して単一のブロックまたはブロックの範囲を検索できます。たとえば、「100 block of New York St, Redlands, CA」や「200-500 block Taylor St, San Francisco」などです。 「ストリート ブロックの検索」の詳細については、REST API Web ヘルプをご参照ください。

POI

POI ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ポイントまたはポリゴン

最適なリバース ジオコーディング結果を得るために推奨されるポリゴン

各フィーチャは特定の地理的な地名またはランドマークを表します。

各フィーチャはテキスト文字列、名前、またはコードで特定されます (コードに数字を入れてもかまいませんが、テキスト文字列で表現する必要があります)。

単一フィールド内のすべての場所名エレメント

Leeds Castle, England

Sapporo, Japan

Cafe Cabrillo

N1N115

目標物

地域または世界での地理的な場所名やランドマークの検索

名前またはコードで特定されるフィーチャの検索

2.3; 10.6.1; Enterprise 10.7 より前では、サポートされていないロケーター機能もあります。

POI (目標物) ロケーター ロールを使用すると、ランドマーク、場所、建物の名前を含むデータのロケーターを作成できます。 また、このロールでは、場所を特定する英数字文字列 (例:「N1N115」) を含む住所データのロケーターを作成することもできます。 このロールで作成されたロケーターを使用して、山、橋、河川、市などのフィーチャを検索できます。 また、このロールで作成されたロケーターを使用して、移動通信用鉄塔、国勢調査区、フィーチャクラス内で仮想的に表現された一意のフィーチャを検索することもできます。 さらに、このロケーター ロールでは、ジオコーディング時に結果の絞り込みに使用したり、ジオコーディングしたフィーチャの追加情報として使用したりできるカテゴリとサブカテゴリを各フィーチャに割り当てることもできます。

ヒント:

フィーチャ ロケーターの作成」ツールを使用すると、参照データ内のフィーチャ (水道メーターや国勢調査区グループなど) に短い一意の名前または識別子しか設定していない場合にロケーターを構築することができます。

このロケーター ロールでは、ポリゴン ジオメトリまたはポイント ジオメトリのフィーチャクラスがプライマリ参照データとして使用されます。 このロケーターの参照データとして使用されるフィーチャクラスには、ObjectID フィールドと Shape フィールドに加えて、フィーチャの位置を区別するための名前および地理ゾーン (市、州、国など) を表す属性や、そのフィーチャに一意の名前または値を格納する特定のフィールドも必要です。 POI の実際の住所の住所要素を、それぞれ個別のフィールドに分けて含めることもできます。 カテゴリとサブカテゴリを使用するには、フィーチャを分類する 1 つまたは 2 つのフィールドをプライマリ参照データに挿入する必要があります。 必要に応じて、代替場所名または代替カテゴリの代替名テーブルへのリンクに使用できる ID を格納する結合フィールドを参照データに含めることができます。 ロケーターの構築時に、プライマリ テーブルと代替名テーブルの [場所の結合 ID] をロケーター ロール フィールドに結合フィールドを割り当てます。 ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (PLACE_NAME_ID など) にマッピングする必要があります。 さらに、代替ストリート名が関連付けられている重複フィーチャがある場合、どのフィーチャが優先ストリート名に使用されているかを示すインジケーター フィールドがフィーチャクラスに含まれている必要があります。 このインジケーター フィールドをロケーター ロールの「優先ストリート名インジケーター」フィールド (PRIMARY_STREET_NAMEPrimaryStreetFlag など) にマッピングする必要があります。 「優先ストリート名」プロパティが想定どおりに機能するようにするには、[フィーチャ ID] フィールドと [優先ストリート名インジケーター] フィールドのマッピングが必要です。

注意:

  • ポリゴン ジオメトリをプライマリ参照データに使用すると、最適なリバース ジオコーディング結果が返されます。
  • POI ロケーター ロールを使用すると、場所名のエイリアス テーブルが必要なくなりますが、このロールでは、場所名のポイントまたはポリゴン フィーチャクラスが、関連付けられた住所と共に属性テーブルに含まれている必要があります。

ヒント:

複数のフィーチャクラスに異なるタイプの場所や位置を表すフィーチャがある場合は (バス停、地下鉄の駅、公園、学校など)、ロールごとに 1 つのプライマリ参照データセットしか使用できないので、個々のフィーチャクラスの各フィーチャにカテゴリを割り当て、各フィーチャクラスを 1 つのフィーチャクラスにマージすることをお勧めします。 これにより、1 つのロケーターを使用してさまざまなタイプの位置を検索することができます。

POI ロケーター ロールのフィーチャクラスの属性

このロケーター ロールを使用してジオコーディングできる住所のテーブルには、地名と地理ゾーンの他に、位置の特定に使用できる一意の名前または値も含める必要があります。 地理ゾーン情報は検索を絞り込むために使用します。これは、「Rochester」のような同じ名前が 1 つの国の複数の州で見つかることがよくあるからです。 POI と住所をジオコーディングする場合は、場所名を address フィールド、住所を address2 フィールドに含めます。 POI ロールで作成されたロケーターを使用して、名前、カテゴリ、名前またはカテゴリと住所の一部の組み合わせを基準に場所を検索することもできます。 たとえば、「Starbucks, Orange St, Redlands」や「gas station, Boulder, CO」と入力します。このロケーター ロールで作成されたロケーターは次の検索形式をサポートします。

  • Disneyland、Starbucks、Niagara Falls などの名前または遊園地、滝、喫茶店などのカテゴリで場所を検索します。

    場所の名前による POI 検索結果

  • オプションのコネクタ (in または at) を含めた 1 つ以上のゾーン (近郊、都市、地域、郵便番号) を使用して名前またはカテゴリで場所を検索します。

    場所検索ウィンドウでゾーンとオプションのコネクタを使用した POI 場所名検索の結果

  • ストリート名など、住所の一部を使用して名前またはカテゴリで場所を検索します。

    場所検索ウィンドウでストリート名を使用した POI カテゴリ検索の結果

  • 住所と 1 つ以上のゾーン (近郊、都市、地域、郵便番号) を使用して名前またはカテゴリで場所を検索します。

    場所検索ウィンドウで完全な住所と郵便番号を使用した POI 場所名検索の結果

サブアドレス

POI ロケーター ロールでは、サブアドレス情報 (診療所内の各部屋や複合商業施設の各店舗を表す識別子など) を含む目標物を使用することができます。 サブアドレスは、商業用のさまざまな建物や、特殊な建造物 (空港、トレーラー パーク、桟橋と船着場、学校など) で使用されています。

ポイントまたはポリゴンのプライマリ参照データ内の各フィーチャは、それぞれ個別のフィールドに分けられた POI の実際の住所およびサブアドレス エレメントを含む単一の目標物に相当します。 サブアドレスは POI の属性であり、単一のサブアドレスのみを単一の POI フィーチャにリンクできますが、ポイント住所によってサポートされている独立したフィーチャとして表すことはできません。

POI ロールは、サブアドレス属性のユニット番号の範囲でモデル化されたプライマリ参照データをサポートします。 複数のユニットが関連付けられた単一の場所 (ショッピング プラザの建物など) では、From フィールドと To フィールドにユニット番号の値の範囲が保持されます。 番地の範囲が設定されたフィーチャが一部存在する場合は、すべてのフィーチャを範囲でモデル化する必要があります。 ユニットの値がユニットの From フィールドまたは To フィールドに格納される場合、ユニット番号の範囲を持たないフィーチャはロケーターに含められます。 これは、参照データの両方のフィールドが同じ値である場合と同じように機能します。

注意:

サブアドレスをサポートする POI ロケーターを構築するとき、ユニット フィールドとユニットの From フィールドと To フィールドがマッピングされている場合、ユニット フィールドの値は無視され、ユニットの From フィールドと To フィールドの値がロケーターの構築に使用されます。

POI ロールのためにサブアドレス ユニットの範囲をモデル化する方法

サブアドレスに対応した POI ロケーターのプライマリ参照データを提供するフィーチャクラスには、ベース アドレス属性だけでなく、建物タイプ、建物ユニット名、レベル タイプ、レベル名、ユニット タイプ、ユニット名を表す各フィールドも含めることができます。

サブアドレス エレメント タイプ フィールド

注意:

このロケーター ロールでは、3 組のサブアドレス エレメント (Unit と Unit Type、Level と Level Type、Building Unit と Building Unit Type) がサポートされています。 必要に応じて、ロケーターでサブアドレス エレメントの各ペアを使用するか、1 つのペアだけを使用できます。 これらのペアは、Apt F や Building A や Floor 1 などが適用されるフィールドにマッピングできます。 目標物フィーチャクラスに関連付けられた場合に、ロケーターの構築時にマッピングされるサブアドレス エレメントが出力に返されます。 プライマリ参照データ内の「住所要素」の詳細をご確認ください。

サブアドレス情報を含む POI フィーチャを使用してこのロケーター ロールで作成されたロケーターは、上記の同じ検索形式をサポートしますが、以下に示すように、検索結果と候補にサブアドレスの詳細を返します。

  • 名前で場所を検索します。

    サブアドレスの詳細を含む場所の名前による POI 検索結果

  • 名前またはカテゴリによる場所の検索

    POI カテゴリまたは場所の名前を入力した後、サブアドレスを示す候補を自動補完します。

距離マーカー

距離マーカー ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ポイント

各フィーチャは、道路に沿って一定の間隔で配置された連番付きのマーカーを表します。

単一のフィールド内の距離マーカー

Mile 25 I-5 N, San Diego, CA

距離マーカー

高速道路上の距離マーカー標識の検索

2.3; 10.6.1; Enterprise 10.7 より前では、サポートされていないロケーター機能もあります。

距離マーカー ロケーター ロールを使用すると、距離マーカー (道路に沿って一定の間隔で配置された連番付きのマーカー) のロケーターを作成できます。 このロケーター ロールでは、ポイント ジオメトリのフィーチャクラスが使用され、参照データ内の各フィーチャは距離マーカーまたは標識を表します。

距離マーカーごとに始点と終点があります。

フィーチャクラスを距離マーカー ロケーターの参照データとして使用するには、距離の値、計測単位、ストリート名情報を格納するそれぞれのフィールド、ObjectID フィールド、および Shape フィールドがフィーチャクラスに含まれている必要があります。 ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (STREET_ID など) にマッピングする必要があります。 さらに、代替ストリート名が関連付けられている重複フィーチャがある場合、どのフィーチャが優先ストリート名に使用されているかを示すインジケーター フィールドがフィーチャクラスに含まれている必要があります。 このインジケーター フィールドをロケーター ロールの「優先ストリート名インジケーター」フィールド (PRIMARY_STREET_NAMEPrimaryStreetFlag など) にマッピングする必要があります。 [優先ストリート名] プロパティが想定どおりに機能するようにするには、[フィーチャ ID] フィールドと [優先ストリート名インジケーター] フィールドのマッピングが必要です。

距離マーカー ロケーター ロールのフィーチャクラスの属性

距離マーカー ロケーターを使用して位置のテーブルをジオコーディングするには、テーブルに、次のいずれかの形式で単一のフィールドにすべての住所要素を含むテキスト フィールドが必要となります。

  • Kilometer 152 MEX-400
  • Km 152 MEX-400
  • MEX-400 Kilometer 152
  • MEX-400 Km 152

注意:

このロールを使用してロケーターを構築するときに距離単位を含めた場合、その距離単位は場所の検索時に無視されます。

距離範囲

距離範囲ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ライン

各フィーチャは、各ライン セグメントの距離マーカー範囲を表します。

単一のフィールド内の距離マーカー範囲

Carr 682 KM 4.4, Barceloneta, 00617

距離マーカー

高速道路に沿った概算距離の検索

2.3; 10.6.1; Enterprise 10.7 より前では、サポートされていないロケーター機能もあります。

距離範囲ロケーター ロールを使用すると、距離マーカー範囲を伴うストリート セグメントのロケーターを作成できます。 このロケーター ロールでは、ライン ジオメトリのフィーチャクラスが使用され、参照データ内の各フィーチャは、ストリート セグメントに沿って 1 つの距離マーカー範囲があるストリート セグメントを表します。 フィーチャクラスを距離範囲ロケーターの参照データとして使用するには、開始距離、終了距離、計測単位、ストリート名情報を格納するそれぞれのフィールド、ObjectID フィールド、および Shape フィールドがフィーチャクラスに含まれている必要があります。 ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (STREET_ID など) にマッピングする必要があります。 さらに、代替ストリート名が関連付けられている重複フィーチャがある場合、どのフィーチャが優先ストリート名に使用されているかを示すインジケーター フィールドがフィーチャクラスに含まれている必要があります。 このインジケーター フィールドをロケーター ロールの [優先ストリート名インジケーター] フィールド (PRIMARY_STREET_NAMEPrimaryStreetFlag など) にマッピングする必要があります。 [優先ストリート名] プロパティが想定どおりに機能するようにするには、[フィーチャ ID] フィールドと [優先ストリート名インジケーター] フィールドのマッピングが必要です。

距離範囲の参照データの属性フィールドの例

郵便番号

郵便番号ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ポイントまたはポリゴン

最適なリバース ジオコーディング結果を得るために推奨されるポリゴン

各フィーチャは、単一の郵便番号の地域または重心を表します。

単一のフィールド内の郵便番号

22066

B4N 1Z5

基本の郵便番号

特定の郵便番号が示す場所の検索

2.3; 10.6.1; Enterprise 10.7 より前では、サポートされていないロケーター機能もあります。

郵便番号ロケーター ロールを使用すると、郵便番号のロケーターを作成できます。 このロケーター ロールでは、ポイント ジオメトリまたはポリゴン ジオメトリのフィーチャクラスが使用され、参照データ内の各フィーチャは郵便番号ポリゴンまたはその重心を表します。

注意:

ポリゴン ジオメトリをプライマリ参照データに使用すると、最適なリバース ジオコーディング結果が返されます。

郵便番号ロケーターのポイント参照データ
郵便番号ロケーターのポリゴン参照データ

郵便番号ロケーター ロールの参照データには、フィーチャの郵便番号を指定するフィールド、ObjectID フィールド、Shape フィールド、代替名テーブルへのリンクに使用できる ID を格納する結合フィールド、および行政区域 (市など) を格納するオプションのフィールドが必要となります。 ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (POSTAL_ID など) にマッピングする必要があります。

都市名値と郵便番号が参照データに含まれる場合、ロケーターを構築するときに、都市値は郵便番号都市値として格納されます。 米国などの国によっては、郵便番号都市はジオコーディングの際にデフォルト値として返されます。 これは、ポイント住所、パーセル、ストリート住所、POI ロールなど、マルチロール ロケーターが返す結果にも影響します。 ロケーターのプロパティ ダイアログ ボックスで「優先する都市名」のデフォルト値を変更すると、地方都市や、一致した都市のロケーターに返す値を変更できます。

このロケーター ロールを使用してジオコーディングできる住所のテーブルには、郵便番号情報を格納するフィールドを挿入する必要があります。

郵便番号拡張

郵便番号拡張ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ポイント

各フィーチャは、単一の郵便番号拡張の重心を表します。

5 桁の郵便番号と別のフィールド内の 4 桁の拡張コード

96822-2323

基本の郵便番号、郵便番号拡張

特定の郵便番号拡張が示す場所の検索

2.3; 10.6.1; Enterprise 10.7 より前では、サポートされていないロケーター機能もあります。

郵便番号拡張ロケーター ロールは、拡張番号 (米国での ZIP+4 番号など) 付きの郵便番号のジオコーディングに使用されます。 このロケーター ロールを使用すると、ポイント フィーチャクラスをプライマリ参照データとして使用するロケーターを作成できます。

参照データの属性フィールドの例

プライマリ参照データ ソース内の各フィーチャは、郵便番号拡張のポイントを表します。 参照データ フィーチャクラスまたはシェープファイルには、ObjectID フィールドと Shape フィールドに加えて、フィーチャの郵便番号 (米国では 5 桁の郵便番号) を表すテキスト フィールドと郵便番号拡張 (米国では 4 桁の ZIP+4 番号) を表す別のテキスト フィールドも必要となります。 ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (POSTAL_EXTENSION_ID など) にマッピングする必要があります。

郵便番号拡張ロケーターを使用して住所のテーブルをジオコーディングするには、郵便番号と郵便番号拡張がすべて格納されるテキスト フィールドをテーブルに挿入する必要があります。 たとえば、米国の場合は、「12345-6789」、「12345 6789」、「123456789」のように、ZIP+4 番号 (5 桁の郵便番号と ZIP+4 番号) になります。

参照データの属性フィールドの例

郵便地区

郵便地区ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ポイント

最適なリバース ジオコーディング結果を得るために推奨されるポリゴン

各フィーチャは、郵便番号と郵便番号の境界または重心内の市のユニオンを表します。

単一のフィールド内の郵便番号と市

7132 Frauenkirchen

基本の郵便番号、郵便地区

特定の郵便地区の検索

2.3; 10.6.1; Enterprise 10.7 より前では、サポートされていないロケーター機能もあります。

郵便地区ロケーター ロールを使用すると、郵便番号と地区のユニオンのロケーターを作成できます。 このロケーターを使用すると、郵便番号が複数の地区にまたがっている場合に場所をより正確に突き止めることができます。 このロケーター ロールでは、参照データ内の各フィーチャが郵便番号と地区のユニオンを表すフィーチャクラスが使用される必要があります。 たとえば、下の図では、Scripps Estates の近郊境界 (紫) が 92037 (La Jolla 市に割り当てられている) の郵便番号境界 (黒) 内に入っています。 この郵便番号データを使用して郵便番号ロケーターを作成した場合、「92037, La Jolla」を検索すると、一致が返されますが、 「92037 Scripps Estates」を検索しても一致は返されません。これは、この郵便番号参照データで Scripps Estates が 92037 郵便番号フィーチャに関連付けられていないためです。 「92037, Scripps Estates」を検索するには、郵便地区ロケーターを構築する必要があります。

注意:

ポリゴン ジオメトリをプライマリ参照データに使用すると、最適なリバース ジオコーディング結果が返されます。

地区の境界と郵便番号の境界、およびそれらの境界が交差する部分を示すマップ

郵便地区ロケーター ロールの参照データには、フィーチャの郵便番号と市を指定するフィールド、ObjectID フィールド、Shape フィールド、および代替名テーブルへのリンクに使用できる ID を格納するオプションの結合フィールドが必要となります。 ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (POSTAL_LOCALITY_ID など) にマッピングする必要があります。 郵便地区ロール付きのロケーターの作成に使用する参照データを作成するには、「ユニオン」ツールを使用して、単一のフィーチャクラス内でそれぞれのデータセット属性を持つ市または地区の境界線フィーチャクラスと郵便番号境界線フィーチャクラスの地理的交差部を算出します。

参照データの属性フィールド

行政区域

行政区域ロールの基本特性

一般的な参照データセットのジオメトリ一般的な参照データセットによる表現住所検索のパラメーターサポートされているカテゴリアプリケーションサポートされている ArcGIS Pro および Enterprise のバージョン

ポイントまたはポリゴン

最適なリバース ジオコーディング結果を得るために推奨されるポリゴン

各フィーチャは、市、近郊、都市圏、テリトリー、地域など、特定の行政区域を表します。

単一フィールド内の行政区域の名前

ブリティッシュコロンビア

North Park, San Diego

ブロック、セクター、近郊、地区、市、都市圏、小地域、地域、テリトリー、国、ゾーン

特定の行政区域の検索

2.3; 10.6.1; Enterprise 10.7 より前では、サポートされていないロケーター機能もあります。

行政区域ロケーター ロールは、市、近郊、郡、州、地区、テリトリーなどの地域のジオコーディングに使用されます。 このロールを使用して、ポイントまたはポリゴン フィーチャクラスをプライマリ参照データとして使用するロケーターを作成できます。 住所レベルと行政区域の両方を含むロケーターを複数のロールで構築する場合は、行政区域ポリゴンを使用して、欠落している行政区域の属性を住所データから取り込むことができます。

注意:

ポリゴン ジオメトリをプライマリ参照データに使用すると、最適なリバース ジオコーディング結果が返されます。

行政区域ロケーター ロールの参照データには、フィーチャの行政区域名を指定するフィールド、ObjectID フィールド、Shape フィールド、および代替名テーブルへのリンクに使用できる ID を格納するオプションの行政区域 JoinID フィールドが必要となります。 この ID をプライマリ参照データ内の複数のフィーチャに関連付けて、代替名テーブルの Join ID フィールドにある一意のレコードへのリンクに使用できます。 これらは、プライマリ参照データと代替名テーブルの多対多または多対 1 のリレーションシップである必要があります。 プライマリ管理フィーチャに複数の名前がある場合は、同じフィーチャの代替管理名の代替名テーブルにある Join ID フィールドには、次に示す一意の ID 値と同じ値を入力する必要があります。

近郊に同じ ID で複数の代替名がある場合の近郊の行政区域
注意:

ロケーターを構築する際、プライマリ参照データの ObjectID と代替名テーブルを結合 ID ロケーター ロール フィールドにマッピングしないでください。 ObjectID を使用するとロケーターのサイズが大きくなり、バッチ ジオコーディングの性能とジオコーディング品質が低下します。

ロケーターで重複ジオメトリを削除するには、同じ位置にある重複フィーチャ同士を結び付ける ID フィールドもフィーチャクラスに含まれている必要があります。 この「処理」により、ロケーターのサイズが削減され、ジオコーディング結果から過剰な一致候補が削除されます。 この ID フィールドをロケーター ロールの [フィーチャ ID] フィールド (REGION_FEATURE_ID など) にマッピングする必要があります。

その他のロール属性

ロケーターを作成」する際のロケーター ロールのリストに、それぞれのロケーター ロールを区別するための他の属性があります。

結合 ID フィールド

テーブルを使用して、参照データ フィーチャクラス内のフィーチャに対して代替名を指定することができます。 ストリートの代替名を使用すると、フィーチャに指定された複数の名前の 1 つを使用して、住所をフィーチャに一致させることができます。 たとえば、Bridge Street が Slash Road とも呼ばれている場合は、266 Bridge Street を使用して見つかるものと同じ住所を 266 Slash Road を使用して見つけることができます。

プライマリ フィーチャクラスには、各レコードについて ID 値が入るフィールドが必要です。 この ID をプライマリ フィーチャクラス内の複数のフィーチャに関連付けて、代替名テーブルの Join ID フィールドにある一意のレコードへのリンクに使用できます。 これらは、プライマリ フィーチャクラスと代替名テーブルの多対多または多対 1 のリレーションシップである必要があります。 プライマリ フィーチャクラスには、各レコードに一意の ID 値を格納するフィールドが必要であり、このフィールドを使用すると、代替名テーブルから結合 ID にリンクすることができます。

注意:

ロケーターを構築する際、プライマリ参照データの ObjectID と代替名テーブルを結合 ID ロケーター ロール フィールドにマッピングしないでください。 ObjectID を使用するとロケーターのサイズが大きくなり、バッチ ジオコーディングの性能とジオコーディング品質が低下します。

行政区域フィールド

ロールごとに、市、州、郵便番号などの行政区域フィールドがあります。これらのフィールドは、正確な一致の可能性をさらに高くするために使用する必要があります。 複数の区域にまたがる長いストリートも存在します。たとえば、米国イリノイ州シカゴの Lake Shore Drive は市を横断し、5 つを超える郵便番号にまたがっています。 上記の例にあるように、郵便番号なしでストリート住所だけをジオコーディングすると、どれが正確かを判断できない複数の一致が返されます。

カスタム出力フィールド

それぞれのロケーター ロールで、ロケーターにカスタム出力フィールドをさらに追加できます。 これらのフィールドはオプションです。 参照フィーチャクラスから任意のフィールドを選択し、カスタム出力フィールドとして含めることができます。 追加フィールドが指定されたロケーターを使用して住所を検索すると、参照データ内の対応するフィールドの情報が住所の候補に表示され、出力フィーチャクラスに保存されます。

一般的な例としては、Block ID、特殊識別子、不動産所有者の名前などがあります。 出力フィーチャクラスに保存された追加フィールドを使用して、他の属性テーブルやフィーチャクラスに結合し、さらに空間解析を行うことができます。 この情報は、住所を再照合して、正しい一致を判断するために追加の情報が必要なときにも使用できます。

関連トピック