תיקון כתובת – דוגמאות

במאמר הזה מתוארים כמה תרחישים מהעולם האמיתי שבהם Address Validation API מספק אותות תגובה שמצדיקים התנהגות של תיקון מהמערכת שלכם. הדוגמאות שמופיעות כאן הן להמחשה בלבד. אפשר לקרוא את הסקירה הכללית על זרימת העבודה בקטע יצירת לוגיקת האימות כדי לקבל הקשר.

דוגמאות נפוצות: תיקון

בקטע הזה מתוארות דוגמאות נפוצות שבהן Address Validation API מספק אותות תגובה שמצביעים על מידע כתובת באיכות נמוכה יותר.

חסרים עיר ומיקוד

בדוגמה הזו מוצגת רשומה שכוללת רק את כתובת הרחוב, בלי עיר או מיקוד.

הכרעה לגבי עיר ומיקוד חסרים

בדוגמה שלמטה מודגשים האותות החשובים מהתגובה.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true
}

האותות האלה מצביעים על כתובת שלא ניתן לשלוח אליה, ולכן אפשר לשלוח שאילתה אל addressComponents כדי לקבל מידע נוסף:

{
  "componentName": {
    "text": "21",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "45 40th street",
    "languageCode": "en"
  },
  "componentType": "route",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
},
{
  "componentName": {
    "text": "United States",
    "languageCode": "en"
  },
  "componentType": "country",
  "confirmationLevel": "CONFIRMED"
}

ה-Address Validation API מחזיר רק את המדינה (ארצות הברית) בתור CONFIRMED. הפונקציה מחזירה את כל רכיבי הכתובת האחרים כ-UNCONFIRMED_BUT_PLAUSIBLE, עם השמטות חשובות של הנתונים, כמו יישוב ומיקוד.

חסר מספר בית

בדוגמה הזו חסר מספר בית.

החלטה לגבי מספר בית חסר

{
    "inputGranularity": "PREMISE_PROXIMITY",
    "validationGranularity": "ROUTE",
    "geocodeGranularity": "ROUTE"
}

הערך של validationGranularity הוא ROUTE, מה שמצביע על התאמה לרחוב, אבל אין מספיק מידע כדי להגיע למקום. בנוסף, המאפיין addressComplete חסר בחוות הדעת, ולכן היא false. שאילתה נוספת על האובייקט address חושפת סוג רכיב חסר:

"missingComponentTypes": [
        "street_number"
      ]

דוגמאות למקרים חריגים: תיקון

במקרים מסוימים, הפעולה שצריך לבצע (תיקון, אישור או קבלת כתובת) תלויה בתרחיש העסקי הספציפי. בדוגמאות שלמטה מוצגים תרחישים שלא נכללים באף אחת מהקטגוריות של תיקונים.

מספר בית לא מאומת

בתרחיש הזה, Address Validation API לא יכול לאשר את מספר הרחוב שסופק, אבל הוא מציין שהכתובת מלאה.

הכרעה לגבי מספר רחוב לא מאומת

בדוגמה הבאה מודגשים האותות החשובים.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete" : true,
  "hasUnconfirmedComponents": true
}

כדאי לבדוק את השילוב של רמת פירוט של אימות רק לקירוב ברמת המקום עם רכיבים לא מאומתים. שאילתה של המאפיין addressComponents מציגה את componentType הלא מאושרים הבאים:

{
  "componentName": {
    "text": "84",
    "languageCode": "en"
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE"
}

בדוגמה הזו, confirmation_level של street_number מוגדר כ-UNCONFIRMED_BUT_PLAUSIBLE. לא אושר – השירות לא הצליח למצוא התאמה למספר הרחוב 84 במערך הנתונים שלו, וסביר – נתוני הרכיב עדיין יכולים להיות תקפים.

חסר מיקום משני

בתרחיש הזה מתוארת כתובת שחסר בה רק פרט משני, כמו מספר דירה או מספר מחלקה. אחרת, ה-Address Validation API יכול לאמת את הכתובת באופן מלא. כמו במקרים שבהם חסר רכיב כלשהו בכתובת, הערך של addressComplete הוא false ולכן הוא לא מופיע בבדיקה ידנית של התוצאה.

לדוגמה, נניח שלקוח מזין כתובת תקינה של משרד שומת המקרקעין בעיר סן פרנסיסקו, אבל לא מזין את מספר החדר.

ההחלטה לגבי כתובת משנה חסרה

בדוגמה הזו, המאפיין addressComplete לא מוצג בתוצאת הבדיקה, ולכן התוצאה היא false. לכן, אתם יודעים שלפחות רכיב כתובת אחד לא צפוי, לא נפתר או חסר.

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "hasInferredComponents": true

}

שאילתת address מגלה את הפרטים הבאים:

"missingComponentTypes": [
        "subpremise"
      ]

בבדיקה נוספת, נתוני USPS מספקים קוד dpvConfirmation של D, שגם הוא מציין שחסר מידע על מיקום משני.