I know this is a conditionally optional field — if you’ve specified route_short_name then you aren’t required to specify route_long_name — according to the GTFS reference. However, it would make a huge difference to include it. It would massively help anyone to create apps or tools that run off this data. It would expect it to be straightforward to add it in.
What would you expect to be in the field?
An example could be:
12 - White Rose Centre - Chpl Allerton Hosp (First Leeds)
The convention would be: number - Start - Via(optional) - End (agency_name) or similar.
Basically, a human-readable descriptive name of the route.
In the Netherlands, the GTFS timetables contain route_long_name: Line <route_number> (<Agency Name>) <Start> - <End>
e.g. Lijn 24 (DuinGo) Station Poort - Duin
1 Like
Tim, do you know if this has been added to the new (forthcoming) BODS GTFS and GTFS RT feed?
Is the above really a name of the route? I expect that a pair of route short name and route long name should convey the same information, where the route short name is just the abbreviated form of the route long name, for example, SP vs sprint, 50 vs Breezer 50, etc.
A route_long_name would provide information about the start and end location of the journey. Currently, this field is empty.
The route_short_name is just the number on the front of the bus.
It would be helpful to have longer route names that are human-readable, especially for building public facing apps/tools. That way it is standardised, and you don’t have to make your own, which may be different to what everyone else uses.
1 Like
I am producing a GTFS file for the National Rail timetable and here is how I am using the fields:
Avanti vs Avanti West Coast
SWR vs South Western Railway
Mildmay vs Mildmay line
And the examples I have mentioned are real-life examples as well
50 is the actual number on the front of the bus, but on the timetables, it is shown as Breezer 50 for the route between Bournemouth and Swanage
8 vs activ8 for the route between Andover and Salisbury
I would consider these variations the appropriate use of route_short_name and route_long_name.
Your variations may be appropriate - I guess that depends on your use case and what you have interpreted the correct form to be.
However, the official GTFS docs for routes.txt route_long_name say this:
“Full name of a route. This name is generally more descriptive than the route_short_name and often includes the route’s destination or stop. Both route_short_name and route_long_name may be defined.”
It’s a conditionally required field, but I think it would be a big help if it could be included by default. In that case, including the destination and/or starting point would be great, as it provides extra detail to identify the routes.
Thanks. I think it should be included if it is included in the timetable. i.e. if the official timetables actually contain such text at the route name, it should be included as the route_long_name.
What are the “official timetables” that aren’t the GTFS or TransXChange from BODS?
I’m suggesting that BODS ensures that route_long_name is populated, because it would be useful for people using GTFS.
E.g. 34-leeds-bus-station-otley-bus-station-2 is used by https://bustimes.org/services/34-leeds-bus-station-otley-bus-station-2
but we found it challenging to recreate what they have done with route names.
If route_long_name was included, we could all just use the same thing.
The TransXChange data contains various Inbound and OutboundDescription, Origin, Destination and Via fields
<Line id="FLDS:PB0000815:355:34">
<LineName>34</LineName>
<OutboundDescription>
<Origin>Leeds Bus Station</Origin>
<Destination>Otley Bus Station</Destination>
<Description>Leeds Bus Station - Otley Bus Station</Description>
</OutboundDescription>
<InboundDescription>
<Origin>Otley Bus Station</Origin>
<Destination>Leeds Bus Station</Destination>
<Description>Otley Bus Station - Leeds Bus Station</Description>
</InboundDescription>
</Line>
It would seem to make sense to use one of them to populate the GTFS route_long_name
I agree, and this is ultimately what we ended up doing ourselves. perhaps DfT could do this step and add it to the GTFS timetables.