Proposal to clarify and extend route_short_name, route_long_name, route_desc
StuartJReynolds
route_desc are not the way that I, submitting data for three large
areas of UK, understand them,
GTFS says that:
route_short_name is e.g. 30X. On that we agree
route_long_name is a long name, and an example would be "London -
Nottingham"
route_desc is a textual description of the service e.g. "runs daily on
the hour every hour"
However, I have many "long service names" such as "Ruddington
Connection", which is sometimes abbreviated e.g. to "RC" on timetable
columns - although that isn't what the buses show so it is important
for the users to see the full name of what they need to catch. Also,
in our terminology a route description is e.g "Clifton - Ruddington -
Nottingham". So currently, that long name doesn't have a home - the
validator spits out a warning if I put it into route_short_name - or
if I put it into route_long_name then I lose the home for my route
description.
I would like therefore to propose to clarify the meanings by re-
purposing and extending the existing fields, as follows:
route_short_name remains as now. "RC" in my example,
could be used e.g. as column headings on a timetable
route_long_name deprecated. retained for backwards
compatibility.
route_full_name an enhanced form of
route_short_name. "Ruddington Connection" in my example.
route_heading_outbound the outbound heading that would display
e.g. on a timetable e.g. "Clifton - Ruddington - Nottingham".
route_heading_inbound as above, but for the inbound direction
(e.g. "Nottingham - Ruddington - Clifton")
route_desc remains as now, although for
clarity calling it "route_general_desc" would clarify what it was for
Regards,
Stuart
Aaron Antrim
Can you describe the additional benefit that would be provided by including this information in routes.txt?
Aaron Antrim
Can you describe the additional benefit that would be provided by including this information in routes.txt?
Roger Slevin
Surely trip_headsign is something different ... it is what we would call “destination board” and comprises a single location at the end of the trip – maybe in the example some trips go to Ruddington and some to Clifton, so each trip would have a different trip_headsign value ... fine for journey planning. But not for putting a header on a route timetable where we need “Clifton – Ruddington – Nottingham” in one direction, and “Nottingham – Ruddington – Clifton” in the other.
Whilst for some routes you could use the values in trip_headsign because the route is just of the A-B variety and doesn’t need any intermediate points, a route description in the UK often needs intermediate points to clarify it – and sometimes variants might be in brackets to show they are not part of the core route, eg: Nottingham – Ruddington (- Clifton) would show that Clifton is only served occasionally, whilst the core route terminates at Ruddington.
Roger
--
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/-/TC-KfMdjfkMJ.
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.
Brian Ferris
1) I'm not clear on how your proposed "route_full_name" field is
different than the existing "route_long_name" field. Also, at this
point, there is a lot of existing feed data and application logic
built up around "route_long_name". I think attempting to deprecate
the field or dramatically change its meaning would be extremely
difficult.
2) Your point (and Roger's) about the potential need for some
descriptive text to associate with all trips headed in a particular
direction for a route is well taken. However, I'd like to suggest
finding some way of connecting these labels to the "direction_id"
field in trips.txt. For example, how do we know which trips to group
under the "route_heading_outbound" label in your proposal?
Thanks,
Brian
> --
> You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
Roger Slevin
marketing name for the service instead of, or in addition to, a short route
number or letter.
So route_longname in the example Stuart quoted is "Ruddington Connection" -
it is the brand name for the service, and it is not a route description (it
only features one main place on the route - and some brand names have no
geographic naming in them).
That is quite different from the route_fullname suggested by Stuart, I think
... at least the two concepts are different and at present there is only one
"home" for them in GTFS
Roger
-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Brian Ferris
Sent: 02 November 2011 9:20 AM
To: gtfs-c...@googlegroups.com
Subject: Re: [gtfs-changes] Proposal to clarify and extend route_short_name,
route_long_name, route_desc
Brian Ferris
timetable in question?
http://www.nottinghamshire.gov.uk/large-static/nottsbus/timetables/TBRC.htm
And the open question is "How do I represent this timetable in GTFS
such that someone could recreate this timetable as shown from that
GTFS?"
Brian
Roger Slevin
That is the service - but the source used to get it into Google is from the
regional traveline service ... and it comes in both a "timing points"
version and an "all-stops" version in traveline.
http://217.158.134.5/se/XSLT_TTB_REQUEST?language=en&command=direct&net=em&l
ine=180RC&sup=%20&project=y08&outputFormat=0&itdLPxx_displayHeader=false&itd
LPxx_sessionID=MentzApp_562064317&lineVer=1
John L
I work on the MTA Metro North Railroad GTFS feed. As example our Hudson line trains are expressed as 'Hudson Line' and 'Hud' for the long and short route names respectively. The trips are expressed in the headsign as 'GRAND CENTRAL TERMINAL - POUGKEEPSIE' or whatever the origin and destination is.
If for example, we had connecting service for Amtrak to Albany at Poughkeepsie, I would add this into the headsign as 'GRAND CENTRAL TERMINAL - POUGKEEPSIE (AMTRAK CONNECTION TO ALBANY)' because it is part of the trip.
Remember, GTFS is for transmitting schedules and the data expressed is for routes, trips and stopping information. Expressing a different route for marketing purposes is not its intent. I think the same could be said if a proposal for a field 'route_real_name' were to be given.
If timetables are your goal, I think a new route is needed if it is SPECIFICALLY intended to have a 'Ruddington Connection'. I might do the same but I have additional data elements to express service. It may be useful to have metadata about routes.
For instance, the we have specific revenue service to Yankees Stadium on all of our lines. Instead of new routes, the service for this is expressed in a separate data element. Same would be said for the AMTRAK service in my example.
A possible solution could be route_extended_service optional file that includes ID, service_short_name, service_long_name, shaped and including an optional ID in the trip with a blank or 0 indicating Regular service.
This could be useful for trips that should have 'Yankee Stadium Service', 'First stop Croton-Harmon with Amtrak connection to Albany' or 'Express to New Haven, Limited Stops'.
By doing this, the route and trip can be expressed as 'Hudson Line, First stop Croton-Harmon with Amtrak connection at Albany' and only those trips can be expressed in a time table. A full timetable can also be made as well with no service filters.
Joe Hughes
you. Here's the original thinking behind those fields:
route_short_name is the short number/letter combination that is shown
most prominently on most buses, used by most riders to refer to that
route
route_long_name is the longer marketing name that is generally used in
combination with the route_short_name for labeling the routes. For
instance, this would be used as part of the title for that route's
printed schedule flyer/brochure.
trip_headsign and stop_headsign are used to represent the longer text
that is shown on the vehicle itself to identify the direction/
destination at any given point in the journey. stop_headsign allows
this value to be changed as many times in the journey as necessary
(for instance, on many routes the display changes to omit intermediate
destinations as they are passed)
So far in the history of GTFS-consuming systems, these fields have
been sufficient to allow the user of a mapping/journey-planning app to
correctly identify which vehicle they should board.
It is likely, however, that this information is insufficient to
generate a printed timetable in the form which many agencies would
prefer. For instance, the open-source TimeTablePublisher system
layers additional annotations on top of GTFS to be able to generate
the output that Portland TriMet and its other users prefer.
Cheers,
Joe
On Nov 2, 8:59 am, "Roger Slevin" <ro...@slevin.plus.com> wrote:
> Surely trip_headsign is something different ... it is what we would call
> each trip would have a different trip_headsign value ... fine for journey
> planning. But not for putting a header on a route timetable where we need
> Ruddington - Clifton" in the other.
> Whilst for some routes you could use the values in trip_headsign because the
> route is just of the A-B variety and doesn't need any intermediate points, a
>
> Roger
>
> From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
> On Behalf Of Aaron Antrim
> Sent: 01 November 2011 7:14 PM
> To: gtfs-c...@googlegroups.com
> Subject: [gtfs-changes] Re: Proposal to clarify and extend route_short_name,
> route_long_name, route_desc
>
> The need for the route_heading_outbound and _inbound seems to already be
> accommodated by trip_headsign (trips.txt).
>
> Can you describe the additional benefit that would be provided by including
> this information in routes.txt?
>
> On 1 Nov 2011, at 12:03 PM, StuartJReynolds wrote:
>
> route_heading_outbound the outbound heading that would display
>
> e.g. on a timetable e.g. "Clifton - Ruddington - Nottingham".
>
> route_heading_inbound as above, but for the inbound direction
>
> (e.g. "Nottingham - Ruddington - Clifton")
>
> --
> You received this message because you are subscribed to the Google Groups
> "General Transit Feed Spec Changes" group.
Roger Slevin
John
We may have different practices in the UK from those in the USA – and GTFS needs to be agile enough to handle both of our requirements.
Headsign is designed to contain a SINGLE location – the destination of the vehicle on each trip.
We then have a service which is called Ruddington Connection – it has no service number. So this is what we need Google Transit and others to show. However when the service is presented in context, then we also use a shorthand version RC to identify it alongside other services at a stop, or on a timetable or departure listing ... but this is a shorthand or abbreviation of the long service name.
In my view you are not following the current spec in what you are putting in headsign – but then probably we are also not doing so. And that is because there isn’t the right container for the information that each of us wants to be able to include.
A further frustration from all this is that Google Transit then decides not to show all supplied information – and my guess is that one reason for them making that decision is that the content of some fields is significantly inconsistent from one data supply to another – and the reason for that is that there is a weakness in the GTFS spec.
It’s not helpful, though, then to dismiss the weakness when someone raises it – particularly as you appear to be forcing inappropriate data into some fields in GTFS yourself, for the very same reason. And I don’t think it is helpful to define the purpose of GTFS in a limited way when it is supposed to be a GENERAL Transit Format Specification – and in my view a service description is an essential part of the data that ought to be transmitted.
We in traveline are not the creators of the information – perhaps another key difference between us. A line is defined by an operator in the UK – and traveline as an information service has no influence on how the line is defined; we just have to ensure that our data can replicate what the operator has defined. Many are simple lines – and we can all cope with those. But we have complex lines with a single name – and we have to make sure that these are handled within our own data management systems – and replicated faithfully in our output to GTFS and others.
Roger
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com] On Behalf Of John L
Sent: 02 November 2011 12:21 PM
To: gtfs-c...@googlegroups.com
--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
Brian Ferris
challenging because agencies tend to do things slightly differently
from place to place, which is why I definitely think it's important to
figure out where the GTFS spec isn't serving agencies fully.
Roger, you'll have to forgive me, but I'm still a bit unclear on your
proposal in terms of what data and labels you'd like to have displayed
in various UI scenarios. Is it perhaps possible that you could point
to an existing UI example (maybe something from Google Maps or another
application) where the application isn't showing the data you would
like and what data you would like to see? I think it would help me
understand the specifics of your proposal.
Thanks,
Brian
StuartJReynolds
- trip_headsign is NOT appropriate for describing a whole service;
and
- route_long_name has a totally different connotation for us when we
have two options for what to call the service depending on usage (RC
vs Ruddington Connection)
Remember too that part of my proposal was aimed not only at finding a
suitable hole to post the information that we want to supply through
GTFS, but also to change the names of some of the fields so that it
was clearer what it actually meant. The terminology is confusing at
present in a UK context, and we are surely aiming for something that
is truly general - and not ambivalent - worldwide.
I would actually be happy to stick with route_long_name if it was
actually used to hold the long name. But it isn't, it's used to hold
the route description, and the route_desc is used to hold something
different. Hence my use of different terms (although I realised after
writing that there is also a need for an additional optional
"route_heading", which equates directly to the existing
route_long_name for those people who don't want separate outbound and
inbound route descriptions)
Cheers,
Stuart
Brian Ferris
Can you elaborate a bit more on "route_long_name has a totally
different connotation for us when we have two options for what to call
the service depending on usage (RC vs Ruddington Connection)". Would
you consider both "RC" and "Ruddington Connection" appropriate
"route_long_names"? Under which situation would you show one vs the
other?
You also make the point that people are using "route_long_name" to
hold more of a route description. Can you maybe give a few examples
of what you consider a route name versus a description?
Brian
StuartJReynolds
Certainly, although I think it might help to consider what the
travelling public might expect to see in a very general sense,
divorced from any one particular system.
In the UK, passengers are used to searching for timetables based on a
service number and a route description - what I am calling "route
heading" here to avoid confusion. If you were presenting a list of
services to the public, you would quote the service number, and you
would quote the route heading so that they could differentiate, say, a
route 2 in Southend-on-sea ("(Thorpe Bay) - Southend - Hadleigh -
Thundersley - Basildon") from a route 2 in Colchester ("Severalls Park
- Colchester Town Centre") which are both in the county of Essex and
both operated by the same operator.
However, the concept of "service number" is flexible. We have
operators who like to give their services what are effectively
marketing names, but are actually the service numbers. With modern dot
matrix displays on the front of vehicles, it is no problem for them to
display e.g. "Ruddington Connection" on the front of the bus. So
service number has to be capable of supporting what we describe as
"long service names". Now, if we could get away with only using those
long names, all would be well. But a user will often be presented with
a composite timetable - a timetable which contains more than one
service which have common sections or some other reason for joining
them together, and potentially from more than one operator. So I have,
for example "the busway A" on the same timetable as "the busway B".
Clearly I cannot write "the busway A" at the top of each column of
times - it is far too wide - so "A" suffices (note that in the UK,
times for a journey read down a column - I believe that it is
different in the US - hence the lack of width) . So we now have the
concept of "short service name" and "long service name", used in
different places, but referring to the same thing. But neither of them
are what GTFS understands "route_long_name" to be, which as the spec
is written is more akin to what I have called "route heading".
When you actually get the timetable, you then need to look at the two
different panels - one for your outbound trips, and one for your
inbound. Captioning them both the same (route heading) doesn't work,
so you need the concept of "route heading outbound" and "route heading
inbound".
Finally, just to round it off, in journey planning the user needs to
know what is on the front of the bus, and where the bus is going. What
is on the front of the bus is either the long service number, if there
is one, or the short service number if there isn't. Where it is going
is dependent upon the particular trip - which is where "trip_headsign"
comes in.
So what we, as UK users, need GTFS to reflect is (in my terminology)
- mandatory short service number
- optional long service number
- mandatory (probably) route heading
- optional outbound and inbound route heading
- "trip_headsign" to give destination for each trip (e.g. catch bus 32
in direction of <end destination>)
Of these:
- short service number maps directly only "route_short_name"
- long service number does not have an equivalent, my suugestion of
new parameter "route_full_name" is to be clear to purpose and avoid
confusion with existing "route_long_name"
- route heading maps onto the current "route_long_name", but this
causes confusion hence my proposal to rename it "route_heading" but
retain old one for compatibility
- outbound and inbound route headings have no current equivalent, so
are new
- "route_desc" is confusing in the sense that "route description"
means different things, hence proposal to rename
"route_general_description"
- "trip_headsign" maps directly as now
I also believe (which is Roger's point) that Google Transit does not
make any use currently of route_desc. That certainly seems to be our
experience.
Regards,
Stuart
Roger Slevin
Stuart has just posted a detailed note - and I hope it covers most of your
questions related to my comments as well.
The item we don't think is being shown on Google Transit is
route_description .... but I haven't personally checked this out, so maybe
our perceptions on this are not up to date. I will try to do some
exploration of this later today, if time permits.
Roger
-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Brian Ferris
Brian Ferris
In your proposal, can you give me an example of a route with both a
long service number and a route heading, with specific values for
both?
If I was building a timetable application, I'm guessing you'd like the
heading for a particular timetable to be something like:
Short Service Number - Long Service Number - Route Heading -
Inbound/Outbound Route Heading
... actual timetable entries go here...
Is that reasonable?
Brian
StuartJReynolds
I thought that I'd already given them in my preceding commentaries.
Just to clarify, though, if the long service number was present then
the short version would only show where there was a lack of space e.g.
in composite column headings or as notes against times in a more
generic presentation style. They might present as shown below (these
are real examples from respectively traveline east midlands, traveline
east anglia and traveline south east in the UK). Note that actually
compiling and presenting composite timetables would require other
extensions (e.g which services to combine, route headings specific to
the composite, etc) that are not part of this proposal.
1. Ruddington Connenction
short service name = "RC"
long service name = "Ruddington Connection"
route heading = "Nottingham - Ruddington - Clifton"
route heading outbound = "Nottingham - Ruddington - Clifton" (same as
non-directional "heading")
route heading inbound = "Clifton - Ruddington - Nottingham"
route general description = "Monday to Saturday at least every half
hour between Nottingham and Ruddington, with every other trip
extending to Clifton. More frequent at peak times. Sundays hourly, all
journeys to Clifton"
I would present this to the user as:
timetable search: "Ruddington Connection" / "Nottingham - Ruddington -
Clifton" (long service name / route heading)
on timetable, outbound table headed: "Ruddington Connection" /
"Nottingham - Ruddington - Clifton" (long service name / route heading
outbound)
inbound table headed: "Ruddington Connection" / "Clifton - Ruddington
- Nottingham" (long service name / route heading inbound)
journey planner: e.g. take Ruddington Connection towards Clifton (long
service name / trip_headsign)
2. The busway A
short service name = "A"
long service name = "the busway A"
route heading = "Trumpington - Addenbrooke's - Cambridge - Longstanton
- St Ives"
route heading outbound = "Trumpington - Addenbrooke's - Cambridge -
Longstanton - St Ives" (same as non-directional heading)
route heading inbound = "St Ives - Longstanton - Cambridge -
Addenbrooke's - Trumpington"
route general description = "Daily every 20 minutes"
which presents as:
timetable search:"the busway A" / "Trumpington - Addenbrooke's -
Cambridge - Longstanton - St Ives" (long service name / route heading)
on timetable (a composite) each column of times for this service is
headed "A" (short service name)
journey planner: e.g. take the busway A towards St Ives (long service
name / trip_headsign)
3. Service 2
short service name = "2"
long service name = (empty - doesn't have one)
route heading = "Severalls Park - Colchester Town Centre"
route heading outbound = "Severalls Park - Colchester Town
Centre" (same as non-directional heading)
route heading inbound = "Colchester Town Centre - Severalls Park"
route general description = "Monday to Saturday evenings only. Monday
to Saturday daytime and Sunday service operated by Network Colchester"
which presents as:
timetable search:"2" / "Severalls Park - Colchester Town
Centre" (short service name in absence of long service name / route
heading)
on timetable (a composite 2/2C) each column of times for this service
is headed "2" (short service name)
journey planner: e.g. take 2 towards Colchester Town Centre (short
service name in absence of long service name / trip_headsign)
Stuart
Brian Ferris
Thanks for all those examples. They really helped me to understand
how you would use your proposed fields in practice.
I think I see your point about how these fields would be used in
practice, but let me try repeating it back to you to make sure we're
on the same page.
1) Route short name seems reasonable as it exists today.
2) In terms of a longer route name, there are two ways agencies
typically specify it in practice. Some have a specific service name
for a route ("Ruddington Connection" in your case) while others tend
to use a long name that describes the important points visited by a
route ("Nottingham - Ruddington - Clifton" in your example). The
problem is when you want to specify both in GTFS. You could simply
combine the two into one value ("Ruddington Connection: Nottingham -
Ruddington - Clifton") and put that in "route_long_name", but then
that gets a bit unwieldy, especially when you want to display that
along with another value like "trip_headsign" or your proposed
inbound/outbound route heading. Certainly, "RC | Ruddington
Connection: Nottingham - Ruddington - Clifton | Clifton - Ruddington
- Nottingham" for service from Clifton to Nottingham is both unwieldy
and a bit confusing for riders. Putting the route service name in
"route_long_name" and the important points visited in "route_desc"
isn't satisfactory either because the route description field is a bit
of a catch-all that can include long blocks of text, so it isn't often
display in UI headings in practice. Thus, the new field.
3) Regarding, your proposal for "route heading outbound" and "route
heading inbound", I think there is some demand for this from some
other agencies and it's something I would have liked when I was
writing timetable generation code in OneBusAway. In practice, I ended
up using the most frequent "trip_headsign" from trips.txt as the next
best thing, which leads to my next question. How would the value you
specify for "route heading outbound" or "route heading inbound" differ
than the value you might specify as "trip_headsign" in trips.txt for
an out-bound or in-bound trip? Where they are different, can you give
a quick example? I know trip headsign refers to what appears on the
headsign of the vehicle itself, but I'm curious how they differ in
practice.
So the next big question, as with any GTFS proposal, is this: are
there any app developers out there who would be interested in using
the new fields proposed by Stuart?
Thanks,
Brian
On Wed, Nov 2, 2011 at 6:12 PM, StuartJReynolds
StuartJReynolds
Thanks for that. I agree with your interpretations of what I have
said.
An example of (3) would be National Express 797, which we describe as
"(Norwich - ) Cambridge - Heathrow - Gatwick ( - Brighton)" outbound
and "(Brighton - ) Gatwick - Heathrow - Cambridge ( - Norwich)"
inbound.
Most if not all trips will do the section that is not in brackets -
Cambridge to Gatwick via Heathrow and return. However some, an
indeterminate number, start (and end) at Norwich, and some start (and
end) at Brighton. Some might even do both! It would be wrong to
describe the service by simply the majority view, because passengers
reading the headline description would have no idea that they could
use the service to get from Norwich or to Brighton, say. On the
individual trips, sure - you would say that the coach goes to
Brighton, or that the coach goes to Cambridge. Indeed you would need
to, because users would refer to front of vehicle display to ensure
that they were getting onto the right service.
Hope that's clear - if not let me know and I'll find another example.
Cheers,
Stuart
>
> read more »
Roger Slevin
Brian
As far as I can see Google transit does not appear to display the route_description field, so there is no point in populating it. Am I mistaken?
I think other points that I was making have now been clarified in subsequent e-mails between you and Stuart. Perhaps I can just reinforce a point - using the now infamous Ruddington Connection service?!
On Google Transit we see a journey between Nottingham and Ruddington summarised in the following ways :
And
As Stuart has described, we only use RC in contexts where the words Ruddington Connection can also be shown – so whilst RC will appear at the top of a journey (presented vertically in a UK matrix timetable), it will be in a table where Ruddington Connection appears as the service name. On our own system, the itinerary for this particular journey looks like :
So we show the operator (Trent Barton) and the service name for complete clarity – and we do not use RC in this situation as it would mean nothing – it does not appear on the bus ... it is just an abbreviation which is only acceptable in a context where the abbreviation is explicitly or implicitly explained.
Best wishes
Roger
Aaron Antrim
When the existing long name and short name fields are both used most
usefully for a trip planner, they provide different types of
information. TriMet in Portland provides an example of this. Below
examples are http://trimet.org/schedules/r020.htm
route_short_name: The short names of bus lines are numbers: quick
unique references for the lines. The short name for this route is
"20."
route_long_name: The long names are the main roads along which the
route alignment runs (in other words, the travel corridor via which
the destination, indicated by the headsign, is served). The long name
is "Burnside/Stark."
Formerly, the Google Maps UI showed both the short and long name in
the itinerary, as shown in this screenshot:
http://code.google.com/transit/spec/transit_feed_specification.html#transitLongNameScreenshot
Now Google Maps shows just the short name in the itinerary view
(http://g.co/maps/3egqx), but will show the long name if the short
name is not defined. The popup info box for a stop shows both the
long and short name. In TriMet's beta OpenTripPlanner implementation,
both the route_short_name and route_long_name are shown: http://tinyurl.com/7nwse7h
In some cases, feed publishers may use an abbreviation for
route_short_name values (as with the Ruddington Connection, or RC). I
question whether providing a route_short_name that is an abbreviation
of the long name is consistent with the current spec, which states
route_short_name is an abstract identifier that is distinct from
route_long_name.
Might a better distinction between route_short_name and
route_long_name be the type of information instead of the length of
the string? route_short_name is generally a more abstract
identifier. route_long_name provides some form of brief description
about the route. feedvalidator returns a warning, not an error, for
longish route_short_names. There is nothing in the spec about a
character limit for the field. Are there applications that would
break with a long route_short_name (say, 21 characters)?
In the trip planner UI, I think that the route heading information is
most usefully presented as the direction of the vehicle, using the
trip_headsign information. Though this is the way many services are
named and presented in timetables, following this formula in a trip
planner creates redundancy. Here's an example ("Newport/Bend Bus
towards Bend"): http://g.co/maps/2eyuh
Instead, it's clearer and less redundant when trip_headsign shows this
information only. Here's an example ("Oakdale via Riverbank"):
http://g.co/maps/vtd6p
A map-based trip planner makes the display of the route_long_name
(service "via" information: "Nottingham - Ruddington - Clifton" or
"Burnside/Stark") less necessary, because the map shows the course of
travel.
Note that with the current spec and Google Maps UI behavior, using a
route_short_name of "Ruddington Connection (RC)", with a long_name of
"Nottingham - Ruddington - Clifton" and trip_headsigns that show the
respective outbound and inbound route headings might present nicely.
This post from the Jarrett Walker's excellent humantransit.org ("the
to/via question") takes a step back to look at how transit agencies
can most usefully communicate their service corridors and destinations
through their signage, information, and service names. I think his
post is helpful for transit agencies to consider their goals in
providing this information: http://www.humantransit.org/2009/07/legibility-as-marketing-and-the-tovia-problem.html
Currently, the GTFS does not offer a very complete way of describing
the necessary information to produce timetables. I support the idea
of adding outbound and inbound route headings but I do not maintain
software that consumes GTFS, nor do I have a lot of experience with
automatically generating timetables.
Still, I'll offer that if there are thoughts of adding patterns.txt or
something similar (http://groups.google.com/group/gtfs-changes/
browse_thread/thread/557dd991c453807a/758e39494db3899d?
#758e39494db3899d), it might be useful to understand how directional
timetable headings would fit in. It's also useful to think about non-
directional or loop routes in this discussion.
Cheers,
Aaron
www.trilliumtransit.com
On Nov 4, 7:16 am, "Roger Slevin" <ro...@slevin.plus.com> wrote:
> Brian
>
> As far as I can see Google transit does not appear to display the
> route_description field, so there is no point in populating it. Am I
> mistaken?
>
> I think other points that I was making have now been clarified in subsequent
> e-mails between you and Stuart. Perhaps I can just reinforce a point -
> using the now infamous Ruddington Connection service?!
>
> On Google Transit we see a journey between Nottingham and Ruddington
> summarised in the following ways :
>
> As Stuart has described, we only use RC in contexts where the words
> in a table where Ruddington Connection appears as the service name. On our
> own system, the itinerary for this particular journey looks like :
>
>
> > needs to be agile enough to handle both of our requirements.
>
>
> > vehicle on each trip.
>
> > We then have a service which is called Ruddington Connection - it has no
> > service number. So this is what we need Google Transit and others to
> show.
>
> > However when the service is presented in context, then we also use a
>
> > shorthand version RC to identify it alongside other services at a stop, or
>
> > on a timetable or departure listing ... but this is a shorthand or
>
> > abbreviation of the long service name.
>
> > In my view you are not following the current spec in what you are putting
>
> > because there isn't the right container for the information that each of
> us
>
> > wants to be able to include.
>
> > A further frustration from all this is that Google Transit then decides
> not
>
>
> > making that decision is that the content of some fields is significantly
>
> > that there is a weakness in the GTFS spec.
>
> > It's not helpful, though, then to dismiss the weakness when someone raises
>
> > fields in GTFS yourself, for the very same reason. And I don't think it
> is
>
> > helpful to define the purpose of GTFS in a limited way when it is supposed
>
> > description is an essential part of the data that ought to be transmitted.
>
>
> > key difference between us. A line is defined by an operator in the UK -
>
> > traveline as an information service has no influence on how the line is
>
> > defined; we just have to ensure that our data can replicate what the
>
>
> > those. But we have complex lines with a single name - and we have to make
>
> > sure that these are handled within our own data management systems - and
>
> > --
>
> > 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.
>
> > --
>
> > 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.
>
> --
>
> 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 athttp://groups.google.com/group/gtfs-changes?hl=en.
>
>
>
> 4KViewDownload
>
> image002.png
> 27KViewDownload
>
> image003.png
> 27KViewDownload
Brian Ferris
a couple hundred existing GTFS feeds to see how agencies are using the
field in practice. As alluded to by most everyone in this thread, the
field, when present, is used almost exclusively for describing the
"via", "to", or "heading" information for a route. I'd say 99% of the
field values I looked at used this semantic, at least for the
languages I could read. I was hard pressed to find many obvious
examples of feeds that used "route_long_name" as more of a service
name in the manner Stuart has outlined.
This presents a problem. As discussed in the thread, a lot of UI that
displays GTFS data has moved away from display "route_long_name"
because it is often shown in combination with a "trip_headsign" value,
which leads to confusing results when both fields are effectively
providing heading information. But what about an agency that has a
route branded with a service name?
Aaron has proposed putting this information in the "route_short_name".
I'll be honest that I don't think I'd vote for this approach. I know
of a couple of apps (a few I've written myself) that do not do so well
when a longer string is included in "route_short_name". I think it
would work for some apps, but ultimately, I think it would dp more
harm than good.
Another alternative, which I think is similar in spirit to what Stuart
proposed, is to introduce a new field like "route_heading_name" and
clarify the purpose of "route_long_name". Specifically,
"route_long_name" would only be used when there is a specific branded
service name for a route ("Ruddington Connection" in Stuart's example)
while "route_heading_name" would be used for
destination-or-waypoints-style route descriptions ("Clifton -
Ruddington - Nottingham" in Stuart's example). The problem with this
proposal is that in practice, almost every agency is using
"route_long_name" for storing data that would ideally go in
"route_heading_name". I think trying to fix that at this point would
be a losing battle. We'd likely end up in some mixed state where some
agencies had adopted "route_heading_name" but not all, which meant
that a consumer of GTFS could not reliably display "route_long_name"
in their UI since it could still conceivably have heading information
in it.
So here's my proposal. At this point "route_long_name" is almost
exclusively being used by agencies for destination-or-waypoints-style
descriptions of a route. I think we're stuck with that at this point,
but we should clarify the documentation to indicate as such. The
column name isn't really indicative of the contents, it's true, but
again I think there might be too much inertia to change it. We would
then also introduce a "route_service_name" field that would be used to
hold branded service names for a route (again, "Ruddington Connection"
in Stuart's example. A consumer of GTFS could more reliably show UI
that combined "route_service_name" + "trip_headsign" without worry
that they'd have conflicting information.
Thoughts?
Brian
Mike Gilligan
> > unique references for the lines. The short name for this route is
> > "20."
> > route_long_name: The long names are the main roads along which the
> > route alignment runs (in other words, the travel corridor via which
> > the destination, indicated by the headsign, is served). The long name
> > is "Burnside/Stark."
>
> > Formerly, the Google Maps UI showed both the short and long name in
> > the itinerary, as shown in this screenshot:
>
> read more »
David Healy
Brian's comments about the usage of the route_long_name. If the
purpose of this field were changed, it would cause a headache for us
trying to consume a variety of data sets with different usages for
this field.
In light of this, I'd add another +1 for adding 'route_service_name'.
>
> read more »
Wojciech Kulesza
Introducing "route_service_name" gets a +1, as we could move "between" info to this column.
Wojciech Kulesza
goEuropa
> ...
>
> read more »
Roger Slevin
I am also a +1 for this (and I hope Stuart is with me on this - I haven't
been able to discuss with him since your post)
Thanks for doing the research that makes the case clear - Stuart and I were
keen to ensure backward compatibility, and to tighten the specification of
how these particular elements are used. I think your proposal to add
route_service_name (with an appropriate clear definition), along with
tightening the definition of route_long_name, will achieve this.
Aaron Antrim
As envisioned, would a trip planner UI show both route_short_name and route_service_name?
Brian Ferris
held a couple of messages for moderation for some unknown reason.
Brian
StuartJReynolds
Thanks. That will be a +1 from me too for "route_service_name". It
seems a sensible option.
I would still like to have an inbound and outbound description
somewhere, but I would be prepared to park that for a later date to
get the route_service_name agreed.
Regards,
Stuart
> > unique references for the lines. The short name for this route is
> > "20."
> > route_long_name: The long names are the main roads along which the
> > route alignment runs (in other words, the travel corridor via which
> > the destination, indicated by the headsign, is served). The long name
> > is "Burnside/Stark."
>
> > Formerly, the Google Maps UI showed both the short and long name in
> > the itinerary, as shown in this screenshot:
>
>
> read more »
StuartJReynolds
I think that would be up to the planner. My own view is that the
public should see the actual name of the service, so
route_service_name if it is populated or route_short_name if it isn't.
However, if you were constrained for space (e.g. column widths in the
bubbles) then you would use the route_short_name - although, again
personally, I would ensure that it was annotated underneath in space
e.g. "RC = Ruddington Connection" so that the public facing name was
still shown somewhere.
Stuart
>
> read more »
Brian Ferris
me describe a proposal I've seen for a similar feature to see what
everybody thinks.
The idea is to add a new column to trips.txt that I'm going to call
"direction_name" to keep it consistent with the existing
"direction_id" field. For each trip in trips.txt, you can specify a
direction name that is similar in purpose to the inbound / outbound
description that Stuart has discussed.
How would this be used in practice? For timetable generation, I could
group trips for a particular route by their "direction_name" and
display that "direction_name" above the timetable for those trips.
"Why not just use trip_headsign for this purpose?" you might ask?
That's probably a reasonable question, but I'm guessing in the case of
timetable generation, feed providers might want to use a general label
for "direction_name" while "trip_headsign" might have specific
variations for different trips. "What is the relationship between
direction_id and direction_name?" you might also ask. Another good
question, and I'm not exactly sure. One option is to require all
trips with the same route and direction_id to have the same
direction_name. Maybe that's too restrictive? Can anyone think of
situations where they'd like a different grouping using "direction_id"
than they would with "direction_name"?
Stuart, regarding your proposal for a "route_heading_outbound" and
"route_heading_inbound", my main concern with that is that it's not
clear how that connects to the actual trip entries in trips.txt, in
terms of using it to group trips in a timetable. Also, not every
route will necessarily have an inbound/output configuration. The more
general direction functionality of trips.txt seems more flexible to
me.
Thoughts?
Thanks,
Brian
StuartJReynolds
I'm not precious about the names that I used, or even where the fields
sit. The reason for coining those particular names was in the context
of the other changes that I was suggesting.
I had a think about your proposal, and it sounds quite promising. As
you say, the direction_name could be constant when the feed was
created (in a way that the trip_headsign needn't be) for a particular
service & direction, and if the naming was done well, then a user of
the feed could actually use it to read across several service/operator
combos and, in effect, produce a "corridor" timetable for a given
route. Or just produce single operator/service/direction timetables,
as required for their particular application.
Regards,
Stuart
>
> read more »
Devin Braun
I am in favor of this proposal for directon_name and direction_id. We have been providing exactly these two fields in our trips.txt file for a while now.
They provide a great way to group trips for timetables, as you mentioned. When you build routes with HASTUS, each route can be assigned a pair of directions whether it's inbound/outbound, east/west, clockwise/counter-clockwise (or anti-clockwise).
Devin Braun
San Diego MTS
T Sobota
Roger Slevin
I think "direction_name" should be a description tied to "direction_id". I
cannot think of a situation where the two should not be related to precisely
the same set of trips.
In response to some other comments, I think the definitions of these names
should make clear the context in which each is to be used - but not specify
the precise format of each name, as these appear to be culturally specific.
The format of the content of each field would be different in the UK from
that used in the US - and other countries may equally have their own
conventional differences. It is the "function" of the field that is
important, not the "format" of the content.
Brian Ferris
a 1-to-1 mapping between direction_id and direction_name, we could
introduce a directions.txt file (name is negotiable) with three
fields: route_id, direction_id, and direction_name. For each unique
combination of route_id and direction_id in trips.txt, a row could be
added to directions.txt that includes a direction_name for that
route_id+direction_id. This would more strictly enforce the idea that
a particular route_id+direction_id combination can only be associated
with one direction_name and would avoid a lot of repeated values in
trips.txt.
Thoughts?
Thanks,
Brian
StuartJReynolds
Yes, I like that idea. Keeps it separate and distinct. +1 from me for
that.
Stuart
>
> read more »