Directions API (लेगसी) की मदद से निर्देश पाना

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

यह प्रॉडक्ट लेगसी स्टेटस में है. अक्टूबर 2026 से, Directions API (लेगसी) को नए Google Cloud प्रोजेक्ट के लिए चालू नहीं किया जा सकेगा. मौजूदा प्रोजेक्ट पूरी तरह से काम करते रहेंगे. नई सुविधाओं और बेहतर परफ़ॉर्मेंस के लिए, Routes API पर माइग्रेट करें.

उपयोगकर्ता के इनपुट के हिसाब से रीयल टाइम में जवाब देने वाले रास्ते की जानकारी पाने के लिए (उदाहरण के लिए, यूज़र इंटरफ़ेस एलिमेंट में), Directions API (लेगसी) का इस्तेमाल किया जा सकता है. इसके अलावा, अगर Maps JavaScript API का इस्तेमाल किया जा रहा है, तो Directions सेवा का इस्तेमाल करें. सर्वर-साइड इस्तेमाल के लिए, Google Maps की सेवाओं के लिए Java क्लाइंट, Python क्लाइंट, Go क्लाइंट, और Node.js क्लाइंट का इस्तेमाल किया जा सकता है.

Directions API (लेगसी) की मदद से, ये काम किए जा सकते हैं:

  • यात्रा के कई साधनों के लिए रास्ते की जानकारी खोजें. जैसे, बस, मेट्रो वगैरह, कार, पैदल या साइकल.
  • वेपॉइंट की सीरीज़ का इस्तेमाल करके, कई हिस्सों में बंटे निर्देश दिखाएं.
  • शुरुआती जगहों, मंज़िलों, और वेपॉइंट को टेक्स्ट स्ट्रिंग (जैसे, "शिकागो, आईएल" या "डार्विन, एनटी, ऑस्ट्रेलिया"), जगह के आईडी या अक्षांश/देशांतर निर्देशांक के तौर पर डालें.

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

शुरू करने से पहले

Directions API (लेगसी) का इस्तेमाल शुरू करने से पहले, आपके पास एक ऐसा प्रोजेक्ट होना चाहिए जिसमें बिलिंग खाता और Directions API (लेगसी) चालू हो. ज़्यादा जानने के लिए, Cloud Console में सेट अप करना लेख पढ़ें.

Directions API (लेगसी) के अनुरोध बनाना

Directions API (लेगसी) का अनुरोध इस तरह किया जाता है:

https://maps.googleapis.com/maps/api/directions/outputFormat?parameters

जहां outputFormat इनमें से कोई भी वैल्यू हो सकती है:

  • json (सुझाया गया) से पता चलता है कि आउटपुट, JavaScript Object Notation (JSON) में है
  • xml से पता चलता है कि आउटपुट, एक्सएमएल फ़ॉर्मैट में है

ध्यान दें: यूआरएल मान्य होने के लिए, उन्हें सही तरीके से एन्कोड किया जाना चाहिए. साथ ही, सभी वेब सेवाओं के लिए, यूआरएल में ज़्यादा से ज़्यादा 16,384 वर्ण हो सकते हैं. यूआरएल बनाते समय इस सीमा का ध्यान रखें.

यूआरएल में स्टैंडर्ड के तौर पर, सभी पैरामीटर को एंपरसैंड (&) वर्ण का इस्तेमाल करके अलग किया जाता है. सभी रिज़र्व किए गए वर्णों (उदाहरण के लिए, प्लस का निशान "+") को यूआरएल के हिसाब से कोड में बदला जाना चाहिए. पैरामीटर और उनकी संभावित वैल्यू की सूची यहां दी गई है.

ज़रूरी पैरामीटर

  • डेस्टिनेशन

    जगह का आईडी, पता या टेक्स्ट के तौर पर अक्षांश/देशांतर की वैल्यू, जिसके लिए आपको निर्देश चाहिए. डेस्टिनेशन पैरामीटर के विकल्प, ऑरिजिन पैरामीटर के विकल्पों जैसे ही होते हैं.

  • origin

    जगह का आईडी, पता या टेक्स्ट के तौर पर अक्षांश/देशांतर की वैल्यू, जिससे आपको निर्देश पाने हैं.

    • जगह के आईडी से पहले place_id: जोड़ना ज़रूरी है. Geocoding API और Places API (इसमें किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा भी शामिल है) से, जगह के आईडी वापस पाए जा सकते हैं. किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा से मिले जगह के आईडी इस्तेमाल करने का उदाहरण देखने के लिए, किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा और निर्देश देखें. जगह के आईडी के बारे में ज़्यादा जानने के लिए, जगह के आईडी की खास जानकारी देखें. 

      origin=place_id:ChIJ3S-JXmauEmsRUcIaWtf4MzE

    • अगर आपने कोई पता पास किया है, तो Directions सेवा स्ट्रिंग को जियोकोड करती है और उसे अक्षांश/देशांतर निर्देशांक में बदल देती है, ताकि रास्ते की जानकारी का हिसाब लगाया जा सके. यह निर्देशांक, Geocoding API से मिले निर्देशांक से अलग हो सकता है. उदाहरण के लिए, किसी इमारत के केंद्र के बजाय उसके प्रवेश द्वार का निर्देशांक. 

      origin=24+Sussex+Drive+Ottawa+ON

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

    • अगर निर्देशांक पास किए जाते हैं, तो पॉइंट सबसे नज़दीकी सड़क पर स्नैप हो जाएगा. जगह का आईडी पास करना बेहतर होता है. अगर निर्देशांक पास किए जाते हैं, तो पक्का करें कि अक्षांश और देशांतर की वैल्यू के बीच कोई स्पेस न हो. 

      origin=41.43206,-81.38992

    • Plus Code को ग्लोबल कोड या कंपाउंड कोड के तौर पर फ़ॉर्मैट किया जाना चाहिए. Plus Code को यहां दिखाए गए तरीके से फ़ॉर्मैट करें. प्लस के निशान को यूआरएल में %2B और स्पेस को %20 के तौर पर दिखाया जाता है.

      • ग्लोबल कोड चार वर्णों का एरिया कोड और छह या उससे ज़्यादा वर्णों का लोकल कोड होता है. जैसे, 849VCWC8+R9, 849VCWC8%2BR9 है.
      • कंपाउंड कोड छह या उससे ज़्यादा वर्णों का स्थानीय कोड होता है. इसमें जगह की जानकारी साफ़ तौर पर दी जाती है. जैसे, CWC8+R9 Mountain View, CA, USA, CWC8%2BR9%20Mountain%20View%20CA%20USA है.
    ध्यान दें: बेहतर और सटीक नतीजे पाने के लिए, जहां तक हो सके जगह के आईडी का इस्तेमाल करें. ये आईडी, अक्षांश/देशांतर वैल्यू पेयर की तरह ही यूनीक होते हैं. साथ ही, ये रूटिंग के लिए जियोकोडिंग के फ़ायदे देते हैं. जैसे, ऐक्सेस पॉइंट और ट्रैफ़िक वैरिएबल. किसी पते के उलट, आईडी को किसी जगह की जानकारी खोजने या उसके लिए इंटरमीडिएट अनुरोध करने के लिए, सेवा की ज़रूरत नहीं होती. इसलिए, आईडी की परफ़ॉर्मेंस बेहतर होती है.

ज़रूरी नहीं पैरामीटर

  • विकल्प

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

  • arrival_time

    बस, मेट्रो वगैरह के रास्ते के लिए निर्देश पाने के लिए, पहुंचने का पसंदीदा समय बताता है. यह समय, 1 जनवरी, 1970 यूटीसी की आधी रात से सेकंड में होता है. departure_time या arrival_time में से किसी एक को तय किया जा सकता है, लेकिन दोनों को नहीं. ध्यान दें कि arrival_time को पूर्णांक के तौर पर बताना ज़रूरी है.

  • बचें

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

    • tolls से पता चलता है कि तय किए गए रास्ते में टोल रोड/पुल शामिल नहीं होने चाहिए.
    • highways से पता चलता है कि तय किए गए रास्ते में हाइवे शामिल नहीं होने चाहिए.
    • ferries से पता चलता है कि तय किए गए रास्ते में फ़ेरी शामिल नहीं होनी चाहिए.
    • indoor से पता चलता है कि पैदल चलने और बस, मेट्रो वगैरह के रास्ते के लिए, तय किए गए रास्ते में सीढ़ियों का इस्तेमाल नहीं किया जाना चाहिए.

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

    avoid=tolls|highways|ferries.

  • departure_time

    इससे, जाने के पसंदीदा समय की जानकारी मिलती है. समय को 1 जनवरी, 1970 यूटीसी की आधी रात के बाद से सेकंड में पूर्णांक के तौर पर बताया जा सकता है. अगर 9999-12-31T23:59:59.999999999Z के बाद का departure_time तय किया जाता है, तो एपीआई departure_time को 9999-12-31T23:59:59.999999999Z पर वापस ले जाएगा. इसके अलावा, departure_time की वैल्यू के तौर पर, now का इस्तेमाल किया जा सकता है. इससे, निकलने का समय मौजूदा समय पर सेट हो जाता है. यह समय, सबसे नज़दीकी सेकंड के हिसाब से सही होता है. इन दो मामलों में, रवानगी का समय बताया जा सकता है:

    • ऐसे अनुरोधों के लिए जिनमें यात्रा का मोड सार्वजनिक परिवहन है: आपके पास departure_time या arrival_time में से किसी एक को तय करने का विकल्प होता है. अगर दोनों में से कोई भी समय नहीं बताया गया है, तो departure_time डिफ़ॉल्ट रूप से मौजूदा समय पर सेट हो जाता है. इसका मतलब है कि जाने का समय, डिफ़ॉल्ट रूप से मौजूदा समय पर सेट हो जाता है.
    • उन अनुरोधों के लिए जिनमें यात्रा का मोड ड्राइविंग है: departure_time की वैल्यू तय की जा सकती है, ताकि आपको रास्ते और यात्रा में लगने वाले समय की जानकारी मिल सके. यह जानकारी, ट्रैफ़िक का हाल को ध्यान में रखकर दी जाती है. रिस्पॉन्स फ़ील्ड: duration_in_traffic. departure_time को मौजूदा समय या आने वाले समय पर सेट करना ज़रूरी है. यह बीते हुए समय की नहीं हो सकती.
    ध्यान दें: अगर रवाना होने का समय नहीं बताया गया है, तो रास्ते और समय का विकल्प, सड़क नेटवर्क और ट्रैफ़िक की औसत स्थिति के आधार पर तय किया जाता है. किसी अनुरोध के नतीजे समय के साथ बदल सकते हैं. ऐसा सड़क नेटवर्क में बदलाव, ट्रैफ़िक की औसत स्थिति में बदलाव, और सेवा के अलग-अलग हिस्सों में बंटे होने की वजह से हो सकता है. किसी भी समय या फ़्रीक्वेंसी पर, करीब-करीब एक जैसे रास्तों के बीच भी नतीजे अलग-अलग हो सकते हैं.
    ध्यान दें: Distance Matrix के ऐसे अनुरोध जिनमें departure_time को mode=driving के तौर पर तय किया गया है उनमें हर अनुरोध के लिए ज़्यादा से ज़्यादा 100 एलिमेंट शामिल किए जा सकते हैं. शुरुआत की जगहों की संख्या को मंज़िलों की संख्या से गुणा करने पर, एलिमेंट की संख्या का पता चलता है.

  • भाषा

    वह भाषा जिसमें नतीजे दिखाए जाएंगे. ध्यान दें कि यह सिर्फ़ start_address और end_address में जियोकोड किए गए पतों, distance और duration फ़ील्ड (लेग और स्टेप में) में स्थानीय भाषा में लिखे गए टेक्स्ट, और html_instructions में रास्ते के निर्देशों के ब्यौरे पर लागू होता है. हालांकि, यह html_instructions में मौजूद नामों और पतों पर लागू नहीं होता है. ये नाम और पते, स्थानीय भाषा और लिपि में फ़ॉर्मैट किए जाते हैं.

    • उपलब्ध भाषाओं की सूची देखें. Google अक्सर उन भाषाओं को अपडेट करता रहता है जिनमें यह सुविधा उपलब्ध है. इसलिए, हो सकता है कि इस सूची में पूरी जानकारी शामिल न हो.
    • अगर language नहीं दिया गया है, तो एपीआई, Accept-Language हेडर में बताई गई पसंदीदा भाषा का इस्तेमाल करने की कोशिश करता है.
    • एपीआई, मोहल्ले का ऐसा पता उपलब्ध कराने की पूरी कोशिश करता है जिसे उपयोगकर्ता और स्थानीय लोग, दोनों पढ़ सकें. इस लक्ष्य को हासिल करने के लिए, यह स्थानीय भाषा में मोहल्ले के पते दिखाता है. साथ ही, अगर ज़रूरी हो, तो उपयोगकर्ता की पसंदीदा भाषा को ध्यान में रखते हुए, उसे ऐसी लिपि में ट्रांसलिट्रेट करता है जिसे उपयोगकर्ता पढ़ सके. अन्य सभी पते, आपकी पसंदीदा भाषा में दिखाए जाते हैं. पते के सभी कॉम्पोनेंट उसी भाषा में दिखाए जाते हैं जो पहले कॉम्पोनेंट के लिए चुनी गई है.
    • अगर पसंदीदा भाषा में कोई नाम उपलब्ध नहीं है, तो एपीआई सबसे मिलते-जुलते नाम का इस्तेमाल करता है.
    • पसंदीदा भाषा का असर, एपीआई से मिलने वाले नतीजों के सेट और उनके क्रम पर थोड़ा-बहुत पड़ता है. जियोकोडर, भाषा के हिसाब से शॉर्ट फ़ॉर्म का अलग-अलग मतलब निकालता है. जैसे, सड़क के टाइप के लिए इस्तेमाल किए जाने वाले शॉर्ट फ़ॉर्म या समानार्थी शब्द, जो एक भाषा में मान्य हो सकते हैं, लेकिन दूसरी भाषा में नहीं. उदाहरण के लिए, हंगेरियन भाषा में utca और tér, स्ट्रीट के समानार्थी शब्द हैं.

  • मोड

    दूरी और निर्देशों का हिसाब लगाने के लिए, यात्रा का साधन तय किया जा सकता है. डिफ़ॉल्ट रूप से, driving मोड का इस्तेमाल किया जाता है. डिफ़ॉल्ट रूप से, ड्राइविंग के लिए रास्ते के निर्देश दिखाए जाते हैं. यात्रा के इन तरीकों का इस्तेमाल किया जा सकता है:

    • driving (डिफ़ॉल्ट) से, ड्राइविंग के लिए रास्ते के स्टैंडर्ड निर्देश या सड़क नेटवर्क का इस्तेमाल करके दूरी का पता चलता है.
    • walking पैदल रास्ते की जानकारी या दूरी का अनुरोध करता है. इसके लिए, पैदल चलने के लिए बने रास्ते और फ़ुटपाथ (जहां उपलब्ध हों) का इस्तेमाल किया जाता है.
    • bicycling, साइकल चलाने के लिए बने रास्तों और पसंदीदा सड़कों (जहां उपलब्ध हों) के ज़रिए, साइकल से यात्रा के लिए दिशा-निर्देश या दूरी का अनुरोध करता है.
    • transit सार्वजनिक परिवहन के रास्तों का इस्तेमाल करके, दिशा-निर्देश या दूरी की जानकारी का अनुरोध करता है (जहां उपलब्ध हो). अगर आपने मोड को ट्रांज़िट पर सेट किया है, तो आपके पास departure_time या arrival_time की जानकारी देने का विकल्प होता है. अगर दोनों में से कोई भी समय नहीं बताया गया है, तो departure_time डिफ़ॉल्ट रूप से 'अभी' पर सेट हो जाता है. इसका मतलब है कि जाने का समय, डिफ़ॉल्ट रूप से मौजूदा समय पर सेट हो जाता है. आपके पास transit_mode और/या transit_routing_preference को शामिल करने का विकल्प भी होता है. बस, मेट्रो वगैरह की यात्राओं की जानकारी, पिछले सात दिनों या आने वाले 100 दिनों तक के लिए उपलब्ध होती है. हालांकि, यह जानकारी डेटा उपलब्ध कराने वाली कंपनियों से मिलने वाली जानकारी पर निर्भर करती है. बस, मेट्रो वगैरह के शेड्यूल में अक्सर बदलाव होता रहता है. साथ ही, उपलब्ध यात्राओं की जानकारी भी समय के साथ बदल सकती है. इसलिए, आने वाले समय के लिए सटीक अनुमान देने की कोई गारंटी नहीं है.
    ध्यान दें: पैदल चलने और साइकल चलाने के निर्देशों में, कभी-कभी पैदल चलने वालों या साइकल चलाने वालों के लिए साफ़ तौर पर रास्ते नहीं दिखते. इसलिए, इन निर्देशों के नतीजे में चेतावनियां दिखेंगी. आपको ये चेतावनियां उपयोगकर्ता को दिखानी होंगी.

  • प्रांत

    क्षेत्र का कोड, दो वर्णों वाली ccTLD ("टॉप-लेवल डोमेन") वैल्यू के तौर पर दिया जाता है. ज़्यादातर ccTLD कोड, ISO 3166-1 कोड से मिलते-जुलते होते हैं. हालांकि, कुछ अपवाद भी होते हैं. उदाहरण के लिए, यूनाइटेड किंगडम का ccTLD "uk" (.co.uk) है, जबकि इसका आईएसओ 3166-1 कोड "gb" है. तकनीकी तौर पर, यह कोड "यूनाइटेड किंगडम ऑफ़ ग्रेट ब्रिटेन ऐंड नॉर्दर्न आयरलैंड" के लिए है.

  • traffic_model

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

    • best_guess (डिफ़ॉल्ट) से पता चलता है कि लौटाया गया duration_in_traffic, यात्रा में लगने वाले समय का सबसे सटीक अनुमान होना चाहिए. यह अनुमान, ट्रैफ़िक के पुराने डेटा और लाइव ट्रैफ़िक, दोनों के आधार पर लगाया जाता है. departure_time के समय के करीब आने पर, लाइव ट्रैफ़िक की जानकारी ज़्यादा अहम हो जाती है.
    • pessimistic से पता चलता है कि ज़्यादातर दिनों में, लौटाई गई duration_in_traffic की वैल्यू, यात्रा में लगने वाले असल समय से ज़्यादा होनी चाहिए. हालांकि, कभी-कभी ट्रैफ़िक की स्थिति खराब होने पर, यह वैल्यू बढ़ सकती है.
    • optimistic से पता चलता है कि ज़्यादातर दिनों में, यात्रा में लगने वाले असल समय के मुकाबले, duration_in_traffic की वैल्यू कम होनी चाहिए. हालांकि, कभी-कभी ट्रैफ़िक का हाल अच्छा होने पर, यात्रा में लगने वाला समय इस वैल्यू से कम हो सकता है.

    best_guess की डिफ़ॉल्ट वैल्यू, इस्तेमाल के ज़्यादातर मामलों के लिए सबसे काम के अनुमान देगी. ऐसा हो सकता है कि best_guess के लिए यात्रा में लगने वाले समय का अनुमान, optimistic से कम हो या pessimistic से ज़्यादा हो. ऐसा इसलिए हो सकता है, क्योंकि best_guess के लिए अनुमान लगाने वाला मॉडल, लाइव ट्रैफ़िक की जानकारी को इंटिग्रेट करता है.

  • transit_mode

    इससे यात्रा के लिए एक या उससे ज़्यादा पसंदीदा साधनों के बारे में पता चलता है. इस पैरामीटर को सिर्फ़ बस, मेट्रो वगैरह के रास्ते के लिए निर्देशों के लिए तय किया जा सकता है. पैरामीटर में ये आर्ग्युमेंट इस्तेमाल किए जा सकते हैं:

    • bus से पता चलता है कि कैलकुलेट किए गए रास्ते में, बस से यात्रा करने को प्राथमिकता दी जानी चाहिए.
    • subway से पता चलता है कि तय किए गए रास्ते में, मेट्रो से यात्रा करने को प्राथमिकता दी जानी चाहिए.
    • train से पता चलता है कि कैलकुलेट किए गए रास्ते में, ट्रेन से यात्रा करने को प्राथमिकता दी जानी चाहिए.
    • tram से पता चलता है कि तय किए गए रास्ते में, ट्राम और लाइट रेल से यात्रा करने को प्राथमिकता दी जानी चाहिए.
    • rail से पता चलता है कि तय किए गए रास्ते में, ट्रेन, ट्राम, लाइट रेल, और सबवे से यात्रा करने को प्राथमिकता दी जानी चाहिए. यह transit_mode=train|tram|subway के बराबर है.

  • transit_routing_preference

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

    • less_walking से पता चलता है कि तय किए गए रास्ते में, पैदल चलने की दूरी कम होनी चाहिए.
    • fewer_transfers से पता चलता है कि कैलकुलेट किए गए रास्ते में, कम से कम वाहन बदलने वाले रास्ते को प्राथमिकता दी जानी चाहिए.

  • इकाइयां

    इससे पता चलता है कि नतीजे दिखाते समय, किस यूनिट सिस्टम का इस्तेमाल करना है.

    निर्देशों के नतीजों में, दूरी वाले फ़ील्ड में टेक्स्ट होता है. इसे उपयोगकर्ता को दिखाया जा सकता है, ताकि रास्ते के किसी खास "चरण" की दूरी बताई जा सके. डिफ़ॉल्ट रूप से, इस टेक्स्ट में मूल देश या इलाके के यूनिट सिस्टम का इस्तेमाल किया जाता है.

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

    • metric से पता चलता है कि मेट्रिक सिस्टम का इस्तेमाल किया जा रहा है. टेक्स्ट के तौर पर दूरी, किलोमीटर और मीटर में दिखाई जाती है.
    • imperial से पता चलता है कि इंपीरियल (इंग्लिश) सिस्टम का इस्तेमाल किया जा रहा है. टेक्स्ट के तौर पर दी गई दूरी, मील और फ़ुट में दिखाई जाती है.
    ध्यान दें: इकाई सिस्टम की इस सेटिंग का असर सिर्फ़ दूरी वाले फ़ील्ड में दिखने वाले टेक्स्ट पर पड़ता है. दूरी वाले फ़ील्ड में भी वैल्यू होती हैं. इन्हें हमेशा मीटर में दिखाया जाता है.

  • वेपॉइंट

    चेतावनी: 10 से ज़्यादा वेपॉइंट (11 से 25 के बीच) या वेपॉइंट ऑप्टिमाइज़ेशन का इस्तेमाल करने वाले अनुरोधों के लिए, ज़्यादा शुल्क लिया जाता है. Google Maps Platform के प्रॉडक्ट के लिए, बिलिंग के बारे में ज़्यादा जानें.

    यह यात्रा शुरू करने की जगह और मंज़िल के बीच के रास्ते में शामिल करने के लिए, इंटरमीडिएट जगहों की कलेक्शन के बारे में बताता है. इन जगहों को पास थ्रू या स्टॉपओवर के तौर पर शामिल किया जाता है. वेपॉइंट, किसी रास्ते को तय की गई जगहों से गुज़ारकर उसमें बदलाव करते हैं. यह एपीआई, यात्रा के इन तरीकों के लिए वेपॉइंट की सुविधा देता है: ड्राइविंग, पैदल चलना, और साइकल चलाना. हालांकि, यह ट्रांज़िट के लिए वेपॉइंट की सुविधा नहीं देता. जगह के आईडी, पते या अक्षांश/देशांतर निर्देशांक के तौर पर, एक या उससे ज़्यादा जगहों की जानकारी दी जा सकती है. इन्हें पाइप वर्ण (| या %7C) से अलग किया जा सकता है. डिफ़ॉल्ट रूप से, Directions सेवा दिए गए क्रम में वेपॉइंट का इस्तेमाल करके, रास्ते का हिसाब लगाती है. वेपॉइंट की वैल्यू को पार्स करने के लिए, सबसे पहले जगह का आईडी, फिर अक्षांश/देशांतर निर्देशांक, और फिर पता इस्तेमाल किया जाता है.

    • अगर आपको जगह का आईडी पास करना है, तो आपको उससे पहले place_id: लगाना होगा. Geocoding API और Places API से जगह के आईडी वापस पाए जा सकते हैं. इनमें, किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा भी शामिल है. किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा से मिले जगह के आईडी इस्तेमाल करने का उदाहरण देखने के लिए, किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा और निर्देश देखें. जगह के आईडी के बारे में ज़्यादा जानने के लिए, जगह के आईडी की खास जानकारी देखें.
      बेहतर और सटीक नतीजे पाने के लिए, जहां तक हो सके जगह के आईडी का इस्तेमाल करें. ये आईडी, अक्षांश/देशांतर वैल्यू पेयर की तरह ही यूनीक होते हैं. साथ ही, ये ऐक्सेस पॉइंट और ट्रैफ़िक वैरिएबल जैसे रूटिंग के लिए, जियोकोडिंग के फ़ायदे देते हैं. पते के उलट, आईडी को किसी जगह की जानकारी खोजने या उसके लिए इंटरमीडिएट अनुरोध करने की ज़रूरत नहीं होती. इसलिए, परफ़ॉर्मेंस बेहतर होती है.
    • अगर अक्षांश/देशांतर के निर्देशांक पास किए जाते हैं, तो वैल्यू सीधे फ़्रंटएंड सर्वर पर जाती हैं. इससे जियोकोडिंग के बिना ही दिशा-निर्देशों का हिसाब लगाया जा सकता है. पॉइंट, सड़कों पर स्नैप किए जाते हैं. इसलिए, हो सकता है कि वे आपके ऐप्लिकेशन के लिए ज़रूरी सटीक जानकारी न दें. निर्देशांकों का इस्तेमाल तब करें, जब आपको पूरा भरोसा हो कि वैल्यू, उन जगहों के बारे में सही जानकारी देती हैं जिनकी ज़रूरत आपके ऐप्लिकेशन को रूटिंग के लिए होती है. भले ही, ऐक्सेस पॉइंट या जियोकोडिंग की अन्य जानकारी उपलब्ध हो या न हो. पक्का करें कि अक्षांश और देशांतर की वैल्यू को स्पेस (%20) के बजाय, कॉमा (%2C) से अलग किया गया हो.
    • अगर आपने कोई पता पास किया है, तो Directions सेवा स्ट्रिंग को जियोकोड करेगी और उसे अक्षांश/देशांतर निर्देशांकों में बदलकर, निर्देश का हिसाब लगाएगी. अगर पते की वैल्यू साफ़ तौर पर समझ नहीं आ रही है, तो हो सकता है कि वैल्यू से मिलती-जुलती वैल्यू को खोजा जाए, ताकि साफ़ तौर पर पता चल सके कि वैल्यू क्या है. उदाहरण के लिए, "1st Street" पूरी वैल्यू हो सकती है या "1st street NE" या "1st St SE" के लिए अधूरी वैल्यू हो सकती है. यह नतीजा, Geocoding API से मिले नतीजे से अलग हो सकता है. जगह के आईडी का इस्तेमाल करके, गलत जानकारी देने से बचा जा सकता है.
    • इसके अलावा, एन्कोड किए गए पॉलीलाइन एल्गोरिदम का इस्तेमाल करके, एन्कोड किए गए पॉइंट का सेट भी दिया जा सकता है. आपको पता चलेगा कि एन्कोड किया गया सेट, कई वेपॉइंट के लिए मददगार होता है. ऐसा इसलिए, क्योंकि यूआरएल काफ़ी छोटा होता है. सभी वेब सेवाओं के लिए, यूआरएल में ज़्यादा से ज़्यादा 16,384 वर्ण हो सकते हैं.
      • एन्कोड की गई पॉलीलाइन से पहले enc: और उसके बाद कोलन (:) लगाना ज़रूरी है. उदाहरण के लिए: waypoints=enc:gfo}EtohhU:.
      • एक से ज़्यादा एन्कोड की गई पॉलीलाइन भी शामिल की जा सकती हैं. इन्हें पाइप वर्ण (|) से अलग किया जाता है. उदाहरण के लिए, waypoints=via:enc:wc~oAwquwMdlTxiKtqLyiK:|enc:c~vnAamswMvlTor@tjGi}L:| via:enc:udymA{~bxM:
    स्टॉपओवर और पास थ्रू पॉइंट की मदद से, रास्तों पर असर डालना

    अनुरोध में मौजूद हर वेपॉइंट के लिए, निर्देश का जवाब legs कलेक्शन में एक एंट्री जोड़ता है. इससे यात्रा के उस चरण में स्टॉपओवर की जानकारी मिलती है.

    अगर आपको रास्ते में रुकने की जगह जोड़े बिना, वेपॉइंट का इस्तेमाल करके रास्ते पर असर डालना है, तो वेपॉइंट में प्रीफ़िक्स via: जोड़ें. जिन वेपॉइंट के पहले via: लगा होता है वे legs कलेक्शन में कोई एंट्री नहीं जोड़ते. हालांकि, वे यात्रा को वेपॉइंट से होकर ले जाते हैं.

    यहां दिए गए यूआरएल में, पिछले अनुरोध में बदलाव किया गया है. इससे, यात्रा को लेक्सिंगटन से होकर गुज़ारा जाता है, लेकिन वहां रुकने की ज़रूरत नहीं होती: 

    https://maps.googleapis.com/maps/api/directions/json?
origin=Boston,MA&destination=Concord,MA
&waypoints=Charlestown,MA|via:Lexington,MA

    via: प्रीफ़िक्स का इस्तेमाल तब सबसे ज़्यादा असरदार होता है, जब उपयोगकर्ता मैप पर वेपॉइंट को खींचकर रास्ते बनाता है. इससे उपयोगकर्ता को यह देखने में मदद मिलती है कि फ़ाइनल रूट रीयल-टाइम में कैसा दिखेगा. साथ ही, यह पक्का करने में मदद मिलती है कि वेपॉइंट ऐसी जगहों पर रखे जाएं जिन्हें Directions API ऐक्सेस कर सके.

    चेतावनी: स्टॉपओवर से बचने के लिए, via: प्रीफ़िक्स का इस्तेमाल करने पर, वे निर्देश मिलते हैं जो वेपॉइंट की व्याख्या में सख्त होते हैं. इस इंटरप्रिटेशन की वजह से, रास्ते में काफ़ी बदलाव हो सकते हैं या ZERO_RESULTS रिस्पॉन्स स्टेटस कोड में बदलाव हो सकता है. ऐसा तब होता है, जब Directions API उस पॉइंट से रास्ता नहीं बना पाता.
    अपने वेपॉइंट ऑप्टिमाइज़ करना

    डिफ़ॉल्ट रूप से, Directions सेवा दिए गए क्रम में, दिए गए वेपॉइंट के ज़रिए रास्ते का हिसाब लगाती है. इसके अलावा, वेपॉइंट पैरामीटर में पहले आर्ग्युमेंट के तौर पर optimize:true को पास किया जा सकता है. इससे, रास्ते की जानकारी देने वाली सेवा को, दिए गए रास्ते को ऑप्टिमाइज़ करने की अनुमति मिलती है. इसके लिए, वेपॉइंट को ज़्यादा बेहतर क्रम में फिर से व्यवस्थित किया जाता है. (यह ऑप्टिमाइज़ेशन, ट्रैवलिंग सेल्सपर्सन प्रॉब्लम का एक ऐप्लिकेशन है.) यात्रा में लगने वाला समय, सबसे अहम फ़ैक्टर है जिसे ऑप्टिमाइज़ किया जाता है. हालांकि, सबसे सही रास्ता तय करते समय, दूरी, टर्न की संख्या, और कई अन्य फ़ैक्टर को भी ध्यान में रखा जा सकता है. रास्ता दिखाने वाली सेवा के लिए, सभी वेपॉइंट स्टॉपओवर होने चाहिए, ताकि वह रास्ते को ऑप्टिमाइज़ कर सके.

    अगर आपने Directions service को वेपॉइंट के क्रम को ऑप्टिमाइज़ करने का निर्देश दिया है, तो उनका क्रम, routes ऑब्जेक्ट में मौजूद waypoint_order फ़ील्ड में दिखेगा. waypoint_order फ़ील्ड, शून्य पर आधारित वैल्यू दिखाता है.

    यहां दिए गए उदाहरण में, दक्षिण ऑस्ट्रेलिया के एडिलेड से दक्षिण ऑस्ट्रेलिया के हर मुख्य वाइन क्षेत्र तक की सड़क यात्रा का हिसाब लगाया गया है. इसके लिए, रूट ऑप्टिमाइज़ेशन का इस्तेमाल किया गया है. 

    https://maps.googleapis.com/maps/api/directions/json?
origin=Adelaide,SA&destination=Adelaide,SA
&waypoints=optimize:true|Barossa+Valley,SA|Clare,SA|Connawarra,SA|McLaren+Vale,SA

    कैलकुलेट किए गए रास्ते की जांच करने पर पता चलेगा कि कैलकुलेशन में, वेपॉइंट के इस क्रम का इस्तेमाल किया गया है: 

    "waypoint_order": [ 3, 2, 0, 1 ]
    चेतावनी: वेपॉइंट ऑप्टिमाइज़ेशन का इस्तेमाल करने वाले अनुरोधों के लिए, ज़्यादा शुल्क लिया जाता है. इस बारे में ज़्यादा जानें कि Google Maps Platform के प्रॉडक्ट के लिए बिलिंग कैसे की जाती है.

आगे क्या करना है

निर्देशों के उदाहरण

रास्ते की जानकारी पाने के अनुरोधों के जवाब