इस दस्तावेज़ में, असल दुनिया की कई स्थितियों के बारे में बताया गया है. इनमें Address Validation API, उन पतों के लिए रिस्पॉन्स सिग्नल देता है जिनके लिए आपके सिस्टम से पुष्टि की ज़रूरत होती है. यहां दिए गए उदाहरणों के अलावा, और भी उदाहरण हो सकते हैं. ज़्यादा जानकारी के लिए, पुष्टि करने का लॉजिक बनाएं में जाकर, वर्कफ़्लो की खास जानकारी देखें.
सामान्य उदाहरण: पुष्टि करना
यहां दिए गए उदाहरण में, एक जैसे नाम वाली सड़कों वाले मेट्रोपॉलिटन इलाकों के बारे में बताया गया है. मान लें कि कोई उपयोगकर्ता, अमेरिका के वॉशिंगटन के कर्कलैंड में मौजूद Google Building D का पता डालना चाहता है. हालांकि, शहर के तौर पर किर्कलैंड के बजाय, वे गलती से सिऐटल डाल देते हैं.
| डाला गया पता | क्षेत्र |
|---|---|
| Building 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, इनपुट में दी गई ग्रैन्युलैरिटी है. जवाब में, पुष्टि नहीं किए गए और बदले गए कॉम्पोनेंट भी शामिल हैं. इसलिए, इस कॉम्बिनेशन को पुष्टि करें कैटगरी में रखा जाता है.
पते के कॉम्पोनेंट की क्वेरी से, इन समस्याओं का पता चलता है:
{
"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 को सिऐटल में दिए गए पते से काफ़ी मिलता-जुलता पता मिला. साथ ही, इसने पिन कोड को बदल दिया, जो कि एक हाई-लेवल कॉम्पोनेंट है. ऐसा सिऐटल के पते को ठीक करने के लिए किया गया. यह एक मान्य बदलाव हो सकता है. हालांकि, कॉम्पोनेंट की पुष्टि नहीं होने की वजह से, यह पक्का करना ज़रूरी है कि उपयोगकर्ता ने सिएटल का पता डाला हो, न कि किसी और जगह का, जैसे कि किर्कलैंड.
कभी-कभार आने वाले मामलों के उदाहरण: पुष्टि करना
यहां दिए गए उदाहरणों में, एज केस के इन टाइप के बारे में बताया गया है:
- नाबालिग होने के ऐसे अनुमान जिनकी पुष्टि हो चुकी है. Address Validation API, देश, पिन कोड या राज्य का अनुमान लगाता है. हालांकि, बाकी सभी जानकारी दी जाती है और उसकी पुष्टि की जाती है. बारीकी और पुष्टि के लेवल के कॉम्बिनेशन से, एक छोटा अनुमान लगाया जाता है. इसके लिए, पुष्टि करने की कार्रवाई ज़रूरी नहीं है.
- पते के ऐसे कॉम्पोनेंट की पुष्टि नहीं की गई है जिसकी उम्मीद नहीं थी. पते के जिन कॉम्पोनेंट की पुष्टि नहीं हुई है उनसे पते के जोखिम का लेवल बढ़ जाता है. इसके लिए, पुष्टि करने की ज़रूरत पड़ सकती है.
- पते का ऐसा कॉम्पोनेंट जिसकी पुष्टि हो चुकी है, लेकिन वह सही नहीं है. किसी पते को सही तरीके से लिखने के लिए, यह कॉम्पोनेंट ज़रूरी नहीं है. साथ ही, Address Validation API इसे आउटपुट से हटा देता है. फ़ॉर्मैटिंग से जुड़ी समस्याओं के लिए, आम तौर पर पुष्टि करने की ज़रूरत नहीं होती.
ऐसे छोटे-मोटे अनुमान जिनकी पुष्टि हो चुकी है
ज़्यादा जानकारी वाले डेटा के साथ जोड़े जाने पर, एपीआई अब भी सही अनुमान लगा सकता है. भले ही, इनपुट में इनमें से किसी एक तरह का कॉम्पोनेंट मौजूद न हो:
- शहर
- राज्य
- पिन कोड
- देश
उदाहरण के लिए, कोई ग्राहक स्प्रिंगफ़ील्ड, मैसाचुसेट्स में McDonald's रेस्टोरेंट के लिए मोहल्ले का मान्य पता देता है, लेकिन शहर का नाम डालना भूल जाता है. साथ ही, चार अंकों के एक्सटेंशन के बिना पिन कोड देता है.
| डाला गया पता | क्षेत्र |
|---|---|
| 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-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, जानकारी के सही फ़ॉर्मैट की भी जांच करता है.