Looking for advice & input on improving wiki page for bicycle parking

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 rack or stands) post_hoop (should be bollard or stands), would also throw in two_tier vs two-tier here

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.

Two questions:

  • Personally, I would tag these as bicycle_parking=stands since 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 another bicycle_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.
1 Like