पैदल चलने या साइकल चलाने के लिए, दो घंटे तक का आइसोक्रोन का अनुरोध क्यों किया जा सकता है, जबकि गाड़ी चलाने के लिए यह सीमा एक घंटे तक ही है?
यह सीमा, कैलकुलेशन की कंप्यूटेशनल जटिलता पर आधारित है. किसी वाहन से, पैदल चलने या साइकल चलाने वाले व्यक्ति की तुलना में, तय समय में ज़्यादा दूरी तय की जा सकती है. इसका मतलब है कि सड़क नेटवर्क का विश्लेषण करने के लिए, यह सीमा तेज़ी से बढ़ती है. गाड़ी चलाने के लिए, ज़्यादा से ज़्यादा एक घंटे (3,600 सेकंड) की सीमा तय की गई है. इससे यह पक्का किया जाता है कि एपीआई, रीयल-टाइम में सिंक होने वाली विंडो में तुरंत जवाब दे सके. वहीं, पैदल चलने और साइकल चलाने के लिए, दो घंटे (7,200 सेकंड) तक की सीमा तय की गई है.
काम पर जाने के लिए, "कम्यूट-टू-वर्क" आइसोक्रोन (किसी जगह पर जाना) और किसी जगह से आने के लिए आइसोक्रोन की कैलकुलेशन कैसे की जाती है?
v1 एपीआई में, travel_direction पैरामीटर का इस्तेमाल करके, किसी जगह पर जाने और वहां से आने, दोनों के लिए कैलकुलेशन की जा सकती है:
FROM(किसी जगह से): तय समय में, शुरुआती पॉइंट से तय की जा सकने वाली दूरी की कैलकुलेशन करता है.fromयह डिलीवरी ज़ोन या सेवा कवरेज जैसे इस्तेमाल के मामलों के लिए सही है.TO(किसी जगह पर): तय समय में, शुरुआती पॉइंटtoतक तय की जा सकने वाली दूरी की कैलकुलेशन करता है. यह कम्यूट-टू-वर्क जैसी सुविधाओं या किसी ऑफ़िस या ट्रांज़िट हब के आस-पास के कैचमेंट ज़ोन तय करने जैसे ऐप्लिकेशन के लिए सही है.
कभी-कभी, दिखाया गया पॉलीगॉन ब्लॉक जैसा दिखता है या उसकी किनारे वाली लाइनें, सीढ़ी की तरह दिखती हैं. ऐसा खास तौर पर, ज़्यादा समय के लिए अनुरोध करने पर होता है. डिटेल का लेवल क्यों बदलता है?
Isochrones API, अनुरोध किए गए travel_duration और travel_mode के आधार पर, स्पेस से जुड़ी कैलकुलेशन के ग्रिड का रिज़ॉल्यूशन डाइनैमिक तरीके से अडजस्ट करता है:
- कम समय के लिए: ज़्यादा रिफ़ाइन और हाई-रिज़ॉल्यूशन वाले ग्रिड का इस्तेमाल करें, क्योंकि कुल एरिया छोटा होता है. इससे, बाउंड्री की ज़्यादा जानकारी मिलती है.
- ज़्यादा समय के लिए: बड़े भौगोलिक एरिया को आसानी से कवर करने के लिए, कम रिज़ॉल्यूशन वाले ग्रिड पर ट्रांज़िशन करें. इससे, लेटेन्सी की समस्या नहीं होती.
अगर आपको समय के हिसाब से, एक जैसा और खास लेवल की जानकारी चाहिए, तो polygon_fidelity को HIGH, MEDIUM या LOW पर सेट किया जा सकता है.
कभी-कभी, किसी पार्क, झील या बड़े इंडस्ट्रियल कॉम्प्लेक्स में मौजूद किसी कोऑर्डिनेट के लिए आइसोक्रोन का अनुरोध करने पर, "Not Found" गड़बड़ी क्यों दिखती है?
Isochrones API, सड़कों और पाथवे का इस्तेमाल करके, यात्रा में लगने वाले समय की कैलकुलेशन करता है. अगर अनुरोध किए गए शुरुआती कोऑर्डिनेट, किसी मान्य सड़क पर मौजूद नहीं हैं, तो एपीआई को कैलकुलेशन शुरू करने से पहले, पॉइंट को सबसे नज़दीकी मान्य सेगमेंट पर "स्नैप" करना होगा.
हर ट्रैवल मोड के लिए, स्नैपिंग की ज़्यादा से ज़्यादा दूरी का थ्रेशोल्ड तय किया गया है:
DRIVE: 200 मीटर (सिर्फ़ पैदल चलने के लिए बने रास्तों को अनदेखा करता है).BICYCLE: 180 मीटर.WALK: 150 मीटर.
अगर आपका शुरुआती कोऑर्डिनेट, मान्य और मोड के हिसाब से सही सड़क सेगमेंट से इन थ्रेशोल्ड से ज़्यादा दूरी पर है, तो स्नैपिंग की प्रोसेस पूरी नहीं हो पाती. साथ ही, एपीआई NOT_FOUND गड़बड़ी दिखाता है. इस समस्या को हल करने के लिए, पक्का करें कि आपके कोऑर्डिनेट, किसी सार्वजनिक सड़क या पाथवे के आस-पास मौजूद हों.
पैदल चलने या साइकल चलाने के लिए, ट्रैफ़िक की जानकारी के साथ रूटिंग का अनुरोध करने पर मुझे गड़बड़ी क्यों दिखती है?
लाइव ट्रैफ़िक का हाल (TRAFFIC_AWARE) सिर्फ़ DRIVE यात्रा मोड के लिए उपलब्ध है. अगर आपने routingPreference को TRAFFIC_AWARE पर सेट करके, WALK या BICYCLE के लिए आइसोक्रोन का अनुरोध किया, तो एपीआई 400 INVALID_ARGUMENT गड़बड़ी दिखाएगा.
जब मैं अपने मैप पर GeoJSON रिस्पॉन्स रेंडर करता/करती हूं, तो आकार गलत जगह पर दिखता है, खराब दिखता है या रेंडर नहीं होता. इसकी वजह क्या है?
ऐसा अक्सर कोऑर्डिनेट के क्रम में गड़बड़ी की वजह से होता है.
GeoJSON स्टैंडर्ड (RFC 7946) के मुताबिक, Isochrones API, कोऑर्डिनेट को [longitude, latitude] क्रम में दिखाता है. हालांकि, मैपिंग के कई एसडीके और कस्टम ज्यामिति ऑब्जेक्ट, कोऑर्डिनेट को [latitude, longitude] क्रम में दिखाते हैं.
अगर आपका मैप सही तरीके से रेंडर नहीं हो रहा है, तो देखें कि आपका मैप एसडीके, GeoJSON को कैसे हैंडल करता है:
- Google Maps JavaScript API: अगर Data Layer (
map.data.addGeoJson()) का इस्तेमाल किया जा रहा है, तो इस क्रम को नेटिव तरीके से हैंडल किया जाता है. इसके लिए, किसी कार्रवाई की ज़रूरत नहीं होती. - कस्टम ऑब्जेक्ट या अन्य एसडीके: अगर रिस्पॉन्स को मैन्युअल तरीके से
LatLngऑब्जेक्ट में पार्स किया जा रहा है, तो आपको GeoJSON पेलोड में मौजूद कोऑर्डिनेट के लिए लूप करना होगा. साथ ही, रेंडर करने से पहले,[lng, lat]वैल्यू को[lat, lng]पेयर में ट्रांसपोज़ करना होगा.
मेरे आइसोक्रोन पॉलीगॉन में, खोखले "होल" क्यों दिखते हैं? क्या मुझे इसके बजाय, सॉलिड आकार मिल सकता है?
होल उन एरिया को दिखाते हैं जहां तय समय में, कोई सड़क नहीं है. ऐसा अक्सर उन इलाकों में होता है जहां बड़े जंगल, जलाशय, एयरपोर्ट या निजी प्रॉपर्टी मौजूद होती हैं. इन जगहों पर, वाहन या पैदल चलने वाले लोग नहीं जा सकते.
एक्सटर्नल v1 एपीआई में, होल को अपने-आप हटाने के लिए कोई पैरामीटर नहीं है. अगर आपके ऐप्लिकेशन के लिए सॉलिड बाउंड्री की ज़रूरत है, तो उदाहरण के लिए, पॉइंट-इन-पॉलीगॉन कंटेनमेंट की जांच करने के लिए, यह तरीका अपनाएं:
- एल्गोरिदम को सामान्य बनाने और इन इंटरनल गैप को मर्ज करने के लिए,
polygon_fidelityपैरामीटर कोMEDIUMयाLOWपर सेट करें. - GeoJSON को पार्स करने और सिर्फ़ पहले कोऑर्डिनेट रिंग (एक्सटीरियर शेल) को एक्सट्रैक्ट करने के लिए, क्लाइंट-साइड जीआईएस लाइब्रेरी (जैसे, Turf.js) का इस्तेमाल करें. इसके बाद, अंदर की रिंग (होल) को छोड़ दें.
क्या मुझे बैकएंड स्पेस से जुड़े विश्लेषण के लिए, enable_smoothing विकल्प चालू करना चाहिए?
नहीं. enable_smoothing पैरामीटर, सिर्फ़ विज़ुअल डिज़ाइन के लिए बनाया गया है.
यह मैप पर आकार को ऑर्गैनिक दिखाने के लिए, कैलकुलेशन ग्रिड के नुकीले कोनों को राउंड ऑफ़ करता है.
सटीक स्पेस से जुड़े विश्लेषण के लिए, स्मूदिंग का इस्तेमाल करने का सुझाव नहीं दिया जाता, क्योंकि इससे वर्टिकल में बदलाव होता है और बाउंड्री थोड़ी बदल जाती हैं. बैकएंड कैलकुलेशन, डेटाबेस क्वेरी या पॉइंट-इन-पॉलीगॉन टेस्ट के लिए, enable_smoothing को false पर सेट रखें. इससे, यह पक्का किया जा सकेगा कि आप गणित के हिसाब से सटीक कैलकुलेट की गई बाउंड्री का इस्तेमाल कर रहे हैं.