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