Add direction_name to trips.txt

[Devin Braun]

trips.txt allows for direction_id, with a 0 or 1 to designate
directions. The spec also states that the name for each direction
should be specified in the trip_headsign field. In some cases,
trip_headsign changes by trip, even for trips of the same direction,
due to alternate routings and shortlines, for example.

Adding direction_name to the field would allow a transit agency to
specify the name of the direction and then trip_headsign would further
clarify the destination of the route.

example
trip_id, ... ,trip_headsign,direction_id,direction_name
1234, ... , to Airport,0,East
1235, ... , to Airport via Commuter Terminal,0,East
1236, ... , to Downtown,1,West
1237, ... , to 4th Ave,1,West

We have this field in our feed for testing purposes (we use it
internally).

Devin Braun
San Diego MTS

(p.s. - the example for direction_id in the current spec shows the
same trip_id "1234" for the two sample trips, making them non-unique)

[Sean]

This additional field would also be very useful to help integrate
between GTFS datasets and other transit information systems designed
to use North/South/East/West directional information.

We hit this problem when developing cell phone software which uses
GTFS data to tell the transit rider when to exit the bus based on
their personal itinerary. Another useful feature of this mobile
application uses a web service operated by the transit agency to
retrieve and display estimated bus arrival info while the transit
rider is waiting at their bus stop. However, since the web service
required North/South/East/West as input for the direction parameter,
and the current GTFS data set only provides 0/1 for inbound/outbound,
we actually have no way to query the web service for the proper route
direction given the stop_ID/trip_ID/direction_ID from the GTFS data.

There are workarounds to resolve this, but none that are as simple and
sustainable as including an additional field in the trips.txt file in
the GTFS.

Sean Barbeau
Center for Urban Transportation Research
University of South Florida

[Frank]

+1 on the addition, and agree that the field be free-text, as it
appears to be in Devin's proposal. (BTW, an enumerated list of
directions could be >15 names.)

[Joe Hughes]

Thanks for the proposal, Devin. I've added it to the Open Proposals
page.

This discussion sounded really familiar to me--it turns out that Van
Sutherland had brought up trip directions in the discussion about stop-
based directions/bearings:
http://groups.google.com/group/gtfs-changes/browse_frm/thread/33216ce36f100ff2

Let me try to summarize the goals that people have expressed in this
thread so far:

Devin wants a free-text, human-readable field, presumably for display
to riders. San Diego already maintains this information. Devin,
could you give an example that shows off how the direction information
helps show something that's hard to do with the headway field. Also,
do you have any examples of how this information is used on the MTS
site and/or signage out in the world?

Frank also wants a free-text field. Frank, I'm assuming you want to
use this information in TimeTablePublisher--is this something you're
using now, and if so how is the information surfaced?

Sean wants an enumeration value that can be fed to a particular web
service. It's not clear to me that this meshes well with the
unstructured field that Devin and Frank seem to have in mind, but it's
worth considering.

Van, would this proposal work for the Capital Metro/Sendero use case
that you brought up earlier?

Are there other data consumers who would like to use trip direction
information? If so, please chime in with details.

Cheers,
Joe

[Tom Hixson]

The term 'direction' is a poor choice--it should be called
'destination'. That is, when you say North you mean Northbound which
means To the North Area. Compass directions should be allowed but not
required, so I agree with free-text.

Direction is like headsign, but can only have two values per route
(there's typically one headsign per stop pattern, and a direction can
have many patterns such as short-turns). I think its only use is for
timetables (from whence the term came). The heading (timepoints) of a
timetable is a kind of 'master' pattern, so direction is a kind of
'master' headsign.

So, I think a free-text direction description field would be valuable.

On a side note--I've been helping another agency use their Google feed
with NextBus, who insists on N/S/E/W designations. The agency does not
like it and is trying to get NextBus to stop it.

Tom
Sacramento

On Jul 27, 11:15 pm, Joe Hughes <joe.hughes.c...@gmail.com> wrote:
> Thanks for the proposal, Devin.  I've added it to the Open Proposals
> page.
>
> This discussion sounded really familiar to me--it turns out that Van
> Sutherland had brought up trip directions in the discussion about stop-

> based directions/bearings:http://groups.google.com/group/gtfs-changes/browse_frm/thread/33216ce...

> > > same trip_id "1234" for the two sample trips, making them non-unique)- Hide quoted text -
>
> - Show quoted text -

[Sean]

Some related useful information for those of us trying to persuade
vendors to change away from N/S/E/W designations for directions:

According to a survey of 90 transit agencies published by the National
Center for Transit in 2008, 67% of agencies represent direction as
"to / from" (the preferred representation according to the report),
25.5% represent direction as "northbound / eastbound, etc," and 7.4%
represent direction as "inbound / outbound."

The main purpose of the research was to examine the readability/
understandability of printed transit materials from the customers
(i.e. transit riders') perspective. They found that for route
direction designations the "To / From" representation was the easiest
for transit customers to understand.

Transit Materials Design Guidebook resulting from report:
http://www.nctr.usf.edu/pdf/77710guidebook.pdf

And NCTR final report is available online here, with the
direction information available on page 79 in table 4.4:
http://www.nctr.usf.edu/pdf/77710.pdf

In interest of full disclosure, the researchers that wrote this report
are also from our University of South Florida.

Sean Barbeau
Center for Urban Transportation Research
University of South Florida

[Martin Akerman]

To add to that, Inbound and Outbound are seen as the best way to
describe the route from an Operational standpoint. I agree that there
should be a free-text area for human use but direction should remain
an inbound or outbound field. trip_long_name (Optional) could be a
good choice for a column name.

Martin Akerman

Center for Urban Transportation Research
University of South Florida

[Tom Hixson]

Always nice to spice up a discussion with facts! And since
'northbound' is a form of 'to the north', and 'inbound' is a form of
'to downtown', I think 'to/from' is at 100%. The ugly part is when
the compass 'direction' associated with a bus stop (as in 'facing
north') becomes comingled with the route 'direction'.
-Tom

> > > - Show quoted text -- Hide quoted text -

[Roger Slevin]

Careful! "inbound" is only the opposite of "outbound" on services go across
a city ... completely arbitrary, so don't assume that "inbound" is always
heading towards "downtown" ... at least not in Europe!

Roger

[Martin Akerman]

The outbound and inbound assignations are used to differentiate 2
trips on the same route that may be leaving their terminals heading
opposite of each other at the same exact time. Most transit agencies
still use archaic IDs for trips (0600 for the 6AM). This caused
agencies to either force a 0602 and 0600 heading in opposite
directions or two 0600 trips with an inbound and outbound assignment.
It's not right, but it is something we find in many existing systems.

The fact that they are heading in a direction other than towards/away
or inbound/outbound may be true but not crucial to operations.

Want to hear a strange case? We just got a project from an agency that
recently merged the local transit systems into a regional system. The
outbound route 12 is run by one system and the inbound route 12 is run
by another.

-Martin Akerman
CUTR

[Devin Braun]

On Jul 27, 11:15 pm, Joe Hughes <joe.hughes.c...@gmail.com> wrote:

> Devin wants a free-text, human-readable field, presumably for display
> to riders.  San Diego already maintains this information.  Devin,
> could you give an example that shows off how the direction information
> helps show something that's hard to do with the headway field.  Also,
> do you have any examples of how this information is used on the MTS
> site and/or signage out in the world?
>

All of our web timetables are split by the direction name:
http://www.sdmts.com/mtscr/Route.aspx?r=1

Our real-time signage says things like: 1, East, La Mesa, 3 Min

Tom Hixson wrote:
> The term 'direction' is a poor choice--it should be called 'destination'.
> That is, when you say North you mean Northbound which means
> To the North Area.

To me, "Destination" implies the goal stop/station/area of the route
and not necessarily the direction of the route. I would think that the
headsign of the bus would be the destination. A developer could
choose to use either the headsign or the direction to group trips into
a schedule.

Sometimes, directions are arbitrary. A route may go east, west, north
and south, so how do you pick one? We have on route which is U-
shaped, but because the two terminals are north and south of each
other, we use north/south.

http://www.sdmts.com/RouteFiles/images/maps/view/11.gif

[Brian Ferris]

When constructing a timetable for a route, my method is to group the trips by 'direction_id' and then use the most common 'trip_headsign' name from each direction group as the label for that group of trips.  This attempts to work around the issue that not all 'trip_headsign' values will be the same even for trips headed in the same direction (as mentioned by Devin), but hopefully the most common 'trip_headsign' will be representative of that group of trips.

It seems there are two issues we're trying to solve:

1) Adding direction of travel information to a specific trip: in my opinion, the way to address this is to add direction information into 'trip_headsign' so you'd get labels like 'Eastbound to Something Neighborhood'.

2) Adding a meaningful direction of travel label when grouping trips for a route timetable: in my opinion, adding a 'direction_label' field or whatnot to 'trips.txt' could address this issue, but there would be some ambiguities.  Do we group trips based on the 'direction_id' or 'direction_label'?  What happens when there isn't a direct mapping from one to the other?  If I had to implement, I'd probably still have to use the policy of grouping by 'direction_id' and then picking the most frequent 'direction_label' as each group's label.

If it's only the case that there is a direct one-to-one mapping from 'direction_id' to 'direction_label', then there would actually be a ton of information duplication if it was included in 'trips.txt'.  Instead, you could create an additional file (call it 'route_directions.txt') that has three fields: 'route_id', 'direction_id', and 'direction_label' since it's the route_id + direction_id that's actually unique and what we wish to apply a label to.

Thanks,
Brian

[T Sobota]

I would like to (formally?) re-open the change request - originally described by D Braun.

The existing trips.txt file allows an optional, binary, direction_id field (0 or 1) - that relates to the route_id.  Transit operations have generally been routes serving a bi-directional system (Orient Express railway had trips heading in either direction 0 "Asia", or 1 "Europe")

I would ask for another review of the formal addition of the sister field to direction_id, direction_name.  (Where route_id/trip_id with a direction_id 0 would always equal direction_name [free-text]"zero"; and route_id/trip_id with direction_id 1 would always equal direction_name [free-text]"one").

Similar to D Braun, our agency has also been using this field name for an extended period of time - to accurately group varying trip_headsign values under a common title.

Keeping with the Orient Express timetable example, individual trains with direction_id of 0 ("Asia") may have had an occasional train running the full alignment with the trip_headsign "Instanbul", but more frequently could have been running short-turn trains "To Venice" or "To Bucarest" - or had varying alignments "Instanbul Via Venice" or "Instanbul Via Vienna".  Without a direction_name field, GTFS feed producers do not have a way to group these disparate trip_headsigns under a common header - for GTFS consuming applications.

In earlier comments in this thread, I do see where contributors for common platforms like Google Maps and One Bus Away have indicated this missing piece of information - and I have seen our agency data similarly mis-conveyed (using too specific of a trip-headsign for a generalized direction) in other applications like the Transit App.

D Braun had created a specific issue for the OneBusAway code, on this topic, as well... which would seem understandable, as OBA does not currently have a generalized field like direction_name to use for this purpose (it must arbitrarily select a trip_headsign value, that may not encompass how all other trips in that direction operate):

https://github.com/OneBusAway/onebusaway-application-modules/issues/180

Thank you for the (re)consideration.

[Frank]

Hey Tim,

I'm still on board with your change, or at least the sentiment behind it.  I'd also like to mention an alternate approach that TriMet took, where we now include a file called route_directions.txt in our GTFS feed.  Here's an example:

route_id,direction_id,direction_name
1,0,To Vermont & Shattuck and Maplewood
1,1,To Portland City Center
2,0,To Gresham Transit Center
2,1,To Portland City Center
4,0,To St Johns
4,1,To Portland City Center

...

18,0,To Hillside and Providence Park

The need for route_directions.txt came about from trying to render this page: https://trimet.org/ride/stop_select_list.html?route=2 .  In TriMet's case, I suppose we could have used a trips.txt / direction_name field, if it had been available.  But honestly, ~4 years ago when we added route_directions.txt it didn't occur to us to do that (we thought about using trip_headsign ... but didn't want to bloat trips.txt with a bunch of redundant route specific direction names; in addition, we also wanted to avoid wrongly using the trip_headsign field, which often has trip specific as opposed to route specific names).  An added benefit of route_directions.txt is that there's a clear indication of uni-directional routes, ala https://trimet.org/ride/stop_select_list.html?route=18 (e.g., don't have to parse thru all of the line 18 trips to figure out it only has a single direction ... rather that information is seen with just a single entry in route_directions.txt).

Anyway, this is what we're doing at TriMet.  We've been using route_directions.txt for about 4 years. I don't think we ever made a formal proposal of this change, but would be willing to do so if others find any value in this addition.

Take care,

Frank

[Leo Frachet (MobilityData)]

This an important subject, on which everybody has a patch, we should indeed normalize it.

Trillium uses a variant of TriMet's solution which has `directions.txt` as file name and `route_id`, `direction_id` and `Direction` as field names. This is based on the GTFS+ proposal which requires `Direction` to be amongst a fix list of options (see sources below).

MBTA uses a third variant, but also closely based on GTFS+, which also has `directions.txt` as file name, but fields are `route_id`, `direction_id`, `direction` (lowercased d) and `direction_destination`. 

Transit app uses internally almost the same feature, but they also define the equivalent for stop_headsign. So two extra fields:

- `trip_direction_headsign` (in `trips.txt`) which is what you are all using.

- `stop_direction_headsign` (in `stop_times.txt`) which is needed when the direction headsign evolves along the trip. See example below:

For example in Boston MBTA, the red line Southbound has two branches, one to Ashmont and one to Braintree, and MBTA uses (or used to use) Inbound/Outbound. So:

- trips toward Ashmont have stop_headsign "Inbound to Ashmont", then "Outbound to Ashmont"

- trips toward Braintree have stop_headsign "Inbound to Braintree", then "Outbound to Braintree"

As direction headsign (or direction name), the best you can put is... "Southbound". Using `stop_direction_headsign` you can define, along the trips, "Inbound" then "Outbound" as stop direction headsign.

MBTA have likely moved away (AFAIR) from the Inbound/Outbound pattern to simplify their GTFS, but it is useful in complex network. For example in the RER network in Paris, Transit uses "Sud vers Paris" ("South toward Paris" aka inbound) then "Sud vers banlieue" ("South toward the suburbs" aka outbound), which is how the agency locally describe it.

So I like the idea of an extra file, but I do thing their is a need for stop_direction_headsign. Making extra file for stop_direction_headsign would be a mess, so I'd advocate for the lightweight implementation of Transit, which just adds extra fields in trips.txt and stop_times.txt. But we should discuss it.

In all cases I do think this is an important topic and we should extend the spec to handle it.

 

Sources:

- Trillium's `directions.txt`: https://trilliumtransit.com/gtfs/reference/

- GTFS+ proposal: https://www.transitwiki.org/TransitWiki/images/e/e7/GTFS%2B_Additional_Files_Format_Ver_1.7.pdf

[Mike Haynes]

A few thoughts on this discussion.  

GTFS-static has no concept of "pattern" while nearly ever transit agency is deeply involved with patters or variants.  Some agencies even include a "pattern" file in their GTFS export (ex. MBTA has "route_patterns.txt"). 

In the hierarchy of transit: 

  -Routes are a collection of patterns.

  -Patterns are a collection of timepoints and stops with waypoints (i.e. shape). 

  -Trips are a sequence of timepoints operated by one or more runs/duties (i.e. mid-route relief)

  -Blocks are a collection of trips from pull-out to pull-in.  

The fundamental link between trips and patterns is that every unique sequence of timepoints from the schedule must match a pattern.  There can exist, and often do, more patterns than are used in a schedule (unscheduled short-turns, summer patterns, school variants, etc.).  Dealing with these unscheduled patterns is often a huge challenge in analysis as there is no schedule to "hook" to for predictions or performance.  It might be nice to at least work them into the GTFS-static feed for geometry. 

GTFS-static also does not have a concept of timepoints, as everything is managed via stoptimes.txt and trips.txt. (Ahem... we might want to have a concept of a timepoint flag field in stoptimes.txt, but I digress.)  Most working with GTFS data build "patterns" or variants out of the stoptimes data along with shapes and trips.  

I see a few solutions on the surface: 

1. Add a route_patterns.txt file and link via a shape_id field.  Store direction and possibly extra headsign data in the patterns file.  (storing headsign data within the concept of patterns is beneficial for locations that do not change the sign mid-trip)

2. Use the existing shapes.txt file to add a direction_id field that maps to a more human understood direction (ideally lowercase sans "-bound", that is north,south,east,west,in,out special case for counter and clockwise : one might suggest standard numbers such as used for route_type)

3. Expand the current use of direction_id in the trips.txt file. It is already binary 0/1, but could be made into a short integer to represent direction (N,S,E,W,in,out,up,down,clock,counter)

Each of the above have benefits and limitations.  Suggestion #2 probably is the least disruptive, which is key for such an established standard.  Why touch more files than necessary or mess with a critical field?

I look forward to working with more GTFS-static data as my current experience is limited to the CTA (nearly a decade off and on) and now some MBTA work.

Thank you for reading these thoughts, I am excited to follow the evolution.  

  --Mike

mhayn...@gmail.com

--
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 gtfs-changes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/0007ba55-028e-43b0-80cc-f572364cfd73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Stefan de Konink]

If people are really suggesting this kind of extensions to GTFS. What is
the reason people are not considering to move to a standard that is
actually done, and contains everything that one could possibly imagine and
is mandatory in Europe for all metropolian areas from 2020?

https://github.com/NeTEx-CEN/NeTEx

Stefan

[Paul Harrington]

Have read through this thread, it is clear that there is quite a bit of complexity when it comes to the representation of route patterns. YourStop is stop oriented and not really intended for route planning so most of the above thankfully does not apply. 

However going back to the resurrection of this thread by T Sobota

"I would ask for another review of the formal addition of the sister field to direction_id, direction_name."

I can see a case where stop oriented applications like yourstop would benefit from this. Have a look at the 2 attached images. A tourist could be on a day trip in the Dublin mountains, wander off the hills and come to the shown location on Stocking Lane. There are 2 stops across the road from each other. The tourist knows that one will bring him to the city center (because most routes in Dublin are radial) and the other will take him further away. He wants to go back to the center and has a choice between 2 trip_headsigns

"Ringsend Road-Dalriada Estate"

"Dalriada Estate-Barrow Street"

The 2 parts of each trip_headsign are the endpoints of the trip. A local will most likely know that Ringsend and Barrow are in Dublin city center and will figure that they need the second option where as this will be unclear to a tourist. You could use the direction_id and translate it to Inbound or Outbound and displays these in the map popup window.  However terms like these are locale specific. It would be much better to give the GTFS producer a way of portraying the correct directional description through a field such as direction_name.