Proposal: bicycle accessibility information

[Devin Braun]

In tandem with wheelchair accessibility information being proposed,
I'd like to propose that bicycle accessibility is included as well.

Many agencies have bicycle racks on their buses and trains which allow
bicycles to be carried on the trip. The agency's feed can represent
bicycle availability on trips with a few simple additional fields.

Like the proposed wheelchair accessibility, two fields can be added
which work with each other.

A new optional field, bicycle_allowed can be added to trips.txt. A
value of 1 indicates that the vehicle on this trip is able to carry
bicycles. A value of 0 or empty indicates no bicycle racks are
available.

A new optional field, bicycle_rack can be added to routes.txt. A
value of 1 indicates that all vehicles on this route are able to carry
bicycles. A value of 0 or empty indicates no bicycle racks are
available.

If a route always has bicycle racks then bicycle_rack will be 1, but
if some trips of this route don't allow bicycles, bicycle_allowed can
be 0, overriding the route value.

I believe that both fields are necessary as some agencies may allow
boardings on some trips but not on others. In previous agencies where
I've worked, bicycles aren't allowed during busy commute times or
bicycles are only allowed on the last trip of the night. Although
most agencies with bicycle racks have no restrictions other than the
capacity of the bicycle rack, making this an easy field to keep up to
date.

I am willing to provide test data for this proposal.

Devin Braun
San Diego MTS

[Aaron Antrim]

Redwood Transit System will also be happy to provide test data for this proposal. -aaron

[Joe Hughes]

Thanks for the proposal, Devin--I know this information is of interest
to many people. I also agree that this needs to be specifiable on a
trip-by-trip basis--I know that BART, for instance, only allows bikes
in off-peak hours.

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
redundant.

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.

Joe

On Tue, Apr 8, 2008 at 8:40 AM, Devin Braun <devin...@sdmts.com> wrote:
>

[Aaron Antrim]

I would like to request that 0, (empty string), and omitting the bikes_allowed column should not have the same meaning.  An empty string or omission of the column should result in using the value from routes.txt, or trips.txt, whichever is available instead.

I would like to suggest that trip_bikes_allowed should override route_bikes_allowed whenever it is specified.  This allows information providers to specify a default, route_bikes_allowed, and then add overrides as necessary.

Under this scenario the chart would look like this:

route=1, trip=1 --> bikes allowed on trip

route=1, trip=0 --> NO bikes allowed on trip

route=0, trip=1 --> bikes allowed on trip
route=0, trip=0 --> NO bikes allowed on trip

route=(not defined), trip=1 --> bikes allowed on trip
route=(not defined), trip=0 --> NO bikes allowed on trip
route=0, trip=(not defined) --> NO bikes allowed on trip
route=1, trip=(not defined) --> bikes allowed on trip

[Joe Hughes]

I agree that having trip_bikes_allowed override route_bikes_allowed
would be useful. It's convenient when writing feed-processing code to
have 0 be equivalent to "no value", though--perhaps we should make the
values:
2: bikes allowed
1: no bikes allowed
0: no information (same as field omitted)

Joe

[Joe Hughes]

I agree that having trip_bikes_allowed override route_bikes_allowed
would be useful. It's convenient when writing feed-processing code to
have 0 be equivalent to "no value", though--perhaps we should make the
values:
2: bikes allowed
1: no bikes allowed
0: no information (same as field omitted)

Joe

On Tue, Apr 8, 2008 at 1:09 PM, Aaron Antrim <aa...@arcatacommunity.org> wrote:

[Marc Ferguson]

There is another wrinkle in the bike trip.  Some places that have bike rack equipped buses prohibit loading in certain locations.   Seattle, for example, prohibits loading/unloading in downtown from 7am-7pm Monday - Friday.   There are other busy locations that also have loading "prohibitions."

Like wheelchair this is a vehicle/trip & stop "condition."

I would suggest that it be the exporting systems responsibility to set trip level "bike" flag based on the vehicle capabilities and/or time of day.

Marc Ferguson
marc.f...@trapezegroup.com
757-961-9224 x304

"Joe Hughes" <joe.hug...@gmail.com> Sent by: gtfs-c...@googlegroups.com 04/08/2008 03:55 PM Please respond to gtfs-c...@googlegroups.com

To gtfs-c...@googlegroups.com cc Subject [gtfs-changes] Re: Proposal: bicycle accessibility information

[Devin Braun]

Joe and Aaron, thanks for clarifying what I was trying to say about
the trip_bikes_allowed value overriding the route_bikes_allowed
column. I agree with that and with the new suggested values you
mentioned.

Here is a revised proposal:

A new optional field, trip_bikes_allowed in trips.txt.
Values-

2: bikes allowed
1: no bikes allowed
0: no information (same as field omitted)

A new optional field, route_bikes_allowed in routes.txt.

2: bikes allowed
1: no bikes allowed
0: no information (same as field omitted)

The fields would interact as follows:

route=2, trip=2 --> bikes allowed on trip
route=2, trip=1 --> NO bikes allowed on trip
route=1, trip=2 --> bikes allowed on trip
route=1, trip=1 --> NO bikes allowed on trip

If route_bikes_allowed is omitted (or is 0) from the feed, then the
value from trip_bikes_allowed will determine solely the availability
to carry bikes.
If trip_bikes_allowed is omitted (or is 0) from the feed, then the
value from route_bikes_allowed will determine solely the availability
to carry bikes.

Did I summarize this ok?

Devin

> > On Tue, Apr 8, 2008 at 12:54 PM, Joe Hughes <joe.hughes.c...@gmail.com>

> > wrote:
>
> > > 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- Hide quoted text -

[KevinChicago]

The addition to trips.txt works well. I guess I'm still not
understanding the need in the routes file.

I do see a possibility for something in the stops file, to denote that
there are bike locking-facilities available. Maybe:
0=No lock or Unknown
1=Outside Lock (exposed to the elements)
2=Inside Lock

I'm not necessarily seeing this as that useful for the trip-planner as
much as added text to the google maps pop-up gadget as more
information about that stop.

Kevin

[Joe Hughes]

Thanks for your comments, Kevin. I agree that it's still unclear
whether having the bike information in routes.txt is really useful, as
it seems like the equivalent information could be reconstructed just
by scanning through the trips on that route when reading the feed.

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:
http://groups.google.com/group/gtfs-changes/browse_thread/thread/5910790204c0d5b2

So I'd like to propose that bike racks/lockers be discussed on a
separate thread.

Joe

[Devin Braun]

The primary reason I proposed having a bike accessibility field in
routes.txt was because administratively, it's easier to mark one field
in routes.txt instead of every field in trips.txt. For larger
agencies with scheduling programs and programming staff, it would be
easy to mark every trip in trips.txt programmatically. However, for
smaller agencies, especially where bicycle accessibility is probably
simply yes or no for the entire system, it's easier to only update
routes.txt. Even for a "larger" agency such as MTS, bicycle
accessibility can be determined simply by route.

Of course, having only a single field in trips.txt would be adequate
for specification of bicycle accessibility.

I can see requests in the future for having the field in
stop_times.txt. For example, in Reno, when almost every bus route
crossed the railroad tracks before arriving at the Citicenter Transfer
Center, passengers were required to unload their bikes at the last
inbound stop before the railroad tracks and load their bicycle at the
first outbound stop after the railroad tracks. This has probably
changed since the trains were routed underground, but it shows a case
for this type of bicycle accessibility detail.

Devin Braun
San Diego MTS

[Joe Hughes]

Thanks for the details, Devin. Let's keep things simple for now as we
try this out, and use just the one field from your proposal:

A new optional field, trip_bikes_allowed in trips.txt.
Values-

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.

Joe

[Aaron Antrim]

I still vote for a route and trips field, as that'll streamline adding, and maintaining this option in Trillium's web-based GTFS feed manager that much easier.  But, honestly, it's not a big deal.

--
Aaron Antrim
707.633.4464

[Joe Hughes]

It seems like it would be pretty straightforward to provide a
route-based presentation of this info in the Trillium UI, and just
turn the flag on for all the trips when you wrote out the feed. Is
there a difficulty that I'm missing?

Joe

[Aaron Antrim]

No -- it's very straightforward.

Aaron