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

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

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

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

डाला गया पता क्षेत्र
बिल्डिंग D, 451 7th Avenue South, Seattle, WA 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"
    ]

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

कभी-कभी होने वाले मामले के उदाहरण: पुष्टि करना

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

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

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

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

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

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

डाला गया पता क्षेत्र
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
}

पते के किसी ऐसे घटक की पुष्टि नहीं की गई है जो आम तौर पर नहीं होता

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

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

डाला गया पता क्षेत्र
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
}

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

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

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

डाला गया पता क्षेत्र
33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP यूनाइटेड किंगडम

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

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

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

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

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