It took me some time to navigate through this thread to understand the
problem, and I'm still not 100% understanding every nuance. We in
Chicago have complex scheduling, with holidays and quarterly picks
(that are different for our bus versus our rail), and special school
runs that only run on Tuesdays, and a scheduling tradition that starts
and ends the day at 3am, not midnight, and 24 hour services that have
to work within those confines. The whole calendaring issue was
actually one of the most difficult part of GTFS for us, so I take an
interest in any proposed changes, as well as I appreciate hearing
about other city's viewpoint on the matter, because we're all going to
be very different, and we can learn from each other (and Google can
learn from us). With all that said, we got our data to work with
GTFS, so I'm surprised to hear a situation where it doesn't work.
I do have a clarification to ask of you, first, Tim. You said "...to
support trip ids in the trips.txt table that are keyed to a service id
that does not happen to fall within the date range of the
calendar_dates.txt file." and then later: "...request that trip ids
with a service id not contained in calendar_dates.txt be flagged as
just a [warning], not an [error]." What confuses me is that a
service_id doesn't need to be in the calendar_dates.txt file right
now, only the calendar.txt file. You also referred to "date range" in
the calendar_dates.txt file. There isn't a range in
calendar_dates.txt file, just individual dates. Did you mean
calendar.txt file in these sentences or calendar_dates.txt?
So to clarify why I'm not understanding the problem 100%, yet. Why is
the following not acceptable?
- in calendar.txt: service_id=regular, start_date=20090301 and
- also in calendar.txt: service_id=holiday, start_date=20090301 and
end_date=20091231, and the Monday thru Sunday fields are all 0.
- in calendar_dates.txt: service_id=holiday has exception_type=1 for
20090525, 20090704,20090907, etc.
ps: We quite often will post an end_date value that is past the last
date of our current scheduling pick because we made the decision it's
worse to not have data past a certain date then to present data that
may change slightly. The reality is that not only will the trips
possibly change, but so may the routes and the stops. There's a lot
of unknowns weeks and month out that will never make it into the GTFS
and, yes, could potentially misinform a customer. But I believe there
is some expectation on the part of the customer that if they ask for
directions many weeks out, they probably should check back closer to
their travel date to see if anything changed. But I appreciate that
part of the point you're making isn't about Trip Planning
functionality, but other "static" uses, so you may very well be on to
something, so let's keep this conversation going.