Limit service namespace scheme to non-redundant usage or ax it

[Adamant36]

The wiki guidelines around the use of namespaces clearly states that they shouldn't be used in cases where it just duplicates data.

As in an example, the Over-namespacing section of the namespace article says "over-namespacing leads to a disseminated data scheme: for example, someone interested in VHF channels data will have to look for harbour:VHF_channel key, plus seamark:habour:VHF_channel, plus VHF_channel, plus lock:VHF_channel, plus vhf to collect the data... Using only the vhf key should be enough to know that this data relates to the harbour or the lock or what else is the OSM object we are tagging." The other sections of the article could just as easily apply to the way people are using the service namespace tags in iD Editor along with it.

For instance out of the 6894 uses of service:bicycle:retail=yes, 6091 of them are tagged on objects already tagged as shop=bicycle. There is only 7198 total uses of service:bicycle:retail. So almost 85% of it's usage is redundant and just duplicates already existing tags. Which is completely ridiculous, goes against the guidelines, and is not how these types of "service" tags were ever intended to be used. A lot of the other service namespace tags have the same issue. Over half of the uses of service:vehicle:car_repair are tagged on objects already tagged as shop=car_repair and there are other examples.

IMO, there are two possible solutions. Either block the ability for a service tag to be added to an object where it already has a more appropriate tag, like with my example of service:bicycle:retail=yes being added to places already tagged as shop=bicycle , or don't have the preset in the first place. If most of the service namespace usage is redundant, and it appears to be, then the best option would be just to disable it. There's zero reason to provide a preset for a tagging scheme that isn't being used how it was intended to be and mainly just duplicates data.

[maro-21]

For instance out of the 6894 uses of service:bicycle:retail=yes, 6091 of them are tagged on objects already tagged as shop=bicycle. There is only 7198 total uses of service:bicycle:retail. So almost 85% of it's usage is redundant and just duplicates already existing tags. Which is completely ridiculous, goes against the guidelines, and is not how these types of "service" tags were ever intended to be used. A lot of the other service namespace tags have the same issue. Over half of the uses of service:vehicle:car_repair are tagged on objects already tagged as shop=car_repair and there are other examples.

I don't agree. shop=bicycle is for shops where one can: buy a bike OR rent a bike OR repair a bike OR buy bike parts. Redundant would be to have separate main tags for it: shop=buy_bicycle, shop=bicycle_rental, shop=bicycle_repair, shop=bicycle_parts. So service:bicycle:retail=yes is not redundant because with shop=bicycle you can tag a place, where you can repair your bike but don't buy.

Shop=bicycle doesn't mean "they sell bikes there". It can be a place where you can only repair your bike or a place where you can only buy accessories.

Either block the ability for a service tag to be added

It was said many times that iD follows the OSM Wiki. The service tag is described there. The tag service:bicycle:retail has a Wiki page and it's approved.

[Adamant36]

I don't agree. shop=bicycle is for shops where one can: buy a bike OR rent a bike OR repair a bike OR buy bike parts. Redundant would be to have separate main tags for it: shop=buy_bicycle, shop=bicycle_rental, shop=bicycle_repair, shop=bicycle_parts. So service:bicycle:retail=yes is not redundant because with shop=bicycle you can tag a place, where you can repair your bike but don't buy.

From my understanding the intent of these types of descriptive tags exist are for the exceptions, not the rules. For instance the whole reason there is a key like outdoor_seating is because some places have outdoor seating and some don't. Otherwise, outdoor seating would be "baked into the cake" and there wouldn't be a need describe it. In this example most people assume that a bicycle shop sells bicycles. Everyone sees the icon for it on the map and thinks the object sells bicycles. They don't scroll through their mind of things it might not do. That's just not how maps work.

For instance people don't see the rendering for or tag landuse=scrub and figure that it's scrub by thinking about all the possible non-scrub things it might be. So, the descriptive tags exist to clarify things through describing them in more detail. Therefore, clarification with service:bicycle:retail=yes would be needed if for instance the place is tagged as shop=bicycle and service:bicycle:repair to show that it isn't exclusively a bicycle repair shop. I'd have zero problem with that as it fits with the purpose of the tag and that's how it is used some of the time.

The problem with that though is that the Wiki is pretty explicit about how we should map multiple features of an object as separate nodes when they they serve different purposes. It's also things are done in most every other case outside of car/bicycle/motorcycle shops. Including in iD Editor. For instance with shop=chemist and amenity=pharmacy or shop=convenience and amenity=fuel. The problem with a lot of these service tags even when they aren't redundant is that using them comes at the cost of mapping extra information that we would be able to add by following the guideline, precedence, etc etc like different hours and contact details. So whatever the shop=bicycle article says, it shouldn't (and doesn't) come at the cost of the guidelines, the naming rule, or the rule that says we should map features of an object separately.

If the amenity=bicycle_rental tags definition should be expanded to include shops that exclusively rent bicycles or separate features of a shop that sells bicycles, then that's a tagging issue and it shouldn't be "solved" by ignoring guidelines and precedent. Guidelines supersede a tags definition also and Just because a tag is approved it doesn't automatically imply support anywhere or in every way possible. Let alone not as intended. Anyway, take service:bicycle:retail out of the equation and like I said the rest of the tagging scheme still has the same and other problems. service:vehicle:whatever etc etc wasn't approved and they aren't automatically valid because service:bicycle:whatever was. So, the problem still needs to be dealt with even without it. Although, I think it should be still be limited or gotten rid of also. You can't ignore the guidelines on how to use namespaces just because of what the top of the shop=bicycle article says. The proper thing to do is to make it so people can use the namespaces while following the guidelines.