इस दस्तावेज़ में असल दुनिया की ऐसी कई स्थितियों के बारे में बताया गया है जहां पते की पुष्टि करने वाला एपीआई, उन पतों के लिए रिस्पॉन्स सिग्नल देता है जिनके लिए आपके सिस्टम से पुष्टि करें के व्यवहार की ज़रूरत होती है. कॉन्टेक्स्ट के लिए, पुष्टि करने वाला लॉजिक बनाएं सेक्शन में, वर्कफ़्लो के बारे में खास जानकारी देखें.
सामान्य उदाहरण: पुष्टि करना
नीचे दिए गए उदाहरण में एक जैसे नाम वाले महानगरीय क्षेत्रों का मामला दिखाया गया है. मान लें कि कोई उपयोगकर्ता Google बिल्डिंग D का पता किर्कलैंड, वॉशिंगटन, अमेरिका डालना चाहता है. हालांकि, कर्कलैंड को शहर बनाने के बजाय, वे अनजाने में मुंबई में पहुंच जाते हैं.
पता डाला गया | इलाका |
---|---|
बिल्डिंग डी, 451 सातवीं एवेन्यू साउथ, सिएटल, डब्ल्यूए 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 Verified API, इसे आउटपुट से हटा देता है. आम तौर पर, फ़ॉर्मैटिंग से जुड़ी समस्याओं के लिए पुष्टि करना ज़रूरी नहीं होता.
छोटे अनुमान, जिनकी पुष्टि की गई है
ज़्यादा जानकारी वाले लेवल के पुष्टि किए गए डेटा के साथ इस्तेमाल करने पर भी, एपीआई सही अनुमान लगा सकता है. ऐसा तब होता है, जब इनपुट में नीचे दिए गए टाइप का सिर्फ़ एक कॉम्पोनेंट मौजूद न हो:
- शहर
- स्थिति
- पिन कोड
- देश
उदाहरण के लिए, कोई ग्राहक मेसाचुसेट्स के स्प्रिंगफ़ील्ड रेस्टोरेंट का मान्य पता देता है, लेकिन शहर का नाम डालना भूल जाता है और चार अंकों वाले एक्सटेंशन के बिना पिन कोड डाल देता है.
पता डाला गया | इलाका |
---|---|
1402 एलन स्ट्रीट, 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 रुए ग्रेनाश, ला कैरिटाट 2, 34630 सेंट-थिबेरी | फ़्रांस |
अनपेक्षित पता घटक के निर्णय की पुष्टि नहीं की गई
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE",
"unconfirmedComponents": true
}
पुष्टि न किए गए कॉम्पोनेंट के नतीजे के अलावा, पते की पुष्टि करने वाला एपीआई, फ़ॉर्मैट किए गए ये पते दिखाता है:
"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 डूनाली स्ट्रीट, चेल्टनहेम, ग्लॉसटरशीयर, GL50 4AP | यूनाइटेड किंगडम |
पते के अनचाहे कॉम्पोनेंट के लिए फ़ैसला, जिसकी पुष्टि हो चुकी है
{
"inputGranularity": "PREMISE",
"validationGranularity": "PREMISE",
"geocodeGranularity": "PREMISE"
}
यहां address_complete
, 'गलत' के तौर पर आकलन करता है और पता कॉम्पोनेंट के विश्लेषण से एक अनचाहा फ़्लैग दिखता है.
{
"componentName": {
"text": "Gloucestershire",
"languageCode": "en"
},
"componentType": "administrative_area_level_2",
"confirmationLevel": "CONFIRMED",
"unexpected": true
}
डाले गए पते के लिए ग्लॉसटरशर सही काउंटी है, लेकिन इस पते को गलत तरीके से फ़ॉर्मैट किया गया है. याद रखें कि पते की पुष्टि करने वाला एपीआई भी सही फ़ॉर्मैट के लिए जानकारी का आकलन करता है.