Use of extra files for timetables

[Aaron Antrim]

(This is *not* a Spec change proposal, rather just a statement of practice.)

It strikes me as though it would be very useful to have more ways of tracking adaptations of GTFS, and current practice. Posting to GTFS-changes seems like one way of documenting practice (as I often start the development of a change proposal with a search for prior discussion).

Trillium has begun to include a number of additional files for creating timetables and setting up websites in some GTFS feeds, namely:

• timetables.txt
  
• timetable_stop_order.txt
  
• route_pages.txt
  
• route_page_assoc.txt
  

Some of these files are being used by the open-source software GTFS-to-HTML. Documentation and source code at this URL: https://github.com/brendannee/gtfs-to-html

Sonoma County Transit provides one example of the above files in use:

http://transitfeeds.com/p/sonoma-county-transit/419/latest

--

Aaron Antrim

Trillium Solutions, Inc.
www.trilliumtransit.com
Portland, Oregon

[Sean Barbeau]

Aaron,
Thanks for sharing!  I think posting these extensions to the gtfs-changes group are useful, because as you say many people start proposals by searching this group.

I think it would also be useful to try and start capturing these extensions in a single place - I just added a "GTFS Extensions" section at the bottom of the GTFS page of Transitwiki.org:
http://www.transitwiki.org/TransitWiki/index.php?title=General_Transit_Feed_Specification#GTFS_Extensions

I added the Google Extensions for GTFS there to start it off - feel free to add yours (maybe linking to this post?) and others!

Sean

[Stefan de Konink]

The interesting part out of these extension might be the code te create
them from the other source files.

Stefan

[Wojciech Kulesza]

I would like to chip in to that discussion as goEuropa is creating schedule timetables printed on transport authority website, with input coming from GTFS files.
We're currently using db to store all data from GTFS and generate a schedule timetable, but this could potentially influence and maybe standardize the way timetables are constructed.
We are able to display timetable per given day (based on calendar dates) but also group them into day categories (normally: workdays, saturdays, sundays&holidays) like it's common for printed timetables.

An example is here:
http://ztm.poznan.pl/komunikacja/rozklad/#/rozklad/wgLinii/ZTM_MPK/0/2992/1

We're using only existing fields in GTFS to cater for all exceptions on route or trip. i.e. using route_desc, trip_id with special characters which are then parsed to display annotations to a given trip (example: trip shorter or longer than the standard type) or produce a "legend".

Having said that, I'm wondering if usage of extra txt files (like the ones suggested and used in the above post by Aaron) is neccesary ?

Wojciech

[Aaron Antrim]

On Monday, February 8, 2016 at 1:54:00 PM UTC-8, Sean Barbeau wrote:

I think it would also be useful to try and start capturing these extensions in a single place - I just added a "GTFS Extensions" section at the bottom of the GTFS page of Transitwiki.org:
http://www.transitwiki.org/TransitWiki/index.php?title=General_Transit_Feed_Specification#GTFS_Extensions

I added the Google Extensions for GTFS there to start it off - feel free to add yours (maybe linking to this post?) and others!

Good idea, Sean!

I added notes about the use of timetables.txt etc. as well as an extension in use in the SF Bay Area called GTFS Extended.

http://www.transitwiki.org/TransitWiki/index.php?title=General_Transit_Feed_Specification#GTFS_Extensions