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 Forward Geocoding से माइग्रेट करना

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

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

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

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

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

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 कॉम्पोनेंट के फ़िल्टर फिर से बनाएं

Geocoding v3 में फ़ॉरवर्ड जियोकोडिंग में components पैरामीटर शामिल था. इससे कुछ कॉम्पोनेंट (जैसे, components=country:US) के नतीजों को हार्ड फ़िल्टर किया जा सकता था. v4 में फ़ॉरवर्ड जियोकोडिंग, अनुरोध पैरामीटर में इस तरह के हार्ड फ़िल्टरिंग का समर्थन नहीं करता है. चौथे वर्शन में, पते की जानकारी को पाथ में बिना किसी स्ट्रक्चर वाली एक स्ट्रिंग के तौर पर या स्ट्रक्चर्ड क्वेरी पैरामीटर के तौर पर दिया जा सकता है. जैसे, address.addressLines, address.locality, address.administrativeArea, address.postalCode, और address.regionCode. स्ट्रक्चर्ड पैरामीटर, हार्ड फ़िल्टर के तौर पर काम नहीं करते. इसके बजाय, दिए गए सभी कॉम्पोनेंट को मिलाकर पूरा पता बनाया जाता है. API इस पते को जियोकोड करने की कोशिश करेगा. यह एपीआई, सभी कॉम्पोनेंट में दिए गए पूरे पते से सबसे ज़्यादा मेल खाने वाले पते को खोजता है. स्ट्रक्चर्ड तरीके से कॉम्पोनेंट देने पर, एपीआई को अनुरोध के मकसद को बेहतर तरीके से समझने में मदद मिल सकती है. ऐसा खास तौर पर तब होता है, जब पते की जानकारी अलग-अलग फ़ॉर्म फ़ील्ड से इकट्ठा की जाती है. इससे एपीआई को हर कॉम्पोनेंट में मौजूद छोटी-मोटी टाइपिंग की गलतियों या अस्पष्टता को ठीक करने में मदद मिल सकती है. ऐसा इसलिए, क्योंकि हर फ़ील्ड में मौजूद जानकारी का टाइप साफ़ तौर पर बताया गया है.

v3 के हार्ड कॉम्पोनेंट फ़िल्टर की तरह काम करने वाले फ़िल्टर बनाने के लिए, आपको v4 API से मिले results ऐरे पर क्लाइंट-साइड फ़िल्टरिंग लागू करनी होगी. यह फ़िल्टरिंग, जवाब में मौजूद postalAddress और addressComponents ऑब्जेक्ट के आधार पर की जाएगी.

नीचे दी गई टेबल में, v3 components फ़िल्टर और v4 postalAddress फ़ील्ड के बीच सबसे ज़्यादा मिलते-जुलते फ़िल्टर और फ़ील्ड दिखाए गए हैं:

v3 कॉम्पोनेंट फ़िल्टर	v4 रिस्पॉन्स फ़ील्ड
`country`	`postalAddress.regionCode`
`postal_code`	`postalAddress.postalCode`
`administrative_area`	`postalAddress.administrativeArea` या `addressComponents`

क्लाइंट-साइड फ़िल्टरिंग के उदाहरण

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

देश के हिसाब से फ़िल्टर करना

अपनी क्वेरी के address.regionCode को हर नतीजे में मौजूद postalAddress.regionCode से मैच करें. ध्यान दें कि एपीआई, अनुरोध में छोटे अक्षरों वाले क्षेत्र के कोड स्वीकार करता है. हालांकि, जवाब में हमेशा बड़े अक्षरों वाले कोड दिखाता है. इसलिए, तुलना करने से पहले आपको अपने इनपुट को बड़े अक्षरों में बदलना होगा.

Python कोड का उदाहरण

def filter_by_country(results, region_code):
    return [
        res for res in results
        if res.get('postalAddress', {}).get('regionCode') == region_code.upper()
    ]

# Example usage:
# v4_response = ... # API call response
# filtered = filter_by_country(v4_response.get('results', []), 'US')

Node.js कोड का उदाहरण

function filterByCountry(results, regionCode) {
    return results.filter(res => res.postalAddress?.regionCode === regionCode.toUpperCase());
}

// Example usage:
// const v4Response = ... # API call response
// const filtered = filterByCountry(v4Response.results, 'US');

राज्य के हिसाब से फ़िल्टर करें

अपनी क्वेरी के address.administrativeArea को हर नतीजे में मौजूद postalAddress.administrativeArea से मैच करें. देश के कोड की तरह ही, तुलना करने से पहले आपको अपने इनपुट को अपरकेस में बदलना चाहिए. यह सिर्फ़ तब भरोसेमंद होता है, जब आपके अनुरोध में मौजूद administrativeArea को दो अक्षरों वाले स्टैंडर्ड संक्षिप्त नाम के साथ दिया गया हो. कई वजहों से, ऐसा हो सकता है कि जवाब में मौजूद postalAddress.administrativeArea, आईएसओ 3166-2 कोड के प्रत्यय से सीधे तौर पर मेल न खाए. पहला, कुछ इलाकों में आईएसओ 3166-2 कोड से मेल खाने वाला सबडिविज़न, डाक पतों के स्टैंडर्ड फ़ॉर्मैट का हिस्सा नहीं होता. उदाहरण के लिए, स्पेन में addressComponents में एडमिनिस्ट्रेटिव एरिया लेवल 1 (जैसे, कैनरी द्वीप के लिए "CN") मौजूद हो सकता है. हालांकि, postalAddress.administrativeArea में लेवल 2 का एरिया (जैसे, सांता क्रूज़ डे टेनेरिफ़) मौजूद हो सकता है. दूसरी बात, कुछ इलाकों में सबडिविज़न के नाम के छोटे रूप का इस्तेमाल आम तौर पर नहीं किया जाता है. इसे postalAddress.administrativeArea में लंबे नाम के साथ दिखाया जाता है. इसी तरह की वजहों से, सबडिविज़न से जुड़े पते के कॉम्पोनेंट addressComponents.shortText का नाम, सबडिविज़न के ISO 3166-2 कोड के सफ़िक्स से मेल नहीं खा सकता. इसके अलावा, कुछ मामलों में सबडिविज़न को पते के कॉम्पोनेंट में दिखाया जा सकता है. ऐसा तब होता है, जब administrative_area_level_n की वैल्यू 1 से ज़्यादा हो. सबसे सटीक नतीजे पाने के लिए, आपको postalAddress.administrativeArea और administrative_area_level_n टाइप (जैसे, administrative_area_level_1) वाले किसी भी addressComponents, दोनों में मैच की जांच करनी चाहिए.

Python कोड का उदाहरण

def filter_by_admin_area(results, admin_area):
    target = admin_area.upper()
    filtered = []
    for res in results:
        # Check postalAddress
        pa_aa = res.get('postalAddress', {}).get('administrativeArea', '')
        if pa_aa == target:
            filtered.append(res)
            continue
        # Check all administrative area levels in addressComponents
        for comp in res.get('addressComponents', []):
            is_admin_level = any(t.startswith('administrative_area_level_')
                               for t in comp.get('types', []))
            if is_admin_level:
                short = comp.get('shortText', '')
                if short == target:
                    filtered.append(res)
                    break
    return filtered

# Example usage:
# filtered = filter_by_admin_area(v4_response.get('results', []), 'CA')

Node.js कोड का उदाहरण

function filterByAdminArea(results, adminArea) {
    const target = adminArea.toUpperCase();
    return results.filter(res => {
        // Check postalAddress.administrativeArea
        if (res.postalAddress?.administrativeArea === target) {
            return true;
        }
        // Check addressComponents for any administrative area level
        return res.addressComponents?.some(c => {
            const isAdmin = c.types?.some(t => t.startsWith('administrative_area_level_'));
            return isAdmin && c.shortText === target;
        });
    });
}

// Example usage:
// const filtered = filterByAdminArea(v4Response.results, 'CA');

पिन कोड के हिसाब से फ़िल्टर करना

अपनी क्वेरी के address.postalCode को हर नतीजे में मौजूद postalAddress.postalCode से मैच करें. तुलना करने से पहले, आपको इनपुट और नतीजे, दोनों के पिन कोड को नॉर्मलाइज़ करना होगा. सामान्य बनाने का लॉजिक, देश/इलाके पर काफ़ी हद तक निर्भर करता है. सामान्य तौर पर, स्पेस और हाइफ़न हटा दिए जाते हैं. साथ ही, सभी अक्षरों को एक ही केस में बदल दिया जाता है.

पिन कोड के प्रीफ़िक्स (जैसे, यूनाइटेड किंगडम में "L2") या सुफ़िक्स (जैसे, अमेरिका के पिन कोड में "+4") को हैंडल करने के लिए, ज़्यादा बेहतर तरीके से सामान्य बनाने की ज़रूरत पड़ सकती है. पिन कोड को स्टैंडर्ड फ़ॉर्मैट में बदलने का लॉजिक, देश और पिन कोड के फ़ॉर्मैट के हिसाब से अलग-अलग होगा. आपको टारगेट किए जा रहे इलाकों के लिए, दिए गए सामान्यीकरण फ़ंक्शन में बदलाव करना पड़ सकता है या ज़्यादा बेहतर लॉजिक लागू करना पड़ सकता है.

यहां दिए गए उदाहरण में, अमेरिका के पिन कोड को हैंडल किया जाता है. साथ ही, अगर ZIP+4 दिया गया है या दिखाया गया है, तो भी पांच अंकों के आधार पर मैच करने की अनुमति दी जाती है.

Python कोड का उदाहरण (इसमें अमेरिका के पिन कोड पर फ़ोकस किया गया है)

import re

def normalize_postal_code_us(pc):
    # Basic normalization for US: uppercase, alphanumeric only
    if not pc:
        return ""
    normalized = re.sub(r'[^A-Z0-9]', '', pc.upper())
    # Return only the first 5 digits for US ZIP codes
    return normalized[:5]

def filter_by_postal_code_us(results, postal_code):
    normalized_input = normalize_postal_code_us(postal_code)
    if not normalized_input:
        return []
    filtered_results = []
    for res in results:
        pa_pc = res.get('postalAddress', {}).get('postalCode', '')
        if normalize_postal_code_us(pa_pc) == normalized_input:
            filtered_results.append(res)
    return filtered_results

# Example usage:
# Matches '94043', '94043-1351', '940431351'
# filtered = filter_by_postal_code_us(v4_response.get('results', []), '94043')
# filtered = filter_by_postal_code_us(v4_response.get('results', []), '94043-1234')

Node.js कोड का उदाहरण (सिर्फ़ अमेरिका के पिन कोड के लिए)

function normalizePostalCodeUs(pc) {
    // Basic normalization for US: uppercase, alphanumeric only
    const normalized = (pc || '').toUpperCase().replace(/[^A-Z0-9]/g, '');
    // Return only the first 5 digits for US ZIP codes
    return normalized.substring(0, 5);
}

function filterByPostalCodeUs(results, postalCode) {
    const normalizedInput = normalizePostalCodeUs(postalCode);
    if (!normalizedInput) {
        return [];
    }
    return results.filter(res => {
        const paPc = res.postalAddress?.postalCode || '';
        return normalizePostalCodeUs(paPc) === normalizedInput;
    });
}

// Example usage:
// Matches '94043', '94043-1351', '940431351'
// const filtered = filterByPostalCodeUs(v4Response.results, '94043');
// const filtered = filterByPostalCodeUs(v4Response.results, '94043-1234');

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

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

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

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

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

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` ऑब्जेक्ट.

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

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

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

अगर आपको Geocoding v3 की मदद से किसी Place ID का पता पाना है, तो आपको v4 Place Geocoding तरीके पर माइग्रेट करना होगा. यह GET अनुरोध स्वीकार करता है.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 बैकएंड का इस्तेमाल करती रहेगी. इसे ब्राउज़र एनवायरमेंट में इस्तेमाल करने के लिए डिज़ाइन किया गया है.
Places UI Kit: पते से जुड़े यूज़र इंटरफ़ेस (यूआई) एलिमेंट के लिए, Places UI Kit का इस्तेमाल करें. इसमें जगह की जानकारी अपने-आप भरने वाले एलिमेंट शामिल हैं.