Dear GTFS stakeholders,
At the MBTA we’re giving ourselves 6 weeks to add something to our GTFS feed to help clients better define the different variations of routes, and the relationships between routes. We’d much prefer to leverage existing GTFS extensions where possible; where not possible we expect to create something new. I wanted to ask what other challenges users have encountered in this area, and what existing approaches are out there.
It’s probably a strength of GTFS that it launched without variants (or variations or patterns), since that means there’s no need to think about them if you don’t want to. There are routes, and within routes there are trips, with no in-between grouping to worry about. But as we build more systems around GTFS we’re encountering a pattern of needs in this area that we’re not meeting. It doesn’t help that the MBTA has an unusually complicated network in which routes can have many variations.
Some user stories in this area we can’t currently address but might be addressable with with information about route variants or with information about the relationship between routes:
As a developer of an application that presents schedule information to users, I can…
Show a shape and list of stops that is typical or representative of the route and direction.
Produce a list of stops served by a route that excludes those only served by highly unusual trips that may only run once a day or once a week.
Let a user select from a list of different route variants, presented as meaningful text descriptions, to show one on a map.
Let a user switch from a view showing a variant in one direction to a view showing the same variant in the opposite direction.
Tell a user, with a string, what is unusual about a particular set of trips (“bypasses Longwood.”) May also include a single-letter identifier of the "note" (i.e. “C” “C: Serves Carey Square.”)
Include a public-facing short identifier for a trip without giving it a unique route_id that separates it from other trips on its route (showing a trip as “111C” but still listing it on the “route 111” page.)
Identify branches, and the relationship between branches (i.e. best represent Green Line’s B, C, D, E service.)
Show schedule information on closely related routes together (i.e. show routes 116 and 117 together since they mostly overlap.)
Identify that a route exists solely in relationship to another route or routes (i.e. the Orange Line shuttle bus during a scheduled diversion of part of the heavy-rail Orange Line.)
With that to give a general idea of the space we’re interested in:
A. What needs do others have in this area? Does anything above resonate? What's missing?
B. What approaches (successful or unsuccessful) have others tried or seen to address challenges in this area?
So, if we try to do a (partial) overview of what is already being used or being asked about those subjects:
## Regarding #1: Canonical shape or list of stops & identification of unusual patterns
• Transit (transit.app) internally uses the field `trip_exclude_in_route_view` on the `trip` to flag the « unusual » trips which should not be displayed when the full shape of the route is drawn.
• TriMet (trimet.org) internally uses `stop_route` to define the canonical order of the stops of a route, to sort them in a timetable for example.
• Bileto (bileto.com), in Czechia, told me that all rail schedules in the country should be flagged if they weren’t following the typical pattern. They flag them by adding « Výlukový » in the planned schedules.
## Regarding #3: Meaning full pattern description
• Johannes Rudolph posted 3 years ago about the need to have a trip_desc field for each trip, to add « specification informations for a specific trip to give information to the travelers », and Steven Judd also wanted it. Do we know with which datasets they were working? (Source: https://groups.google.com/forum/#!topic/gtfs-changes/BUBhQrpMqgQ)
## Regarding #5 and #6: public facing identifier and it’s definition
• TTC (ttc.ca) uses letters to distinguish between patterns, with sometime very specific ones (like the one at end-of-school-time which makes a detour to pick up student). E.g. for route 32, the branch will be « A », and this information will be in the `trip_headsign` field, as « 32A Eglinton West Towards… » (Detours of the 32: http://www.ttc.ca/Routes/32/Eastbound.jsp)
• NJ Transit (njtransit.com) also uses letters to distinguish between patterns, but not always put them in their GTFS. E.g. for route 114, the schedule defines two special patterns: X and m. But the GTFS only contains the X. Like for TTC, it’s encoded in the `trip_headsign` fields, which contains « 114X Bridgewater Express ».
## Regarding #8: Showing merged schedule information when the two routes are close one to another
• Metro LA (metro.net) runs short version of their routes during the week-end, which are often the common portion of different routes. Therefore the vehicle is at the same time running on the 35 and the 38. They represent that in the GTFS as another route, with the route short name « 35/38 ».
## Regarding #9: Identifying a route which solely exists in relationship to another route, like a shuttle route
• Kisio Digital has extended/modified the GTFS format, and they created another level on top of the routes, that they call the lines (lines.txt with line_id). This is allowing them to group different routes (a bit like a « parent route ») which are branded as one line. This allows to have distinct route_type, but only one branding at the end.
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To unsubscribe from this group and stop receiving emails from it, send an email to email@example.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/c37a07af-55e0-4799-a3eb-60814e2cf1d3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.