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

हालांकि, नतीजे में पूरे राज्य का जियोकोड होता है. साथ ही, इनपुट में मौजूद किन कॉम्पोनेंट में गड़बड़ी हो सकती है, इसके बारे में कम जानकारी मिलती है.
स्पेलिंग से जुड़ी गड़बड़ी का उदाहरण
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, नतीजे की सटीकता का पता लगाने के लिए सटीक सुझाव नहीं देगा.
लोकेशन किस तरह की है
इस सेक्शन को ठीक से समझने के लिए, आपको 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 या Geocoding API को कॉल करते समय, यह सबसे सही तरीका है कि उस जगह की जानकारी को सीमित किया जाए जहां उस पते को खोजना है. ये दोनों एपीआई, इस सुविधा को दो अलग-अलग तरीकों से लागू करते हैं:
Geocoding API - Region Biasing
अगर आपको पता है कि जियोकोड किसी देश के अंदर के हैं, तो क्षेत्र के हिसाब से नतीजे दिखाने की सुविधा का इस्तेमाल करके बेहतर नतीजे पाए जा सकते हैं. उदाहरण के लिए, अगर आपको कनाडा में जियोकोडिंग करनी है, तो हमारा सुझाव है कि आप अपने अनुरोधों में
®ion=caजोड़ें, ताकि कनाडा के हिसाब से नतीजे मिलें. कृपया ध्यान दें कि क्षेत्र के हिसाब से खोज के नतीजों को प्राथमिकता देने की सुविधा, सिर्फ़ उस क्षेत्र के नतीजों को प्राथमिकता देती है. आपको अब भी क्षेत्र के बाहर के नतीजे मिल सकते हैं.Address Validation API - क्षेत्र का कोड
इसी तरह, अगर अनुरोध में
regionCodeफ़ील्ड का इस्तेमाल करके ISO2 कोड पास किया जाता है, तो Address Validation API ज़्यादा सटीक नतीजे देता है.
जगह के आईडी सेव करना
Google Maps Platform से मिली जगह की जानकारी को आने वाले समय के अनुरोधों के लिए सेव किया जा सकता है. इसके लिए, जगह की जानकारी के एट्रिब्यूट के तौर पर, अपने डेटाबेस में जगह का आईडी हमेशा के लिए सेव करें. आपको हर placeID के लिए, जगह ढूंढें अनुरोध सिर्फ़ एक बार करना होगा. जब भी कोई उपयोगकर्ता ट्रांज़ैक्शन की जानकारी का अनुरोध करता है, तब भी जगह का आईडी खोजा जा सकता है.
यह पक्का करने के लिए कि आपके पास हमेशा अप-टू-डेट जानकारी हो, हर 12 महीनों में जगह के आईडी रीफ़्रेश करें. इसके लिए, place_id पैरामीटर के साथ जगह के बारे में ज़्यादा जानकारी का अनुरोध करें.
ध्यान दें: कृपया जियोकोडिंग के लिए, सबसे सही तरीके वाली गाइड भी देखें.
नतीजा
इस दस्तावेज़ में, Address Validation API और Geocoding API के बीच मुख्य अंतर के बारे में बताया गया है. संक्षेप में, Address Validation API का इस्तेमाल तब करें, जब:
- सही डाक पता देना ज़रूरी है, ताकि आपको ईमेल मिल सकें.
- इनपुट डेटा की क्वालिटी खराब है. Address Validation API, इनपुट में हुई गड़बड़ियों को ज़्यादा आसानी से ठीक कर सकता है. साथ ही, यह पते के उन कॉम्पोनेंट को हाइलाइट करेगा जिनकी पुष्टि नहीं की जा सकती. इसके अलावा, यह इनपुट डेटा में सुधार भी करेगा.
- पते के बारे में ज़्यादा जानकारी की ज़रूरत है. जैसे, रिहायशी बनाम कमर्शियल (यह सुविधा कुछ देशों/इलाकों में उपलब्ध है).
अगले चरण
सही पतों की मदद से, चेकआउट, डिलीवरी, और ऑपरेशंस को बेहतर बनाएं व्हाइटपेपर डाउनलोड करें. साथ ही, पते की पुष्टि करने की सुविधा की मदद से, चेकआउट, डिलीवरी, और ऑपरेशंस को बेहतर बनाना वेबिनार देखें.
इस बारे में और पढ़ें:
- ई-कॉमर्स चेकआउट के लिए, पते की पुष्टि करने की सुविधा
- जगह के नाम के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा से जुड़ा दस्तावेज़
- Address Validation API के बारे में जानकारी देने वाला दस्तावेज़
- Google Maps Platform की रिपोर्टिंग
योगदानकर्ता
Google इस लेख को मैनेज करता है. इस लेख को इन लोगों ने लिखा है.
मुख्य लेखक:
हेनरिक वाल्व | सलूशन इंजीनियर
थॉमस ऐंगलरेट | सलूशन इंजीनियर
सार्थक गांगुली | सलूशन इंजीनियर