इस पेज का अनुवाद Cloud Translation API से किया गया है.

पते की पुष्टि करें - उदाहरण

इस दस्तावेज़ में, असल दुनिया के कई ऐसे उदाहरणों के बारे में बताया गया है जहां पता की पुष्टि करने वाला एपीआई, उन पतों के लिए जवाब के सिग्नल देता है जिनके लिए आपके सिस्टम को पुष्टि करने की ज़रूरत होती है. संदर्भ के लिए, पुष्टि करने का लॉजिक बनाएं में वर्कफ़्लो की खास जानकारी देखें.

सामान्य उदाहरण: पुष्टि करें

इस उदाहरण में, एक जैसे सड़क के नाम वाले मेट्रोपॉलिटन इलाकों के बारे में बताया गया है. मान लें कि कोई उपयोगकर्ता किर्कलैंड, वॉशिंगटन, अमेरिका में Google बिल्डिंग D का पता डालना चाहता है. हालांकि, शहर के तौर पर किर्कलैंड के बजाय, वे गलती से सिऐटल डाल देते हैं.

पता डाला गया	क्षेत्र
बिल्डिंग डी, 451 7वां एवेन्यू साउथ, सिऐटल, वॉशिंगटन 98033	अमेरिका

बदले गए डेटा के लिए फ़ैसला

नीचे दिए गए उदाहरण में, रिस्पॉन्स से मिले अहम सिग्नल पर ज़ोर दिया गया है.

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

PREMISE_PROXIMITY, बिल्डिंग के लेवल के पते के आस-पास के बारे में बताता है. हालांकि, इसमें SUB_PREMISE के मुकाबले ज़्यादा जानकारी नहीं होती. 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 को सिएटल में दिए गए पते से मिलता-जुलता एक अनुमान मिला. इस एपीआई की मदद से, सिऐटल के पते वाले पते पर पहुंचने के लिए, पिन कोड को बदल दिया गया. यह एक हाई-लेवल कॉम्पोनेंट है. यह एक मान्य विकल्प हो सकता है. हालांकि, कॉम्पोनेंट की पुष्टि नहीं की गई थी. इसलिए, यह पक्का करना ज़रूरी है कि उपयोगकर्ता का मकसद सिएटल का पता डालना है, न कि किर्कलैंड जैसा कोई दूसरा पता.

एज-केस के उदाहरण: पुष्टि करें

यहां दिए गए उदाहरणों में, अलग-अलग तरह के एज केस के बारे में बताया गया है:

ऐसे छोटे-मोटे अनुमान जिनकी पुष्टि हो चुकी है. पते की पुष्टि करने वाला एपीआई, देश, पिन कोड या राज्य का अनुमान लगाता है. हालांकि, बाकी सभी जानकारी दी जाती है और उसकी पुष्टि की जाती है. ज़्यादा जानकारी और पुष्टि के लेवल, दोनों के कॉम्बिनेशन से एक छोटा सा अनुमान लगाया जाता है. इसके लिए, पुष्टि करने की ज़रूरत नहीं होती.
पते के अनचाहे कॉम्पोनेंट की पुष्टि नहीं की गई. पते के ऐसे कॉम्पोनेंट जिनकी पुष्टि नहीं हुई है, पते के जोखिम के लेवल को बढ़ाते हैं. इसकी पुष्टि करना ज़रूरी हो सकता है.
पते का ऐसा अनचाहा कॉम्पोनेंट जिसकी पुष्टि हो चुकी है. सही पते के लिए कॉम्पोनेंट की ज़रूरत नहीं होती है और पते की पुष्टि करने वाला एपीआई इसे आउटपुट से हटा देता है. आम तौर पर, फ़ॉर्मैट से जुड़ी समस्याओं की पुष्टि की ज़रूरत नहीं होती.

ऐसे छोटे-मोटे अनुमान जिनकी पुष्टि हो चुकी है

ज़्यादा जानकारी वाले पुष्टि किए गए डेटा के साथ जोड़े जाने पर, एपीआई अब भी सही अनुमान लगा सकता है. ऐसा तब होता है, जब इनमें से किसी एक कॉम्पोनेंट का इनपुट मौजूद न हो:

शहर
स्थिति
पिन कोड
देश

उदाहरण के लिए, कोई ग्राहक मैसाचुसेट्स के स्प्रिंगफ़ील्ड में मौजूद मैकडॉनल्ड्स रेस्टोरेंट का मान्य पता देता है, लेकिन शहर की जानकारी नहीं देता. साथ ही, वह चार अंकों के एक्सटेंशन के बिना पिन कोड देता है.

डाला गया पता	क्षेत्र
1402 Allen St, MA 01118	अमेरिका

शहर की जानकारी मौजूद न होने पर मिलने वाला फ़ैसला

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

जिन मामलों में पते की पुष्टि करने वाला एपीआई, डिलीवर किए जा सकने वाले पते का पता लगाने के लिए, बेहतर लेवल के कॉम्पोनेंट का अनुमान लगाता है उनमें आपको इस बात का ज़्यादा भरोसा हो सकता है कि सिस्टम का डेटा सही है. ऐसा इसलिए होता है, क्योंकि अनुमानित घटक, बड़े भौगोलिक इलाके को दिखाते हैं. इसलिए, इन्हें पुष्टि किए गए पते के घटकों से आसानी से मैच किया जा सकता है. जिन देशों में शहरों के नाम दोहराए जाते हैं, जैसे कि अमेरिका में स्प्रिंगफ़ील्ड, वहां भी शहर के नाम के साथ अन्य कॉम्पोनेंट जोड़कर यूनीक पता दिया जा सकता है.

ऊपर दिए गए उदाहरण का इस्तेमाल करके, पते के सभी कॉम्पोनेंट को स्कैन करने पर पता चलता है कि हर कॉम्पोनेंट की पुष्टि हो चुकी है. इसका मतलब है कि यह पते की पुष्टि करने वाले एपीआई से सेव किए गए डेटा से मेल खाता है. साथ ही, यह सेवा दो उच्च-लेवल के कॉम्पोनेंट का भी अनुमान लगाती है.

{
  "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-Thibéry	फ़्रांस

अनपेक्षित पता घटक के लिए निर्णय की पुष्टि नहीं हुई है

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "unconfirmedComponents": true
}

जिन कॉम्पोनेंट की पुष्टि नहीं हुई है उनके नतीजे के अलावा, Address Validation API इस फ़ॉर्मैट में दिया गया पता दिखाता है:

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

पुष्टि नहीं किए गए कॉम्पोनेंट के लिए स्कैन करने पर पता चलता है कि एपीआई ने दिखाए गए पते से la caritat 2 को हटा दिया है:

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

कार्रवाई: पुष्टि करें. इस मामले में, उप-इलाके की जानकारी सही हो सकती है. इससे किसी हाउसिंग डिस्ट्रिक्ट या आस-पास के इलाके का पता चल सकता है. इसके बावजूद, डाक विभाग इस जानकारी को अनदेखा कर सकता है. हालांकि, Address Validation API से इस जानकारी की पुष्टि **नहीं** होती है. इसलिए, ग्राहक से इसकी पुष्टि करना सही होता है. इस समय, आपके पास कॉन्टेंट हटाने के अनुरोध को अनदेखा करने या उसकी पुष्टि करने का विकल्प होता है.

अनचाहा पता, जिसकी पुष्टि हो चुकी है

इस उदाहरण में, दिए गए पते में यूके के एक काउंटी को शामिल किया गया है, जो एक आम बात है. हालांकि, यूके की डाक विभाग की ओर से ऐसा करना ज़रूरी नहीं है और आम तौर पर इस बात को अनदेखा कर दिया जाता है. postoffice.co.uk और यूनाइटेड किंगडम और अंतरराष्ट्रीय मेल के लिए पता लिखने का तरीका देखें.

इस वजह से, जब कोई ग्राहक यूनाइटेड किंगडम के किसी देश/इलाके का नाम मुहैया कराता है, तो कंपनी उसे अनचाही जानकारी के तौर पर मानती है.

डाला गया पता	क्षेत्र
33 डनली स्ट्रीट, चेल्टनहम, ग्लॉस्टरशायर, GL50 4AP	यूनाइटेड किंगडम

ऐसे पते के कॉम्पोनेंट के लिए फ़ैसला जिसकी पुष्टि की जा चुकी है

{
   "inputGranularity": "PREMISE",
   "validationGranularity": "PREMISE",
   "geocodeGranularity": "PREMISE"
}

यहां, address_complete गलत पर आकलन करता है और पता कॉम्पोनेंट के विश्लेषण में एक अनचाहा फ़्लैग दिखता है.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

डाले गए पते के लिए, ग्लूस्टरशायर सही काउंटी है. हालांकि, पते का फ़ॉर्मैट गलत है. याद रखें कि पते की पुष्टि करने वाला एपीआई, सही फ़ॉर्मैटिंग के लिए जानकारी का आकलन भी करता है.