इस दस्तावेज़ में, ऐसे कई उदाहरण दिए गए हैं जिनमें 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
जितनी ज़्यादा जानकारी नहीं देता. 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, सही फ़ॉर्मैट के लिए भी जानकारी का आकलन करता है.