यह प्रॉडक्ट लेगसी स्टेटस में है. अक्टूबर 2026 से, Google Cloud के नए प्रोजेक्ट के लिए, Directions API (लेगसी) को चालू नहीं किया जा सकेगा. मौजूदा प्रोजेक्ट पूरी तरह से काम करते रहेंगे. नई सुविधाओं और बेहतर परफ़ॉर्मेंस के लिए, Routes API पर माइग्रेट करें.
उपयोगकर्ता के इनपुट के हिसाब से रीयल टाइम में निर्देश देने के लिए, Directions API (लेगसी) का इस्तेमाल किया जा सकता है. जैसे, यूज़र इंटरफ़ेस एलिमेंट में. इसके अलावा, अगर Maps JavaScript API का इस्तेमाल किया जा रहा है, तो निर्देश देने वाली सेवा का इस्तेमाल करें. सर्वर-साइड के इस्तेमाल के लिए, 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है.
-
ग्लोबल कोड में चार वर्णों का एरिया कोड और छह या उससे ज़्यादा वर्णों का लोकल कोड होता है. जैसे, 849VCWC8+R9,
ज़रूरी नहीं पैरामीटर
विकल्प
अगर इसे 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को मौजूदा समय या आने वाले समय पर सेट करना ज़रूरी है. यह बीते हुए समय की नहीं हो सकती.
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से पता चलता है कि इंपीरियल (इंग्लिश) सिस्टम का इस्तेमाल किया जा रहा है. टेक्स्ट के तौर पर दी गई दूरी, मील और फ़ुट में दिखाई जाती है.
वेपॉइंट
यह यात्रा शुरू करने की जगह और मंज़िल के बीच के रास्ते में शामिल करने के लिए, इंटरमीडिएट जगहों की कलेक्शन की जानकारी देता है. इन जगहों को रास्ते में पड़ने वाली जगहों या रुकने की जगहों के तौर पर शामिल किया जाता है. वेपॉइंट, किसी रास्ते को तय की गई जगहों से गुज़ारकर उसमें बदलाव करते हैं. यह एपीआई, यात्रा के इन तरीकों के लिए वेपॉइंट की सुविधा देता है: ड्राइविंग, पैदल चलना, और साइकल चलाना. हालांकि, यह सार्वजनिक परिवहन के लिए वेपॉइंट की सुविधा नहीं देता. जगह के आईडी, पते या अक्षांश/देशांतर निर्देशांक के तौर पर, एक या उससे ज़्यादा जगहों की जानकारी दी जा सकती है. इन्हें पाइप वर्ण (| या %7C) से अलग किया जा सकता है. डिफ़ॉल्ट रूप से, Directions सेवा, वेपॉइंट के दिए गए क्रम के हिसाब से रास्ते का हिसाब लगाती है. वेपॉइंट की वैल्यू को पार्स करने के लिए, सबसे पहले जगह का आईडी, फिर अक्षांश/देशांतर निर्देशांक, और फिर पता इस्तेमाल किया जाता है.
-
अगर आपको जगह का आईडी पास करना है, तो आपको उससे पहले
place_id:लगाना होगा. Geocoding API और Places API (इसमें किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा भी शामिल है) से, जगह के आईडी वापस पाए जा सकते हैं. किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा से मिले प्लेस आईडी का इस्तेमाल करने का उदाहरण देखने के लिए, किसी जगह के शुरुआती अक्षर लिखने पर पूरा नाम सुझाने की सुविधा और निर्देश देखें. जगह के आईडी के बारे में ज़्यादा जानने के लिए, जगह के आईडी की खास जानकारी देखें.बेहतर और सटीक नतीजे पाने के लिए, जहां तक हो सके जगह के आईडी का इस्तेमाल करें. ये आईडी, अक्षांश/देशांतर वैल्यू पेयर की तरह ही यूनीक होते हैं. साथ ही, ये रूटिंग के लिए जियोकोडिंग के फ़ायदे देते हैं, जैसे कि ऐक्सेस पॉइंट और ट्रैफ़िक वैरिएबल. पते के उलट, आईडी को किसी जगह की जानकारी खोजने या उसके लिए इंटरमीडिएट अनुरोध करने की ज़रूरत नहीं होती. इसलिए, परफ़ॉर्मेंस बेहतर होती है. -
अक्षांश/देशांतर निर्देशांक पास करने पर, वैल्यू सीधे फ़्रंटएंड सर्वर पर जाती हैं. इससे जियोकोडिंग के बिना ही दिशा-निर्देशों का हिसाब लगाया जा सकता है. पॉइंट, सड़कों पर स्नैप किए जाते हैं. इसलिए, हो सकता है कि वे आपके ऐप्लिकेशन के लिए ज़रूरी सटीक जानकारी न दें. निर्देशांकों का इस्तेमाल तब करें, जब आपको पूरा भरोसा हो कि वैल्यू से उन जगहों की सटीक जानकारी मिलती है जिनकी ज़रूरत आपके ऐप्लिकेशन को रूटिंग के लिए होती है. भले ही, ऐक्सेस पॉइंट या जियोकोडिंग की अन्य जानकारी उपलब्ध हो या न हो. पक्का करें कि अक्षांश और देशांतर की वैल्यू को कॉमा (
%2C) से अलग किया गया हो, न कि स्पेस (%20) से. - अगर कोई पता पास किया जाता है, तो 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: प्रीफ़िक्स का इस्तेमाल करने पर, वे रास्ते दिखाए जाते हैं जो वेपॉइंट के हिसाब से सटीक होते हैं. इस तरह से समझने पर, रास्ते में काफ़ी ज़्यादा चक्कर लगाने पड़ सकते हैं. इसके अलावा, अगर Directions API उस पॉइंट से निर्देश नहीं बना पाता है, तो जवाब के स्टेटस कोड में ZERO_RESULTS दिख सकता है.
अपने वेपॉइंट ऑप्टिमाइज़ करना
डिफ़ॉल्ट रूप से, Directions सेवा दिए गए वेपॉइंट के हिसाब से रास्ता तय करती है. इसके अलावा, वेपॉइंट पैरामीटर में पहले आर्ग्युमेंट के तौर पर optimize:true को पास किया जा सकता है. इससे, Directions API को वेपॉइंट को ज़्यादा बेहतर क्रम में फिर से व्यवस्थित करके, दिए गए रास्ते को ऑप्टिमाइज़ करने की अनुमति मिलती है. (यह ऑप्टिमाइज़ेशन, ट्रैवलिंग सेल्सपर्सन प्रॉब्लम का एक ऐप्लिकेशन है.) यात्रा में लगने वाला समय, सबसे अहम फ़ैक्टर है जिसे ऑप्टिमाइज़ किया जाता है. हालांकि, सबसे सही रास्ता तय करते समय, दूरी, टर्न की संख्या, और कई अन्य फ़ैक्टर को भी ध्यान में रखा जा सकता है. रास्ता बताने वाली सेवा के लिए, सभी वेपॉइंट स्टॉपओवर होने चाहिए, ताकि वह रास्ते को ऑप्टिमाइज़ कर सके.
अगर आपने Directions सेवा को निर्देश दिया है कि वह रास्ते के पड़ावों के क्रम को ऑप्टिमाइज़ करे, तो उनका क्रम, रूट ऑब्जेक्ट में मौजूद 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 ]
आगे क्या करना है
निर्देशों के उदाहरण
- यात्रा के मोड
- ट्रैफ़िक की जानकारी
- वेपॉइंट और वेपॉइंट ऑप्टिमाइज़ेशन
- रास्ते की पाबंदियां
- यूनिट सिस्टम
- क्षेत्र के हिसाब से नतीजे दिखाना
- जगह की जानकारी के मॉडिफ़ायर
रास्ते की जानकारी पाने के अनुरोधों के जवाब
- DirectionsResponse
- DirectionsRoute
- DirectionsLeg
- DirectionsStep और DirectionsPolyline
- DirectionsTransitDetails
- DirectionsStatus
- DirectionsGeocodedWaypoint