Proposal: Bike Parking

[Jessica Rapson]

I would like to open a discussion about adding a bike_parking field to the stops.txt file.

This would be a simple field where transit providers could indicate whether or not any bike parking is available at each transit stop, similar to the way that the field wheelchair_boarding is defined:

For parentless stops:
0 or empty - No bicycle parking information for the stop.
1 - Some bicycle parking is available at this stop.
2 - Bicycle parking is not possible at this stop.

For child stops:
0 or empty - Stop will inherit its bike_parking behavior from the parent station, if specified in the parent.
1 - There exists some bicycle parking between the station and the specific stop/platform.
2 - There exists no bicycle parking between the station and the specific stop/platform.

For station entrances/exits:
0 or empty - Station entrance will inherit its bike_parking behavior from the parent station, if specified for the parent.
1 - Station entrance has bicycle parking.
2 - No bicycle parking between station entrance and stops/platforms.

Having this field would be invaluable for multi-modal trip planning and (from a research and investment perspective) for identifying gaps in transit infrastructure connectivity (e.g. where a lack of bike parking could be a barrier to multi-modal travel). It also makes sense to have the field given that there is already bikes_allowed in trips.txt.

There has already discussion about a separate stop_amenities.txt file, however this variable makes sense to be included with the standard text files for consistency with other transit-related variables (i.e., bikes_allowed).

There are obviously complexities with bicycle parking that may not be expressed by a simple field (e.g. maybe parking is not always available or requires a pass to access), there are also a wide range of bicycle parking infrastructure that is available (e.g. simple bike rack outside, protected bike shed, elevated storage with security, etc.). However, the same is true for the wheelchair_boarding variable. In generally, have an imperfect information is more useful than having no information at all.

Any feedback on this proposal would be appreciated.

J. Rapson

Infrastructure Canada

[Brody Flannigan]

I really like this idea.

As you said, the field would be really easy to implement from a producer's standpoint. As the producer for Transcollines, I would be absolutely willing to be the producer when this goes into voting.

You should open an issue in the Google/Transit repository (you can literally copy and paste the contents of your first message into the issue). You'll get even more feedback there.

--
You received this message because you are subscribed to the Google Groups "GTFS 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/d47fbaea-e8f1-46bb-bb17-5fb84a22b6dan%40googlegroups.com.

[Holger Bruch]

As a consumer, I'd prefer the exact coordinates of such bicycle parkings to give specific routing instructions. 

OpenTripPlanner for example currently extracts bicycle parking information from OpenStreetMap, and proposes cycling to the closest bicycle parking and then walking to the stop.

Adding a new location_type bicycle_parking would allow to publish them in stop.txt.

Is it common for producers, to know there are bike parkings for stations/stop but not knowing their geo position?

Best regards,

Holger Bruch

MITFAHR|DE|ZENTRALE

[Jessica Rapson]

Hi Holger, I think given the scope of GTFS data, this would only cover bike parking located at transit stations and stops -- so in most cases the appropriate location would be the same as the stop coordinate.

The location type you are proposing would be a significant departure from existing location types (stops, stations, entrances/exits, generic nodes, and boarding areas) that goes beyond the scope of public transit. I think keeping the feature as an additional field for each stop in stops.txt would be the most consistent with current practices and the easiest to implement.

J. Rapson

Infrastructure Canada

[Weston Shippy]

I like this idea from a philosophical point of view. The usefulness of this field probably outweighs this issue, but I foresee the most challenging thing about adding this feature being to define what "bike parking" is and ensuring producers adhere to that definition. This includes agreeing on how far away from a stop/station bike parking can be while still being considered part of that stop/station's infrastructure. Something like wheelchair_accessible is easier to define and validate because the boundaries of a vehicle's space are intrinsically and clearly limited, while a stop's boundaries are not.

--
You received this message because you are subscribed to the Google Groups "GTFS 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/f5fed630-6d5a-4779-a112-145884609999n%40googlegroups.com.

--

Weston Shippy (he/him | en, es)

Associate consultant/GTFS spec engineer

Trillium - We make transit easier to use.
503-567-8422 x16

[Gavriel Fleischer]

Hi,

I like the idea, but would suggest to change the values:

empty (and only empty) should mean: no data so it's backwards compatible.

0 should me: no bike parking

1 should mean: there is bike parking

as for the inheritance: we can say that in case of empty value it inherits the value from the parent stop

I also think it would be useful to have the location. This will probably be the same as the stop in case of small bus stops, but will be important in case of huge train stations, where

a) you might need to calculate the time it needs to walk from the bike parking area to the actual platform,

b) there might be multiple entrances but only one bike parking area.

c) it's especially important if it takes considerable time to ride to the bike parking area (would need different route to get to the right side of the station, because it's not convenient to cross the station with bike and takes 5 minutes to go around)

I think we can even do this in 2 steps:

1st add the is_bike_parking_available:""/0/1

2nd add enchanced data (i.e: lat/lon, but we can also extend it later with other fields as the need arises) 

--
You received this message because you are subscribed to the Google Groups "GTFS 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/d47fbaea-e8f1-46bb-bb17-5fb84a22b6dan%40googlegroups.com.

--

Gavriel Fleischer

Server Developer, Moovit 

Phone: +972-52-4232064

Email: gavriel....@moovit.com

───────────────────

       

───────────────────

[Jessica Rapson]

Hi Gavriel,

I think it's important to keep the convention established with wheelchair_accessible, which is a very similar field in stops.txt. That field uses the coding I described in my initial comment.

Are there any further comments on this proposal?

J. Rapson

Infrastructure Canada