Better describing vehicle headsigns

[Aaron Antrim]

This group has been discussing issues with displaying headsign information in a way that corresponds with what is shown on vehicles.  A significant number of services are affected by this issue in the Google Maps UI (if we use Trillium’s clients as a sample, more than half of agencies that we manage data for are affected).  I thought I would start a new thread with a better subject to continue this discussion.

Here are the two problems that I see:

1. Ambiguity about the interpretation of blank trip_headsign values in customer-facing applications.

Within the Google Maps UI, blank trip_headsign and stop_headsign fields trigger a default behavior where the trip planner assumes the vehicle's headsign based on destination.  Google Maps shows the destination as the last stop of the current trip “Red Route toward Transit Center.”  Some feed publishers may depend on this behavior; however, in other cases, this provides useless or confusing information.  Additional information in the GTFS could better inform the default behavior.

2. Need to present different types of headsign values within an appropriate context.

The approach in the Google Maps UI works very nicely when the vehicle headsign indicates destination but is kludgy if a headsign is, for example a travel direction (ex “10 Bus toward Northbound”).

A headsign_type field in trips.txt could inform GTFS-consuming applications how to show or use trip_headsign and stop_headsign information usefully.  This could be useful for trip planner, timetable creation, and arrival applications.  Some possible headsign types are:

A. To (Destination, and, optionally, via Intermediate destinations)
B. Travel direction (Northbound/Southbound or Inbound/Outbound)

Does anyone support this idea?  Have responses to this idea?  I welcome alternative proposals for discussion.

Previous discussion here:

• “New field in routes.txt to describe route geometry (loops)”: https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/Q-rNtluImiE
  
• “new field in trips.txt to define whether destination indicator is shown” (https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/E8VROkTTwf4)
  

[Nicholls, Gregory]

I'd caution against amending the spec to work around the behaviour of one presentation engine. Why not propose a change to google maps ? 

     

---

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Aaron Antrim
Sent: Tuesday, 8 May 2012 12:40 PM
To: gtfs-c...@googlegroups.com
Subject: [gtfs-changes] Better describing vehicle headsigns

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/deO7gTjsYMoJ.
To post to this group, send email to gtfs-c...@googlegroups.com.
To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

[Aaron Antrim]

I agree that making the Spec more complicated to work around one trip
planning site isn't desirable.

It seems as if, with the various types of headsign values (directional
or destination-based, for example), it could be useful for a variety
of applications to know what type of headsign is expressed. This
would allow the headsign to be presented in an appropriate context.

This issue may continue to come up for trip planners and timetable
creation software.

On May 7, 7:51 pm, "Nicholls, Gregory"

<Gregory.Nicho...@railcorp.nsw.gov.au> wrote:
> I'd caution against amending the spec to work around the behaviour of one presentation engine. Why not propose a change to google maps ?
>
> ________________________________
> From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Aaron Antrim
> Sent: Tuesday, 8 May 2012 12:40 PM
> To: gtfs-c...@googlegroups.com
> Subject: [gtfs-changes] Better describing vehicle headsigns
>
> This group has been discussing issues with displaying headsign information in a way that corresponds with what is shown on vehicles.  A significant number of services are affected by this issue in the Google Maps UI (if we use Trillium's clients as a sample, more than half of agencies that we manage data for are affected).  I thought I would start a new thread with a better subject to continue this discussion.
>
> Here are the two problems that I see:
>
> 1. Ambiguity about the interpretation of blank trip_headsign values in customer-facing applications.
>
> Within the Google Maps UI, blank trip_headsign and stop_headsign fields trigger a default behavior where the trip planner assumes the vehicle's headsign based on destination.  Google Maps shows the destination as the last stop of the current trip "Red Route toward Transit Center."  Some feed publishers may depend on this behavior; however, in other cases, this provides useless or confusing information.  Additional information in the GTFS could better inform the default behavior.
>
> 2. Need to present different types of headsign values within an appropriate context.
>
> The approach in the Google Maps UI works very nicely when the vehicle headsign indicates destination but is kludgy if a headsign is, for example a travel direction (ex "10 Bus toward Northbound").
>
> A headsign_type field in trips.txt could inform GTFS-consuming applications how to show or use trip_headsign and stop_headsign information usefully.  This could be useful for trip planner, timetable creation, and arrival applications.  Some possible headsign types are:
>
> A. To (Destination, and, optionally, via Intermediate destinations)
> B. Travel direction (Northbound/Southbound or Inbound/Outbound)
>
> Does anyone support this idea?  Have responses to this idea?  I welcome alternative proposals for discussion.
>
> Previous discussion here:
>

>  *   "New field in routes.txt to describe route geometry (loops)":https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/Q-rNt...
>  *   "new field in trips.txt to define whether destination indicator is shown" (https://groups.google.com/forum/?fromgroups#!topic/gtfs-changes/E8VRO...)

>
> --
> You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

> To view this discussion on the web visithttps://groups.google.com/d/msg/gtfs-changes/-/deO7gTjsYMoJ.

[Stuart Heinrich]

I don't think there are different types of headsigns, rather, just different interpretations of what the headsign field is meant to be.

 

The GTFS documentation might be better clarified to say, ie, "headsign is an identifiable landmark or stop that the vehicle is headed towards."

 

In addition, there can be another column to specifiy travel direction, such as "northbound".

 

Because this information is not mutually exclusive, it makes more sense to represent under two different columns, than to put the data in one column and a type in a second column.  This allows the route planners to present routes using the headsign and/or travel direction at their discretion.

 

--

You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/deO7gTjsYMoJ.

[Bradley Tollison]

I'm starting to wonder if the real problem is either

A) how the agencies you're dealing with display information

Or

B) if the word "towards" preceding the headsign information should be changed to be more general that would indicate what the bus sign should be saying rather than imply that it's the direction of travel?

[Aaron Antrim]

Stuart & Bradley- 

The current spec defines trip_headsign as a destination:

The trip_headsign field contains the text that appears on a sign that identifies the trip's destination to passengers. Use this field to distinguish between different patterns of service in the same route. If the headsign changes during a trip, you can override the trip_headsign by specifying values for the the stop_headsign field in stop_times.txt.

However, providing travel direction information in addition to destination could also be useful for timetables in some cases.

For example, Redwood Transit System's Mainline service is divided into "Northbound" and "Southbound" trips and timetables.  Vehicle signs show "Northbound" or "Southbound" with the destination for the trip.  I have provided trip_headsigns in the format "Trinidad (Northbound)".  Here is how this looks in Google Maps: http://goo.gl/maps/FXFi

The Spec currently is written with the assumption that headsigns shown on vehicles are always destinations, when, in actuality some headsigns show other indicators, like cardinal directions, or in other cases, a travel direction does not apply well, like for loop routes.  And I speculate that this assumption from the Spec has transferred into the assumptions made about headsigns in Google Maps: both the context in which the headsign is displayed ("toward"), and the default behavior which causes the headsign is assumed as the last stop of the trip in cases where trip_headsign is empty.

[Brian Ferris]

I agree with Aaron that agencies are putting different kinds of values trip_headsign and that's perfectly fine, since the spec encourages to have the trip_headsign value match what's actually listed on the bus and if that's "Loop" then that's what it is.  Google Transit doesn't do the best job of handling this, and I'm generally in favor of adding descriptive details to the spec, such as loop routes or describing the type of headsign value if it helps applications better interpret the value.

Brian