I’ve been thinking of working on some improvements to the (english-language) wiki pages for amenity=bicycle_parking and wanted to get some advice and input on some ideas:
Improving the guidance for bicycle_parking=* on the Tag:amenity=bicycle_parking page
Despite being the most common tag added alongside amenity=bicycle_parking, bicycle_parking=* (i.e. what kind of bike parking is it) is a little buried on this page and doesn’t have much description.
I would propose to move it to the top of the “Tags used in combination” section, before the table of other possible co-tags. I would also add the suggested bicycle_parking=* tags in the “examples” gallery on this page.
For the other co-tags described on this page, I can probably improve the description texts and it might be worth breaking out the table into three sections, something like:
- Other commonly-used tags (e.g. capacity, covered, access, fee, operator) - approximately anything with 5%+ usage on taginfo
- Additional tags (e.g. name, indoor, the cargo bike tags, maxstay, surveillance) - will also check if there’s anything in the common editor presets that’s missing from this list
- Reference tags (e.g. cyclestreets_id, ref:velopark)
Adding detail and organization to Key:bicycle_parking
Two main ideas for this page:
Documenting the “functional” style of tagging
Some users focus on functionality over appearance when tagging, e.g.:
- Locks to wheel only →
bicycle_parking=wall_loops(i.e. “wheelbender” racks) - Locks to frame only, no wheel support →
bicycle_parking=stands - Can lock/support both frame and wheel →
bicycle_parking=safe_loops
The streetcomplete app appears to be particularly influential in this regard, since it uses functional descriptions and omits tags such as bicycle_parking=bollard and bicycle_parking=rack:
(See GitHub discussion threads: #330, #923, #1038, #1202)
Without weighing in on whether this is more or less correct than any other method of tagging this key, it would be helpful to add a section describing the approach and noting that editors like StreetComplete do not have options for common values like rack and bollard, since this fits with their specific design goals and intended user experience.
Organizing values into sections
I think the list of bicycle_parking=* tag values would benefit from being organized into categories, e.g.:
- Common values (maybe all the ones with 1% or more on taginfo, e.g. stands, wall_loops, rack, shed, bollard, safe_loops, building, wide_stands, lockers)
- Other values (less common, but still notable, e.g. anchors, floor, ground_slots, two-tier, handlebar_holder…) - I would also consider adding notes to indicate values that are strongly regional, e.g. streetpod, arcadia
- Discouraged / deprecated values, e.g. wave (should be
rackorstands) post_hoop (should bebollardorstands), would also throw intwo_tiervstwo-tierhere
Also, has anyone seen a good example of how to make these big tables more mobile-friendly?
Documenting commonly-confusing bicycle_parking= types
We were talking on the OSM-US slack tagging channel about this particular model of bicycle parking (the landscapeforms “Pi” stand" [1]) which is a bit confusing. In theory, you’re supposed to hang your frame on it [2], but most users would probably use it like a bicycle_parking=stands or bollard.
- [1] Bicycle stands by Cedarbrae library | These are the "Pi" mod… | Flickr
- [2] Instructions sticker on landscapeforms “Pi” bike stand at Cedarbrae library
Two questions:
- Personally, I would tag these as
bicycle_parking=standssince I’ve never seen them used “as intended” and it seems unlikely that most cyclists would want lift (and disassemble?) their bikes in this way. Does this make sense, or is there anotherbicycle_parking=value that would be better? - Someone suggested these would be good to document on the OSM Wiki. Perhaps it would be worth adding another section in the Key:bicycle_parking page titled something like “potentially confusing bicycle parking designs” or “tagging recommendations for specific designs” and adding this as an entry.
