これは注意が必要です。住所にはグローバルな標準がなく、パラメータを使用してあいまい検索を呼び出さない限り、構造化された住所の部分のマッピング (修飾された入力の例を参照) が一致する必要があるためです。&additionaldata=FlexibleAdminValues
ユースケースを順番に取り上げると、次のように自由形式の入力を使用して、最も単純なリクエストと最も広範な結果セットを取得できます。
出力からわかるように、ラベルには住所 (必ずしもすべての階層情報が含まれているとは限りません) が保持されますが、State、County、City、Districtなどには構造化された住所の一部が保持されます (少なくともHERE のデータベースにある形式)。したがって、クエリで正しい City または State を使用することにより、クエリの範囲を縮小できます。
<Address>
<Label>Sonora 12AV, Aculco, 09410 Iztapalapa, Distrito Federal, México</Label><Country>MEX</Country>
<State>Distrito Federal</State>
<County>Ciudad de México</County>
<City>Iztapalapa</City>
<District>Aculco</District>
<Street>Sonora</Street>
<HouseNumber>12AV</HouseNumber>
<PostalCode>09410</PostalCode>
<AdditionalData key="CountryName">México</AdditionalData>
<AdditionalData key="StateName">Distrito Federal</AdditionalData>
</Address>
正しい国は既にわかっているため、検索を 1 つの国に追加&country=Mexico
または&country=Brazil
制限することができます (不明な場合は、countryfocus
パラメーターを使用して、代わりにその国に結果をバイアスします。
市や地区 などがわかっている場合は、より限定的な検索を行うことができます。
十分な情報が提供されているため、これでも単一の結果が見つかります。
つまり、構造化された住所を使用して結果の誤検出を減らす前に、各国でいくつかの自由形式のサンプル住所を試し、searchText
その国でどのフィールドが使用されているかを確認することをお勧めします。
Geocoding ResultsのXSD スキーマも、特にMatchedAddressNamesTypeのセクションで役立ちます。