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

החלקה ודיוק

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

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

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

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

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

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

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

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

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

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

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

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