Bikes on transit

[David Turner]

At Brian's suggestion, I'm resurrecting the trip_bikes_allowed concept
from

https://groups.google.com/forum/?fromgroups#!
topic/gtfs-changes/QqaGOuNmG7o

To summarize:
We propose a new optional field, trip_bikes_allowed in trips.txt.
The possible values are:

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

There are a lot of more complicated scenarios possible -- for instance,
folding bikes only, bikes can only board at certain stations, some
stations have bike lockers (but only during certain hours), no bikes on
the nekobasu, etc. But presently, we have a producer (San Diego MTS)
and a consumer (OpenTripPlanner) for this very simple proposal. So,
let's make it official.

I'm totally open to discussing the more complicated scenarios, but
there's no reason to let the perfect be the enemy of the good.

Also, I think once we get a momentum up of putting small, incremental
changes into GTFS, we'll find it easier to iterate more quickly on the
spec.

[Brian Ferris]

+1

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

[Antonio Orlando]

+1 for the trip_bikes_allowed, we would definitely use this.
And (even if it is already pushed ahead) +1 for the
wheelchair_accessibility, we would use that too.

--
Antonio


On Wed, 13 Jun 2012 23:11:11 +0200, David Turner <nov...@novalis.org>
wrote:

[Aaron Antrim]

+1 for trip_bikes_allowed.  BTW, all of the feeds that Trillium publishes currently include this field.

-- 

Aaron Antrim

Trillium Solutions, Inc.

www.trilliumtransit.com

Portland, Oregon

--
You received this message because you are subscribed to the Google Groups "General 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+unsubscribe@googlegroups.com.

[Stuart Heinrich]

Good idea on (b).  The feed should have a field provided for this URL, the rules are complicated here in SF.

On Thu, Jun 14, 2012 at 9:30 AM, Neil <tre...@co.rockland.ny.us> wrote:

+1 here as well. 

It may also be useful to either (a) have a generic warning in the trip planner for the end-user to to check the agency's bike-on-board policy or (b) have a direct URL link to the transit agency's bike-on-board policy, since even if a bike can be brought on board, there are different rules and logistical issues that the end-user would need to know about, such as whether a permit is required.  (Our agency doesn't require permits, but two of our neighboring agencies do require them)

To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/I-NBaCZEgc4J.

To post to this group, send email to gtfs-c...@googlegroups.com.

To unsubscribe from this group, send email to gtfs-changes...@googlegroups.com.

[Brian Ferris]

I want to resurrect this proposal one more time and see if we can't get it added to the spec.  Seeing as how there were no complaints when David brought this up in June, I'd like to start the clock ticking for formal adoption of this proposal.  If there are no blocking objections by Oct 8 (one week from now), then let's add this to the spec.

And just as a reminder, anyone can start the clock ticking for a proposal if they think it's ready.  I'll try to do my part to keep the changes process moving, but my that shouldn't have to slow anyone else down.

Brian

[Stefan de Konink]

On 10/01/12 18:26, Brian Ferris wrote:
> I want to resurrect this proposal one more time and see if we can't get
> it added to the spec. Seeing as how there were no complaints when David
> brought this up in June, I'd like to start the clock ticking for formal
> adoption of this proposal. If there are no blocking objections by Oct 8
> (one week from now), then let's add this to the spec.

I would like to see this proposal a bit altered. The problem with this
thing is that it is too specific.

It would be better if inheritance is possible (think of agency.txt,
routes.txt & trips.txt) where you could enable this for an entire
agency, per route and per trip.

So instead of trip_bikes_allowed, I would go for: bikes_allowed.

And pretty please: the suggested 0, 1, 2 scheme really doesn't make
sense. Can we please make it similar to wheelchair_accessible aka: 0
noinfo, 1 yes, 2 no.


Stefan

[Brian Ferris]

I'm not opposed to those changes, but it's going to take some work.  I currently count 72 feeds with a "trip_bikes_allowed" field.  Of those, 32 are using a value of "2" to indicate that bikes are allowed, one feed is using a value of "1" to indicate no bikes allowed, and 54 feeds are using a value of "0" to indicate that bike status is unknown.

Changing the proposal at this point means convincing these feeds to change, as well as refactoring a primary consumer of the proposal as well.  Granted, 90% of the feeds supplying "trip_bikes_allowed" info seem to be coming from Trillium Transit, so you might try lobbying them directly.

Regarding the agency < route < trip override semantics, I'm not opposed to that either.  I think we could even adopt a trip-level proposal first and come back and work on a route or agency level proposal, since conceivably any field value in trips.txt would override values in agency.txt or routes.txt.  But of course, if you'd like to see the feature added sooner rather than later, the best way forward is to find some agencies and GTFS consumers to implement the proposal.

Thoughts?

Brian

[Aaron Antrim]

I think that it does make sense to have the meanings in a *_bikes_allowed field match the wheelchair_accessible field, so if others want this change, I would change all of Trillium's feeds.

Regarding the agency < route < trip override semantics, I'm certainly no opposed.  However, I will point out that a similar idea was originally discussed and discarded because it would add complexity for data consumers.  Currently, Trillium's application allows setting at the route and trip level in its interface, then exports the trip_bikes_allowed field factoring in the inputs for the route, and overriding when something different is set for the trip.

-- 

Aaron Antrim

www.trilliumtransit.com

Portland, Oregon

[Brian Ferris]

While we're on the subject, what do people think of the "trip_blah" field naming convention?  We haven't used that convention for the recent wheelchair accessibility field, for example.  But keeping it would be consistent with some other trip fields.  I'm not sure if there is an exact rule of thumb here... it looks like a "trip_" prefix was used for direct properties of the trip, as opposed to references to other ids for other features.

I bring it up because if we did switch semantics of the 0/1/2 for indicating bike support, it might be worthwhile to change the field name.  For example, "trip_bikes_allowed" => "bikes_allowed". That way, it would be clear which feeds had been updated with the new semantics and which ones had not.

[Guillaume]

Hello,

Is anyone aware of any transit trip where folding bikes are forbidden? In my opinion a folding bike is just like any piece of luggage or backpack, especially if it's covered in a bag.

Therefore I would propose :
3 : bikes allowed on this agency/route/trip
2 : no bikes allowed on this agency/route/trip except folding bikes
1 : no bikes allowed on this agency/route/trip except folding bikes enclosed in a bag
Any other value or content : no information (same as field omitted)

I am not a native English-speaker, therefore feel always free to correct my files/fields proposals in terms of English language, or to improve them for clarity.

For information, I use a Strida folding bike, which has a (dry) rubber belt instead of a lubricated chain. That ensures no one in the bus/tramway/subway/train/boat can get soiled by the chain lubricant.I have never had boarding issues with this bike.
(I am not saying that lubricated chain bikes should always be enclosed in a bag; I much prefer mutual respect and simple courtesy in transit vehicles...)


Anyway, I support the "bikes_allowed" proposal, and for sure will add this field to my feed as soon as it is included in https://Developers.Google.com/transit/gtfs/reference .

[Nicholas Albion]

It might also be useful if it could be conveyed that:

- a given bus has capacity for N bikes on the front-mounted bike rack

- bikes are only allowed in the first/last carriage of a train.

[Guillaume]

I think the "bikes_allowed" field is relevant, since there is already certainly plenty of transit information in the world that use an icon to show trips where bikes are allowed.

Example in this train timetable :

(http://Telechargement.TER-SNCF.com/Images/Midi_Pyrenees/Tridion/FH15_TOULOUSE_MONTAUBAN.indd_tcm-25-17745.pdf)


Therefore it would be useful to have this bikes_allowed "flag" in a specific field of the GTFS format, in order that information systems can automatically represent this bikes_allowed value with a bike icon (or with a "bikes forbidden" icon).


However, up to now I have never seen transit information with a specific icon or symbol, to specify the number of bikes allowed, or which carriage(s) accept(s) bikes. This is usually explained with text.

Therefore maybe it's better to keep these informations (number of bikes allow, carriage(s) which accept(s) bikes) as text ?

For routes(.txt), there is already the "route_desc" field that can be used to write if all trips of a route allow N bikes / only in some carriage(s).

But if for one given route, this depends on the trip, then it would be nice to also have an (optional) field "trip_desc" in trips.txt. Furthermore, this "trip_desc" field could be used to convey many other information regarding a particular trip.

What do you think?

[Thomas]

My 2 cents:

Folding bikes is a good property to have as a boolean/enum during routing, capacity is only relevant realtime. I don't think there is any agency currently keeping tabs on how many bike stands are taken.

Regarding trip_desc, i would prefer to see a separate proposal on that, that allows for multiple texts per trip and the possibility to specify which parts of the trip the message has to be shown. 

The existing feeds we see such as HAFAS, Dutch Railways' IFF and soon NETex can contain multiple messages per (part of) of a trip. Sometimes it's possible to translate these in existing fields such as drop_off_type, pick_up_type, bike_allowed, etc, but often they are very specific.

Some examples from as HAFAS feed.

1  0   5  1 1st class only#

2  0   6  1 2nd class only#

B  0   4  4 Bar#

MP 0   3  4 Minibar / Meals served at your seat#

PR 0   5  4 Panorama coach: Reservation compulsory#

SN 0   3  7 SnackPoint#

SP 0   3  5 Sleeperette (Reclining seats)#

SV 0   9  1 Bus substitution#

SZ 0   1  2 Special ticket or supplement required#

TF 0   1  3 Other connections: see www.fahrplanfelder.ch#

TG 0   1  3 WITHOUT ANY GUARANTEE: see www.fahrplanfelder.ch#

TS 0   1  1 Additional train#

TT 0   1  1 Tilting train#

VA 2   2  0 Exit in front of train please#

VL 0   5  6 BICYCLES: Self-service loading by sender limited#

VN 0   5  6 BICYCLES: No self-service loading by sender#

VP 0   6  6 BICYCLES: Reservation, see www.postbus.ch#

VR 0   6  6 BICYCLES: Reservation compulsory#

VT 0   6  6 No transportation of packed bicycles#

VX 0   6  6 BICYCLES: Transport not admitted#

VZ 1   2  0 Board in front of train please#

WL 0   1  5 Sleeping car#

WR 0   4  1 Restaurant#

WS 0   4  2 Bistro#

--

You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

To post to this group, send email to gtfs-c...@googlegroups.com.

Visit this group at http://groups.google.com/group/gtfs-changes?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brian Ferris]

Ok, it's been a while, but I wanted to resurrect the "bikes on transit" thread once more to see if we can get this across the finish line.  Since I last chimed in... oh my god, a YEAR ago (time flies), we had discussed the idea of changing the bikes proposal to match the general semantics of "0=unknown, 1=yes, 2=no" established by the trips.txt wheelchair_accessible and stops.txt wheelchair_boarding fields.  To avoid conflict with the previous semantics of "routes_bikes_allowed" and "trips_bikes_allowed", we proposed naming the new field simply "bikes_allowed" in both routes.txt and trips.txt.

Since that discussion, I've convinced Aaron at Trillium to update the feeds he exports to include the new "bikes_allowed" column with the updated 0/1/2 semantics.  I've also updated the OneBusAway GTFS library to parse this field and I've updated OTP to use this new field for bikes-on-bus routing.  Finally, I've updated both Google's GTFS validator and the open-source TransitFeed GTFS validator to validate the new field.

Simply put, we've got a number of feeds providing the new field and a couple of feed consumers using the new field.  We're very close to getting this proposal accepted!

So let's now revisit the official text for the proposal:

We propose a new optional field "bikes_allowed" in trips.txt with the following semantics:

0 (or empty): no information

1: the transit vehicle being used on this particular trip can accommodate at least one bicycle
2: no bicycles allowed on this trip

I readily acknowledge that more complicated scenarios exist -- folding bikes only, bikes can only board at certain stations, some stations have bike lockers (but only during certain hours), no bikes on the nekobasu, etc.  But presently, we have a producer (all Trillium GTFS feeds) and we have a consumer (OTP) for this very straight-forward proposal.  So, let's make it official!  As David said originally in the thread, we can discuss complicated scenarios, but there's no reason to let the perfect be the enemy of the good.

Thoughts?

[Thomas]

Make that two producers, last weekend i've swapped bikes_allowed 2 for 1 in the Netherlands feed by OVapi.

Kind regards,

Thomas Koch

OVapi

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/CAG9YwWBDKWTVxCAv_OkhCkbwk5_Zr8mXURrQgp1%2B3-PAes4PNQ%40mail.gmail.com.

[Bradley Tollison]

I'd be happy to add it to the Torrance Transit feed

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/CABCuiFy0WrRL5AK%3DxJQQHyQiLDY-QQrvaaV99pe92yN2_AUMqw%40mail.gmail.com.

[T Sobota]

Brian-

  Not entirely clear from the updated discussion, but would a value in the field in routes.txt be sufficient to signal general bike allowance (by route) - without needing to populate the field/values for each line of trips.txt?

Thanks

[Brian Ferris]

Hey Tim,

I didn't specifically outline it, but yes, there has been a proposal for a "bikes_allowed" in routes.txt.  The idea is that if "bikes_allowed" is not specified or unknown for a particular trip in trips.txt, then the value would be inherited from the parent route entry in routes.txt.  This logic has actually been implemented in OTP, but I don't know of any feeds specifying "bikes_allowed" in routes.txt, so I didn't bring it up for official adoption.  That said, if someone would like to use this convention, please do so!  And let me know!

Brian

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/ecec455b-153a-4a29-9090-5d9a65f69d46%40googlegroups.com.

[T Sobota]

I will plan to extend the next update of madison-wi-us, in early December, with this field in routes.txt.

Would seem to make more sense where 100% of vehicles use external bike racks (i.e. no time of day/trip restrictions where bikes cannot fit inside vehicles).

[Brian Ferris]

Since the reception to this proposal has mostly been positive, I'd actually like to start the clock on this proposal.

If anyone has any reason why this proposal should NOT be adopted officially into the GTFS spec, speak your mind or forever hold your peace, ideally before next Wednesday, November 27th.

[John L]

+1 for me

I know LIRR and MNR have bike policies that require a permit so if you can add

3: Bikes allowed for this trip with permit

Otherwise, we would be forced to have a 0 for all instances.

And yes, a bike has a legal description for railroads, subways, buses and ferry. 

http://www.mta.info/bike/

Click into LIRR and MNR policies and you will get my drift.

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/CAG9YwWBAW50YVO9j%2BmqCJDfkv_0w2cZMRE%3DfHEv4S9ro83r8sA%40mail.gmail.com.

[Catala, Martin]

+1 on the URL idea

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.

 

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/I-NBaCZEgc4J.

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.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.
To post to this group, send email to gtfs-c...@googlegroups.com.

[Guillaume]

+1 for "3 : Bikes allowed for this trip (or route) with permit".

And +1 also for the bike policy URL.

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.

--
You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To view this discussion on the web visit https://groups.google.com/d/msg/gtfs-changes/-/I-NBaCZEgc4J.

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.

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

[Guillaume]

Hello,

I have just uploaded my feed with bikes_allowed in routes.txt (and not anymore in trips.txt), since the bike policy is the same for all trips of each of our routes.

[Tim Cooper]

+1 from TripGo, a Sydney-based door-to-door search engine.  In Sydney, bikes are allowed on trains at any time except rush hour, and I think always on ferries.  So we'll have to apply some extra logic, but we'd still like this field for Sydney and the various other cities we're in.  (Although it seems a bit odd that "2=yes and 1=no" when the "wheelchair_accessible" field is the other way round.)

[Brian Ferris]

The proposal up for discussion (see my post on Nov 19) does specify 1=yes and 2=no.

On Mon, Nov 25, 2013 at 1:03 AM, Tim Cooper <t...@edval.com.au> wrote:

+1 from TripGo, a Sydney-based door-to-door search engine.  In Sydney, bikes are allowed on trains at any time except rush hour, and I think always on ferries.  So we'll have to apply some extra logic, but we'd still like this field for Sydney and the various other cities we're in.  (Although it seems a bit odd that "2=yes and 1=no" when the "wheelchair_accessible" field is the other way round.)

--

You received this message because you are subscribed to the Google Groups "General Transit Feed Spec Changes" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gtfs-changes...@googlegroups.com.

To view this discussion on the web visit