Agreed, thus amenity=bicycle_wash is needed.
On the other hand, there are much more tool stations for bikes and with the increasing amount of ebikes, chances are that communities support recharging once in a while.
I sincerely hope no municipality will get the idea to combine charging station and wash station in one stand!
You know, water and electricity go together just like gasoline and smoking - it would be a very bad idea.
So instead of opening amenities for all the different bike station types, let’s keep things simple and call it “bike_station” and then specify the available services.
- using two tags instead of one to convey meaning is by definition more complex than using one tag for same purpose.
- while I see your point, I’m of opinion that unfortunately it wouldn’t result in “keeping things simple”. Because amenity=bicycle_repair_station already exist in wide use, and trying to “just rename it” to
amenity=bike_station with extra service:bicycle:repair=yes tag just won’t work.
Because everything is more complicated than expected when trying to deprecate things you’d get ObKXCD #927 and more complex result instead of intended simplification (i.e. you would end up having to support both old and new ways of tagging)
What do you do when a wash station starts offering repair tools and accessories or vice versa?
That does not seem likely to happen (at least I’m not seeing it), but if it did, you could add (already existing) property tag service:bicycle:cleaning=yes to (already existing) amenity=bicycle_repair_station primary tag (just like you can e.g. add already existing property tag car_wash=yes to already existing amenity=fuel instead of mapping separate amenity=car_wash)
This proposal is about creating a node with separate amenity=bicycle_wash instead – just like you may want to tag separate amenity=car_wash, instead of adding it as a property to gas station or a car repair shop, although at first it might seem like a good idea to unify them all under amenity=car_station and then add service:repair=yes, service:wash=yes, service:fuel=yes etc under it, depending on what car services are offered.
But that is not wanted, because people are like that – car owners don’t think “Oh I need to go to car station and get some fuel” (or “go to car station and wash my car”). They think/say “I need to go to fuel station” (or “I should go to car wash”). Same thing happens with cyclists, just replace the words.
You’ll then need to specify the individual services but can categorize only one which is not fully appropriate. In Germany, shoe repair shops often do key services, too, how do you categorize them?
Now that you mention it, how do you categorize them? I’m guessing adding two separate nodes, one on top of another? Or something similar?
For bicycle wash station, even that “two nodes as same location” is not a problem, because even if there is bicycle repair station nearby it is highly unlikely that it would be exactly the same physical element, so you could just micromap amenity=bicycle_repair_station next to amenity=bicycle_wash next to amenity=charging_station+bicycle=yes – as each one would be extremely likely separate physical device at a separate physical location (at least half a meter to 10s of meters away), so you could map them exactly where they are without any overlap. (Also as noted before, even those situation are much less likely to happen then shoe repair + key cutter combination which we already have and handle).
And three nodes (each with one tag) is not really more complex than one node with four tags. And it provides more precise information (more exact location for each of the amenities, instead of more approximate location of all of them combined lumped together). And it avoids issues with adding additional tags and ambiguity what exactly they apply to (see my next post about “One feature, one OSM element” principle).
