שאלות נפוצות בנושא Isochrones API

איך מחשבים איזוכרון של נסיעה נכנסת "נסיעה לעבודה" (נסיעה אל יעד) לעומת איזוכרון של נסיעה יוצאת (נסיעה מ נקודת מוצא)?

בגרסה 1 של ה-API יש תמיכה בחישובים של נסיעות נכנסות ויוצאות באמצעות הפרמטר travelDirection (travel_direction):

• ‫FROM (יוצא): מחשב את האזור שאפשר להגיע אליו from מנקודת המוצא במסגרת מגבלת הזמן שצוינה. האפשרות הזו מתאימה לתרחישי שימוש כמו אזורי החלוקה או כיסוי שירות.

• ‫TO (נכנס): חישוב האזור שממנו אפשר להגיע to נקודת המוצא במסגרת מגבלת הזמן שצוינה. האפשרות הזו מתאימה לאפליקציות כמו תכונות של נסיעה לעבודה או קביעת אזורי איסוף סביב משרד מרכזי או מרכז תחבורה ציבורית.

הערה: מצולעים של FROM ו-TO לאותה נקודת מוצא ולאותו משך זמן יכולים להיות אסימטריים בכל מצב. הסיבות ל-DRIVE, TWO_WHEELER ו-BICYCLE כוללות רחובות חד-סטריים והגבלות פנייה. בDRIVE ובTWO_WHEELER, גם נתיבי כניסה לכביש מהיר, נתיבי יציאה ממנו ועומסי תנועה בכיוון מסוים משפיעים על הדירוג. בWALK ובBICYCLE, גם השיפוע חשוב כי הנסיעה בעלייה איטית יותר מאשר בירידה.

מה ההבדל בין ארבעת מצבי הנסיעה (DRIVE,‏ TWO_WHEELER,‏ BICYCLE ו-WALK)?

לכל מצב יש כללי גישה משלו לרשת הכבישים, עלויות פנייה ומודל מהירות:

• ‫DRIVE: מעבר בכבישים שניתן לנסוע בהם במהירויות שמופיעות בשלטים, במהירויות של תנועה חופשית או במהירויות של תנועה בזמן אמת (TRAFFIC_AWARE), עד 3,600 שניות (60 דקות).
• ‫TWO_WHEELER: נסיעה בכבישים שנגישים לכלי רכב דו-גלגליים ממונעים, עם מהירויות נמוכות יותר מאשר DRIVE בכבישים מהירים, ואפשרות למסלול TRAFFIC_AWARE, עד 3,600 שניות (60 דקות). כתוצאה מכך, איזוכרון של TWO_WHEELER גדול יותר מ-BICYCLE אבל קטן יותר מ-DRIVE לאורך כבישים מהירים.
• ‫BICYCLE: נסיעה ברחובות, בנתיבים לאופניים ובשבילים שמתאימים לאופניים, במהירויות שמותאמות לסוג הדרך ולשיפוע (לא כולל כבישים מהירים), עד 7,200 שניות (120 דקות).
• ‫WALK: מעבר במדרכות, בשבילים וברחובות להולכי רגל, עם מהירות הליכה שמותאמת לשיפוע (תוך התעלמות מהגבלות על כלי רכב בכבישים חד-סטריים), עד 7,200 שניות (120 דקות).

האם Isochrones API כולל מעבורות או מעברי מים?

לא. Isochrones API עובר רק דרך חיבורים של כבישים, גשרים, מנהרות ושבילים. מסלולי מעבורות ומעברי מים לא נכללים בכל אמצעי התחבורה. איים או חצאי איים שמחוברים רק באמצעות מעבורת לא ייכללו באיזוכרון שנוצר מהיבשת.

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

‫Isochrones API מתאים באופן דינמי את הרזולוציה של רשת החישוב המרחבי שלו על סמך הערכים של travel_duration ו-travel_mode שצוינו בבקשה:

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

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

למה לפעמים בקשה לאיזוכרון של קואורדינטה בתוך פארק, אגם או מתחם תעשייתי גדול מחזירה את השגיאה "לא נמצא"?

‫Isochrones API מחשב את זמני ההגעה באמצעות כבישים ושבילים. אם הקואורדינטות של נקודת המוצא שביקשתם לא נמצאות בכביש מוכר, ה-API צריך "להצמיד" את הנקודה לקטע התואם הקרוב ביותר לפני תחילת החישוב.

לכל אמצעי תחבורה יש מרחק הצמדה מקסימלי של כ-200 מטרים או פחות. בפרופילים WALK ו-BICYCLE נעשה שימוש במרחקים קצרים יותר מאשר בפרופילים DRIVE ו-TWO_WHEELER, ובפרופילים DRIVE ו-TWO_WHEELER המערכת מתעלמת מנתיבים להולכי רגל בלבד.

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

למה מופיעה שגיאה כשמבקשים מסלול מבוסס-תנועה להליכה או לרכיבה על אופניים?

מצב התנועה בזמן אמת (TRAFFIC_AWARE) נתמך במצבי הנסיעה DRIVE ו-TWO_WHEELER. אם תנסו לבקש איזוכרון ל-WALK או ל-BICYCLE כשהערך של routingPreference מוגדר כ-TRAFFIC_AWARE, ה-API יחזיר שגיאה מסוג 400 INVALID_ARGUMENT.

כשאני מעבד את התגובה של GeoJSON במפה, הצורה מוצגת במקום הלא נכון, מעוותת או לא מעובדת. מה גורם לזה?

הסיבה לכך היא כמעט תמיד חוסר התאמה בסדר הקואורדינטות.

בהתאם לתקן GeoJSON‏ (RFC 7946), ה-Isochrones API מחזיר קואורדינטות בסדר של [longitude, latitude]. עם זאת, בהרבה ערכות SDK למיפוי ובאובייקטים גיאומטריים בהתאמה אישית, הקואורדינטות צריכות להיות בסדר של [latitude, longitude].

אם העיבוד של המפה שגוי, צריך לבדוק איך ה-SDK של המפה מטפל ב-GeoJSON:

• Google Maps JavaScript API: אם אתם משתמשים בשכבת הנתונים (map.data.addGeoJson()), הסדר הזה מטופל באופן מקורי ואין צורך לבצע פעולה כלשהי.
• אובייקטים בהתאמה אישית או ערכות SDK אחרות: אם אתם מנתחים את התגובה באופן ידני לאובייקטים מסוג LatLng, אתם צריכים לעבור בלולאה על הקואורדינטות במטען הייעודי (payload) של GeoJSON ולהמיר את הערכים של [lng, lat] לזוגות של [lat, lng] לפני העיבוד.

למה יש "חורים" ריקים בתוך פוליגון האיזוכרון שלי, והאם אפשר לקבל צורה מלאה במקום זאת?

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

ב-API החיצוני בגרסה 1 אין פרמטר להסרה אוטומטית של חורים. אם באפליקציה שלכם נדרש גבול מוצק, למשל כדי לבצע בדיקות הכלה של נקודה במצולע, אתם יכולים:

• מגדירים את הפרמטר polygon_fidelity לערך MEDIUM או LOW כדי לעודד את האלגוריתם להכליל ולמזג את הפערים הפנימיים האלה.
• משתמשים בספריית GIS בצד הלקוח (כמו Turf.js) כדי לנתח את ה-GeoJSON ולחלץ רק את טבעת הקואורדינטות הראשונה (המעטפת החיצונית), תוך התעלמות מכל הטבעות הפנימיות הבאות (החורים).

האם כדאי להפעיל את האפשרות enable_smoothing לניתוח מרחבי בקצה העורפי?

לא. הפרמטר enable_smoothing נועד רק למטרות אסתטיקה חזותית. הוא מעגל את הפינות החדות של רשת החישוב הבסיסית כדי שהצורה תיראה טבעית במפה.

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