I just want to make sure the interaction between your two fields is
well-defined. Here's a proposed chart:
route=1, trip=1 --> bikes allowed on trip
route=1, trip=0 --> bikes allowed on trip
route=0, trip=1 --> bikes allowed on trip
route=0, trip=0 --> NO bikes allowed on trip
Note that in the example above, 0, (empty string), and omitting that
column all have the same meaning. Making route=1, trip=0 mean bikes
allowed makes it possible to leave out the bike column entirely from
trips.txt, and only specify bike information in routes.txt. Otherwise
you always need to specify the trip field, making the route field
Also, I would propose naming the fields something like
"route_bikes_allowed" and "trip_bikes_allowed", since a metro system
like BART doesn't have bike racks per se.
On Tue, Apr 8, 2008 at 8:40 AM, Devin Braun <devin...@sdmts.com> wrote:
On Tue, Apr 8, 2008 at 1:09 PM, Aaron Antrim <aa...@arcatacommunity.org> wrote:
Sent by: gtfs-c...@googlegroups.com
04/08/2008 03:55 PM
Is there someone who wants to make more of a case for why we need the
routes.txt field in addition to the trips.txt field?
As for the bike-locking facilities, that sounds like something that
would fit well in Mike Gilligan's stop amenities proposal:
So I'd like to propose that bike racks/lockers be discussed on a
A new optional field, trip_bikes_allowed in trips.txt.
2: bikes allowed on this trip
1: no bikes allowed on this trip
0: no information (same as field omitted)
Fortunately we have some of the small agencies in this group, and they
can give feedback about whether having only the trips field would
cause an undue burden. In my experience, almost no feeds are being
generated entirely by hand, and those that are tend to be
frequency-based feeds, which wouldn't have many trip entries anyway.
I agree that we might want stoptimes-based extensions in the future,
but let's see how far we can get with this 90% solution.