Package google.maps.routes.v1alpha

इंडेक्स

• RoutesAlpha (इंटरफ़ेस)

RoutesAlpha

The Routes Preferred API.

ComputeCustomRoutes

rpc ComputeCustomRoutes(ComputeCustomRoutesRequest) returns (ComputeCustomRoutesResponse) टर्मिनल और इंटरमीडिएट वेपॉइंट के सेट और रूट का मकसद दिए जाने पर, रूट के मकसद के लिए सबसे अच्छे रूट की गिनती करता है. सबसे तेज़ और सबसे छोटे रास्ते को रेफ़रंस के तौर पर भी दिखाता है. ध्यान दें: इस तरीके का इस्तेमाल करने के लिए, आपको इनपुट में रिस्पॉन्स फ़ील्ड मास्क तय करना होगा. यूआरएल पैरामीटर $fields या fields का इस्तेमाल करके या एचटीटीपी/gRPC हेडर X-Goog-FieldMask का इस्तेमाल करके, रिस्पॉन्स फ़ील्ड मास्क उपलब्ध कराया जा सकता है. उपलब्ध यूआरएल पैरामीटर और हेडर देखें. यह वैल्यू, कॉमा लगाकर अलग की गई फ़ील्ड पाथ की सूची होती है. फ़ील्ड पाथ बनाने के तरीके के बारे में ज़्यादा जानकारी वाला दस्तावेज़ देखें. उदाहरण के लिए, इस तरीके से: सभी उपलब्ध फ़ील्ड का फ़ील्ड मास्क (मैन्युअल जांच के लिए): X-Goog-FieldMask: * रास्ते की दूरी, कुल दूरी, टोकन, और टोल की जानकारी का फ़ील्ड मास्क: X-Goog-FieldMask: routes.route.distanceMeters,routes.route.duration,routes.token,routes.route.travelAdvisory.tollInfo Google, वाइल्डकार्ड (*) रिस्पॉन्स फ़ील्ड मास्क या टॉप लेवल (routes) पर फ़ील्ड मास्क तय करने की सलाह नहीं देता, क्योंकि: सिर्फ़ अपनी ज़रूरत के फ़ील्ड चुनने से हमारे सर्वर को कंप्यूटेशन साइकल सेव करने में मदद मिलती है. इससे हम, इंतज़ार के समय को कम करके आपको नतीजे दे पाते हैं. प्रोडक्शन जॉब में सिर्फ़ उन फ़ील्ड को चुनने से, इंतज़ार का समय बेहतर होता है. हम आने वाले समय में, जवाब वाले और फ़ील्ड जोड़ सकते हैं. उन नए फ़ील्ड के लिए, कंप्यूटेशन के ज़्यादा समय की ज़रूरत हो सकती है. अगर आपने सभी फ़ील्ड चुने हैं या टॉप लेवल पर सभी फ़ील्ड चुने हैं, तो परफ़ॉर्मेंस में गिरावट आ सकती है. इसकी वजह यह है कि हम जो भी नया फ़ील्ड जोड़ते हैं वह जवाब में अपने-आप शामिल हो जाता है. सिर्फ़ उन फ़ील्ड को चुनने से रिस्पॉन्स साइज़ कम मिलता है जिनकी आपको ज़रूरत है. इससे नेटवर्क की क्षमता बढ़ जाती है. अनुमति पाने के लिंक नीचे दिए गए OAuth के लिंक की ज़रूरत हाेती है: https://www.googleapis.com/auth/maps-platform.routespreferred ज़्यादा जानकारी के लिए, OAuth 2.0 की खास जानकारी देखें.

ComputeRouteMatrix

rpc ComputeRouteMatrix(ComputeRouteMatrixRequest) returns (RouteMatrixElement) ऑरिजिन और डेस्टिनेशन की सूची लेता है. साथ ही, ऐसी स्ट्रीम दिखाता है जिसमें ऑरिजिन और डेस्टिनेशन के हर कॉम्बिनेशन के लिए रूट की जानकारी होती है. ध्यान दें: इस तरीके का इस्तेमाल करने के लिए, आपको इनपुट में रिस्पॉन्स फ़ील्ड मास्क तय करना होगा. यूआरएल पैरामीटर $fields या fields का इस्तेमाल करके या एचटीटीपी/gRPC हेडर X-Goog-FieldMask का इस्तेमाल करके, रिस्पॉन्स फ़ील्ड मास्क उपलब्ध कराया जा सकता है. उपलब्ध यूआरएल पैरामीटर और हेडर देखें. यह वैल्यू, कॉमा लगाकर अलग की गई फ़ील्ड पाथ की सूची होती है. फ़ील्ड पाथ बनाने के तरीके के बारे में ज़्यादा जानकारी वाला दस्तावेज़ देखें. उदाहरण के लिए, इस तरीके से: सभी उपलब्ध फ़ील्ड का फ़ील्ड मास्क (मैन्युअल जांच के लिए): X-Goog-FieldMask: * रूट की अवधि, दूरी, एलिमेंट के स्टेटस, स्थिति, और एलिमेंट इंडेक्स का फ़ील्ड मास्क (उदाहरण के लिए, प्रोडक्शन सेटअप): X-Goog-FieldMask: originIndex,destinationIndex,status,condition,distanceMeters,duration यह ज़रूरी है कि आप status को अपने फ़ील्ड मास्क में शामिल करें. ऐसा न करने पर, सभी मैसेज 'ठीक है' के तौर पर दिखेंगे. Google, वाइल्डकार्ड (*) रिस्पॉन्स फ़ील्ड मास्क के इस्तेमाल की सलाह नहीं देता, क्योंकि: सिर्फ़ अपनी ज़रूरत के फ़ील्ड चुनने से हमारे सर्वर को कंप्यूटेशन साइकल सेव करने में मदद मिलती है. इससे हम, इंतज़ार के समय को कम करके आपको नतीजे दे पाते हैं. प्रोडक्शन जॉब में सिर्फ़ उन फ़ील्ड को चुनने से, इंतज़ार का समय बेहतर होता है. हम आने वाले समय में, जवाब वाले और फ़ील्ड जोड़ सकते हैं. उन नए फ़ील्ड के लिए, कंप्यूटेशन के ज़्यादा समय की ज़रूरत हो सकती है. अगर आपने सभी फ़ील्ड चुने हैं या टॉप लेवल पर सभी फ़ील्ड चुने हैं, तो परफ़ॉर्मेंस में गिरावट आ सकती है. इसकी वजह यह है कि हम जो भी नया फ़ील्ड जोड़ते हैं वह जवाब में अपने-आप शामिल हो जाता है. सिर्फ़ उन फ़ील्ड को चुनने से रिस्पॉन्स साइज़ कम मिलता है जिनकी आपको ज़रूरत है. इससे नेटवर्क की क्षमता बढ़ जाती है. अनुमति पाने के लिंक नीचे दिए गए OAuth के लिंक की ज़रूरत हाेती है: https://www.googleapis.com/auth/maps-platform.routespreferred ज़्यादा जानकारी के लिए, OAuth 2.0 की खास जानकारी देखें.

ComputeRoutes

rpc ComputeRoutes(ComputeRoutesRequest) returns (ComputeRoutesResponse) टर्मिनल और बीच के वेपॉइंट के सेट के आधार पर, वैकल्पिक रास्तों के साथ मुख्य रास्ता दिखाता है. ध्यान दें: इस तरीके का इस्तेमाल करने के लिए, आपको इनपुट में रिस्पॉन्स फ़ील्ड मास्क तय करना होगा. यूआरएल पैरामीटर $fields या fields का इस्तेमाल करके या एचटीटीपी/gRPC हेडर X-Goog-FieldMask का इस्तेमाल करके, रिस्पॉन्स फ़ील्ड मास्क उपलब्ध कराया जा सकता है. उपलब्ध यूआरएल पैरामीटर और हेडर देखें. यह वैल्यू, कॉमा लगाकर अलग की गई फ़ील्ड पाथ की सूची होती है. फ़ील्ड पाथ बनाने के तरीके के बारे में ज़्यादा जानकारी वाला दस्तावेज़ देखें. उदाहरण के लिए, इस तरीके से: सभी उपलब्ध फ़ील्ड का फ़ील्ड मास्क (मैन्युअल जांच के लिए): X-Goog-FieldMask: * रूट-लेवल पर दूरी, दूरी, और पॉलीलाइन का फ़ील्ड मास्क (उदाहरण के लिए, प्रोडक्शन सेटअप): X-Goog-FieldMask: routes.duration,routes.distanceMeters,routes.polyline.encodedPolyline Google, वाइल्डकार्ड (*) रिस्पॉन्स फ़ील्ड मास्क या टॉप लेवल (routes) पर फ़ील्ड मास्क तय करने की सलाह नहीं देता, क्योंकि: सिर्फ़ अपनी ज़रूरत के फ़ील्ड चुनने से हमारे सर्वर को कंप्यूटेशन साइकल सेव करने में मदद मिलती है. इससे हम, इंतज़ार के समय को कम करके आपको नतीजे दे पाते हैं. प्रोडक्शन जॉब में सिर्फ़ उन फ़ील्ड को चुनने से, इंतज़ार का समय बेहतर होता है. हम आने वाले समय में, जवाब वाले और फ़ील्ड जोड़ सकते हैं. उन नए फ़ील्ड के लिए, कंप्यूटेशन के ज़्यादा समय की ज़रूरत हो सकती है. अगर आपने सभी फ़ील्ड चुने हैं या टॉप लेवल पर सभी फ़ील्ड चुने हैं, तो परफ़ॉर्मेंस में गिरावट आ सकती है. इसकी वजह यह है कि हम जो भी नया फ़ील्ड जोड़ते हैं वह जवाब में अपने-आप शामिल हो जाता है. सिर्फ़ उन फ़ील्ड को चुनने से रिस्पॉन्स साइज़ कम मिलता है जिनकी आपको ज़रूरत है. इससे नेटवर्क की क्षमता बढ़ जाती है. अनुमति पाने के लिंक नीचे दिए गए OAuth के लिंक की ज़रूरत हाेती है: https://www.googleapis.com/auth/maps-platform.routespreferred ज़्यादा जानकारी के लिए, OAuth 2.0 की खास जानकारी देखें.