דרישות ל-GTFS

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

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

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

שיטות מומלצות של GTFS – עליכם לפעול לפי השיטות המומלצות, לפי הצורך.

העלאת פידים של מידע על תחבורה ציבורית (GTFS) – צריך לפעול לפי התהליך הבא כדי להעלות את הפיד של מידע על תחבורה ציבורית (GTFS).

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

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

היקף

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

תרגומים

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

שמות מסלולים, שמות קצרים של נסיעות וחתימות ראש

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

דוגמאות

• קו הרכבת האקספרס ההודי קמאיאני, רכבת 11071 מומבאי לוארנאסי הערה: מספר 11071 מציין נסיעה ספציפית ברכבת ממומבאי לוארנאסי, ולא את המסלול עצמו.
  • routes.txt:
    • שם קצר: <ריק>
    • long_name: KaMayani Express
  • trips.txt:
    • Tri_short_name: 11071
    • headsign: וארנאסי
• אוטובוס מבואנוס איירס לקורדובה, באוטובוס שואלייר. הערה: באוטובוס שהפעיל את השירות הזה לא מוצג שם מסלול מסוים. במקום זאת, השם של הסוכנות התפעולית והיעד שלה מוצגים באופן בולט. לנסיעה הספציפית הזו אין מספר/מזהה ייחודי שמבדיל אותה מנסיעות אחרות שמופעלות על ידי אותה סוכנות או שנוסעים באותו מסלול. במקרה כזה אפשר להשתמש ב-"Chevallier" גם בתור שם הסוכנות (ב-agencies.txt) וגם בתורlong_name (ב-routes.txt). היעד צריך לשמש לציון הראש. trip_short_name צריך להישאר ריק.
  • routes.txt:
    • שם קצר: <ריק>
    • long_name: Chevallier
  • trips.txt:
    • Tri_short_name: <ריק>
    • מספר ראשי: קורדובה

זמני הפסקה

יש לציין גם arrival_time וגם את המילה exit_time (שעת יציאה) ב-stop_times.txt.

מבנה הנסיעה

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

מבני תחנות

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

מיקומי תחנות/תחנות

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

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

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

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

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

GTFS-Fares גרסה 1

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