Add direction_name field to trips.txt for human-readable stop pattern names

[gsvalbe]

Describe the problem

Urban public transport schedules in Baltics are most often viewed in online timetables. The timetables are split in two directions (existing GTFS functionality with direction_id), but also in trip patterns. There are often separate groups of trips that divert to serve additional stops, that are extended, shortened, or that run to the depot or other destinations. And very often trip origin and destination stop names differ from the recognized route name or displayed headsigns (end stop name is "X street" but headsign/destination is "Y neighbourhood"). When users open timetables to choose a direction, they expect understandable, descriptive trip pattern names.

Currently agencies store this information in the following ways:

• custom non-standard field in trips.txt (direction_name in Riga, Vilnius, Kaunas, ...);
• trip_short_name (whole of Estonia)
  from standard: this field "should uniquely identify a trip within a service day" – incorrect use,
  also uses up this field when could be used for real trip codes;
• trip_headsign (Daugavpils, Jelgava, ...)
  also does not match the standard perfectly; vehicle headsigns, departure boards show destinations, not full pattern names, this field should contain that data;
• different routes for each trip pattern, with the same route_short_name (Tartu)
  OK for journey planners, but confusing for users when viewing timetables;
• omit the information in open data but still use it their own systems (all Latvian regional buses, ...).

None of the existing GTFS standard fields seem to fit this usecase well, but there is a need for it or it is already used with custom fields.

Use cases

Show full, descriptive, easily understandable trip (stop pattern) name for users, not only destination or headsign.

Trip planning and timetable apps may then use this value to help users distinguish between different service patterns on the same route.

For example, in Riga, full direction_name value "2.parks (Jelgavas ielā) - Valguma iela - Vanšu tilts - Mežciems" is describing full route for users in online timetables. But trip_headsign value "Mežciems" is enough for riders on the ground viewing the destination board there (based on stop location and direction).

Proposed solution

Add optional direction_name text field to trips.txt describing the full trip pattern name for the public. Distinct from trip_headsign, which shows the destination, headsign on vehicle or stop departure boards.

Additional information

This proposal is somewhat related to #228, but that suggested an additional field and route-level direction labels describing only the two existing direction_ids. This proposal instead operates at the trip level and describes a specific stop pattern for timetables.

Field by this name is already unofficially used by many agencies in the Baltics, but maybe pattern_name or some other field name is more descriptive for this.

Examples of current use:
https://saraksti.rigassatiksme.lv/gtfs.zip (gtfs, Riga)
https://saraksti.lv/#trol/19/d2-a/en (pattern dropdown, clicking routes on sidepanel, Riga)
https://stops.lt/vilnius/#bus/12/b1-a (pattern dropdown, Vilnius)
https://tartu.pilet.ee/en/explore?selectedTab=routes (duplicate routes, Tartu)

[felixguendling]

For example, in Riga, full direction_name value "2.parks (Jelgavas ielā) - Valguma iela - Vanšu tilts - Mežciems" is describing full route for users in online timetables.

Why can't this be a route_long_name? I think that's a good fit and I have seen this already used for "describing full route for users in online timetables".

[jfabi]

If I understand, @gsvalbe, you are looking for a mechanism to be able to define multiple direction/trip descriptions (maybe, put another way, multiple route_long_name values) per route, one for each trip pattern operating under the same passenger route number?

For the @mbta's website, we've had a very similar need previously, and we developed a concept of route patterns that we publish experimentally. You can see route patterns in use on this line page by clicking the destination name with the small arrow above the map.

STM in Montréal will also begin publishing a route_patterns.txt file imminently—it does not include written names/descriptions, however it's not difficult to see how it could be added.

[gsvalbe]

@jfabi yes, MBTA's route_patterns.txt file looks perfect for this usecase. The other fields are also very useful and cover rest of the pieces missing for publishing all the route pattern data.

I guess I would like to see this somewhat standartised and/or advertised, so that GTFS producers (transit agencies) can be motivated to publish this data, and consumers can implement it. Because, by default, transit agencies stick to standard GTFS producing solutions and rarely publish entirely new non-standard files. And it is very hard to convince them to output data, when the data format is seemingly differernt for each provider.

[ckraatz]

@gsvalbe we've used trip_headsign to achieve a similar goal, but I can see how that field might be too limited to describe an entire pattern.

We've also seen some agencies (including MBTA I think) include the directions.txt file to add clarity beyond the binary 1/0 direction_id in trips.txt. I like the idea of embedding a direction_name into trips.txt if all that's needed is some passenger-facing text.

@jfabi how does MBTA use route_patterns.txt differently from directions.txt?