דרישות ל-GTFS

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

דרישות ברירת מחדל

הפניה ל-GTFS סטטי – כל דרישות ברירת המחדל מוחלות.

שיטות מומלצות ל-GTFS – מומלץ לפעול לפי השיטות המומלצות כאילו הן חובה.

העלאת פידים של GTFS – צריך לפעול לפי התהליך הזה כדי להעלות את פיד ה-GTFS.

עדכונים: שימו לב שאחרי העלאת הפידים, אפשר לעדכן אותם לפי התהליך שמתואר כאן. בדרך כלל, עדכון הפיד יכול להימשך 2-3 ימים עד להשלמתו.

דרישות נוספות

היקף

• כל פיד GTFS צריך לכלול נתונים של מדינה אחת או של חלק ממדינה. אם הנסיעות חוצות גבולות של מדינות, צריך לספק אותן בפידים נפרדים של יבשת שלמה. אם פיד GTFS מכסה אזור גדול יותר ממדינה, צריך לפנות אל צוות התחבורה של Google נסיעות.
  • הגודל של הקבצים בקובץ ה-ZIP של GTFS צריך להיות קטן מ-4GB. קבצים גדולים יותר בדרך כלל מעידים על שיטות עבודה לא טובות, כמו התעלמות מאפשרויות הדחיסה שמוצעות על ידי frequencies.txt או תכונות דומות. הדבר עלול לגרום לבעיות במהלך העיבוד. אם אתם חושבים שאתם צריכים קבצים גדולים מ-4GB, אתם יכולים לפנות לצוות של Google נסיעות ותחבורה בכתובת [e-mail].
  • בכל עדכון של נתוני GTFS, צריך לספק נתונים לגבי כל התקופה העתידית שבה השירותים יפעלו בפיד GTFS. אסור לבצע פילוח של שירותים לפי תקופות זמן שונות.
• כל התאריכים של מפעיל מסוים צריכים להיכלל בפיד אחד.

תרגומים

• אפשר לספק תרגומים באמצעות translations.txt, והם יידרשו במדינות שבהן:
  • יכול להיות שהמידע למשתמשים יופיע בסקריפטים שונים, או בסקריפטים שאינם לטיניים
  • אפשר לספק מידע למשתמשים בכמה שפות, או במקרים שבהם ישויות עשויות להשתמש בשמות שונים בשפות האלה (לדוגמה, בריסל/Brussel/Bruxelles)
• ישויות לתרגום
  • שמות של סוכנויות, תחנות או מסלולים
  • שילוט ליעד הנסיעה או לתחנה

שמות מסלולים, שמות מקוצרים של נסיעות ושילוט יעד

• צריך לספק את השילוט לכל הנסיעות בפורמט trips.txt (אם השילוט נשאר זהה לאורך כל הנסיעה) או בפורמט stop_times.txt (אם השילוט משתנה בשלבים שונים של הנסיעה).
• המידע בשילוט צריך להיות זהה למידע שהמשתמשים יכולים למצוא בשטח. לדוגמה, שלטים שמוצגים על כלי הרכב או על לוחות מידע.
• אם למסלול יש שם, צריך לציין אותו כ-long_name ב-routes.txt.
• אם למסלול יש מספר ספציפי או מזהה אלפאנומרי שרלוונטי לכל הנסיעות במסלול הזה ובשני הכיוונים, צריך לספק אותו כערך של short_name במאפיין routes.txt.
• אם לנסיעות במסלול יש מזהים נפרדים (למשל מספרי רכבות), צריך לספק את המזהים האלה כשמות קצרים של נסיעות.
• בשירותים למרחקים ארוכים שאין להם מספרי נתיבים או שמות נתיבים, הבחירה בשם נתיב הופכת לבעייתית. ההנחיה הכללית במקרים כאלה היא ששילוב של שם המסלול והיעד הסופי צריך לעזור למשתמש לזהות את הרכב באופן חד-משמעי. לדוגמה, אפשר להשתמש בשם של סוכנות ההפעלה כשם המסלול, ובשם היעד של הנסיעה (אם הוא מוצג ברכב) כשלט היעד של הנסיעה.

דוגמאות

• רכבת Kamayani Express של Indian Railways מספר 11071 ממומבאי לווראנסי. הערה: המספר 11071 מזהה נסיעה ספציפית ברכבת ממומבאי לווראנסי, ולא את המסלול עצמו.
  • routes.txt:
    • short_name: <empty>
    • long_name: Kamayani Express
  • trips.txt:
    • trip_short_name: 11071
    • headsign: Varanasi
• אוטובוס מבואנוס איירס לקורדובה של חברת Chevallier Bus. הערה: באוטובוס שפעל בשירות הזה לא מוצג שם מסלול מסוים. במקום זאת, מוצגים בו באופן בולט שם הסוכנות המפעילה ויעד הנסיעה. לנסיעה הספציפית הזו אין מספר או מזהה ייחודי שמבדיל אותה מנסיעות אחרות שמפעילה אותה סוכנות או שמשרתות את אותו מסלול. במקרה כזה, אפשר להשתמש בערך Chevallier גם כשם הסוכנות (במאפיין agencies.txt) וגם כשם הארוך של המסלול (במאפיין routes.txt). במאפיין היעד צריך להשתמש בשביל השילוט. מאפיין השם הקצר של הנסיעה צריך להישאר ריק.
  • routes.txt:
    • short_name: <empty>
    • long_name: Chevallier
  • trips.txt:
    • trip_short_name: <empty>
    • שלט יעד: קורדובה

שעות הפסקה

צריך לספק את הערכים של arrival_time ו-departure_time בפורמט stop_times.txt.

מבנה הנסיעה

• נסיעות למרחקים ארוכים שמשרתות כמה ערים או אזורים צריכות להיות מסופקות מקצה לקצה ללא פילוח (לדוגמה,A->B->C ולא [A->B,A->C,B->C]), כאשר A, ‏ B ו-C הם אזורים עירוניים. לדוגמה, אוטובוס למרחקים ארוכים שנוסע מבואנוס איירס לקורדובה, עם עצירה ברוסאריו, צריך להיות מיוצג כנסיעה עם עצירות בשלוש הערים האלה, ולא כשלוש נסיעות: 'בואנוס איירס – רוסאריו', 'בואנוס איירס – קורדובה' ו'רוסאריו – קורדובה'.
• במקרים שבהם ספק הנתונים לא מצליח לקבל את המידע על מבנה הנסיעה הנכון, יכול להיות שיינתנו נסיעות מפולחות מעיר לעיר על בסיס כל מקרה לגופו. אם בנסיעות כאלה מעיר לעיר יש כמה נקודות איסוף או נקודות הורדה בתוך עיר (אזור עירוני), אסור לפצל את הנסיעה לפי תחנות – צריך לכלול את כל נקודות האיסוף ואת כל נקודות ההורדה בנסיעה אחת.

מבנים של תחנות

בתחנות גדולות עם כמה רציפים או מפרצים, צריך לציין בפיד את הקשרים בין התחנה לרציף, ולזהות מפרצים או רציפים ספציפיים באמצעות השדה platform_code ב-stops.txt. רכבים שיוצאים באופן קבוע ממפרץ או מרציף ספציפיים או מגיעים אליהם צריכים להיות מקושרים למפרץ או לרציף האלה בפיד GTFS. אם הרציף או המפרץ של היציאה או ההגעה משתנים בימים או בשעות שונים של היציאה, אפשר לספק את המידע הזה ב-GTFS בזמן אמת.

מיקומי תחנות

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

תוספי GTFS נוספים

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

תוסף לרכישת כרטיסים ב-Google Transit

• השותפים צריכים להטמיע את המפרט של תוסף Google Transit לרכישת כרטיסים, שהוא קבוצת משנה של תוסף GTFS לרכישת כרטיסים.
• אנחנו מטילים את הדרישות הבאות על מזהי כרטיסים:
  • מזהי כרטיסים צריכים להיות יציבים (כלומר, מותר לשנות אותם לעיתים רחוקות, ומסיבה טובה). במקרים שבהם מזהי הכרטיסים משתנים, נדרשת תאימות לאחור (למשך תקופה מינימלית של שבוע לפחות).
  • כדי לקבוע את הפרמטרים של SegmentKey בבקשות API, הפרמטרים ticketing_trip_id (ב-trips.txt) ו-ticketing_stop_id (ב-ticketing_identifiers.txt) הם חובה. הגיבוי ב-stop_sequence לא אפשרי כי הוא לא יציב.

‫GTFS-Fares v1

בהפניה ל-GTFS סטטי מצוינים הקבצים האופציונליים fare_attributes.txt ו-fare_rules.txt. אם שותף משתמש בממשקי ה-API של השותפים, אין צורך לספק את הקבצים האלה.