Talk:Tag:amenity=bicycle repair station

From OpenStreetMap Wiki
Jump to navigation Jump to search

Repair stations are also tagged with amenity=compressed_air Brycenesbitt (talk) 18:38, 28 July 2014 (UTC)

Similar repair stations exist, usually at resorts, for fixing skis and snowboards. Brycenesbitt (talk) 19:04, 15 November 2014 (UTC)


this tag is getting confused with bicycle repair shops. What to do about it? Brycenesbitt (talk) 16:05, 14 September 2016 (UTC)


opening_hours=destination does not make sense in my eyes. If the bicycle repair station is accessible 24/7 then opening_hours=24/7 if it is inside a building and the building is not open 24/7 and has opening hours then the opening hours of the repair station are the same like the opening hours from the building. There are exactly 0 objects tagged with opening_hours=destination at the moment. --Klumbumbus (talk) 19:39, 11 February 2015 (UTC)

I fully agree. --Scai (talk) 17:17, 4 March 2015 (UTC)
We don't have good support for objects inheriting properties of parents. I'd rather be warned a given station may be closed, without having to duplicate the opening hours. Brycenesbitt (talk) 18:47, 1 May 2015 (UTC)
*=destination means, that your are only allowed to use the object, if there is no other way. This does not fit in the opening_hours key. --Klumbumbus (talk) 19:30, 1 May 2015 (UTC)

chaintool vs. chain_tool

I'm not a native speaker, but I think the correct english word is "chain tool" and not "chaintool". Therefore the key should be service:bicycle:chain_tool=*. We don't want to create such a bad situation like power=sub_station --Klumbumbus (talk) 19:39, 11 February 2015 (UTC)

-- I have changed it. Note that the community hates bulk tag renaming, but if it that feeling changed, then fixing things like this would be easy. Brycenesbitt (talk) 20:55, 18 February 2015 (UTC)

There are reasons for not doing such huge mechanical tag changes. Therefore this feeling will likely not change in the future. However in this case, there were only 6 nodes with this tag and 4 of them were from you. So I don't see a problem with changing the key with this low number.--Klumbumbus (talk) 23:06, 18 February 2015 (UTC)
Please ask again for the preset change of the ID editor.--23:07, 18 February 2015 (UTC)

Why not add compressed_air to bicycle repair station ?

Why not 'delete' Tag:amenity=compressed_air, and add compressed_air=yes/no to Tag:amenity=bicycle repair station ? Because, a compressed air pump is also to 'repair' a bicycle, and also, there is sometimes 'confusing' when there is only a standalone public 'hand pump' ->

Deprecation of approved tag service:bicycle:diy?

Recently this page was edited to strike-out the common tag service:bicycle:diy which was approved in the original proposal ( Until recently this key was more common than service:bicycle:tools, which was created several years later:***/service:bicycle:diy/&***/service:bicycle:tools/

Should service:bicycle:diy by deprecated? Why? --Jeisenbe (talk) 21:31, 13 July 2020 (UTC)

Hey, we are working on a tool and during discussions this came up. In our opinion, a repair station is a pole with either tools, a pump or both. This implies by default that it is DIY, so service:bicycle:diy is a quite redudant and doesn't make sense in this context - both in cases of a pump or a toolstand it is DIY.
The tag for diy does make sense when applied on a bicycle shop which also offers tools though!
Note that in some cases, a bicycle repair station is solely a pump, not offering tools. For that, 'service:repair:tools' is semantically better to make the distinction.
And yeah, there is some ambiguity with amenity=compressed air too...
Also, this should have been communicated better by me, sorry about that.
Pietervdvn (talk) 22:26, 13 July 2020 (UTC)
I'm thinking we have to separate out the services documentation from the specific amenities (pumps/repair stations/shops). For example, a community centre can offer DIY cycle services, or a café can also sell bikes (fashionable these days!). If we do that, we can make a neat table of which services are needed or implied on what kind of feature Joost schouppe (talk) 07:13, 15 July 2020 (UTC)

lastcheck:status -> replace with more common operational_status?

Is there anything wrong with replacing lastcheck:status=* with operational_status=*? lastcheck:status=* seems to be a tagging invented especially for these repair stations, although the more common operational_status=* would be suitable. --Supaplex030 (talk) 13:53, 21 October 2021 (UTC)

operational_status=* has a very big issues in general and should not be promoted. check_date=* is preferable Mateusz Konieczny (talk) 07:25, 31 March 2022 (UTC)
I see no trace on the talk page of operational_status=* that there are issues with that tag. Perhaps you can document those concerns there?
With your suggestion above, do you mean to suggest check_date:status=* or check_date:operational_status=*? Joost schouppe (talk) 08:04, 31 March 2022 (UTC)
I meant to suggest check_date=* which I suggested. Maybe check_date:existence=* if people really want to be specific Mateusz Konieczny (talk) 10:10, 31 March 2022 (UTC)
I added Mateusz Konieczny (talk) 10:16, 31 March 2022 (UTC)

Is presence of one service tag implying no for other?

Note that appears to take no position on that, is amenity=bicycle_repair_station service:bicycle:pump=yes implying that it is sole service? And service:bicycle:chain_tool=* is implied to be of value no? (like recycling tags)?

Or, like service:bicycle tag family for shop=bicycle presence of one tag does not imply that other absent service:bicycle:* tags are of value "no"? (for consistency with shop=bicycle and to make iterated survey possible it seems highly preferable to have this interpretation) Mateusz Konieczny (talk) 07:29, 31 March 2022 (UTC)

AFAIK the latter. E.g. using service:bicycle:pump=yes+service:bicycle:rental=no only defines that: "yes, bicycle pump exists here" + "no, bicycles are not rented here" and says nothing about any and all other possible services (they are presumed unknown/unsurveyed yet, unless explicitly marked with yes or no).
Recycling tags are weird exception to this rule, but only because there are: (a) zillion of them with new ones popping up all the time, so it would be unreasonable to map all of them as "no" and constantly resurvey if there are new ones; and (b) person caring about mapping recycling usually cares about all of recycling offered (while person wanting for example to buy a bicycle, might not be interested to inquire and map whether the facility also provide bike washing service, whether there are tools for do-it-yourself bike repair, can they charge e-bike there, etc.) --mnalis (talk) 22:28, 31 March 2022 (UTC)
Default negative in the absence of recycling:*=* works for recycling_type=container, but not really recycling_type=centre. There are more functions and technicalities in a amenity=bicycle_repair_station (not to mention business in a shop=bicycle), that a user may not understand, know, or be bothered to add all the service:bicycle:*=*.
Ideally adding *=only (for single) or *:others=no (for multiple) explicitly would make it clear. --- Kovposch (talk) 06:47, 4 April 2022 (UTC)