Bicycle parking with different areas, types of parking, and capacity

I’m currently mapping bicycle parking stands on the areas that I frequent. I have now encountered several issues pertaining to how to indicate the different types and combinations of bicycle parking solutions that are practically in the same area.

One location has 3 different stand types in there <>. This is a bicycle parking area/garage that is indoors open at certain hours and is CCTV monitored. It has 3 types of stands (front wheel holders, stands, and two-tiered racks) with different capacity and possibility to park cargo bikes. And a repair station. I don’t exactly know how to indicate this, as the different types of stands are generally good to capture due to the fact that those two-tiered solutions would not be able to hold my bike as its wheels are too thick to fit them. And to indicate that this bicycle repair station is part of this bicycle parking area.

Other location has multiple groups of stands/racks that are in a half-circle-like formation with footpath going through it <>. Each of those groups individually does not have that high of a capacity, but the total capacity of that area is quite decent. Now when adding those low-capacity rows individually, the cycle map layer in OpenStreetMap viewer shows them as individual bicycle parking areas with low capacity. Some of them exceed the “high capacity” area threshold where they are shown the number of bikes that you can park. But some of the rows of racks do not exceed this threshold and show as single blue dots on the map. I would like to indicate that this is a larger capacity bicycle parking area so that these maps could render it as I would expect. But also maintain the disconnected inner-outer half-circle shape so that it wouldn’t be mapped as a single closed area.

Barro: I can’t really answer your first two queries (although I think large bicycle garages with just a capacity tag is adequate).

For the two close together areas, map them separately, It is is easy to cluster individual parking nodes to provide an aggregate capacity (although I’m not sure any renderer already does this). Another example is if there are some covered stands and some uncovered stands in the same location (two nodes).

I wouldn’t say it’s easy, but it’s probably possible. And it’s likely the only decent solution with existing tags.

In my opinion, a better solution would be if we had an equivalent to amenity=parking_space for bicycles, which would allow us to map details within a large bicycle parking area.

I should note that the capacity tag is not enough to capture the situation where the width of tires is a deciding factor on if you can use the parking space or not. You can’t put fatbikes in those two-tiered racks or in any wheelbenders as they are made for wheels that are around 40mm or less in width. That’s why the information if there are any stands (or anything that supports locking the frame) that can support these less common bikes (fatbikes, many bikes with small wheels, carbo bikes) is valuable. does cluster bike parking, but it doesn’t aggregate the capacity. That’d be an interesting thing to do.

At least in PostGIS it’s fairly straightforward to use ST_DBScanCluster on objects with reasonable results (see Dan Stowell’s roof-top solar paper for the approach they used &mdash: the need was to avoid double counting panels of different orientations on the same house/building). Of course rogue tag values need to be filtered out (e.g., with regexp, and with sensible bounds (>0, < 10,000 perhaps). Slightly more complex is that the appropriate distance will depend on zoom level, and it would be nice to cluster adjacent to specific types of POIs too).

The proposal is older than bicycle_parking and in fact could be used for bicycles, too. The site relation will definitely work, but I would prefer to have one area for the whole parking, e.g. amenity=bicycle_parking and inside areas for the different stands with