change service/vehicle field to use service tag instead of nonstandard service:vehicle:*

[tyrasd]

See https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions#4th_format_for_vehicle_services_%22introduced%22. This field was introduced in openstreetmap/iD#3535 without going through the regular tagging approval process (neither explicitly through a tag proposal/vote nor implicitly through organic usage).

It would be straight forward to change the field to use the service tag (using its semicolon syntax). Also, iD's validator could help fixing any existing service:vehicle:* tags.

[1ec5]

For reference, I posted some tables on the wiki showing the current usage of each major tagging scheme for vehicle services. Previously, there had been some unsourced statements about usage that were either inaccurate or outdated.

Apart from the process considerations that have been raised, the service=* tagging scheme comes with some technical downsides. Given that tradeoff and the large number of features that would be affected – more than the number of features left unaffected – I think deprecation should also be discussed outside of GitHub. Otherwise, some people could potentially view this change in a similar light as openstreetmap/iD#3535, depending on their personal preferences. If there isn’t already a documented consensus to deprecate service:vehicle:*=*, consider taking the initiative to propose this deprecation or, alternatively, a formal restoration of service:vehicle:*=* through the proposal process.

Incidentally, there seems to have been a significant shift from the service=* scheme to the service:vehicle:*=* scheme sometime in November. Does anyone know more about that change? Was it in response to a community discussion or mapping campaign? Was it “organic”, so to speak?

[bhousel]

openstreetmap/iD#4497 contains counts of the service=* usage at the time when I made the change. The most common "vehicle service" value (and only documented one) was "tyres" at 0.05%.

I don't believe the service=* key ever went through the tagging proposal process either, so it's not like there was a formal proposal to start sticking values like "tyres" in there.

Back in 2017 we really just saw it as trying to fix a proliferation of problematic tagging before it gained widespread use. I still don't think it's possible to build a semicombo field that gives users good suggestions for these values - the road and rail values would far overload the vehicle service values - so you'd be stuck maintaining lists of what all the "correct" values are for each usage class.

Also - it's disingenuous for people to call this an "undiscussed" change. Wille put it out on tagging mailing list and on our GitHub issue, people said that it seemed like a good change , and I let #3535 sit open for at least 5 months before doing anything about it.

[Elefant-aus-Wuppertal]

Didn't you want to solve the fact that the "service" tag itself (without further words like "vehicle" or "car") has these two meanings? Once as a subgroup of highway=service / railway and once as a subtag of shop=car_repair? I think that was the origin of service:vehicle, right?