Geocoding API v4 के तरीकों के लिए, डिफ़ॉल्ट कोटा 25 क्वेरी प्रति सेकंड (क्यूपीएस) है. अनुरोध भेजने की सीमा बढ़ाने का अनुरोध करने के बारे में जानकारी पाने के लिए, अनुरोध भेजने की सीमा देखना और मैनेज करना लेख पढ़ें. इसके बाद, सेवा के तौर पर Geocoding API चुनें.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Geocoding v3 से v4 पर माइग्रेट करना

यूरोपियन इकनॉमिक एरिया (ईईए) के डेवलपर

Geocoding API v4 में कई नए तरीके उपलब्ध कराए गए हैं. ये एपीआई के v3 में मौजूद सुविधाओं की जगह लेते हैं. इस गाइड में, नए v4 के तरीकों का इस्तेमाल करने के लिए, अपने ऐप्लिकेशन को माइग्रेट करने का तरीका बताया गया है.

नए v4 के तरीकों के साथ, अपनी मौजूदा एपीआई कुंजियों का इस्तेमाल किया जा सकता है. हालांकि, अगर आपने एपीआई के v3 पर कोटा बढ़ाने का अनुरोध किया है, तो आपको नए v4 एपीआई पर कोटा बढ़ाने का अनुरोध करना होगा.

चेतावनी: सुरक्षा से जुड़े जोखिमों की वजह से, आपको क्लाइंट-साइड JavaScript से सीधे तौर पर Geocoding API v4 के तरीकों को कॉल नहीं करना चाहिए. अगर ऐसा सुझावों के ख़िलाफ़ किया जा रहा है, तो ध्यान रखें कि ज़्यादा कोटा का अनुरोध करने से, एपीआई पासकोड के गलत इस्तेमाल का असर बढ़ जाता है. क्लाइंट-साइड पर दिखाए गए एपीआई पासकोड का इस्तेमाल करके, Geocoding API v4 को किए गए सभी कॉल से ज़्यादा जोखिम होता है. ज़्यादा जानकारी के लिए, सुरक्षा से जुड़ी बातें

देखें.

फ़ॉरवर्ड जियोकोडिंग के v3 से माइग्रेट करना

अगर पतों को जियोकोड करने के लिए v3 Geocoding का इस्तेमाल किया जाता है, तो आपको v4 Geocode an address तरीके पर माइग्रेट करना चाहिए. यह GET अनुरोध स्वीकार करता है.

v4 API में, कई पैरामीटर के नाम, स्ट्रक्चर, और सहायता से जुड़े बदलाव किए गए हैं. हमारा सुझाव है कि जवाब में आपको जिन फ़ील्ड की वैल्यू चाहिए उनके लिए, फ़ील्ड मास्क का इस्तेमाल करें.

अनुरोध के पैरामीटर में बदलाव

v3 पैरामीटर	v4 पैरामीटर	नोट
`address`, `components`	`address`	बिना स्ट्रक्चर वाला पता (v3 `address`) अब यूआरएल पाथ में पास किया जाता है. कॉम्पोनेंट फ़िल्टर (v3 `components`) को अब `address.*` क्वेरी पैरामीटर के तौर पर पास किया जाता है.
`bounds`	`locationBias.rectangle`	नाम बदला गया; स्ट्रक्चर को ऑब्जेक्ट में बदल दिया गया.
`language`	`languageCode`	नाम बदला गया.
`region`	`regionCode`	नाम बदला गया.
`extra_computations`	हटा दिया गया

जवाब वाले फ़ील्ड में बदलाव

v3 फ़ील्ड	v4 फ़ील्ड	नोट
`status`, `error_message`	हटा दिया गया	v4 में एचटीटीपी स्टेटस कोड और गड़बड़ी की जानकारी का इस्तेमाल किया जाता है.
`results.address_components.long_name` / `results.address_components.short_name`	`results.addressComponents.longText` / `results.addressComponents.shortText`	नाम बदला गया.
`results.geometry.location_type`	`results.granularity`	नाम बदला गया.
`results.geometry.location`	`results.location`	फ़ील्ड के नाम: `lat`/`lng` -> `latitude`/`longitude`.
`results.geometry.viewport`	`results.viewport`	फ़ील्ड के नाम: `northeast`/`southwest` -> `high`/`low`.
`results.postcode_localities`	`results.postalCodeLocalities`	नाम बदला गया. अब एक या उससे ज़्यादा इलाकों के लिए, यह सुविधा उपलब्ध है. इसके लिए, v3 की ज़रूरत है.
`results.partial_match`	हटा दिया गया
नया	`results.addressComponents.languageCode`	पते के किसी कॉम्पोनेंट की भाषा.
नया	`results.bounds`	`high`/`low` का इस्तेमाल करके, साफ़ तौर पर तय की गई सीमाएं.
नया	`results.place`	जगह का संसाधन नाम.
नया	`results.postalAddress`	स्ट्रक्चर्ड `PostalAddress` ऑब्जेक्ट.

v3 रिवर्स जियोकोडिंग से माइग्रेट करना

अगर आपको निर्देशांकों को पतों में बदलने के लिए, v3 रिवर्स जियोकोडिंग का इस्तेमाल करना है, तो आपको v4 किसी जगह के रिवर्स जियोकोड का पता लगाएं तरीके पर माइग्रेट करना होगा. यह जीईटी अनुरोध स्वीकार करता है.

अनुरोध के पैरामीटर में बदलाव

v3 पैरामीटर	v4 पैरामीटर	नोट
`language`	`languageCode`	नाम बदला गया.
`region`	`regionCode`	नाम बदला गया.
`result_type`	`types`	नाम बदला गया; इसमें बार-बार इस्तेमाल किए गए क्वेरी पैरामीटर का इस्तेमाल किया जाता है.
`location_type`	`granularity`	नाम बदला गया; इसमें बार-बार इस्तेमाल किए गए क्वेरी पैरामीटर का इस्तेमाल किया जाता है.
`extra_computations`	हटा दिया गया

जवाब वाले फ़ील्ड में बदलाव

v3 फ़ील्ड	v4 फ़ील्ड	नोट
`status`, `error_message`	हटा दिया गया	v4 में एचटीटीपी स्टेटस कोड और गड़बड़ी की जानकारी का इस्तेमाल किया जाता है.
`results.address_components.long_name` / `results.address_components.short_name`	`results.addressComponents.longText` / `results.addressComponents.shortText`	नाम बदला गया.
`results.geometry.location_type`	`results.granularity`	नाम बदला गया.
`results.geometry.location`	`results.location`	फ़ील्ड के नाम: `lat`/`lng` -> `latitude`/`longitude`.
`results.geometry.viewport`	`results.viewport`	फ़ील्ड के नाम: `northeast`/`southwest` -> `high`/`low`.
नया	`results.addressComponents.languageCode`	पते के किसी कॉम्पोनेंट की भाषा.
नया	`results.bounds`	`high`/`low` का इस्तेमाल करके, साफ़ तौर पर तय की गई सीमाएं.
नया	`results.place`	जगह का संसाधन नाम.
नया	`results.postalAddress`	स्ट्रक्चर्ड `PostalAddress` ऑब्जेक्ट.

Address descriptors v3 से माइग्रेट करना

अगर आपको Geocoding v3 की मदद से किसी जगह के बारे में ज़्यादा जानकारी पाने के लिए address_descriptor का इस्तेमाल करना है, तो आपको SearchDestinationsResponse के landmarks फ़ील्ड का इस्तेमाल करना होगा.

Place API v3 की जियोकोडिंग सेवा से माइग्रेट करना

अगर आपको Geocoding v3 की मदद से किसी जगह का आईडी का पता पाना है, तो आपको v4 Place Geocoding तरीके पर माइग्रेट करना होगा. यह जीईटी अनुरोध स्वीकार करता है.place_id

अनुरोध के पैरामीटर में बदलाव

v3 पैरामीटर	v4 पैरामीटर	नोट
`place_id`	अनुरोध प्रोटो में `place` फ़ील्ड	अब Place ID को पाथ पैरामीटर `places/{place}` के तौर पर दिया जाता है. उदाहरण के लिए: `https://geocode.googleapis.com/v4/geocode/places/ChIJj61dQgK6j4AR4GeTYWZsKWw`. यह अनुरोध में मौजूद जगह फ़ील्ड पर मैप होता है.
`language`	`languageCode`	नाम बदला गया.
`region`	`regionCode`	नाम बदला गया.

जवाब वाले फ़ील्ड में बदलाव

v3 फ़ील्ड	v4 फ़ील्ड	नोट
`status`, `error_message`	हटा दिया गया	v4 में एचटीटीपी स्टेटस कोड और गड़बड़ी की जानकारी का इस्तेमाल किया जाता है.
`results`	(रूट)	v4, `results` कलेक्शन नहीं, बल्कि एक नतीजा ऑब्जेक्ट दिखाता है.
`results.address_components.long_name` / `results.address_components.short_name`	`addressComponents.longText` / `addressComponents.shortText`	नाम बदला गया.
`results.geometry.location_type`	`granularity`	नाम बदला गया.
`results.geometry.location`	`location`	फ़ील्ड के नाम: `lat`/`lng` -> `latitude`/`longitude`.
`results.geometry.viewport`	`viewport`	फ़ील्ड के नाम: `northeast`/`southwest` -> `high`/`low`.
`results.postcode_localities`	`postalCodeLocalities`	नाम बदला गया. अब एक या उससे ज़्यादा इलाकों के लिए, यह सुविधा उपलब्ध है. इसके लिए, v3 की ज़रूरत है.
नया	`addressComponents.languageCode`	पते के किसी कॉम्पोनेंट की भाषा.
नया	`bounds`	`high`/`low` का इस्तेमाल करके, साफ़ तौर पर तय की गई सीमाएं.
नया	`place`	जगह का संसाधन नाम.
नया	`postalAddress`	स्ट्रक्चर्ड `PostalAddress` ऑब्जेक्ट.

जियोकोडिंग हाइपरलोकल डेटा से डेस्टिनेशन पर माइग्रेट करना

Geocoding API v3 की इन सुविधाओं को, Geocoding API v4 के SearchDestinations तरीके से बदला जा रहा है:

एंट्रेंस
नेविगेशन पॉइंट
बिल्डिंग की आउटलाइन
मैदान

अगर ऊपर दी गई सुविधाओं के लिए Geocoding API v3 का इस्तेमाल किया जा रहा था, तो इन सुविधाओं को पाने के लिए SearchDestinations तरीके का इस्तेमाल करें. इसके लिए, यह दस्तावेज़ पढ़ें. इस दस्तावेज़ में बताया गया है कि SearchDestinations के जवाब में इन सुविधाओं को कहां ढूंढें. साथ ही, Geocoding API v3 और Geocoding API v4 की SearchDestinations विधि के बीच, एपीआई के जवाबों में इन सुविधाओं को दिखाने के तरीके में अंतर के बारे में बताया गया है.

एंट्रेंस

destination से जुड़े दरवाज़ों की जानकारी पाने के लिए, destination.entrances फ़ील्ड का इस्तेमाल करें.

ध्यान दें कि entrance का फ़ॉर्मैट, Geocoding API v3 में मौजूद एंट्रेंस फ़ॉर्मैट से थोड़ा अलग होता है. destination.entrances में हर एंट्री के लिए ये फ़ील्ड होते हैं:

displayName - यह एक नया वैकल्पिक फ़ील्ड है. इसमें प्रवेश द्वार का नाम होगा, ताकि लोग उसे आसानी से समझ सकें. उदाहरण के लिए, "गेट बी".
location - यह LatLng टाइप की जगह है. यह Geocoding API v3 में इस्तेमाल किए गए फ़ॉर्मैट से अलग है.
tags - यह Geocoding API v3 के प्रवेश द्वारों के tags फ़ील्ड के जैसा ही है.
place - यह Geocoding API v3 के buildingPlaceId फ़ील्ड के जैसा है. हालांकि, इस फ़ील्ड में मौजूद जगह का आईडी, किसी भी तरह की जगह का हो सकता है. यह ज़रूरी नहीं कि वह सिर्फ़ किसी इमारत का हो.

नेविगेशन पॉइंट

किसी destination से जुड़े नेविगेशन पॉइंट पाने के लिए, destination.navigationPoints फ़ील्ड का इस्तेमाल करें.

ध्यान दें कि navigationPoint का फ़ॉर्मैट, Geocoding API v3 में नेविगेशन पॉइंट के फ़ॉर्मैट से थोड़ा अलग होता है. destination.navigationPoints में मौजूद हर नेविगेशन पॉइंट में ये फ़ील्ड होते हैं:

displayName - यह एक नया वैकल्पिक फ़ील्ड है. इसमें नेविगेशन पॉइंट के लिए ऐसा नाम होगा जिसे आसानी से पढ़ा जा सकता है. उदाहरण के लिए, "पांचवीं एवेन्यू".
location - यह LatLng टाइप की जगह है. यह Geocoding API v3 में इस्तेमाल किए गए फ़ॉर्मैट से अलग है.
travelModes - यह Geocoding API v3 के नेविगेशन पॉइंट के restrictedTravelModes फ़ील्ड जैसा ही है. इनकी एनम वैल्यू एक जैसी हैं. सिर्फ़ यह अंतर है कि यह फ़ील्ड अब नेविगेशन पॉइंट के लिए, यात्रा के स्वीकार किए गए तरीकों को दिखाता है. पहले यह यात्रा के प्रतिबंधित तरीकों को दिखाता था.
usage - यह एक नया फ़ील्ड है. इसमें नेविगेशन पॉइंट के साथ काम करने वाले इस्तेमाल के उदाहरण शामिल होते हैं. ध्यान दें कि ज़्यादातर नेविगेशन पॉइंट में UNKNOWN का इस्तेमाल किया जाएगा. हालांकि, इसका मतलब यह नहीं है कि नेविगेशन पॉइंट के इस्तेमाल पर किसी तरह की पाबंदी है.

बिल्डिंग की आउटलाइन

destination से जुड़ी बिल्डिंग की आउटलाइन पाने के लिए, आपको destination में मौजूद उन placeView ऑब्जेक्ट के displayPolygon फ़ील्ड का इस्तेमाल करना चाहिए जो बिल्डिंग को दिखाते हैं. हर placeView के लिए, यह देखा जा सकता है कि क्या यह placeView.structureType फ़ील्ड वाली बिल्डिंग है. अगर स्ट्रक्चर टाइप BUILDING है, तो आपको आउटलाइन placeView.displayPolygon फ़ील्ड से मिल सकती है. placeView में बिल्डिंग के लिए अतिरिक्त फ़ील्ड भी होंगे, जो Geocoding API v3 में नहीं थे.

ध्यान दें: क्या आपको किसी जगह पर मौजूद इमारत का पॉलीगॉन चाहिए? नतीजों को सीमित करने के लिए, अपने अनुरोध में placeFilter पैरामीटर का इस्तेमाल करें. सिर्फ़ बिल्डिंग के नतीजे पाने के लिए, placeFilter में structureType को "BUILDING" पर सेट करें. अगर आपको सटीक पते वाली जगहों के साथ-साथ, बिना सटीक पते वाली जगहों के लिए भी पॉलीगॉन चाहिए, तो placeFilter में addressability को "ANY" पर सेट करें. इससे आपको सबसे सटीक पॉलीगॉन मिलेगा.

उदाहरण

{
  "locationQuery": {
    "location": {
      "latitude": 37.4224,
      "longitude": -122.0841
    },
    "placeFilter": {
      "structureType": "BUILDING",
      "addressability": "ANY"
    }
  }
}

destination में placeView ऑब्जेक्ट हो सकता है. यह ऑब्जेक्ट, इन फ़ील्ड में मौजूद बिल्डिंग के बारे में जानकारी देता है:

destination.primary - यह डेस्टिनेशन की मुख्य जगह है.
destination.containingPlaces - यह दोहराया गया फ़ील्ड है. इसमें ऐसी बड़ी जगहें शामिल हो सकती हैं जिनमें प्राइमरी जगह "शामिल" है. उदाहरण के लिए, अगर मुख्य जगह subpremise है, तो containingPlaces में आम तौर पर placeView होता है, जो बिल्डिंग को दिखाता है.
destination.subDestinations - यह दोहराया गया फ़ील्ड है, जिसमें मुख्य जगह की उप-जगहों की जानकारी शामिल हो सकती है. उदाहरण के लिए, किसी बिल्डिंग के अलग-अलग अपार्टमेंट. इस फ़ील्ड में आम तौर पर, placeView नहीं होता है.

ध्यान दें कि placeView.displayPolygon का फ़ॉर्मैट, Geocoding API v3 में मौजूद बिल्डिंग के आउटलाइन फ़ॉर्मैट से मेल खाता है. यह RFC 7946 फ़ॉर्मैट का इस्तेमाल करने वाला GeoJSON फ़ॉर्मैट है.

मैदान

आउटलाइन बनाने की तरह ही, destination से जुड़े ग्राउंड पाने के लिए, आपको destination में मौजूद placeView ऑब्जेक्ट के displayPolygon फ़ील्ड का इस्तेमाल करना चाहिए. ये ऑब्जेक्ट, ग्राउंड को दिखाते हैं. हर placeView के लिए, यह देखा जा सकता है कि यह placeView.structureType फ़ील्ड के हिसाब से सही है या नहीं. अगर स्ट्रक्चर टाइप GROUNDS है, तो आपको placeView.displayPolygon फ़ील्ड से आउटलाइन मिल सकती है. placeView में ऐसे अतिरिक्त फ़ील्ड भी होंगे जो Geocoding API v3 में नहीं थे.

destination में placeView ऑब्जेक्ट हो सकता है. यह ऑब्जेक्ट, इन फ़ील्ड में किसी आधार को दिखाता है:

destination.primary
destination.containingPlaces
destination.subDestinations

ध्यान दें कि placeView.displayPolygon का फ़ॉर्मैट, Geocoding API v3 में मौजूद ग्राउंड आउटलाइन फ़ॉर्मैट से मेल खाता है. यह RFC 7946 फ़ॉर्मैट का इस्तेमाल करने वाला GeoJSON फ़ॉर्मैट है.

नतीजे कितने सटीक हैं

Geocoding API v3 में, जवाब की ज्यामिति में मौजूद location_type फ़ील्ड से नतीजों की सटीक जानकारी मिलती थी. कुछ क्लाइंट, इन वैल्यू (ROOFTOP, RANGE_INTERPOLATED, GEOMETRIC_CENTER, और APPROXIMATE) के आधार पर नतीजों को रैंक करते थे या फ़िल्टर करते थे. Standard Geocoding API v4 पर माइग्रेट करने पर, इस फ़ील्ड का नाम बदलकर granularity कर दिया गया है.

Destinations API (v4 SearchDestinations) में, location_type फ़ील्ड मौजूद नहीं है. इसके बजाय, जगह की जानकारी को अलग तरीके से मैनेज किया जाता है:

क्लाइंट-साइड पर मैन्युअल तरीके से फ़िल्टर करने की ज़रूरत नहीं होती: स्टैंडर्ड जियोकोडिंग में, अलग-अलग लेवल पर कई नतीजे मिलते हैं. वहीं, SearchDestinations तरीके में, एक ही ऑप्टिमाइज़ किए गए डेस्टिनेशन का इस्तेमाल किया जाता है. इससे, अस्पष्टता कम हो जाती है. इससे क्लाइंट को यह तय करने के लिए, जगह के हिसाब से फ़िल्टर करने की ज़रूरत नहीं पड़ती कि कौनसा नतीजा सबसे अच्छा है.
स्ट्रक्चर टाइप और डिसप्ले पॉलीगॉन के ज़रिए दिखाई गई जगह की जानकारी: जगह की ज्यामिति और स्ट्रक्चर को इनके ज़रिए दिखाया जाता है:
- displayPolygon (पूरी तरह से मेल खाने वाली ज्यामिति के लिए).
- placeView ऑब्जेक्ट में मौजूद structureType फ़ील्ड.
स्ट्रक्चर टाइप मैपिंग:
- POINT, BUILDING या SECTION में से किसी एक structureType का मतलब आम तौर पर वही होता है जिसे पहले ROOFTOP कहा जाता था.
- आम तौर पर, structureType का GROUNDS, GEOMETRIC_CENTER के बराबर होता है.

इन सुविधाओं का अनुरोध करने के लिए, फ़ील्ड मास्क का इस्तेमाल करना

SearchDestinations तरीके के लिए फ़ील्ड मास्क की ज़रूरत होती है. इसके बारे में दिखाने के लिए फ़ील्ड चुनना लेख में बताया गया है. सभी फ़ील्ड वापस पाने के लिए, फ़ील्ड मास्क को * पर सेट किया जा सकता है. इसके अलावा, इसे उन फ़ील्ड पर सेट किया जा सकता है जिन्हें आपको वापस पाना है. उदाहरण के लिए, यहां दिए गए एपीआई अनुरोध में फ़ील्ड मास्क सेट किया गया है. इससे किसी जगह के सभी ज़रूरी फ़ील्ड की जानकारी मिलती है. जैसे, प्रवेश द्वार, नेविगेशन पॉइंट, बिल्डिंग की आउटलाइन, और ग्राउंड:

curl -X POST -d '{"place": "places/ChIJG3kh4hq6j4AR_XuFQnV0_t8"}' \
  -H "X-Goog-Api-Key: API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-Goog-FieldMask: destinations.entrances,destinations.navigationPoints,destinations.primary,destinations.containingPlaces,destinations.subDestinations" \
  https://geocode.googleapis.com/v4/geocode/destinations

सुरक्षा से जुड़ी बातें

Geocoding API v4 को सर्वर-टू-सर्वर एपीआई के तौर पर डिज़ाइन किया गया है. JavaScript का इस्तेमाल करने वाले लोगों के लिए, v3 से v4 पर सीधे माइग्रेट करने का कोई तरीका नहीं है. क्लाइंट-साइड JavaScript (उदाहरण के लिए, ब्राउज़र में) से सीधे तौर पर v4 के तरीकों को कॉल करने के लिए, एपीआई कुंजी का इस्तेमाल करने से, आपकी एपीआई कुंजी के चोरी होने और उसके गलत इस्तेमाल का खतरा बढ़ जाता है.

एचटीटीपी रेफ़रर से जुड़ी पाबंदियां काम की होती हैं. हालांकि, ये वेब सेवा के एंडपॉइंट के लिए सुरक्षा के लिहाज़ से काफ़ी नहीं होती हैं. ऐसा इसलिए, क्योंकि हमलावर अपने अनुरोधों में Referer हेडर को फ़र्ज़ी बनाकर, इन पाबंदियों को आसानी से बाईपास कर सकते हैं.

सुझाया गया तरीका

हमारा सुझाव है कि Geocoding API v4 का इस्तेमाल अपने बैकएंड सर्वर से करें. आपका क्लाइंट ऐप्लिकेशन, इस इंटरमीडियरी सर्वर को अनुरोध भेजेगा. इसके बाद, यह सुरक्षित एपीआई कुंजी का इस्तेमाल करके Google API को सुरक्षित तरीके से कॉल करेगा. उदाहरण के लिए, एनवायरमेंट वैरिएबल या सीक्रेट मैनेजर में सेव की गई कुंजी. इससे यह पक्का होता है कि आपकी एपीआई कुंजी, फ़्रंटएंड कोड में कभी भी नहीं दिखती.

क्लाइंट-साइड की ज़रूरतों के लिए विकल्प

अगर आपको क्लाइंट-साइड पर जियोकोडिंग की ज़रूरत है, तो क्लाइंट-साइड के मौजूदा समाधानों में से किसी एक का इस्तेमाल करें:

Maps JavaScript API में जियोकोडिंग सेवा: Geocoding Service, v3 बैकएंड का इस्तेमाल करती है. इसे ब्राउज़र एनवायरमेंट में इस्तेमाल करने के लिए डिज़ाइन किया गया है.
जगहों की जानकारी देने वाली यूआई किट: पते से जुड़े यूज़र इंटरफ़ेस (यूआई) एलिमेंट के लिए, जगहों की जानकारी देने वाली यूआई किट का इस्तेमाल करें. इसमें किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा वाले एलिमेंट शामिल हैं.