I think the reason they tried to move “fire_hydrant:diameter” to global namespaced “diameter” (and similar tags) is lying here:

https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpipeline

pipelines use diameter and pressure without a namespace bound to the object. While dealing with potentially lots of diameters on a fire_hydrant, a pipeline is assumed to only have one of importance (presumably the outer diameter, together with the wall thickness an inner diameter may be deductable).

So maybe (this is just a guess) the intention was to streamline the usage of diameter and pressure for pipeline and fire_hydrant objects. But in this case this might have also been achieved by proposing “pipeline:diameter” and “pipeline:pressure” on the man_made=pipeline side of things.

After rereading (and recalling) some key points of the fire hydrant proposal, I consent with Nakaner in this case. The proposal seriously needs rework. Instead of degrading tag names to be ambiguous (again?) it should have proposed further refinements to resolve ambiguity in tag names (if and where needed).

However, iterating on the above, please do not generalize disapprovals using arguments like avoid change of heavily used tags, this is too unspecific to be useful. It does not help proposal authors to understand why or where they failed and it potentially discourages people to propose changes in areas where change might indeed be useful to the community.

@escada: I agree with you in that “fire_hydrant:diameter” and “diameter” may not be self explanatory (which in general is desirable when chosing a tag name). For example, if the valve diameter of the fire hydrant was meant, then “fire_hydrant:valve:diameter” should have been used. Making a decision between the former two without documentation is error prone (you do not really know which one to use for the true object diameter).

So yes, in that respect the fire hydrant proposal may not have been perfect - and its a much better argument to disapprove it or demand rework than choking it off with a heavy use of prior art argument.

@escada: To try to understand why “fire_hydrant:diameter” was chosen over “diameter” I can only speculate (I usually do not tag these objects).

Maybe “fire_hydrant:diameter” specifically means the diameter of the water pipe within the hydrant, while “diameter” (a general object tag) simply means the true diameter of the fire hydrant?? In pretty much all cases these are two different values.

I’d guess that the value to this tag is currently useless, because you do not know whether mappers tagged the true diameter or the pipe diameter. You will note, that useless means, data consumers will also process useless data. So indeed, fixing the tag in this respect may actually be of more value to data consumers than leaving it in its useless state. ;-) But it’s just my guess. Usually fire fighters are not that dumb to rely on data they have not mined themselves (let’s hope they are not).

@escada: I did not delve into the fire hydrant proposal. My reply mainly deals with Nakaners generalization ‘‘to avoid changing heavily used tags’’ (which is not specific to the fire hydrant proposal).

I personally think that people should decline voting on proposals that they are not concerned with. If people do not map, tag and understand objects of that realm, their judgement is impaired or lead by secondary reasons and, most of the time, unrelated to the main issue.

That said, I do not oppose exchanging secondary viewpoints and bringing them to the awareness of proposal authors, but they should remain what they are: secondary issues. And they should (ideally) be raised during draft, not during voting. (I think that was a main complaint of the author(s) for the fire hydrant stuff).

If a proposal really is not an improvement (or if it has to be reworked), then there are better arguments to disapprove it than saying “it’s inconvenient to adopt to”. This is a foolproof argument to disapprove ‘‘any’’ change, regardless of its usefulness.

Once upon a time OSM prioritized the community aspect over data quality (!)

In this regard here it essentially means that we do not care about data consumers, if and only if a majority of the community reached a consensus to change heavily used tags.

This is necessary for two reasons:

(1) Tag finding is a rapid process and it is easy to introduce quirks and misnomers that may spread out to being widely used ‘‘before’’ the majority of the community notices that there’s a better tag to be used (producing less work in the long run, because it has less conflicts with other tags).

(2) If OSM is to avoid fixing long standing design flaws (which this proposal is essentially about), it will be trapped by inextensible map features in the future:

Most of the time, people seek to change and namespacify existing tags, because they ‘‘have used’’ them for a very specific feature, without noticing that the label of the tag denotifies other objects as well. -> Often this is noticed and accomodated to at times when the tag is not yet in widespread use, but there are exceptions.

Fixing these exceptions has a larger impact, yes. But the reasons to change these are just as valid as to change tagging flaws with lesser impact.

Being convenient about this may very well hinder growth of the data model at a later time (or lead to overly complicated new tag creations in desperation to circumvent the limitations presented by tags used in the wrong place ‘‘then’’).

To actually ‘‘fix’’ and improve such a situation in OSM, it ‘‘must’’ however strictly be a community effort and well documented. There’s no use in fixing tag labels and documentation if the reason to do so is not widely understood and supported. Of course (and unfortunately) the latter implies some feedback to the couch potatoe crowds which Nakaner’s arguments have in part fallen victim of:

The DWG mediating disputes (or generally reverting changes back and forth) is a ‘‘result’’ of poorly discussed, communicated (and hence supported) tag changes. Advancing to this (potential) result of an effort to improve the map features must not be presented as a ‘‘reason’’ to give up on such effort.

Die einfachste Lösung ist bei weitem nicht immer die beste. Ein krasses Beispiel: Überbevölkerung wäre am einfachsten dadurch zu lösen, indem man zum einen Menschen vernichtet und zum anderen die Fortpflanzung verbietet, bzw. verhindert. Gemessen an der Kreativität und dem Potential, das in jedem von uns steckt, ist aber ausnahmslos jedes Leben lebens- und schützenswert. Zudem hatten wir in der Geschichte schon Perioden, wo diese vermeintlich “einfachsten” Lösungen praktiziert wurden. Die besten waren es mit Sicherheit nicht.

Kurzum: Deine Abneigung gegen Freaks ist rein subjektiv und nicht rational zu begründen. Die Komplexität, die hinter OSM steht, macht das Projekt überhaupt möglich - mit einer Excel-Tabelle lassen sich auch geographische Daten “einfachst” erfassen. Die beste Lösung ist das aber mitnichten.

Es ist nicht verkehrt, wenn EDV-affine Leute ihre Meinung zum besten geben. Die beste Lösung entsteht, wenn sich beide Seiten einig werden. Genau dann ist die Lösung tragfähig und bringt den maximalen Nutzen für die größte Nutzerbasis.

Deine Beschwerde ist ein technisches Problem: Du schreibst, dass du Probleme hast “mal eben eine Abfrage zu schreiben”. Hast Du dir schonmal overpass-turbo.eu angeschaut oder die umfangreichen Arbeiten zum Thema Overpass-API von Roland Olbricht? Das ist alles dokumentiert und erlernbar und wenn man es einmal verstanden hat, macht es auch mehr Sinn, als wenn man sich dem Thema “automatisiertes Auswerten” verschließt.

Die einfachste Lösung ist “Bleistift und Papier”, aber es ist mit Sicherheit nicht die beste, schon gar nicht, wenn betrachtet wird, wieviel Anwendungsfälle mit der Datensammlung von OSM bedient werden können.

Gruß