proposal: trip_type to allow client applications to exclude unusual trips from certain displays

[Joe Hughes]

Summary:
Add a way to distinguish between typical and atypical trip patterns.

Motivation:
Many agencies have a few trips per day that follow unusual paths for
that route. For instance, most trips on the BART rail system in the
San Francisco bay area stop at either SFO Airport or Millbrae, but not
both. However, a few trips per day (usually in the late night/early
morning) stop at both. When displaying summary views of the route,
some clients might want to exclude the uncharacteristic trips.

Proposal:
The following field would be added to trips.txt:
--------------------------------
trip_type (optional):
The trip_type field characterizes the path (sequence of stops) that
this trip visits. The allowable values are:

"0" - the trip follows a typical path
"1" - the trip follows an unusual path, something that the route does
only a few times a day or on special occasions. A trip should be
given this value if riders wouldn't expect the route to follow this
path.

If the field is omitted, all trips are treated as though they have
trip_type "0".
--------------------------------

Discussion:
While this meets the basic need, one could argue that the format would
be better served by a more explicit notion of "trip patterns"; that
is, giving each trip a pattern ID that groups it with similar trips.
We could then mark certain patterns as atypical, rather than marking
the individual trips.

Your thoughts?

Joe Hughes
Google

[Nicholas Albion]

Unless I'm missing something, trip planning algorithms (and other
processes) could be made a lot more efficient by the addition of a new
table, similar to stop_times.txt but omits the time-specific info:

trip_patterns.txt -
- pattern_id (key for this table)
- route_id
- stop_id
- stop_sequence
- shape_dist_traveled

Ideally, there would be 2 tables - the above table would be renamed to
something like "common_patterns.txt" and then there would be a 2nd to
combine common patterns (even if there was only one pattern for some/
all trips in some feeds)

trip_patterns_merged.txt
- trip_pattern_id (key for this table)
- pattern_id (refers to key in table above)
- pattern_sequence

then in trips.txt you'd have an extra field
- pattern_id
- pattern_merged - (might provide a way to eliminate the need for the
2nd table - defaults to false in which case pattern_id refers to 1st
table, otherwise it refers to 2nd table (trip_patterns_merged) .

So you might have several routes which come from North, North West,
North East, but all take the same path through the city (and possibly
beyond). The pattern would be a lot more explicit and descriptive (to
the application) than ("this trip follows an unusual path")

-------
Or make shapes.txt compulsory and add a field "stop_id" which would
only be present where the shape coincides with the location of a stop.

Either of these 2 changes would make trip planning time independent
(where appropriate to the consuming application or user). The lack of
this information has been a major stumbling block for the applications
I've been working on.

Feed-generating/manipulation/maintenance applications would also
benefit from the pattern idea if there was a concept of "average time
from the next/previous stop" as the stop_times entry could take
guesses after the trip start time was provided.

[Devin Braun]

One of the challenges of creating a regional transit map from the shapes
and a schedule display from stop_times in GTFS becomes finding a trip
pattern for a route and direction of a route from all of the variants
and shortlines. When dealing with CAD/AVL systems, and even in HASTUS,
we must specify these patterns so that schedules are accurately
portrayed in printouts, on websites, etc.

Using the trip_type field and marking a variant unusual would allow one
to draw a dotted line for a regional transit map, signifying limited
service.

I can provide testing data for stop-level trip patterns if needed.

Devin Braun
San Diego MTS

[Mike Gilligan]

If you look at the latest TriMet feeds, there is a field named
trip_type in trips.txt. I currently have a text description but an
enumeration would work better. The value is either blank, to indicate
typical service, Express, or Limited. These values are currently being
used by TimeTablePublisher for footnotes. Express is service that
skips a significant segment of the typical route path, Limited is
service that only serves limited/major stops during a segment of the
typical route path. I think it would be nice to have a more
comprehensive list of trip_types such as Typical (0,blank), Limited
(1), Express(2), Short Line(3), Branching(4), etc.

In house, we also maintain a field to indicate that a pattern will not
be displayed to the public for our system map & other GIS files. We
could supply a patterns.txt file which includes the shape_id and a
public field (0,blank = include, 1 = exclude)

Thanks,
Mike Gilligan
TriMet

[Tom Hixson]

Joe-
I believe the spec already has a way to warn of atypical patterns:
trip_headsign in trips.txt. In Trapeze the patterns have this field,
so each pattern can have its own headsign. This supposes that any
service worth warning about will have a different stop sequence (aka
pattern).

But in general I agree with adding explicit patterns, and have alway
been surprised by their omission. In fact I include a patterns file
so the feed can be used in other ways (and use patternId for
shape_id). The hardest part of the data is getting the patterns right
(and near the corresponding shape), which is why Devin's www.gt-preview.com
site is so useful.

Some agencies use patterns where other would make a new route (we went
from the former to the latter). For those agencies who have atypical
(rare) patterns, I would mark the typical one as the 'master'; all
others are deviants.

But what becomes of stop_id in Stop_times.txt? It likely should not
be in two files (bad normal form).

Another problem is the source. Trapeze uses stand-alone patterns like
you suggest while Hastus uses common patterns with variants, like
Nicholas suggests. Smaller systems might not use patterns at all
(like GTFS).

Tom Hixson
Sacramento

On Nov 20, 6:41 pm, Joe Hughes <joe.hughes.c...@gmail.com> wrote:

[Joe Hughes]

Hey Mike,

Could you create a new thread with a proposal for this TTP field,
since it seems like it's aimed at a different use case? It's
definitely worth considering for inclusion in the spec.

Joe

On Nov 21, 11:25 am, Mike Gilligan <mgilli...@gmail.com> wrote:
> If you look at the latest TriMet feeds, there is a field namedtrip_typein trips.txt. I currently have a text description but an

> > Thetrip_typefield characterizes the path (sequence of stops) that