Zum Inhalt

Prozess zur Änderung der Spezifikation

Die GTFS ist nicht in Stein gemeißelt. Es handelt sich vielmehr um eine offene Spezifikation, die von der Gemeinschaft der Verkehrsunternehmen, Entwickler und anderen Beteiligten, die GTFS nutzen, entwickelt und gepflegt wird. Es wird erwartet, dass diese Gemeinschaft von Produzenten und Nutzern von GTFS Vorschläge zur Erweiterung der Spezifikation unterbreiten wird, um neue Funktionen zu ermöglichen. Um diesen Prozess zu unterstützen, wurden die folgenden Verfahren und Richtlinien festgelegt.

Die offizielle Spezifikation, Referenz und Dokumentation sind in englischer Sprache verfasst. Weicht eine Translation in eine andere Sprache vom englischen Original ab, hat letztere Vorrang. Die gesamte Kommunikation erfolgt in englischer Sprache.

  1. Erstellen Sie einen Git-Zweig mit der Aktualisierung aller relevanten Teile der Protokolldefinition, der Spezifikation und der Dokumentationsdateien (mit Ausnahme der Übersetzungen).
  2. Erstellen Sie einen Pull-Request auf https://github.com/google/transit. Der Pull Request muss eine ausführliche Beschreibung des Patches enthalten. Der Ersteller des Pull Requests wird zum Advocate.
  3. Sobald der Pull Request registriert ist, muss er von seinem Befürworter in der GTFS Changes Mailingliste angekündigt werden, einschließlich eines Links zum Pull Request. Nach der Ankündigung wird der Pull Request als Vorschlag betrachtet. Die Pull-Anfrage sollte auch so bearbeitet werden, dass sie einen Link zu der Google Groups-Ankündigung enthält, so dass beide leicht miteinander verglichen werden können.
  4. Da der Befürworter ein Mitwirkender ist, muss er die Lizenzvereinbarung für Mitwirkende unterzeichnen, bevor die Pull-Anfrage angenommen werden kann.
  5. Die Diskussion des Vorschlags folgt. Als einziges Diskussionsforum sollten Pull-Request-Kommentare verwendet werden.
  6. Die Diskussion dauert so lange, wie der Befürworter es für notwendig hält, mindestens jedoch 7 Kalendertage.
  7. Der Befürworter ist für die rechtzeitige Aktualisierung des Vorschlags (d. h. des Pull Request) auf der Grundlage der Kommentare verantwortlich, denen er zustimmt.
  8. Der Befürworter kann zu jedem time behaupten, dass der Vorschlag aufgegeben wurde.
  9. Der Befürworter kann zu jedem time nach dem anfänglichen 7-Tage-Intervall, das für die Diskussion erforderlich ist, zur Abstimmung über eine Version des Vorschlags aufrufen.
  10. Bevor er zur Abstimmung aufruft, sollten mindestens ein GTFS und ein GTFS die vorgeschlagene Änderung umsetzen. Es wird erwartet, dass der/die GTFS (en) die Änderung in einen öffentlich zugänglichen GTFS aufnimmt/aufnehmen und in den Kommentaren zum Pull Request einen Link zu diesen Daten bereitstellt/bereitstellen und dass der/die GTFS (en) in den Kommentaren zum Pull Request einen Link zu einer Anwendung bereitstellt/bereitstellen, die die Änderung in einer nicht-trivialen Weise nutzt (d.h. sie unterstützt neue oder verbesserte Funktionen).
  11. Die Abstimmung dauert mindestens 7 FULL Kalendertage und 5 FULL Schweizer Arbeitstage. Die Abstimmung endet um 23:59:59 UTC.
  12. Der Befürworter sollte die genaue time zu start der Abstimmung bekannt geben.
  13. Während des Abstimmungszeitraums sind nur redaktionelle Änderungen am Vorschlag erlaubt (Tippfehler, Formulierungen dürfen geändert werden, solange sie den Sinn nicht verändern).
  14. Jeder darf in Form eines Kommentars zum Pull-Request mit ja/nein stimmen, und Stimmen können bis zum end des Abstimmungszeitraums geändert werden. Wenn ein Wähler sein Votum ändert, wird empfohlen, den ursprünglichen Kommentar zu aktualisieren, indem man das Votum durchstreicht und das neue Votum schreibt.
  15. Abstimmungen vor start des Abstimmungszeitraums werden nicht berücksichtigt.
  16. Die Eröffnung und Schließung von Abstimmungen muss auf der GTFS Changes Mailingliste bekannt gegeben werden.
  17. Der Vorschlag ist angenommen, wenn ein einstimmiger Konsens mit mindestens 3 Stimmen vorliegt.
  18. Die Stimme des Vorschlagsgebers zählt nicht für die Gesamtzahl von 3 Stimmen. Wenn z.B. Antragsteller X einen Pull Request erstellt und mit "Ja" stimmt, und Benutzer Y und Z mit "Ja" stimmen, wird dies als insgesamt 2 Ja-Stimmen gezählt.
  19. Gegenstimmen müssen motiviert sein und idealerweise verwertbares Feedback liefern.
  20. Wenn die Abstimmung gescheitert ist, kann der Befürworter entscheiden, ob er die Arbeit an dem Vorschlag fortsetzen oder den Vorschlag aufgeben möchte. Jede Entscheidung des Befürworters muss in der GTFS Changes Mailingliste bekannt gegeben werden.
  21. Wenn der Befürworter die Arbeit an dem Vorschlag fortsetzt, kann zu jedem time eine neue Abstimmung angesetzt werden.
  22. Jeder Pull Request, der 30 Kalendertage lang inaktiv bleibt, wird geschlossen. Wenn ein Pull Request geschlossen wird, wird der entsprechende Vorschlag als aufgegeben betrachtet. Der Befürworter kann den Pull Request time wieder öffnen, wenn er die Konversation fortsetzen oder aufrechterhalten möchte.
  23. Wenn der Vorschlag angenommen wird:
  24. Google verpflichtet sich, die abgestimmte Version des Pull-Requests zusammenzuführen (vorausgesetzt, die Mitwirkenden haben den CLA unterzeichnet) und den Pull-Request innerhalb von 5 Werktagen auszuführen.
  25. Übersetzungen dürfen nicht in die ursprüngliche Pull-Anfrage aufgenommen werden. Google ist für die Aktualisierung der relevanten Übersetzungen in den unterstützten Sprachen verantwortlich, aber reine Translation aus der Community sind willkommen und werden akzeptiert, sobald alle redaktionellen Kommentare berücksichtigt wurden.
  26. Das Endergebnis der Pull-Anfrage (angenommen oder aufgegeben) sollte in demselben Google Groups-Thread bekannt gegeben werden, in dem die Pull-Anfrage ursprünglich angekündigt wurde.

Leitprinzipien

Um die ursprüngliche Vision von GTFS zu bewahren, wurde eine Reihe von Leitprinzipien aufgestellt, die bei der Erweiterung der Spezifikation zu berücksichtigen sind:

Feeds sollten einfach zu erstellen und zu bearbeiten seinWir
haben uns für CSV als Basis für die Spezifikation entschieden, weil es mit Tabellenkalkulationsprogrammen und text einfach zu betrachten und zu bearbeiten ist, was für kleinere Agenturen hilfreich ist. Es lässt sich auch problemlos aus den meisten Programmiersprachen und Datenbanken generieren, was für die Herausgeber größerer Feeds von Vorteil ist.

Feeds sollten einfach zu parsen
seinFeed-Leser sollten in der Lage sein, die gesuchten Informationen mit möglichst wenig Aufwand zu extrahieren. Änderungen und Ergänzungen des Feeds sollten so weit wie möglich nützlich sein, um die Anzahl der Codepfade zu minimieren, die die Leser des Feeds implementieren müssen. (Die Vereinfachung der Erstellung sollte jedoch Vorrang haben, da es letztlich mehr Feed-Herausgeber als Feed-Leser geben wird).

In der Spezifikation geht es um FahrgastinformationenGTFS
befasst sich in erster Linie mit Fahrgastinformationen. Das heißt, die Spezifikation sollte in erster Linie Informationen enthalten, die den Fahrgästen bei der Nutzung von Hilfsmitteln helfen können. Es gibt potenziell eine große Menge an betriebsorientierten Informationen, die Verkehrsbetriebe intern zwischen Systemen übermitteln möchten. GTFS ist nicht für diesen Zweck gedacht und es gibt möglicherweise andere betriebsorientierte Datenstandards, die besser geeignet sind.

Änderungen an der Spezifikation sollten rückwärtskompatibel seinWenn wir
der Spezifikation neue Funktionen hinzufügen, wollen wir Änderungen vermeiden, die bestehende Feeds ungültig machen. Wir wollen den Herausgebern von Feeds keine zusätzliche Arbeit machen, bis sie ihren Feeds neue Funktionen hinzufügen wollen. Außerdem möchten wir, wann immer möglich, dass bestehende Parser weiterhin in der Lage sind, die älteren Teile neuerer Feeds zu lesen.

Von spekulativen Funktionen wird abgeratenJede
neue Funktion erhöht die Komplexität bei der Erstellung und dem Lesen von Feeds. Daher wollen wir darauf achten, nur Funktionen hinzuzufügen, von denen wir wissen, dass sie nützlich sind. Im Idealfall wurde jeder Vorschlag durch die Generierung von Daten für ein reales Verkehrssystem, das die neue Funktion nutzt, und durch das Schreiben von Software zum Lesen und Anzeigen der Daten getestet. Beachten Sie, dass das GTFS Erweiterungen durch Hinzufügen zusätzlicher Spalten und Dateien zulässt, die von den offiziellen Parsern und Validierern ignoriert werden, so dass Vorschläge leicht in Prototypen umgesetzt und an bestehenden Feeds getestet werden können.

Historie der Revision

März 14, 2023

26. Juli, 2022

  • Hinzufügen eines Transfers von Fahrt zu Fahrt mit der Option "In-Seat". Siehe Diskussion

17. Mai 2022

  • GTFS-Fares V2 Basisimplementierung. Siehe Diskussion

22. Oktober 2021

  • Primäre und fremde id hinzugefügt. Siehe Diskussion

05. Oktober 2021

  • Übertragungen von Reise zu Reise und von Route zu Route wurden hinzugefügt. Siehe Diskussion

15. September 2021

  • Erlaubt, dass fare gates (pathway_mode=6) bidirektional sind. Siehe Diskussion.

13. September 2021

  • Aktualisierte stop_name Best Practices. Siehe Diskussion.

27. August 2021

4. Januar 2021

  • Klärung der Beschreibung von stop_times.stop_id. Siehe Diskussion.
  • Definierte positive und Nicht-Null-Feldvorzeichen. Siehe Diskussion.

Oktober 2, 2020

  • Der Feldtyp von frequencies.headway_secs wurde von einer nicht-negativen in eine positive Ganzzahl geändert. Siehe Diskussion.

25. Mai 2020

  • Definiert pathways.txt, levels.txt xt und attributions.txt als übersetzbare Tabellen. Es wurden Empfehlungen für die Übersetzung von mehrsprachigen signposted_as hinzugefügt. Siehe Diskussion.

13. Mai 2020

  • continuous_pickup und continuous_drop_off zu routes.txt und stop_times.txt hinzugefügt. shape_id wurde von "Optional" auf "Conditionally required" geändert. Siehe Diskussion.

März 24, 2020

  • text Feld definiert und tts_stop_name zu stops.txt hinzugefügt. Siehe Diskussion.

5. Februar 2020

  • Oberleitungsbus und Einschienenbahn route_types hinzugefügt. Siehe Diskussion.

9. Januar 2020

  • translations.txt hinzugefügt. Siehe Diskussion.

26. Dezember 2019

  • Aktualisierte Definitionen für Seilbahn und Luftseilbahn in route_type. Siehe Diskussion.

20. Dezember 2019

  • attributions.txt hinzugefügt. Siehe Diskussion.

26. August 2019

  • Es wurde festgelegt, dass stop_lat und stop_lon dort positioniert werden, wo Fahrgäste auf das Einsteigen warten. Siehe Diskussion.

9. Juli 2019

  • Best Practices für arrival und time hinzugefügt. Siehe Diskussion.
  • Bewährte Praktiken für Kopfschilder wurden hinzugefügt. Siehe Diskussion.
  • Best Practices für stop_id hinzugefügt. Siehe Diskussion.

25. Juni 2019

  • Die Beziehung zwischen Shape und Haltestellen wurde geklärt. Siehe Diskussion.

4. April 2019

  • platform_code Feld in stops.txt hinzugefügt. Siehe Diskussion.

27. März 2019

  • pathways.txt und levels.txt hinzugefügt. Siehe Diskussion.

6. Februar 2019

  • Redaktionelle und Formatierungsänderungen für mehr Klarheit. Siehe Diskussion.

Oktober 2, 2018

14. September 2018

  • Konzept "Conditionally required" hinzugefügt. Siehe Diskussion.

4. September 2018

  • Vereinheitlichung der Definitionen von agency_lang und feed_lang. Siehe Diskussion.

August 27, 2018

  • CHANGES.md und Datum der letzten Überarbeitung aktualisiert. Siehe Diskussion.

22. August 2018

  • Felder feed_contact_email und feed_contact_url in der Datei feed_info.txt hinzugefügt. Siehe Diskussion.

Dezember 11, 2017

  • route_sort_order zu routes.txt hinzugefügt. Siehe Diskussion.

März 15, 2017

  • Es wurde klargestellt, dass die Stimme eines Vorschlagsgebers nicht zur Gesamtzahl zählt. Siehe Diskussion.
  • Es wurde festgelegt, dass vor dem Aufruf einer Abstimmung mindestens ein GTFS und ein GTFS die vorgeschlagene Änderung implementieren sollten. Siehe Diskussion.

7. Februar 2017

  • Klärung der Beziehung von block_id und service_id. Siehe Diskussion.
  • Es wurde klargestellt, dass der frequenzbasierte Dienst mit der departure vehicle beginnt. Siehe Diskussion.
  • Klärung der Beschreibungen von stop_id und stop_code. Siehe Diskussion.

11. Dezember 2017

  • Das Feld route_sort_order in der Datei routes.txt wurde hinzugefügt. Siehe Diskussion.

27. November 2016

  • Bahnhofseingang als stops.location_type hinzugefügt. Siehe Diskussion.

September 2, 2016

  • Die Dokumentation wurde aktualisiert, um agency_id unter fare_attributes.txt hinzuzufügen. Siehe Diskussion.

März 16, 2016

3. Februar 2016

  • agency_email zu agency.txt Vorschlag zu spec hinzugefügt: Diskussion

2. Februar 2015

  • stop_times.txt xt 'timepoint' Vorschlag zu spec hinzugefügt: Diskussion

17. Februar 2014

  • trips.txt 'bikes_allowed' Vorschlag zur Spezifikation hinzugefügt: Diskussion

Oktober 15, 2012

  • trips.txt wheelchair_accessible' Vorschlag zur Spezifikation hinzugefügt: Diskussion

Juni 20, 2012

  • Vorschlag 'wheelchair_boarding' zur Spezifikation hinzugefügt: Diskussion

2. Februar 2012

  • Vorschlag 'stop_timezone' zu spec: discussion hinzugefügt

Januar 18, 2012

  • Die Dokumentation wurde von der alten Seite code.google.com auf die neue Seite developers.google.com verlagert.

September 26, 2011

  • Vorschlag 'feed_info' zur Spezifikation hinzugefügt: Diskussion

6. September 2011

  • Vorschlag 'agency_fare_url' zu spec: discussion hinzugefügt
  • Vorschlag 'exact_times' zur Spezifikation hinzugefügt: Diskussion

März 30, 2009

  • Ein neuer Abschnitt darüber, wie man einen Transit-Feed öffentlich zugänglich macht. Dies wurde zuvor in der Gruppe nicht diskutiert, da es sich nicht um eine Änderung der Interpretation oder des Schreibens der Daten handelt. Einige Google-Mitarbeiter waren jedoch der Meinung, dass es informativ wäre, auch die Verwendung von GTFS außerhalb von Google zu diskutieren, da es immer mehr Anwendungen gibt, die GTFS Daten verwenden können.
  • Klärung des CSV-Formats: Diskussion.
  • Zusätzliche Hinweise zur Auswahl kontrastierender Farben in den Beschreibungen der Felder route_color und route_text_color.
  • trip_short_name, wie in diesen Threads vorgeschlagen und getestet: a und b.
  • Behebung eines kleinen Fehlers in den Beispieldaten am end des Dokuments (Angabe der Haltestelle S7 als übergeordnete Station S8).
  • Hinzufügung von "agency_lang"-Informationen zu den Beispieldaten am end des Dokuments, wie von Marcy während der Kommentarphase vorgeschlagen: Diskussion.
  • Aktualisierung des Links zu OCTAs GTFS in der Seitenleiste
  • Siehe ursprüngliche Zusammenfassung.

26. Februar 2009

  • Die meisten der Google-spezifischen Anweisungen zur Übermittlung des Feeds wurden entfernt, da es inzwischen viele andere Anwendungen gibt, die GTFS verwenden.
  • In der Seitenleiste wurde ein fehlerhafter Link zum öffentlichen Feed der Orange County OCTA behoben.

7. August 2008

  • Das Feld stop_url wurde wiederhergestellt, das in der Version vom 6. August versehentlich ausgelassen wurde.
  • agency_phone zu Beispieldaten hinzugefügt
  • Es wurde ein Hinweis auf die Datennutzungsvereinbarung hinzugefügt, wenn ein Feed an Google übermittelt wird.

August 6, 2008

  • Hinzufügung der Datei transfers.txt, die es den Herausgebern von Feeds ermöglicht, Hinweise zum bevorzugten Übertragungsverhalten zu geben (ursprünglicher Vorschlag)
  • Die Felder location_type und parent_station in stops.txt wurden hinzugefügt, so dass Haltestellen in Stationen gruppiert werden können (ursprünglicher Vorschlag)
  • Das Feld agency_phone wurde hinzugefügt, um eine Telefonnummer für eine Agentur anzugeben (ursprünglicher Vorschlag)
  • Abschnitt "Testing Your Feeds" mit Hinweisen auf Open-Source-Testwerkzeuge hinzugefügt
  • Klarstellungen zum CSV-Format, agency_timezone, agency_lang, route_color, route_text_color, arrival_time, departure_time, calendar.txt vs. calendar_dates.txt, fare tables und frequencies.txt hinzugefügt
  • Link zum Feed-Historiendokument hinzugefügt und einige öffentliche Feed-Links korrigiert
  • Aktualisierte Beispielbilder, um die aktuelle Google Maps UI darzustellen
  • Beispieldaten im Dokument aktualisiert/korrigiert

29. Februar 2008

  • Feld stop_code in stops.txt hinzugefügt, um die Angabe von fahrerbezogenen Haltestellencodes zu ermöglichen (ursprünglicher Vorschlag)
  • Klärung der Beschreibungen von route_short_name und route_long_name in routes.txt
  • Klärung der Beschreibungen von arrival_time und departure_time in stop_times.txt
  • Tippfehler im Abschnitt Beispieldaten korrigiert

November 20, 2007

  • Klärung der Beschreibung von block_id
  • Die Sprache wurde geändert, um Google Transit nicht mehr so stark zu betonen (da Anwendungen, die nicht von Google stammen, GTFS verwenden und Transit-Routing jetzt eine integrierte Funktion von Google Maps ist), und es wurden verschiedene Tippfehler korrigiert
  • Aktualisierte Beispiel-Screenshots, um die Darstellung der GTFS in der aktuellen Google Maps-Benutzeroberfläche wiederzugeben
  • Aktualisierung der Google-Kontakt-E-Mail-Adresse für Anbieter von Transitdaten
  • Aktualisierte Formatierung

Oktober 5, 2007

  • stop_sequence und shape_pt_sequence wurden so geändert, dass sie nun auch steigende nicht-negative Ganzzahlen zulassen
  • Klarere Beschreibungen und Korrektur von Tippfehlern

31. Mai 2007

  • Seitenstil aktualisiert, HTML sauberer und zugänglicher gemacht
  • Links zu öffentlichen Feed-Beispielen und anderen nützlichen Seiten hinzugefügt
  • Beispiele aus den Beschreibungen einzelner Felder entfernt

9. April 2007

  • Abschnitt über das Einreichen eines Feeds hinzugefügt.
  • Beispiel-Feed für eine Transitagentur hinzugefügt.
  • Hinweis hinzugefügt, dass calendar.txt weggelassen werden kann, wenn alle Dienstleistungsdaten in calendar_dates.txt definiert sind.
  • Das Feld agency_id wurde in Feeds, die nur eine Agentur enthalten, optional gemacht. Dadurch können bestehende Feeds ohne agency_id gültig bleiben.
  • Vollständigere Spezifikation von agency_url, stop_url und route_url sowie zusätzliche Beispielwerte für diese Felder hinzugefügt.
  • 6 (Gondel) und 7 (Standseilbahn) wurden als gültige route_type hinzugefügt.

8. März 2007

  • Geringfügige Änderung, um das Feld stop_url von stop_times.txt, wo es in der Aktualisierung vom 28. Februar falsch angegeben wurde, in stops.txt zu verschieben, wo es hingehört.

5. März 2007

  • Kleine Änderung, um die Beschreibung des route_long_name Feldes zu verdeutlichen.

28. Februar 2007

  • Hinzufügung von frequencies.txt für die Unterstützung von Fahrplänen auf Basis der Fahrzeit.
  • Mehrere Agenturen sind jetzt im selben Feed erlaubt. Außerdem wurde das neue Feld agency_id sowohl in agencies.txt als auch in routes.txt hinzugefügt, mit dem man angeben kann, welche Route von welcher Agentur betrieben wird.
  • Hinzufügen von URLs pro Strecke und pro Haltestelle.
  • Hinzufügung des Feldes direction_id in trips.txt.
  • Unterstützung für Änderungen von Haltestellenschildern während der Fahrt durch Hinzufügen des Feldes stop_headsign in stop_times.txt.
  • Unterstützung für Routenfarben durch Hinzufügen von optionalen route_color und route_text_color in routes.txt.
  • Die Möglichkeit, Haltestellen mit Straßenadressen anzugeben, wurde entfernt. In der vorherigen Version der Spezifikation war es möglich, die Lage einer Haltestelle über eine Straßenadresse in den Feldern stop_street, stop_city, stop_region, stop_postcode und stop_country anzugeben. Jetzt müssen die Haltestellenstandorte mit stop_lat für den latitude und stop_lon für den longitude angegeben werden, was für die meisten Anwendungen sinnvoller ist.
  • Hinzufügen des vehicle der Seilbahn für das Feld route_type in routes.txt.
  • Siehe die ursprüngliche Zusammenfassung der Änderungen im Headway Blog Post.

November 29, 2006

  • Unterstützung für Shape über shapes.txt hinzugefügt
  • Klärung der Definition von stop_sequence
  • Markierung von pickup_type und drop_off_type als optional

Oktober 31, 2006

  • Unterstützung für Fahrpreisinformationen hinzugefügt
  • Datumsangaben aus einzelnen Dateinamen entfernt
  • Die Definitionen der route_type wurden geändert
  • Erlaubt die time Veröffentlichung mehrerer Feed-Dateien, solange sich deren Dienstzeiträume nicht überschneiden
  • block_id in trips.txt wurde korrigiert, so dass sie korrekt als optional gekennzeichnet wurde
  • Es wurde darauf hingewiesen, dass Spaltenüberschriften enthalten sein müssen.

29. September 2006

  • Kleine Änderung, um einige Fehler in den Beispielen zu korrigieren.

25. September 2006

  • Erste Version.