मकसद
आपको अक्सर किसी जगह के पते की पुष्टि करने की ज़रूरत पड़ती है. Google Maps Platform में कुछ ऐसी सेवाएं हैं जो इस काम में आपकी मदद कर सकती हैं. इस दस्तावेज़ में, पते की पुष्टि करने वाली दो मुख्य सेवाओं - Address Validation API और Geocoding API के बीच अंतर बताया गया है, ताकि आपको यह तय करने में मदद मिल सके कि आपको कौनसी सेवा इस्तेमाल करनी चाहिए.
Address Validation API, Google Maps Platform की एक सेवा है. इसकी मदद से, ग्राहक यह पुष्टि कर सकते हैं कि कोई पता सही है या नहीं.
Geocoding API की मदद से जियोकोडिंग करने का मतलब है, पतों को भौगोलिक निर्देशांकों में बदलना. इन निर्देशांकों का इस्तेमाल, मैप पर मार्कर लगाने या मैप पर कोई जगह दिखाने के लिए किया जा सकता है.
Address Validation API और Geocoding API के बीच के अंतर के बारे में खास जानकारी यहां देखी जा सकती है.
Address Validation API और Geocoding API में से किसे चुनें

ऊपर दिए गए फ़्लोचार्ट के बारे में जानकारी:
- उपयोगकर्ता के इंटरैक्शन वाले इस्तेमाल के उदाहरण का मतलब है कि उपयोगकर्ता, नतीजों के साथ इंटरैक्ट करने के लिए मौजूद है.
- Places Autocomplete, JavaScript API है. इसलिए, इसे यूज़र इंटरफ़ेस के साथ इंटिग्रेट किया जा सकता है.
- आपको अपने मौजूदा पतों में डेटा क्वालिटी से जुड़ी समस्याओं के बारे में पता हो सकता है. इसलिए, भले ही आपको सिर्फ़ जियोकोड चाहिए हों, लेकिन हमारा सुझाव है कि डेटासेट को ठीक करने के लिए, उन जगहों के लिए Address Validation API का इस्तेमाल करें.
ऊपर दिए गए फ़्लोचार्ट के आधार पर, कई स्थितियों में एक प्रॉडक्ट के बजाय दूसरे प्रॉडक्ट का इस्तेमाल किया जा सकता है. हालांकि, कुछ स्थितियों में अपने लक्ष्यों को पूरा करने के लिए, दोनों प्रॉडक्ट का इस्तेमाल करना पड़ सकता है.
इन स्थितियों में, Geocoding API के बजाय Address Validation API का इस्तेमाल किया जा सकता है:
- जब गलत डेटा मिलने की संभावना ज़्यादा हो या गलत पता मिलने से, आगे की प्रोसेस पर बुरा असर पड़ने की संभावना हो. ऐसा इसलिए, क्योंकि Address Validation API से यह पता चलता है कि किसी इनपुट के लिए सटीक नतीजे क्यों नहीं मिले.
- जब आपको उपयोगकर्ता के इनपुट ठीक करने हों.जैसे, वर्तनी की गड़बड़ियां ठीक करना या छूटे हुए फ़ील्ड भरना. इससे, आउटपुट में सटीक नतीजे मिलने की संभावना बढ़ जाती है.
- जब आपके टारगेट किए गए इलाके के लिए, Address Validation API से Geocoding API के मुकाबले ज़्यादा मेटाडेटा मिलता है. जैसे, बिल्डिंग के टाइप को रिहायशी बनाम व्यावसायिक के तौर पर कैटगरी में बांटना.
इन स्थितियों में, Address Validation API के बजाय Geocoding API का इस्तेमाल किया जा सकता है:
- जब आपका मुख्य मकसद किसी पते की जगह की जानकारी पाना हो और अलग-अलग पतों की सटीक जानकारी पाना ज़रूरी न हो.
- उदाहरण के लिए, हो सकता है कि आपको बड़े डेटासेट से हीटमैप जनरेट करना हो.
- जब आपको हाइपर-लोकल डेस्टिनेशन की जानकारी चाहिए. जैसे, बिल्डिंग के एंट्रेंस, बिल्डिंग की आउटलाइन या पिकअप और ड्रॉप-ऑफ़ के नेविगेशन पॉइंट. ये जानकारी, Geocoding API के चौथे वर्शन में SearchDestinations तरीके से मिलती है.
- जब आपको किसी ग्लोबल सलूशन की ज़रूरत हो और Address Validation API, टारगेट किए गए सभी इलाकों में उपलब्ध न हो.
यहां कुछ उदाहरण दिए गए हैं. इनसे, Geocoding API के मुकाबले Address Validation API की क्षमताओं के बारे में पता चलता है.
अमान्य पते का उदाहरण
1 Fake St, Mountain View, CA 94043, USA
Address Validation API, इस इनपुट को पते के अलग-अलग कॉम्पोनेंट (सड़क, शहर, राज्य वगैरह) में बांट देता है. यह इस बारे में भी सटीक जानकारी दे सकता है कि PREMISE लेवल तक, पता अमान्य क्यों है.
Mountain View, CA में Fake St मौजूद नहीं है. Address Validation API, कॉम्पोनेंट लेवल की जानकारी में यह दिखाता है:
{
"componentName": {
"text": "Fake St",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel":"UNCONFIRMED_BUT_PLAUSIBLE"
}
इस मामले में, confirmationLevel प्रॉपर्टी की जांच करना ज़रूरी है. Fake St के लिए UNCONFIRMED_BUT_PLAUSIBLE दिखाने से, एपीआई ने यह तय किया है कि किसी सड़क का नाम ऐसा हो सकता है. हालांकि, इसे पते के डेटा से मैच नहीं किया जा सका.
एपीआई के नतीजे को फ़ीडबैक के तौर पर इस्तेमाल करके, यह अनुमान लगाया जा सकता है कि इस इनपुट का सड़क वाला कॉम्पोनेंट (Fake St) गलत है.
Geocoding API के साथ इसी पते का इस्तेमाल करने पर, यह “California” से मैच हो जाता है. यह बात, जियोकोडिंग टूल के स्क्रीनशॉट में देखी जा सकती है. इसे यहां आज़माया जा सकता है:

हालांकि, नतीजे में पूरे राज्य का जियोकोड मिलता है. साथ ही, इस बारे में कम जानकारी मिलती है कि इनपुट के कौनसे कॉम्पोनेंट गलत हो सकते हैं.
वर्तनी की गड़बड़ी का उदाहरण
76 Buckingamm Palace Road, Londn, SW1W 9TQ, GB
ऊपर दिए गए पते में, वर्तनी की दो गड़बड़ियां हैं. एक सड़क के नाम में और दूसरी इलाके के नाम में.
Address Validation API और Geocoding API, दोनों इन गड़बड़ियों को ठीक करके, 76 Buckingham Palace Road, London, SW1W 9TQ का नतीजा दे सकते हैं. हालांकि, Address Validation API, प्रोसेस के बारे में ज़्यादा जानकारी दे सकता है.
पते के उस कॉम्पोनेंट को देखें जिसकी वर्तनी इनपुट में गलत है:
{
"componentName": {
"text": "Buckingham Palace Road",
"languageCode": "en"
},
"componentType": "route",
"confirmationLevel": "CONFIRMED",
"spellCorrected": true
}
}
Address Validation API, एक फ़्लैग दिखाता है. इससे पता चलता है कि फ़ील्ड में सुधार किया गया है. इस फ़्लैग के आधार पर, कारोबार के लॉजिक को लागू किया जा सकता है, ताकि डेटा देने वाले व्यक्ति या कंपनी से सुधार की दोबारा पुष्टि की जा सके. जैसे, ई-कॉमर्स के चेकआउट में कोई ग्राहक.
डेटा मौजूद न होने और वर्तनी की गड़बड़ी का उदाहरण
Bollschestraße 86, 12587, DE
ऊपर दिए गए पते में, सड़क के नाम की वर्तनी गलत है. साथ ही, इसमें बर्लिन शहर (इलाके) का नाम मौजूद नहीं है.
Address Validation API, इन दोनों गड़बड़ियों को ठीक कर सकता है. साथ ही, PREMISE लेवल का जियोकोड और ऐसा पता दिखाता है जिसकी PREMISE लेवल तक पुष्टि की गई है:
Bölschestraße 86, 12587 Berlin, DE
इस मामले में, Geocoding API, इनपुट में मौजूद गड़बड़ियों को ठीक नहीं कर पाता और ZERO_RESULTS का नतीजा दिखाता है.
पते के अतिरिक्त मेटाडेटा का उदाहरण
111 8th Avenue Ste 123, New York, NY 10011-5201, US
यह पता सही है. हालांकि, इसमें यूनिट नंबर (Ste 123) गलत है, क्योंकि यह बिल्डिंग में मौजूद नहीं है.
Address Validation API, PREMISE (111 8th Ave) तक पते की पुष्टि कर सकता है. साथ ही, प्रॉपर्टी के बारे में कुछ मेटाडेटा दे सकता है. इसमें यह भी शामिल है कि यह एक व्यावसायिक
परिसर है:
"business": true
इसके अलावा, रिस्पॉन्स में uspsData के हिस्से के तौर पर दिखाई गई dpvConfirmation की वैल्यू S है:
"dpvConfirmation": "S"
dpvConfirmation की वैल्यू S से पता चलता है कि पते की पुष्टि PREMISE लेवल तक की गई है. हालांकि, इनपुट में दिया गया यूनिट नंबर, उस पते से जुड़ा नहीं है.
Geocoding API, यह जानकारी नहीं दे पाता.
Geocoding API के रिस्पॉन्स को समझना
खास जानकारी
Geocoding API का इस्तेमाल करने पर, जियोकोड के नतीजे में रिस्पॉन्स में कई तरह की जानकारी मिलती है. इसका इस्तेमाल, दिए गए पते की जानकारी समझने के लिए किया जा सकता है.
Geocoding API, पते के कॉम्पोनेंट को क्रम के हिसाब से हल करता है.
**उदाहरण के लिए, 123 Example Street, Chicago, 60007, USA को इस क्रम में हल किया जाता है:
/ Example Street/ Chicago/ 60007/ USA का मूल्यांकन इसी क्रम में किया जाएगा. इस मामले में, पहला मैच शिकागो है. खास तौर पर, 60007 पिन कोड. इसलिए, यह उस पिन कोड के लिए यह Place_id दिखाता है:
ChIJwRKzf8ixD4gRHiXqucwr_HQ
Geocode API के रिस्पॉन्स में यह जानकारी शामिल होती है:
"partial_match": true,
"place_id": "ChIJwRKzf8ixD4gRHiXqucwr_HQ",
"types": [
"postal_code"
]
Geocoding API से यह पुष्टि की जा सकती है कि यह पता किस तरह की जगह का है. Geocoding API से मिले पते के types की सूची यहां देखी जा सकती है.
अगर इनपुट के किसी भी कॉम्पोनेंट को हल नहीं किया जाता है, तो एपीआई यह दिखाता है:
{
"results": [],
"status": "ZERO_RESULTS"
}
सिर्फ़ सड़क का पता डालकर अनुरोध करने पर, बिना घर के नंबर के, इस फ़ॉर्म में नतीजा मिलता है:
"types": [
"route"
]
इसका मतलब है कि Geocoding API को सड़क का नंबर नहीं मिला या वह उससे मैच नहीं हुआ.
ध्यान दें: यह जानने के लिए कि कोई पता मौजूद है या नहीं, देखें कि Geocoding API के रिस्पॉन्स में कोई पैरामीटर (जैसे, types, partial_match, results, status) सेट है या नहीं. इससे, इस बात की पुष्टि करने में मदद मिलेगी कि कोई पता मौजूद हो सकता है. हालांकि, इससे 100% सटीक जानकारी नहीं मिलेगी. इसलिए, हमें Address Validation API की ज़रूरत होती है.
Geocoding API के रिस्पॉन्स से, पते की सटीक जानकारी की पुष्टि करने के लिए, ऊपर दिए गए तरीकों का इस्तेमाल किया जा सकता है. हालांकि, Address Validation API के नतीजे के उलट, Geocoding API, नतीजे की सटीक जानकारी तय करने के लिए सटीक फ़ीडबैक नहीं देगा.
लोकेशन किस तरह की है
इस सेक्शन को सही तरीके से समझने के लिए, आपको Geocoding API के रिस्पॉन्स से मिलने वाली अलग-अलग तरह की लोकेशन के बारे में समझना होगा:
- ROOFTOP से पता चलता है कि मिला नतीजा, सटीक जियोकोड है. इसके लिए, हमारे पास सड़क के पते की सटीक जानकारी है.
- RANGE_INTERPOLATED से पता चलता है कि मिला नतीजा, दो सटीक पॉइंट (जैसे, चौराहे) के बीच इंटरपोलेट की गई एक अनुमानित जगह (आम तौर पर, सड़क पर) दिखाता है. इंटरपोलेट किए गए नतीजे आम तौर पर तब मिलते हैं, जब सड़क के पते के लिए रूफ़टॉप जियोकोड उपलब्ध नहीं होते.
- GEOMETRIC_CENTER से पता चलता है कि मिला नतीजा, किसी नतीजे का ज्यामितीय केंद्र है. जैसे, पॉलीलाइन (उदाहरण के लिए, सड़क) या पॉलीगॉन (इलाका).
- APPROXIMATE से पता चलता है कि मिला नतीजा, ऊपर दिए गए नतीजों में से कोई नहीं है.
अगर Geocoding API, location_type के तौर पर ROOFTOP या RANGE_INTERPOLATED दिखाता है, तो इसका मतलब यह नहीं है कि पता मौजूद है. इसी तरह, अगर Geocoding API, partial_match फ़्लैग को true पर सेट करके रिस्पॉन्स देता है, तो हो सकता है कि यह आपके लिए सही नतीजा हो.
Geocoding API की मदद से, गलत मैचिंग की इस समस्या को हल करना बहुत मुश्किल है. कम से कम, अनुरोध / रिस्पॉन्स के देश और इलाके की पुष्टि करने के लिए, पोस्ट-प्रोसेसिंग की बुनियादी सुविधा लागू की जा सकती है. इससे भी बेहतर है कि वर्तनी की गड़बड़ियों और/या अधूरे पते के लिए, सड़क के असली पतों की तुलना की जाए.
ध्यान दें: अगर Geocoding API का इस्तेमाल करने का फ़ैसला लिया जाता है, तो हमारा सुझाव है कि शुरुआती अनुरोध और Geocoding API के रिस्पॉन्स के बीच, डेटा क्वालिटी की जांच नियमित तौर पर की जाए.
कुछ हद तक मिलता-जुलता और गलत मैचिंग
अगर कोई पता, कुछ हद तक मिलता-जुलता है, तो इसका मतलब है कि Geocoding API, पते की सटीक पहचान नहीं कर सका. ऐसे में, रिस्पॉन्स में यह जानकारी शामिल होती है:
"partial_match": true,
"types": [
"locality",
"political"
]
लोकेशन के टाइप से ज़्यादा ज़रूरी है कि रिस्पॉन्स में partial_match = true कब हो . partial_match से पता चलता है कि Geocoding API ने, ओरिजनल अनुरोध के लिए सटीक मैच नहीं दिखाया. हालांकि, यह अनुरोध किए गए पते के कुछ हिस्से से मैच हो गया.
अधूरे पते के लिए, ओरिजनल अनुरोध की जांच की जा सकती है. कुछ हद तक मिलते-जुलते नतीजे, अक्सर सड़क के उन पतों के लिए मिलते हैं जो अनुरोध में बताए गए इलाके में मौजूद नहीं होते. कुछ हद तक मिलते-जुलते नतीजे तब भी मिल सकते हैं, जब कोई अनुरोध, एक ही इलाके में दो या उससे ज़्यादा जगहों से मैच होता है.
उदाहरण के लिए, "21 Henr St, Bristol, UK" से हेनरी स्ट्रीट और हेनरीटा स्ट्रीट, दोनों के लिए कुछ हद तक मिलता-जुलता नतीजा मिलता है. ध्यान दें कि अगर किसी अनुरोध में, पते का कोई कॉम्पोनेंट गलत लिखा गया है, तो Geocoding API, कोई दूसरा पता सुझा सकता है. इस तरह ट्रिगर किए गए सुझावों को, कुछ हद तक मिलते-जुलते नतीजे के तौर पर मार्क नहीं किया जाएगा.
सिंथेटिक पते
Geocoding API, "सिंथेटिक" पतों के लिए लोकेशन दिखा सकता है. ये पते, Google के डेटाबेस में सटीक लोकेशन के तौर पर मौजूद नहीं होते.
ऐसे मामलों में, रिस्पॉन्स ऑब्जेक्ट में अक्सर लंबा प्लेस आईडी और यह प्रॉपर्टी शामिल होती है: geometry.location_type=APPROXIMATE.
अगर आपको रिस्पॉन्स में ये इंडिकेटर दिखते हैं, तो कृपया इनपुट पते को अमान्य के तौर पर मार्क करें और किसी दूसरे तरीके से इसकी पुष्टि करने की कोशिश करें.
ध्यान दें: यह एक और उदाहरण है, जिसमें Address Validation API की मदद से, सीधे तौर पर फ़ीडबैक मिलता है. इससे पता चलता है कि कोई पता मौजूद है या नहीं.
Address Validation API के रिस्पॉन्स को समझना
Address Validation API के रिस्पॉन्स को समझने के तरीके के बारे में पहले से ही ज़्यादा जानकारी वाला दस्तावेज़ मौजूद है. इसलिए, हम यहां ज़्यादा जानकारी नहीं देंगे.
- रिस्पॉन्स ऑब्जेक्ट की खास जानकारी यहां देखी जा सकती है.
- रिस्पॉन्स के अलग-अलग कॉम्पोनेंट दिखाने वाला डेमो यहां देखा जा सकता है
- चेकआउट के लिए Address Validation के दस्तावेज़ में, सही और गलत पतों के बीच अंतर करने के तरीके के बारे में ज़्यादा जानकारी दी गई है.
सबसे सही तरीके
देश या इलाके की जानकारी देना
Address Validation API या Geocoding API को कॉल करते समय, हमारा सुझाव है कि उस देश या इलाके को सीमित करें जिसमें उस पते को खोजना है. ये दोनों एपीआई, इसे दो अलग-अलग तरीकों से लागू करते हैं:
Geocoding API - रीजन बाइसिंग
अगर आपको पता है कि जियोकोड किसी खास देश में होंगे, तो रीजन बाइसिंग का इस्तेमाल करके बेहतर नतीजे पाए जा सकते हैं. उदाहरण के लिए, अगर कनाडा में जियोकोडिंग की जा रही है, तो हमारा सुझाव है कि कनाडा के लिए अनुरोधों में
®ion=caजोड़ें. कृपया ध्यान दें कि रीजन बाइसिंग, सिर्फ़ उस इलाके में मौजूद नतीजों को वरीयता देता है. आपको उस इलाके के बाहर के नतीजे भी मिल सकते हैं.Address Validation API - रीजन कोड
इसी तरह, Address Validation API, ज़्यादा सटीक नतीजे देता है. इसके लिए, अनुरोध में ISO2 कोड पास किया जाता है. इसके लिए,
regionCodeफ़ील्ड का इस्तेमाल किया जाता है.
प्लेस आईडी सेव करना
Google Maps Platform से मिली जगह की जानकारी को, भविष्य के अनुरोधों के लिए सेव किया जा सकता है. इसके लिए, प्लेस आईडी को अपने डेटाबेस में, जगह के एट्रिब्यूट के तौर पर हमेशा के लिए सेव किया जा सकता है. आपको हर प्लेस आईडी के लिए, Find Place का अनुरोध सिर्फ़ एक बार करना होगा. जब भी कोई उपयोगकर्ता, लेन-देन की जानकारी का अनुरोध करता है, तब भी प्लेस आईडी खोजा जा सकता है.
यह पक्का करने के लिए कि आपके पास हमेशा सबसे नई जानकारी हो, हर 12 महीने में प्लेस आईडी रीफ़्रेश करें. इसके लिए, Place Details का अनुरोध करें. इसमें place_id पैरामीटर का इस्तेमाल करें.
ध्यान दें: कृपया Geocoding के लिए, सबसे सही तरीके वाली गाइड की भी समीक्षा करें.
नतीजा
इस दस्तावेज़ में, Address Validation API और Geocoding API के बीच के मुख्य अंतरों के बारे में बताया गया है. संक्षेप में, इन स्थितियों में Address Validation API का इस्तेमाल करें:
- जब सटीक मेलिंग पते की ज़रूरत हो. खास तौर पर, डिलीवरी के मकसद से.
- जब इनपुट डेटा की क्वालिटी खराब हो. Address Validation API, इनपुट में मौजूद गड़बड़ियों को ठीक करता है. साथ ही, उन पते के कॉम्पोनेंट को हाइलाइट करता है जिनकी पुष्टि नहीं की जा सकती. इसके अलावा, यह इनपुट डेटा में सुधार करता है.
- जब किसी पते के लिए ज़्यादा जानकारी की ज़रूरत हो. जैसे, रिहायशी बनाम व्यावसायिक (चुनिंदा इलाकों में उपलब्ध).
अगले चरण
सही पतों की मदद से, चेकआउट, डिलीवरी, और ऑपरेशन को बेहतर बनाने के बारे में श्वेत पत्र डाउनलोड करें. साथ ही, Address Validation की मदद से, चेकआउट, डिलीवरी, और ऑपरेशन को बेहतर बनाने के बारे में वेबिनार देखें.
ज़्यादा जानकारी के लिए, ये लेख पढ़ें:
- ई-कॉमर्स के चेकआउट के लिए Address Validation
- Places Autocomplete का दस्तावेज़
- Address Validation API का दस्तावेज़
- Google Maps Platform की रिपोर्टिंग
योगदानकर्ता
Google इस लेख को मैनेज करता है. इसे मूल रूप से इन लोगों ने लिखा था.
मुख्य लेखक:
हेनरिक वाल्व | सलूशन इंजीनियर
थॉमस ऐंगलारेट | सलूशन इंजीनियर
सार्थक गांगुली | सलूशन इंजीनियर