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 https://groups.google.com/d/msgid/gtfs-changes/936778ab-6c21-4a24-a5c8-09bdc931a725%40googlegroups.com.

[Brian Ferris]

Looking back, I don't see a specific proposal for a bikes policy url, so let's try this.  In agency.txt, we propose "bikes_policy_url", which specifies a URL where riders can find detailed policies and rules for taking bikes on the agency's transit vehicles.  If you are interested in having this field added to the GTFS spec, please (a) add it to your GTFS feed or (b) at support for this field in your GTFS-consuming software.

That said, I think the current "bikes_allowed" proposal can be adopted as-is without waiting for "bikes_policy_url", agreed?

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/5E720878F33D3244932503066FC93BF07B68CEE21F%40USFMAIL2.forest.usf.edu.

[Brian Ferris]

John, am I reading correctly that on LIRR, regular bikes require a permit but folding bikes do not?

I'd like to flesh this out a bit more before committing to additional values for "bikes_allowed".  I'm worried we might be trying to cram to many separate concepts into one field, especially for agencies that have complex policies.  Anyone know of an agency with similarly complex bike policies?  Any that make bike distinctions beyond normal bike vs folding bike?

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

[sabre23t]

In Malaysia KL's LRT, bicycles not allowed but folding bikes allowed during off peak ...

''.. folding bikes are permitted to board the LRT. The current ruling, however, only allows owners of folding bikes to use the LRT outside the peak hours; from 9am to 4pm on working days; and after 7.30pm onwards"

Source:

·         http://www.myrapid.com.my/feeds/2011/09/12/myrapidkl-peyday-bicycle-foldable-frame-allowed-during-peak-hrs-only-ie-between

http://www.myrapid.com.my/news-events/media-releases/2011/prasarana-host-special-folding-bike-ride-promote-car-free-campaign

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/CAG9YwWAWC3O7%3DHDwmniMR00W_RgQ%2BgQ7%2BG4LW_a1CSHOGQQguQ%40mail.gmail.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
regards,
sabre23t =^.^=

[Guillaume]

I have added "bike_policy_url" to my agency.txt.


However, since there is also "agency_fare_url", I think it would be logical to name them :

agency_fare_url  and  agency_bike_policy_url

OR

fare_url  and  bike_policy_url


OK to adopt "bikes_allowed" without waiting for "bikes_policy_url".

[Brian Ferris]

Hey Guillaume,

Can you remind me again if your feed is posted publicly?  It'd be cool if others could play with your data.

Regarding "bike_policy_url" vs "agency_bike_policy_url", I guess I'm generally in-favor of getting rid of the file-specific prefix for field names, since I'm not sure it adds anything.  Thus, my votes for "bikes_allowed" and "wheelchair_accessible", as opposed to "trip_bikes_allowed" and "trip_wheelchair_accessible".  What does everybody else think?

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/d666d4ba-e93c-493b-bb8d-fcf24fa971c0%40googlegroups.com.

[Guillaume]

Hello Brian,

My feed is in final validation by Google Transit "quality analysis team".

Once it is validated (hopefully today), I think I will be able to post it publicly, since my "metropolitan area council" has an open-data policy.


I fully agree with you to get rid of file-specific prefix for field names, therefore I am in favour of "bikes_policy_url" and "fare_url" (instead of agency_fare_url).

[Brian Ferris]

Another year... another push to get the "bikes_allowed" proposal officially adopted ; )

Back in November, when I made the last push on this proposal, there were some questions about folding bikes vs regular bikes, bike permits, and how this all might be modeled in the future.  After looking at the issue, it's clear that there are a couple of agencies that have distinct policies for regular bikes vs folding bikes.  To support this differentiation for GTFS producers and consumers who want to support this use-case in the future, I propose NOT modeling folding bike rules with "bikes_allowed".  Instead, I feel it should be modeled in a separate "folding_bikes_allowed" field with similar semantics to "bikes_allowed".  This would give agencies the power to set policy separately for the two classes of bikes.

Regarding permits, I believe we can model this by adding an additional value to the "bikes_allowed" enum.  Something like "3: bikes allowed with appropriate permit".  The same field could be supported in "folding_bikes_allowed" as well.

It's also worth noting that TriMet appears to be including the proposed "bikes_policy_url" field in agency.txt.  Anyone using it yet?

Either way, those are the ideas for future modeling.  However, I think the base proposal is still pretty stable at this point and can be easily extended in the future as described above.

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

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?

Thanks,

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/96f911e8-cf20-425d-a625-353e34d72191%40googlegroups.com.

[Brian Ferris]

It's been a week with no comments, so I'd like to start the clock on the "bikes_allowed" proposal.  Unless I hear arguments to the contrary by Monday, February 17, I'd like to nominate this proposal for official adoption in the GTFS spec.  Anyone have a reason we should hold off on this proposal?

Thanks,

Brian

[John L]

+1 for me

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

[Catala, Martin]

+1

I also wonder if the stops.txt should include a bike rack amenity field.  Because bikes allowed doesn’t guarantee the bike can get on the bus.  So if I were planning such a trip I would want to make my connection at a stop with bike rakes. But that is adding to this proposal but I do think it may contribute to the utility of this proposal. 

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

[Brian Ferris]

Perhaps, but I think it's outside the scope of the current proposal.

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/5E720878F33D3244932503066FC93BF07B69599415%40USFMAIL2.forest.usf.edu.

[Catala, Martin]

I agree…didn’t mean to muddy the waters.   J 

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

[Brian Ferris]

Congrats everyone, it's official!  The bikes_allowed field is now officially part of the GTFS trips.txt specification:

https://developers.google.com/transit/gtfs/reference#trips_fields

However, there is still work to be done ; )

1) I noticed that TriMet has included the proposed bikes_policy_url field in their agency.txt field.  Anyone out there interested in using it in their app?

2) For many agencies, the bikes_allowed policy is the same for all trips of a route.  As such, we'd originally proposed a routes.txt bikes_allowed field to complement the trips.txt field.  No one is using bikes_allowed in routes.txt yet as far as I can tell, but there is one feed using the old deprecated routes_bikes_allowed field: SETRAVI in Mexico.  I will try reaching out to them to see if they'd consider switching to the new field.  In the meantime, if any other agencies want to use bikes_allowed in routes.txt, please do!

3) As discussed previously, some agencies have different policies for folding bikes.  If there are agencies interested in providing this information, I think a "folding_bikes_allowed" field in either trips.txt or routes.txt with similar semantics to "bikes_allowed" would be a good place to start.

4) Similarly, some agencies require a permit to bring a bike on a transit vehicle.  We'd proposed extending "bikes_alllowed" with a new value, 3, indicating that a permit is required.  If there are agencies wishing to provide this information, this would also be a good place to start.

5) There are also all the larger stop amenities proposals for someone to wade through at some point : )

Thanks!

Brian

To view this discussion on the web visit https://groups.google.com/d/msgid/gtfs-changes/5E720878F33D3244932503066FC93BF07B69599437%40USFMAIL2.forest.usf.edu.

[Guillaume]

Hello everyone,

1) I am including "bikes_policy_url" in agency.txt in my GTFS feed, for many years now, so yes, I think it would be nice to have it included in the GTFS agency.txt specification

3) We do have a different policy for folding bikes and would be interested in providing this information in our feed, for instance in trips.txt

Thanks!