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