このドキュメントでは、Address Validation API がシステムのサブプレミス追加動作を正当化するレスポンス シグナルを提供する、さまざまな実際のシナリオについて説明します。これらのシグナルは、米国の住所でのみ使用できます。コンテキストについては、検証ロジックを構築するのワークフローの概要をご覧ください。
一般的な例: サブプレミス追加
このシナリオは、システムが住所に部屋番号を追加するようお客様に求める可能性がある住所を示しています。
入力した住所 | 地域 |
---|---|
1450 Brickell Avenue, Miami, FL 33131-4065 | 米国 |
住所にサブプレミスがない場合に下される判定
次の例では、重要なシグナルがハイライト表示されています。
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}
エッジケースの例: サブプレミス追加
次の例は、verdict
が、さらなる調査が必要な住所の品質の問題を示している場合の状況を示しています。この例は、システム ロジックを強化するために、より完全な画像を取得するために、判定結果から住所コンポーネントにロジックを転送する方法も示しています。
不足しているサブ前提、推定されたコンポーネント、置き換えられたコンポーネント
この例は、地域が指定されておらず、郵便番号が正しくない米国の住所の入力を示しています。
入力した住所 | 地域 |
---|---|
1450 Brickell Avenue, FL 33132-4065 | 米国 |
不足しているサブ前提、推論されたコンポーネント、置換されたコンポーネントの判定結果
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"hasInferredComponents": true,
"hasReplacedComponents": true,
"possibleNextAction": "CONFIRM_ADD_SUBPREMISES"
}
住所の構成要素を詳しく調査した結果、地域が推測され、郵便番号が置き換えられていることが判明しました。
{
"componentName": {
"text": "33131",
}
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
},
{
"componentName": {
"text": "Miami",
"languageCode": "en"
}
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
}