למה אפשר לבקש איזוכרון של הליכה או רכיבה על אופניים למשך שעתיים, אבל נסיעה מוגבלת לשעה אחת?
המגבלה הזו מבוססת על מורכבות החישובים. רכב נוסע מרחק גדול בהרבה מהמרחק שהולך רגל או רוכב אופניים עוברים באותו פרק זמן, ולכן רשת הכבישים הבסיסית שצריך לנתח מתרחבת באופן אקספוננציאלי. הנסיעה מוגבלת לשעה אחת לכל היותר (3,600 שניות) כדי להבטיח שה-API יוכל להחזיר תגובה במהירות, בזמן אמת ובאופן סינכרוני. הליכה ורכיבה על אופניים נתמכות למשך שעתיים לכל היותר (7,200 שניות).
איך מחשבים איזוכרון של נסיעה לעבודה (נסיעה אל יעד) לעומת איזוכרון של נסיעה מהעבודה (נסיעה מנקודת מוצא)?
גם חישובים של תעבורה נכנסת וגם חישובים של תעבורה יוצאת נתמכים ב-API בגרסה 1 באמצעות הפרמטר travel_direction:
FROM(Outbound): מחשבת את השטח שאפשר להגיע אליוfromמנקודת המוצא בתוך מגבלת הזמן שצוינה. האפשרות הזו מתאימה לתרחישי שימוש כמו אזורי משלוח או כיסוי שירות.
TO(Inbound): מחשב את השטח שממנו אפשר להגיעtoלנקודת המוצא במסגרת מגבלת הזמן שצוינה. האפשרות הזו מתאימה לאפליקציות כמו תכונות שקשורות לנסיעה לעבודה או לקביעת אזורי השפעה מסביב למשרד מרכזי או למרכז תחבורה.
לפעמים הפוליגון שמוחזר נראה מגושם או עם קצוות משוננים ומדורגים, במיוחד אם משך הזמן ארוך יותר. למה רמת הפירוט משתנה?
ה-API של איזוכרונות מתאים באופן דינמי את הרזולוציה של רשת החישוב המרחבי שלו על סמך travel_duration וtravel_mode שנדרשו:
- משכי זמן קצרים יותר: צריך להשתמש ברשת ברזולוציה גבוהה עם דיוק רב, כי השטח הכולל קטן, ולכן הגבול מפורט.
- משכי זמן ארוכים יותר: מעבר לרשת גסה יותר ברזולוציה נמוכה יותר כדי לכסות את האזור הגיאוגרפי העצום בצורה יעילה בלי לגרום לזמן אחזור חמור.
אתם יכולים להגדיר את הערך האופציונלי polygon_fidelity ל-HIGH, ל-MEDIUM או ל-LOW אם אתם צריכים רמת פירוט ספציפית ועקבית, ללא קשר למשך הזמן.
למה כשמבקשים איזוכרון לקואורדינטה בתוך פארק, אגם או מתחם תעשייתי גדול, לפעמים מקבלים את השגיאה 'לא נמצא'?
Isochrones API מחשב את זמני הנסיעה באמצעות כבישים ושבילים. אם קואורדינטות המקור שביקשתם לא נמצאות על כביש מוכר, ה-API צריך 'להצמיד' את הנקודה לפלח התואם הקרוב ביותר לפני שהוא מתחיל את החישוב.
לכל אמצעי תחבורה יש סף מרחק הצמדה מקסימלי ספציפי:
-
DRIVE: 200 מטר (מתעלם משבילים להולכי רגל בלבד). -
BICYCLE: 180 מטרים. -
WALK: 150 מטרים.
אם קואורדינטת המוצא נמצאת במרחק גדול יותר מהסף הזה מקטע דרך תקין שתואם למצב, ההצמדה תיכשל וה-API יחזיר שגיאה NOT_FOUND. כדי לפתור את הבעיה, צריך לוודא שהקואורדינטות ממוקמות קרוב לרחוב או לשביל ציבורי.
למה מופיעה שגיאה כשמבקשים מסלול להליכה או לרכיבה על אופניים עם נתונים על עומסי תנועה?
תנאי התנועה בזמן אמת (TRAFFIC_AWARE) נתמכים רק במצב הנסיעה DRIVE. אם תנסו לבקש איזוכרון עבור WALK או BICYCLE עם הערך TRAFFIC_AWARE של routingPreference, ה-API יחזיר שגיאה 400 INVALID_ARGUMENT.
כשמציגים את תגובת ה-GeoJSON במפה, הצורה מוצגת במקום הלא נכון, מעוותת או לא מוצגת בכלל. מה גורם לזה?
הסיבה לכך היא כמעט תמיד אי-התאמה בסדר הקואורדינטות.
בהתאם לתקן GeoJSON (RFC 7946), Isochrones API מחזיר קואורדינטות בסדר [longitude, latitude]. עם זאת, הרבה ערכות SDK למיפוי ואובייקטים גיאומטריים מותאמים אישית מצפים לקואורדינטות בסדר [latitude, longitude].
אם רינדור המפה שגוי, כדאי לבדוק איך Map SDK מטפל ב-GeoJSON:
- Google Maps JavaScript API: אם אתם משתמשים בשכבת הנתונים (
map.data.addGeoJson()), הטיפול בסדר הזה מתבצע באופן מובנה ולא נדרשת פעולה. - אובייקטים בהתאמה אישית או ערכות SDK אחרות: אם אתם מנתחים ידנית את התגובה לאובייקטים מסוג
LatLng, אתם צריכים להשתמש בלולאה כדי לעבור על הקואורדינטות במטען הייעודי (payload) של GeoJSON ולהמיר את הערכים[lng, lat]לזוגות של[lat, lng]לפני העיבוד.
למה יש 'חורים' ריקים בתוך הפוליגון של איזוכרון, ואפשר לקבל צורה מלאה במקום?
החורים מייצגים אזורים שאין בהם כבישים שאפשר להגיע אליהם במסגרת מגבלת הזמן. הבעיה הזו נפוצה באזורים עם יערות גדולים, מקווי מים, שדות תעופה או נכסים פרטיים שבהם כלי רכב או הולכי רגל לא יכולים לעבור.
ממשק ה-API החיצוני v1 לא חושף פרמטר להסרה אוטומטית של חורים. אם האפליקציה שלכם דורשת גבול מוצק, למשל כדי לבצע בדיקות של נקודה בתוך מצולע, אתם יכולים:
- מגדירים את הפרמטר
polygon_fidelityלערךMEDIUMאוLOWכדי לעודד את האלגוריתם להכליל ולמזג את הפערים הפנימיים האלה. - משתמשים בספריית GIS בצד הלקוח (כמו Turf.js) כדי לנתח את GeoJSON ולחלץ רק את טבעת הקואורדינטות הראשונה (המעטפת החיצונית), ומתעלמים מכל הטבעות הפנימיות הבאות (החורים).
האם כדאי להפעיל את האפשרות enable_smoothing לניתוח מרחבי של הנתונים בעורף?
לא. הפרמטר enable_smoothing מיועד רק לשיפור האסתטיקה החזותית.
הוא מעגל את הפינות החדות של רשת החישוב הבסיסית כדי שהצורה תיראה אורגנית במפה.
לא מומלץ להשתמש בהחלקה לניתוח מרחבי מדויק, כי היא משנה את הקודקודים ומזיזה את הגבולות קצת. לחישובים בעורף, לשאילתות במסד נתונים או לבדיקות של נקודה בתוך מצולע, צריך להגדיר את enable_smoothing לערך false כדי לוודא שאתם משתמשים בגבול המחושב המדויק מבחינה מתמטית.