שיטות מומלצות לשימוש ב-Isochrones API

החלקה ודיוק

אפשר להתאים אישית את המראה והדיוק של מצולעי הפלט באמצעות הפרמטרים polygon_fidelity ו-enable_smoothing. האפשרויות האלה פועלות באופן עצמאי, אבל הן משולבות כדי לקבוע את הצורה הסופית.

• ‫polygon_fidelity: הפתרון. ההגדרה קובעת את הגודל של תאי הרשת הבסיסיים (תאי S2) שמשמשים לחישוב האזור שאפשר להגיע אליו.
  • ‫LOW: משתמש בתאים גדולים יותר ברשת. האפשרות הכי טובה לכיסוי אזורים גדולים ללא פערים, וכתוצאה מכך מתקבלת צורה כללית.
  • ‫MEDIUM: דיוק מאוזן.
  • ‫HIGH: משתמש בתאים קטנים יותר ברשת. התוצאה היא התאמה טובה יותר לרשת הכבישים, אבל יכול להיות שיווצרו אזורים ריקים או 'חורים' במקומות שבהם רשת הכבישים דלילה.
  • ברירת מחדל: אם לא מציינים את הפרמטר הזה, השירות בוחר באופן דינמי את רמת הדיוק בהתאם למשך הנסיעה המבוקש.

טיפ: צמצום החורים במצולעים
מכיוון שחישוב האיזוֹכרוֹנוֹת מתבסס על רשת הכבישים בפועל, אזורים עם כבישים דלילים, כמו פארקים גדולים, אזורים פרטיים שלא מופיעים במפה או אזורי תעשייה, יכולים להופיע באופן טבעי כ'חורים' לא נגישים בתוך המצולע שנוצר. אם התרחיש לדוגמה שלכם מחייב היקף גיאוגרפי מוצק וכללי ללא הפערים האלה, צריך להגדיר באופן מפורש את polygon_fidelity לערך MEDIUM או LOW.

• ‫enable_smoothing: האסתטיקה. ההגדרה הזו קובעת אם הפינות החדות של תאי הרשת שמוגדרים על ידי רמת הדיוק יעוגלו.
  • ‫false (Raw): מחזירה את החישוב הגיאומטרי המדויק. הקצוות נראים משוננים או מדורגים, ומשקפים את התאים ברשת. הכי מתאים לדיוק אנליטי, כמו בדיקות קפדניות של נקודה בתוך מצולע.
  • ‫true (החלקה): החלת אלגוריתם לעיבוד בדיעבד כדי לעגל את הפינות. האפשרות הטובה ביותר להצגה חזותית במפות.

איך הם פועלים: רמת הדיוק קובעת את רמת הפירוט הבסיסית שעליה פועל אלגוריתם ההחלקה.

• איכות גבוהה + החלקה: יוצר צורה מפורטת שנראית אורגנית, שמתאימה לסיומי כבישים.
• נאמנות נמוכה + החלקה: יוצר צורה רחבה וכללית של 'כתם'.

גודל המטען הייעודי החזותי ועיבוד שלו

איזוכרונות גדולים יכולים להכיל אלפי קואורדינטות, והמטען הייעודי יכול להיות בין 300 ל-500 קילובייט.

• רוחב פס: חשוב לדעת שגודל תגובת ה-JSON משמעותי לבקשות של משך זמן מקסימלי.
• רינדור: רינדור של מצולעים מפורטים מאוד משפיע על הביצועים. כדאי להשתמש בפרמטר enable_smoothing או בספריות פשוטות בצד הלקוח כדי לצמצם את מספר הקודקודים לתצוגה.

טיפול בשגיאות

הטמעת לוגיקה של ניסיון חוזר עם השהיה מעריכית לפני ניסיון חוזר (exponential backoff) לשגיאות שרת 5xx. עם זאת, אין לנסות שוב שגיאות לקוח 4xx בלי לשנות את הפרמטרים:

• ‫INVALID_ARGUMENT (400): מוודאים שהמשך חיובי ולא חורג מהמגבלה של המצב שנבחר, שהיא 3,600 שניות לכל היותר למצבים DRIVE ו-TWO_WHEELER, או 7,200 שניות למצבים אחרים.
• ‫NOT_FOUND (404): נקודת המוצא לא הצליחה להיצמד אל כביש. כדאי לנסות להזיז את הקואורדינטה קרוב יותר לרחוב מוכר או לוודא שהאזור נתמך.