Service Variations

[DaveFulton-Trapeze]

One of the issues that can be an issue for our clients is when the
client has a complex set of variations to standard service. These
variations include school variations (Exclusion - ie Open/Closed), day
of week variations, and special event variations. These change the
service levels on a day to day basis depending on what is running or
not running.

A trip can be marked with one or more variations. For example a trip
that serves a school maybe would be marked with a school open
variation and if the dismissle times varied daily it may also be
marked with a day of the week. In addition, there may be an
alternative trip which runs in its place when school is closed.

Currently, there is no way to mark a trip in the spec with a
variation, requiring addition serviceid's to be created for each
combination of variations that are running in a given period.

The current specification has a calendar and calendar dates table both
with an id that points to the trips and there is no way to note/mark a
trip with a set of variations.

There are two proposals I have:

1. Allow a service variation id to be included against a trip and
allow the calendar dates file to be set with these id's.

2. Allow a Note/Comment to be added to a trip to indicate variations
(ie. This trip runs on School days only)

Porposal 2 is very simple and it would be the public who would have to
determine if schools were open for example.

Proposal 1 would look something like this in the changed files:

Trips

Trip 1 - 813a-847a Route 1 - service 1 - variation 2 - Block 1
Trip 2 - 820a-855a Route 1 - service 1 - variation 3 - Block 1
Trip 3 - 857a-933a Route 1 - service 1 - variation 0 - Block 1
.
.
.
Trip 18 - 935p-1001p Route 1 - service 1 - variation 4 - Block 1
Trip 19 - 1005p-1036p Route 1 - service 1 - variation 4 - Block 1

In this example a block is formed with school/non-school trips in the
morning and two late night trips that will operate on specific days to
accomodate late night xmas service to a mall.

Calendar

Service 1 - 1111100 - 20091201 - 20100331

Calendar Dates

Service 1 - date 20091210 - exc type 1 - service variation 2
Service 1 - date 20091211 - exc type 1 - service variation 3
Service 1 - date 20091211 - exc type 1 - service variation 4
Service 1 - date 20091214 - exc type 1 - service variation 2
Service 1 - date 20091215 - exc type 1 - service variation 2

New File Service Variations

Service Variation (id)
Service Variation (abbreviation)
Service Variation (description)

2, SCH, School Days Only
3, SCC, School Holidays Only
4, XMAS, Xmas Shopping Special to Galleria Mall
etc...

Trips marked with service variation 0 would always operate when the
serviceid is operating and those with a not 0 service variation would
operate only on the dates specifed in the calendar dates.

Thanks

[J. R. Westmoreland]

I, personally, like the idea in 2. I would also say that this field is an
optional field.

Thanks,
J. R.

--------------------
J. R. Westmoreland
Custom Computers & Consulting
E-mail: j...@jrw.org
Twitter: GeneralJR
Skype: j.r.westmoreland

--

You received this message because you are subscribed to the Google Groups
"Google 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.

[Joe Hughes]

Hi Dave,

Thanks for the detailed proposal. Can you provide additional context
on the motivation for this? I'm unclear on what capabilities proposal
#1 adds to the spec. As you say, it seems like the same information
can be expressed by just having the GTFS export software convert
variations into service periods. I'm probably missing something,
though.

Proposal 2 does add extra information (variation abbreviation &
description) that would be relevant to client apps, though. Are any
of the app developers here interested in using this extra information
in their apps?

Thanks,
Joe

On Dec 10, 8:38 am, DaveFulton-Trapeze <dave.ful...@trapezegroup.com>
wrote:

[J. R. Westmoreland]

We would likely add this as an additional piece of descriptive information
appended to the route name etc in our database.

J. R.

--------------------
J. R. Westmoreland
Custom Computers & Consulting
E-mail: j...@jrw.org
Twitter: GeneralJR
Skype: j.r.westmoreland


-----Original Message-----
From: gtfs-c...@googlegroups.com [mailto:gtfs-c...@googlegroups.com]
On Behalf Of Joe Hughes
Sent: Thursday, December 10, 2009 2:30 PM
To: Google Transit Feed Spec Changes

[Michi]

I can't see why school trippers can't be done in the feed spec as is.
In my mock system GTFS feed, i have school trippers and they use
different service Id codes. These codes also trigger a footnote in
timetable publisher.

Many systems may have a lot of schools to deal with but only a small
number of districts which may have the same calendars.

Putting trips in a trip planner with a mark that they are not valid on
school holidays (but still come up) totally defeats the purpose of
effective online trip planning as it gives a rider a false expectation
that a trip will run.

Now of course, I don't use "big system" software (HASTUS, Trapeze,
etc.). I use good ol' excel spreadsheets and a lot of handwork.
Perhaps for larger systems, if HASTUS or Trapeze could support these
variations. We need to make sure that the support flows to GTFS and
that the agencies who need this capability are educated on it's
availability.

I don't see any change to the spec warranted.

Just my thoughts..

Michi Eyre


On Dec 10, 9:38 am, DaveFulton-Trapeze <dave.ful...@trapezegroup.com>
wrote:

[Devin Braun]

I agree. Instead of giving a sub-service_id, just give a different
service ID and then add only to calendar_dates.txt as additional
service for each day they run and leave that service_id out of
calendar.txt completely.

Devin
San Diego MTS

[T Sobota]

I would concur with the observation that the current spec does
accomodate the real world as described above - just cumbersomely.

Our university campus routes result in ten added service ids (beyond
our generic weekday, saturday, sunday, holiday, etc.). We schedule a
vehicle block for each possible service day of actual trips the
vehicle block would operate, keying each trip within that block to the
specific service id, then add that particular service id to whatever
calendar dates it runs.

Where the current spec is cumbersome is the repetitive trip and stop
time records that result. Even a basic thing like a simple loop trip
that runs seven days a week, 365 days a year, might show up in the
trip and stop time file upwards of seven times (in our case, weekday
service, saturday service, sunday service, holiday service... maybe a
modified service day service, and presently a special Christmas Eve
service and New Years Eve service). The same 7am departure, with the
same stop times throughout, is repeated seven times in the trip file
and stop time file. If that identical trip was then part of a vehicle
block that had subsequent trips with service exceptions... the one
entry for the generic weekday service (in trip and stop times) could
multiply out to three or four entries for the weekday with school,
weekday without school, weekday with school early dismissal, and so
on.

Tim Sobota
Metro Transit, City of Madison

> > I can't see why school trippers can't be done in the feed spec as is.- Hide quoted text -
>
> - Show quoted text -

[keith@guelph]

Cross posting from Feature Requests and Suggestions. A lighter weight
approach to service variations that makes use of the calendar_dates
file:

Sometimes we have a day where we run our regular trips but change the
start or end time. For example, we will shut down regular service
early on Christmas Eve. We will run our regular service later than
usual on New Year's Eve.

These 2 exceptions do not seem worth creating entirely new trips,
frequencies, and stop_times.

One idea would be for calendar_dates exception type 1 (add a service)
to use start_time and end_time fields to indicate when the added
service starts or ends. Null means to use the normal time, of course.

Or for exception type 2 (delete a service), remove trips before the
start time and after the end time. (Meaning of nulls is a bit
trickier
since NULL, NULL means to remove the trip entirely.)

Almost all of our trips use frequencies.txt, so we only define the
stop_times once for each trip. The actual start and end times come
from frequencies.txt. Just overriding those times on a given date
would help a lot.

Happy Holidays ;-) and thanks to Google Transit for the great trip
planning service.

Keith @ Guelph

[Max Campos]

I personally disagree - as an application developer, I'd rather you just add the extra trip or two to your GTFS data, than have to implement a new scheme in my code to understand this for one agency for one day a year. Even if you use this special new feature, there's no guarantee that someone else in this situation will do the same -- meaning that now I have to support it BOTH ways.

Not trying to pick on you Keith, but I've seen this a lot on this group, and it concerns me. In general, I think we need to really ponder the cost vs benefit when considering things that complicate the spec. The more convoluted the GTFS specification gets, the higher the barrier for implementation for consumers, and the less likely they will use it. It also means that (for me, for example), there are some agencies that I think twice about picking-up because I'd have to rework significant parts of code to support them.

Ex: I think having both calendar and calendar_dates was a mistake. (This is essentially the same information specified two completely different ways).

Since I am working on an embedded device, I've had to write code that is very good at finding patterns in trips/times/etc and optimizing them out -- my TriMet data set is 1MB uncompressed (it is ~77MB in uncompressed GTFS text form) -- but my application is not so good at understanding odd GTFS peculiarities.

So to sum up: I prefer a simple GTFS that is easy to use, but may be somewhat redundant; rather than a precise but very complicated standard.

- Max

* PS - I think the bar is much lower for things like "does this stop have a bench or a shelter." The bar should be high for things like "what days does the bus/train run," "where does it go," "what time will it arrive", etc.

[Max Campos]

Tim -

I realize this is a little old, but nobody else responded - so I will:

Why not create a service id that means "runs every single day" for your loop trip. Then on a weekday you have two active service IDs - the "weekday" service ID, and the "everyday" service Id. Then you only put the trip/stop_times in once, rather than the 7 times you mentioned.

TriMet does this -- today (Tue), for example, there are 5 active service IDs (weekdays, weekdays except friday, everyday, etc).

- Max

[T Sobota]

Max-

I think the quick answer to your suggestion is that it would be
unachieveable within the original transit system scheduling program(s)
used by transit systems. Building a transit database from scratch,
it'd be easy enough to designate certain trips as "everyday" and
others as only "weekday", etc. But following a typical path of
exporting data from an established scheduling program into the GTFS
spec, there is no straight path from A to B... and arriving at B (your
idea) would take a significant amount of post-processing.

I guess my impression is that scheduling programs are presently a
model of a whole built as parts, rather than the parts forming a
whole. I'd interpret what Dave originally outlined as a paradigm
shift to some extent, using parts to create a whole picture (i.e.
individual trips assigned to one or more services) - contrary to an
approach of starting with a (whole) service defintion and populating
each such service with its own trips (parts).

-Tim Sobota

> > For more options, visit this group athttp://groups.google.com/group/gtfs-changes?hl=en.- Hide quoted text -