Lee Carré (2021-10-14 17:06:20+00:00): “Is there a difference between the meaning of service:vehicle:tires and service:vehicle:tyres?”

I don't know, I haven't examined it closely enough. However, in this case (context), probably not.

Personally, I'd opt for tyres (regardless of popularity) because it avoids the possible ambiguity of tires (hence my opening pun: “one tires of enormous changeset bounding boxes”).

Plus, being culturally-British, I'd habitually spell it with a Y.

To argue that something else was proper because it was more common, would be an argument-from-authority fallacy (assuming one cares about rationality & truth; not all do).

“There is consensus on this topic based on the uses (700 for tires vs 2.7k for tyres).”

Depends on your definition of consensus. I agree that tyres has the majority. Where should the threshold be, and who decides (or otherwise how is it decided)?

“There is also consensus to tag the "colour" and not the "color" of roofs, buildings etc.”

Again, I haven't compared. I do know that the presets I use employ colour.

For me (being culturally-British) colour is always spelled with a U.

Yet, even for (*:)colour=* I've encountered (for one context) a (common) value of gray and (in another) grey (also commonly). Makes a slight mockery of things.

Consider, though, that kerb (Yankish) is used instead of curb (British).

I am, in part, playing devil's advocate, here (for good reason, which I'll get to); when presets make it easy to follow (sane, sensible) conventions, then I do so (kerb, sidewalk, street, et alli) (and largely for some of the reasons you hint at).

“abolish widely used tagging schemes as you suggested with your sidewalk vs pavement example”

I wasn't suggesting that it actually be done (besides, changing the text string of a key is not abolishing a scheme; different concepts at different levels of abstraction); I was using hyperbole to make a point. I even indicated a problem with the term pavement (look back to what I said about *:surface=paved).

“I'm only doing it for tags that have the same meaning like in this case.”

Yet, sidewalk & pavement do (as far as I'm aware) refer to the same thing (thus ‘have the same meaning’?).



Broader perspective, for a moment: some of my concern comes from seeing where such zealous thinking leads. Including objectionable changesets (the contributor dismissing objections from many, and citing as justification similar reasons to yours, annoying very many people in the process) & restrictive policies (that inhibit productive work).

I've encountered examples of important details (e.g. if an amenity=charging_station was socket-only or tethered) for which a tagging convention wasn't well established (so I left a note:* to at least capture & preserve the info garnered from survey, for when a good scheme is devised; I could think of a few ways to tag it, but out surveying isn't really the best time for such thinking (especially avoiding bad consequences), nor trying to check taginfo), and of using an obvious tag (rating) to codify relevant data on the info-plate of a street cabinet only to be told that that tag is only for transformers (as if transformers are the only electrical equipment with any kind of rating, which (in reality) is nonsense) because the one saying so was too focused on tagging rules instead of representing reality (which entirely misses the point). Others include changing source(:*)=* tags (when there were multiple sources for values to different keys on the same element) which led to a misleading representation (which I guessed was a case of http://wiki.osm.org/wiki/Tagging_for_the_renderer again rather than best (least-badly (accurately, ambiguously)) representing reality; all despite my having surveyed the thing, yet he-who-knew-better was far away (and relying on an outdated book)).

All these (notable) examples and I'm one of a few local mappers on a small island (and only contributing for several months so far), nevermind a larger jurisdiction which will see more examples.

I don't disagree with the ideals you express, but it's not that simple.

Other cases which come to mind involve changing the design of the tagging scheme, to fix a clear problem. That's breaking consensus (on use of tagging, if not on the proposed change). That's how separating cuisine=* & diet:*=* came about. Likely others, in the past.

How is anything to ever be improved (by redesign, to fix fundamental (unforeseen) problems with an existing convention?

Would you tell a mechanic to fix your car, but not replace or modify any components?

Unless done en masse (which counts as an automated edit), then trying to do it piecemeal will always face the ‘but that's not what's popular’ objection.

What if consensus is opposed to that which works well or has superior merit? Consensus is a little bit of a cop-out (because it's easier & quicker than proper debate, and settling on any convention tends to have more utility than exactly what that convention is).

Back to the flexibility I mentioned.

Plus, consensus (however that's defined) need not be global; there are national-level differences in conventions. So, data-parsers need to account for this, anyway (besides it being a good idea).

Any wise implementor (of a parser) will know to not expect OSM data to be perfect, and thus won't want his software failing when it isn't. So, using pattern-matching would be done anyway. If there's only ever one match, then nothing is lost, yet the parser remains robust in the face of obvious variations.

Did you consider that maybe a preset is the cause of the different spellings? If not, and that (preset differences) is the case (or presets lacking the key, so people are manually-entering it with their native spelling), then you'll forever be cleaning up the results until the source is fixed.

Turn off the fire-hose (or at least take it outside) before trying to mop the floor and otherwise clean up. Else you'll be doing a lot of mopping indefinitely.

Work smarter, not harder.