این سند تعدادی از سناریوهای دنیای واقعی را توضیح میدهد که در آن Address Validation API سیگنالهای پاسخی را برای آدرسهایی ارائه میدهد که رفتار تأیید را از سیستم شما تضمین میکنند. نمای کلی گردش کار را در Build your validation logic for context ببینید.
مثال های رایج: تایید
مثال زیر مورد کلان شهرها با نام خیابان های مشابه را نشان می دهد. فرض کنید کاربری قصد دارد آدرس ساختمان D Google را در Kirkland، WA، ایالات متحده وارد کند. با این حال، به جای کرکلند به عنوان شهر، آنها به طور ناخواسته وارد سیاتل می شوند.
آدرس وارد شد | منطقه |
---|---|
ساختمان D، 451 خیابان هفتم جنوبی، سیاتل، WA 98033 | ایالات متحده |
حکم برای داده های جایگزین شده
مثال زیر بر سیگنال های مهم از پاسخ تاکید می کند.
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
PREMISE_PROXIMITY
نشاندهنده نزدیکی یک آدرس در سطح ساختمان است، اما به اندازه SUB_PREMISE
نیست، که جزئیات ارائه شده در ورودی است. پاسخ همچنین شامل هر دو مؤلفه تأیید نشده و جایگزین شده است، بنابراین ترکیب این را در دسته تأیید قرار می دهد.
یک پرس و جو از اجزای آدرس، زمینه های نگرانی زیر را نشان می دهد:
{
"componentName": {
"text": "451",
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
"componentName": {
"text": "98104",
},
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
}
...
{
"componentName": {
"text": "Building D",
"language_code": "en"
},
"componentType": "subpremise",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......
"unconfirmedComponentTypes": [
"street_number",
"subpremise"
]
در این مورد، Address Validation API تقریبی نزدیک به آدرس ارائه شده در سیاتل پیدا کرد و کد پستی را که یک جزء سطح بالاتر بود، جایگزین کرد تا به آدرس سیاتل حل شود. این می تواند جایگزین معتبری باشد، اما در کنار این واقعیت که مؤلفه ها تأیید نشده بودند، منطقی است که اطمینان حاصل شود که کاربر قصد دارد یک آدرس سیاتل را وارد کند و نه چیز دیگری مانند Kirkland.
مثال های حاشیه ای: تایید
مثالهای زیر انواع لبههای زیر را نشان میدهند:
- استنباط های جزئی که تایید شده اند . Address Validation API یا کشور، کد پستی یا ایالت را استنباط می کند، اما بقیه موارد هم ارائه شده و هم تأیید شده است. ترکیبی از هر دو سطح دانه بندی و تأیید، استنتاج جزئی را ایجاد می کند که لزوماً نیازی به اقدام تأیید ندارد.
- مؤلفه آدرس غیرمنتظره تأیید نشد . اجزای آدرس تایید نشده به سطح ریسک آدرس اضافه می کنند. این ممکن است تأیید را تضمین کند.
- مؤلفه آدرس غیرمنتظره که IS تأیید شده است . کامپوننت به شدت برای یک آدرس مناسب مورد نیاز نیست و Address Validation API آن را از خروجی حذف می کند. مشکلات قالب بندی معمولاً تأیید را تضمین نمی کند.
استنباط های جزئی که تایید شده اند
هنگامی که با دادههای تایید شده در سطح دانهایتر ترکیب میشود، اگر ورودی فقط یک جزء از انواع زیر را نداشته باشد، API همچنان میتواند استنتاج درستی داشته باشد:
- شهر
- ایالت
- کد پستی
- کشور
به عنوان مثال، مشتری یک آدرس خیابان معتبر برای رستوران مک دونالد در اسپرینگفیلد، ماساچوست ارائه می دهد، اما فراموش می کند که وارد شهر شود و یک کد پستی بدون پسوند 4 رقمی ارائه می دهد.
آدرس وارد شد | منطقه |
---|---|
1402 Allen St, MA 01118 | ایالات متحده |
حکم شهر مفقود شده
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
در شرایطی که Address Validation API اجزای سطح بالاتر را به منظور تولید یک آدرس قابل تحویل استنباط میکند، میتوانید سطح اطمینان بیشتری نسبت به صحیح بودن دادههای سیستم داشته باشید. این به این دلیل است که مؤلفههای استنباطشده که یک منطقه جغرافیایی وسیع را نشان میدهند، راحتتر با مؤلفههای آدرس تأیید شده که دانهبندیتر هستند مطابقت دارند. حتی در کشورهایی که نام شهرها تکرار می شود، مانند اسپرینگفیلد در ایالات متحده، سایر اجزای ترکیبی با آن می تواند یک آدرس منحصر به فرد ارائه دهد.
با استفاده از مثال بالا، اسکن تمام اجزای آدرس نشان می دهد که هر مؤلفه تأیید شده است، به این معنی که با داده های ذخیره شده توسط Address Validation API مطابقت دارد، و این سرویس همچنین دو مؤلفه سطح بالاتر را استنباط می کند.
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
مؤلفه آدرس غیرمنتظره تأیید نشد
این سناریو اهمیت بررسی زمانی که مؤلفه ها تأیید نشده اند را نشان می دهد. اگر یک جزء آدرس غیرمنتظره باشد، Address Validation API آن را از خروجی حذف می کند. در این موارد، بسته به سطح ریسک و سطح اطمینان خود، میتوانید آدرس را بپذیرید یا آن را مجدداً با مشتری تأیید کنید.
به عنوان مثال، یک آدرس ممکن است از منطقه ای باشد که مشتریان اغلب اطلاعات بی ضرری را وارد می کنند که توسط اداره پست نادیده گرفته می شود، در این صورت شما آدرس را می پذیرید. با این حال، در برخی موارد ممکن است یک جزء تایید نشده آن چیزی نباشد که مشتری می خواهد.
آدرس وارد شد | منطقه |
---|---|
1 Rue Grenache, la caritat 2, 34630 Saint-Thibery | فرانسه |
حکم برای مؤلفه آدرس غیرمنتظره تأیید نشد
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
علاوه بر یک حکم با مؤلفههای تأیید نشده، Address Validation API آدرس قالببندی شده زیر را برمیگرداند:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
اسکن برای اجزای تأیید نشده نشان می دهد که API la caritat 2 را از آدرس برگشتی حذف کرده است:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
مؤلفه آدرس غیرمنتظره ای که IS تأیید کرده است
این مثال گنجاندن یک شهرستان بریتانیا در آدرس ارائه شده را نشان می دهد که یک روش معمول است. با این حال، این یک الزام توسط اداره پست بریتانیا نیست و اساسا نادیده گرفته می شود. به postoffice.co.uk و نحوه آدرس دهی نامه های بریتانیا و بین المللی مراجعه کنید.
در نتیجه، وقتی مشتری یک شهرستان را در یک آدرس بریتانیا ارائه میکند، سرویس این را به عنوان ورودی غیرمنتظره ارزیابی میکند.
آدرس وارد شد | منطقه |
---|---|
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | انگلستان |
حکم برای مؤلفه آدرس غیرمنتظره که تأیید شده است
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
در اینجا، address_complete
به false ارزیابی میشود و تجزیه و تحلیل جزء آدرس، پرچم غیرمنتظرهای را نشان میدهد.
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
در حالی که Gloucestershire شهرستان صحیح برای آدرس وارد شده است، خود آدرس به درستی قالب بندی شده است. به یاد داشته باشید که Address Validation API نیز اطلاعات را برای قالب بندی مناسب ارزیابی می کند.
،این سند تعدادی از سناریوهای دنیای واقعی را توضیح میدهد که در آن Address Validation API سیگنالهای پاسخی را برای آدرسهایی ارائه میدهد که رفتار تأیید را از سیستم شما تضمین میکنند. نمای کلی گردش کار را در Build your validation logic for context ببینید.
مثال های رایج: تایید
مثال زیر مورد کلان شهرها با نام خیابان های مشابه را نشان می دهد. فرض کنید کاربری قصد دارد آدرس ساختمان D Google را در Kirkland، WA، ایالات متحده وارد کند. با این حال، به جای کرکلند به عنوان شهر، آنها به طور ناخواسته وارد سیاتل می شوند.
آدرس وارد شد | منطقه |
---|---|
ساختمان D، 451 خیابان هفتم جنوبی، سیاتل، WA 98033 | ایالات متحده |
حکم برای داده های جایگزین شده
مثال زیر بر سیگنال های مهم از پاسخ تاکید می کند.
{
"inputGranularity": "SUB_PREMISE",
"validationGranularity": "PREMISE_PROXIMITY",
"geocodeGranularity": "PREMISE_PROXIMITY",
"addressComplete": true,
"hasUnconfirmedComponents": true
"hasReplacedComponents": true
}
PREMISE_PROXIMITY
نشاندهنده نزدیکی یک آدرس در سطح ساختمان است، اما به اندازه SUB_PREMISE
نیست، که جزئیات ارائه شده در ورودی است. پاسخ همچنین شامل هر دو مؤلفه تأیید نشده و جایگزین شده است، بنابراین ترکیب این را در دسته تأیید قرار می دهد.
یک پرس و جو از اجزای آدرس، زمینه های نگرانی زیر را نشان می دهد:
{
"componentName": {
"text": "451",
},
"componentType": "street_number",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
"componentName": {
"text": "98104",
},
"componentType": "postal_code",
"confirmationLevel": "CONFIRMED",
"replaced": true
}
...
{
"componentName": {
"text": "Building D",
"language_code": "en"
},
"componentType": "subpremise",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......
"unconfirmedComponentTypes": [
"street_number",
"subpremise"
]
در این مورد، Address Validation API تقریبی نزدیک به آدرس ارائه شده در سیاتل پیدا کرد و کد پستی را که یک جزء سطح بالاتر بود، جایگزین کرد تا به آدرس سیاتل حل شود. این می تواند جایگزین معتبری باشد، اما در کنار این واقعیت که مؤلفه ها تأیید نشده بودند، منطقی است که اطمینان حاصل شود که کاربر قصد دارد یک آدرس سیاتل را وارد کند و نه چیز دیگری مانند Kirkland.
مثال های حاشیه ای: تایید
مثالهای زیر انواع لبههای زیر را نشان میدهند:
- استنباط های جزئی که تایید شده اند . Address Validation API یا کشور، کد پستی یا ایالت را استنباط می کند، اما بقیه موارد هم ارائه شده و هم تأیید شده است. ترکیبی از هر دو سطح دانه بندی و تأیید، استنتاج جزئی را ایجاد می کند که لزوماً نیازی به اقدام تأیید ندارد.
- مؤلفه آدرس غیرمنتظره تأیید نشد . اجزای آدرس تایید نشده به سطح ریسک آدرس اضافه می کنند. این ممکن است تأیید را تضمین کند.
- مؤلفه آدرس غیرمنتظره که IS تأیید شده است . کامپوننت به شدت برای یک آدرس مناسب مورد نیاز نیست و Address Validation API آن را از خروجی حذف می کند. مشکلات قالب بندی معمولاً تأیید را تضمین نمی کند.
استنباط های جزئی که تایید شده اند
هنگامی که با دادههای تایید شده در سطح دانهایتر ترکیب میشود، اگر ورودی فقط یک جزء از انواع زیر را نداشته باشد، API همچنان میتواند استنتاج درستی داشته باشد:
- شهر
- ایالت
- کد پستی
- کشور
به عنوان مثال، مشتری یک آدرس خیابان معتبر برای رستوران مک دونالد در اسپرینگفیلد، ماساچوست ارائه می دهد، اما فراموش می کند که وارد شهر شود و یک کد پستی بدون پسوند 4 رقمی ارائه می دهد.
آدرس وارد شد | منطقه |
---|---|
1402 Allen St, MA 01118 | ایالات متحده |
حکم شهر مفقود شده
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"addressComplete": true,
"hasInferredComponents": true
}
در شرایطی که Address Validation API اجزای سطح بالاتر را به منظور تولید یک آدرس قابل تحویل استنباط میکند، میتوانید سطح اطمینان بیشتری نسبت به صحیح بودن دادههای سیستم داشته باشید. این به این دلیل است که مؤلفههای استنباطشده که یک منطقه جغرافیایی وسیع را نشان میدهند، راحتتر با مؤلفههای آدرس تأیید شده که دانهبندیتر هستند مطابقت دارند. حتی در کشورهایی که نام شهرها تکرار می شود، مانند اسپرینگفیلد در ایالات متحده، سایر اجزای ترکیبی با آن می تواند یک آدرس منحصر به فرد ارائه دهد.
با استفاده از مثال بالا، اسکن تمام اجزای آدرس نشان می دهد که هر مؤلفه تأیید شده است، به این معنی که با داده های ذخیره شده توسط Address Validation API مطابقت دارد، و این سرویس همچنین دو مؤلفه سطح بالاتر را استنباط می کند.
{
"componentName": {
"text": "Springfield",
"languageCode": "en"
},
"componentType": "locality",
"confirmationLevel": "CONFIRMED",
"inferred": true
},
{
"componentName": {
"text": "1806"
},
"componentType": "postal_code_suffix",
"confirmationLevel": "CONFIRMED",
"inferred": true
}
مؤلفه آدرس غیرمنتظره تأیید نشد
این سناریو اهمیت بررسی زمانی که مؤلفه ها تأیید نشده اند را نشان می دهد. اگر یک جزء آدرس غیرمنتظره باشد، Address Validation API آن را از خروجی حذف می کند. در این موارد، بسته به سطح ریسک و سطح اطمینان خود، میتوانید آدرس را بپذیرید یا آن را مجدداً با مشتری تأیید کنید.
به عنوان مثال، یک آدرس ممکن است از منطقه ای باشد که مشتریان اغلب اطلاعات بی ضرری را وارد می کنند که توسط اداره پست نادیده گرفته می شود، در این صورت شما آدرس را می پذیرید. با این حال، در برخی موارد ممکن است یک جزء تایید نشده آن چیزی نباشد که مشتری می خواهد.
آدرس وارد شد | منطقه |
---|---|
1 Rue Grenache, la caritat 2, 34630 Saint-Thibery | فرانسه |
حکم برای مؤلفه آدرس غیرمنتظره تأیید نشد
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
علاوه بر یک حکم با مؤلفههای تأیید نشده، Address Validation API آدرس قالببندی شده زیر را برمیگرداند:
"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",
اسکن برای اجزای تأیید نشده نشان می دهد که API la caritat 2 را از آدرس برگشتی حذف کرده است:
{
"componentName": {
"text": "la caritat 2",
"languageCode": "fr"
},
"componentType": "sublocality_level_1",
"confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
"unexpected": true
}
مؤلفه آدرس غیرمنتظره ای که IS تأیید کرده است
این مثال گنجاندن یک شهرستان بریتانیا در آدرس ارائه شده را نشان می دهد که یک روش معمول است. با این حال، این یک الزام توسط اداره پست بریتانیا نیست و اساسا نادیده گرفته می شود. به postoffice.co.uk و نحوه آدرس دهی نامه های بریتانیا و بین المللی مراجعه کنید.
در نتیجه، وقتی مشتری یک شهرستان را در یک آدرس بریتانیا ارائه میکند، سرویس این را به عنوان ورودی غیرمنتظره ارزیابی میکند.
آدرس وارد شد | منطقه |
---|---|
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP | انگلستان |
حکم برای مؤلفه آدرس غیرمنتظره که تأیید شده است
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
در اینجا، address_complete
به false ارزیابی میشود و تجزیه و تحلیل جزء آدرس، پرچم غیرمنتظرهای را نشان میدهد.
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
در حالی که Gloucestershire شهرستان صحیح برای آدرس وارد شده است، خود آدرس به درستی قالب بندی شده است. به یاد داشته باشید که Address Validation API نیز اطلاعات را برای قالب بندی مناسب ارزیابی می کند.