Proposal: new field in trips.txt to define whether destination indicator is shown

[Aaron Antrim]

This is a proposal to provide a mechanism to indicate when transit
vehicles do not indicate their destination or travel direction.

NEED:
Currently, some information-presenting applications assume that there
is always a destination indicator. For example, if trip_headsign or
stop_headsign values are not provided, Google Maps assumes that the
headsign is the name of the last stop in the trip. However, for some
trips, such as on loop routes, it would be better if no headsign were
displayed (This Cottonwood Area Transit bus is always bound for
Garrison Park: http://g.co/maps/uhm5g).

I perceive this as a major issue based on the number of services
affected: 50 of our client transit services collectively operate
approximately 195 loop routes, most of which do not show destination
headsigns.

PROPOSAL:
Since some feed publishers now expect the displayed headsign to be the
last stop name of the trip, I propose to add a new field to trips.txt,
no_dest_indicator. This field will indiciate whether the destination
is indicated on vehicle signs. Trip planning applications could use
this field to control if destination information is shown.

Possible values and meanings as follows.
no_dest_indicator is 0 or not defined: Vehicle destination is shown.
no_dest_indicator is 1: Vehicle destination is not shown.

BACKGROUND:
This follows after a discussion regarding loop routes
(https://groups.google.com/group/gtfs-changes/browse_thread/thread/
43eacdb65b889a21)

REQUEST FOR RESPONSES:
Does this seem like a sensible, workable change to the Spec? Does
anyone have alternative ideas? Are there other organizations that
have similar needs?

--
Aaron Antrim
Trillium Solutions, Inc.
www.trilliumtransit.com
Portland, Oregon

[Nicholls, Gregory]

This sounds like you really want to specify the expected behaviour if xxx_headsign is not present. Rather than adding another flag, why not amend the description of the field in the spec to state that if a headsign is not provided the implementation must not display anything.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
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 would be fine with this approach.  However, I believe that there is some concern that changing the default behavior may affect a number of feed publishers that depend on the current approach.  If feed publishers do not change their data, then results presented to customers might be missing information.  Can anyone elaborate by describing current implementations in applications that display transit information?

[Matt]

You should see how SEPTA in Philadelphia, PA has their bus loop's trip_headsign set up

http://g.co/maps/xqfwd

http://g.co/maps/4jdqp

http://g.co/maps/z5d7n

the 38th and Spruce means that those trips actually end at 38th and Spruce St

[Nicholls, Gregory]

Changing the specification won't change the behaviour of existing code. All that will happen is that existing implementations will no longer be in precise compliance. Google maps will still use the last stop if they don't have a headsign (at least for now) , however the change to the spec may prompt the feed publishers to specifically add the last stop as a headsign if that's what they want.

    This segues nicely into versioning. I don't see anything in the GTFS spec that allows for versioning. Has any thought been given to that ?

---

From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of Aaron Antrim

Sent: Thursday, 26 April 2012 10:38 AM
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Proposal: new field in trips.txt to define whether destination indicator is shown

[Aaron Antrim]

Yes, I see that some "LUCY Gold" trips end at 38th & Spruce.  For these trips, trip_headsign values are "38th-Spruce."  I assume this matches what is on the destination indicator.

LUCY Gold timetable here: http://www.septa.org/schedules/bus/w/LUCYGO_0map.htm

Some "LUCY Gold" (route_short_name = LUCYGO) trips run through the entire loop.  For these trips, the trip_headsign value is "LUCY Gold Loop," which is not a direction or destination.  It also duplicates the route name.  This will be awkward after "toward" or "Direction:" in the Google Maps UI.

With SEPTA's LUCY Gold route, I see an example where trip_headsign is used effectively for trips that do not complete the entire loop.  For trips that do complete the loop, the trip_headsign values shown in Google Maps do not seem to be contributing to clear, concise information.

--
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/-/sgu6aq1_3w8J.

[Brian Ferris]

For better or worse, it's true that adding this flag won't mean much if the provider you care about (ahem Google) doesn't change their default behavior.

In general, I'm in favor of descriptive fields as opposed to prescriptive fields.  I'd rather introduce a field that describes the type of headsign value (destination vs direction vs something else) than a field that prescribes what exactly you do with a field in UI.  Descriptive fields will ultimately be more useful to feed consumers in deciding how to present values in their UI, especially as UIs and use-cases evolve over time.  I'll also admit that Google's UI doesn't handle all headsign values in the best possible way and we are working to improve that.

All of this is to say I'm -1 on the proposed "no_dest_indicator" and more in favor of the loop route type indicator or adding a field that suggests the type of headsign value.

Brian

[Aaron Antrim]

Thanks for the feedback.  Approaches to provide more description of the service will allow developers to do more, and more flexibly.

I would like to make a case that this proposed field actually is descriptive of the provided transit services.

Originally, I considered proposing a field "no_headsign," which would aim to control the display of headsign values in GTFS consuming applications.  However, the proposed field is "no_dest_indicator."  This field describes whether a the destination is indicated on vehicles.  It is up to the application developer to determine if or how this information can be used.

Aside from this, however, the main purpose of the field is to suppress the display of headsigns in trip planner interfaces.  So, I must acknowledge that for the purposes that I envision, the field is intended as largely prescriptive.

What would work really well for Trillium (my company), would be for a blank trip_headsign to mean that there is no destination indication given, and thus that no headsign should be shown.  However, my understanding is that this would break many feeds that depend on default behaviors.

So, we need a way to describe situations when showing a headsign or direction indicator is not appropriate.

To review, here are two ideas already proposed:

1.) A new route_geometry field in routes.txt.  This describes whether a route is a loop or is directional or another shape (?).  The idea is that for non-directional routes, this could provide an indication that destination headsigns are not useful.  This information may also be used in other ways.

2.) A no_dest_indicator field in trips.txt.  This says whether destinations are indicated on the vehicle readerboards.

A third alternative could be a headsign_type field, that indicates whether a headsign shows a travel direction (Northbound, Inbound, etc.), a destination, or no information.

What are the best out of these options?  Does anyone have other ideas?

[T Sobota]

Out of curiosity, and apologize if I missed such clarification earlier, but do the trips in question truly display a blank headsign to passengers encountering the vehicles on the street (or do vehicles lack a headsign display)?  I recall the discussion about how loop routes in general can create marketing difficulties from the headsign programming perspective (how to describe at various points along the loop of the route what headsign should read to be meaningful from a marketing standpoint) - so would conceptually argue that where a transit vehicle does display a headsign message to customers on the street as it approaches, that the value in the current feed specification should be matching that actual headsign message display on the vehicle (as confirmation to the passenger that the actual headsign does equal what the feed data suggests it should be).

At the same time, the illustration provided by Google would imply that the value of the headsign field is what follows the "DIRECTION:" text... so to the extent feed consumers like Google are using alternative fields after this "DIRECTION:" text, when headsign is perhaps purposefully being left blank - that is confusing as well.

https://developers.google.com/transit/gtfs/examples/display-to-users#TripHeadsign 

Brian

To unsubscribe from this group, send email to gtfs-changes+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.

To unsubscribe from this group, send email to gtfs-changes+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/gtfs-changes?hl=en.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.

To unsubscribe from this group, send email to gtfs-changes+unsubscribe@googlegroups.com.

[Aaron Antrim]

Tim,

You have boiled this issue down to its core:  The trip_headsign field is intended to match the headsigns shown on transit vehicles.  However, sometimes transit vehicles may not shown a destination or direction indicator.  Google Maps, and potentially other applications, do not interpret a blank trip_headsign field to mean that headsign is not shown on the vehicle, or that it is not applicable.  Thus, I think there is a real need for describing these cases.

With regard to loop routes specifically, my interim solution has been to specify a trip_headsign of "(Loop)", so it is clear to the passenger that the route does not have an end terminus.  Here's an example result in the GMaps UI (http://g.co/maps/7vnhn).  Most agencies that operate these types of loop route just set the readerboard to something like "Gold Route," and leave it at that.

I would like to work out a less kludgy arrangement for about 195 loop routes operated by 50 agencies in the data feeds that Trillium maintains.

Aaron

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

To post to this group, send email to gtfs-c...@googlegroups.com.

To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.

[Marcy]

I also manage many loop routes that do not offer headsigns that would match the precise specification for "direction."  The headsign and route name are the same.  

How many public users are reading the GTFS spec hoping that that it precisely matches the headsign on the UI for a simple explanation of the "direction of travel"?   

I will not fill-in or manage more data for the many loop routes I manage.  Especially if the UI may not change.

Stop_headsigns work well.  Perhaps some of the style-guide could offer a reminder of why leaving trip_headsign blank might be confusing.

If the headsign is captured in the route name, why can't direction add some direction-based information without being limited by the spec for large cities that may have more precise headsigns that is helpful?  User feedback I get is that the stop_headsign can display appropriate places or stops along the way for example: senior center, civic center, __Mall, library, Post Office, or stop names, etc. Here's a Friday-only Trolley Loop serving Avila Beach Farmers Market: http://g.co/maps/yftnv 

With thoughtfully filling-in stop_headsign the current UI works well and public user will know where the bus is going. The new public user or visitor can glance at the map & see the way the route will go & get on the right bus without having to confirm if this is the "loop" or "clockwise" trip of the day.

I don't believe I've had positive user feedback on "counterclockwise" as a direction that really helps riders know where they are going.

If we are not seeing app developers concerned about the display from their users, is it possible that stop_headsigns are working well for them, if supplied?

Marcy

[Aaron Antrim]

Thank you for the comments, everyone.

My goal is to provide GTFS data in such a way that trip planner and other applications can show headsign and direction information that corresponds with what is displayed on vehicles, and what is presented in timetables.

The proposal for a "no_dest_indicator" field seem does not seem like it would do much to enhance the GTFS, and has garnered little support here, so I am going to create a new thread to discuss other ideas.

-Aaron