Proposal: Bike Parking

[rapsoj]

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 general, having imperfect information is more useful than having no information at all.

Any feedback on this proposal would be appreciated.

Note: Transcollines has volunteered to be the producer when this goes into voting

J. Rapson
Infrastructure Canada

[leonardehrenfried]

I echo @hbruch's comment from the mailing list.

In Germany at least this need is served quite well by putting the data into OpenStreetMap which has a lot of bicycle infrastructure in it.

This also relieves you from having to decide if a bike parking facility is "part of" the transit infrastructure or just happens to be near it.

OpenTripPlanner (which I'm a developer of) parses the OSM data and can offer very precise information where to drop your bike before moving onto transit.

Also OSM has a lot of geospatial tooling that allow you to identify train stations that don't have parking infrastructure near them.

(As a keen cyclist myself, I don't like being negative and really don't want to discourage better information but want to offer an alternative where might want to focus your energy. I will not vote -1.)

[rapsoj]

Thank you for your comments.

I think what would separate this from the data available on OSM is the level of standardization. GTFS is standardized data format and is normally produced directly by the transit operators themselves. This brings a level of standardization and authority that OSM data lacks.

Further, there are definitely transit systems with bike storage facilities who would really appreciate the opportunity to advertise their facilities to potential riders in Google Maps and similar applications.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[skinkie]

Keep open.