स्मूदिंग और फ़िडेलिटी
polygon_fidelity और enable_smoothing पैरामीटर का इस्तेमाल करके, आउटपुट पॉलीगॉन के दिखने के तरीके और सटीक जानकारी को पसंद के मुताबिक बनाया जा सकता है. ये विकल्प अलग-अलग होते हैं, लेकिन ये एक साथ काम करके फ़ाइनल शेप तय करते हैं.
polygonFidelity(polygon_fidelity): समस्या का समाधान. इससे, स्पेसियल ग्रिड सेल के साइज़ को कंट्रोल किया जाता है. इन सेल का इस्तेमाल, पैदल या ड्राइव करके पहुंचने की जगह का हिसाब लगाने के लिए किया जाता है.LOW: यह सबसे बड़े ग्रिड सेल (कई सौ मीटर चौड़े) का इस्तेमाल करता है. यह बिना किसी गैप के बड़े इलाकों को कवर करने और वर्टेक्स की संख्या को कम करने के लिए सबसे सही है. इससे एक सामान्य आकार बनता है, जो संकरी सड़कों के आस-पास के इलाकों को ज़्यादा दिखा सकता है.MEDIUM: सटीक जानकारी और पेलोड साइज़ के बीच संतुलन.HIGH: इसमें सबसे छोटे ग्रिड सेल का इस्तेमाल किया जाता है. ये करीब 100 से 150 मीटर के होते हैं. इससे रोड नेटवर्क के साथ बेहतर तरीके से फ़िट होने वाले नतीजे मिलते हैं. साथ ही, ज़्यादा वर्टिसेस मिलते हैं. हालांकि, जहां रोड नेटवर्क कम है वहां अंदरूनी छेद हो सकते हैं.- डिफ़ॉल्ट (
POLYGON_FIDELITY_UNSPECIFIED): अगर कोई वैल्यू नहीं दी गई है, तो सेवा यात्रा के मोड और अवधि के आधार पर रिज़ॉल्यूशन को अपने-आप चुनती है. इसके लिए, कम अवधि औरWALKके लिए बेहतर सेल और लंबी अवधि के लिए मोटे सेल का इस्तेमाल किया जाता है. अलग-अलग समयावधि या यात्रा के मोड के लिए आइसोक्रोन की तुलना करने के लिए,polygonFidelityको साफ़ तौर पर सेट करें, ताकि वे एक ही रिज़ॉल्यूशन का इस्तेमाल करें.
सेल के साइज़ अनुमानित हैं. बहुत बड़े आइसोक्रोन को और सामान्य बनाया जा सकता है, ताकि रिस्पॉन्स का साइज़ मैनेज किया जा सके.
enableSmoothing(enable_smoothing): द एस्थेटिक. यह नीति कंट्रोल करती है कि फ़िडेलिटी के हिसाब से तय किए गए ग्रिड सेल के किनारों को गोल किया जाए या नहीं.false(Raw): यह ग्रिड के हिसाब से अलाइन की गई बाउंड्री दिखाता है. किनारे, आरी जैसे या सीढ़ीदार दिखते हैं. इससे ग्रिड सेल का पता चलता है. यह सटीक विश्लेषण के लिए सबसे सही है. जैसे, पॉइंट-इन-पॉलिगॉन टेस्ट.true(स्मूद): यह हर रिंग के एरिया को करीब-करीब सुरक्षित रखते हुए, कोनों को गोल करता है. मैप पर विज़ुअल दिखाने के लिए सबसे सही. बाउंड्री अब ग्रिड सेल के मुताबिक नहीं है. इसलिए, पॉलीगॉन में पॉइंट की जांच के लिए इसका इस्तेमाल न करें.
ये दोनों आपस में कैसे इंटरैक्ट करते हैं: फ़िडेलिटी, बेसलाइन जानकारी सेट करती है. इसके बाद, स्मूथिंग एल्गोरिदम इस जानकारी पर काम करता है.
- हाई फ़िडेलिटी + स्मूथिंग: इससे सड़क के आखिरी हिस्सों को बारीकी से दिखाने वाला, ऑर्गैनिक दिखने वाला आकार बनता है.
- कम फ़िडेलिटी + स्मूदिंग: इससे एक बड़ा और सामान्य "ब्लॉब" आकार बनता है.
पेलोड का साइज़ और रेंडरिंग
बड़े आइसोक्रोन (खास तौर पर, HIGH फ़िडेलिटी वाले लंबे समय के अनुरोध) में हज़ारों निर्देशांक हो सकते हैं. साथ ही, कंप्रेस नहीं किए गए JSON रिस्पॉन्स का साइज़ कई सौ किलोबाइट या उससे ज़्यादा हो सकता है.
- बैंडविड्थ: ध्यान रखें कि ज़्यादा अवधि वाले अनुरोधों के लिए, JSON रिस्पॉन्स का साइज़ काफ़ी बड़ा होता है.
- रेंडरिंग: बहुत ज़्यादा जानकारी वाले पॉलीगॉन रेंडर करने से, क्लाइंट की परफ़ॉर्मेंस पर असर पड़ता है. वर्टेक्स की संख्या और पेलोड का साइज़ कम करने के लिए,
polygonFidelity: MEDIUMयाLOWचुनें. इसके अलावा, रेंडर करने से पहले क्लाइंट पर ज्यामिति को आसान बनाएं. इसके लिए, डगलस-प्यूकर जैसे लाइन-सिंप्लिफ़िकेशन एल्गोरिदम का इस्तेमाल करें.
लेटेंसी और क्लाइंट टाइम आउट
जवाब मिलने में लगने वाला समय, तय की गई दूरी के हिसाब से बढ़ता है: कम समय और WALK और BICYCLE मोड सबसे तेज़ होते हैं. वहीं, लंबी DRIVE और TWO_WHEELER के अनुरोधों (खास तौर पर TRAFFIC_AWARE के साथ) में सबसे ज़्यादा समय लगता है.
- क्लाइंट टाइम आउट के लिए सुझाई गई अवधि: एचटीटीपी या gRPC क्लाइंट की समयसीमा को कम से कम 30 सेकंड पर कॉन्फ़िगर करें, ताकि क्लाइंट टाइम आउट की कम अवधि की वजह से, लंबे अनुरोधों को जल्दी रद्द न किया जाए.
गड़बड़ी ठीक करना
429
RESOURCE_EXHAUSTED रेट-लिमिट रिस्पॉन्स और 5xx सर्वर की गड़बड़ियों के लिए, एक्स्पोनेंशियल बैकऑफ़ और जिटर के साथ फिर से कोशिश करने का लॉजिक लागू करें. अपने अनुरोध में बदलाव किए बिना, 400, 403 या 404 क्लाइंट गड़बड़ियों को फिर से ठीक करने की कोशिश न करें:
INVALID_ARGUMENT (400): देखें किtravelDuration,1sऔर3600s(DRIVE/TWO_WHEELER) या7200s(WALK/BICYCLE) के बीच में हो,locationको छोड़ा न गया हो और वह(0, 0)न हो (याplaceएक मान्य जगह का आईडी हो), औरTRAFFIC_AWAREका इस्तेमाल सिर्फ़DRIVEयाTWO_WHEELERके साथ किया गया हो. अगरlatitudeयाlongitudeको शामिल नहीं किया जाता है, तो उसे0.0माना जाता है. इसलिए, इनमें से सिर्फ़ एक को शामिल न करने पर, आम तौर पर400गड़बड़ी नहीं होती है. हालांकि, ऐसा तब होता है, जब दूसरी वैल्यू भी0.0हो. अगर आइसोक्रोन गलत जगह पर दिखता है, तो दोनों वैल्यू की दोबारा जांच करें.PERMISSION_DENIED (403): पुष्टि करें कि आपके एपीआई पासकोड या OAuth टोकन को शामिल किया गया है. साथ ही, आपके Google Cloud प्रोजेक्ट पर Isochrones API और बिलिंग की सुविधा चालू है.NOT_FOUND (404):placeको किसी जगह से नहीं जोड़ा जा सका या यात्रा के मोड के हिसाब से, शुरुआती जगह को आस-पास की किसी सड़क से नहीं जोड़ा जा सका. जैसे,WALKऔरBICYCLEके लिए, करीब 200 मीटर या उससे कम दूरी पर मौजूद सड़क.RESOURCE_EXHAUSTED (429): आपके प्रोजेक्ट ने हर मिनट के अनुरोध का कोटा पार कर लिया है. डिफ़ॉल्ट रूप से, हर मिनट 300 अनुरोध किए जा सकते हैं. एक्स्पोनेंशियल बैकऑफ़ के साथ फिर से कोशिश करें.