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