[Talk-de] Aufräumen von bollard=* tags

[Hauke Stieler]

Hi Volker, hi Martin,

Zunächst zu dem was Volker zuvor meinte mit ground-truth prüfen und second-
guessing:

Ganz offensichtlich kann ich die ground-truth nicht prüfen, weswegen das ganze 
hier ja ein mechanische-edit mit Diskussion ist ;)
Damit die lokalen mapper aber eine Möglichkeit haben die Änderungen zu 
begutachten möchte ich die changesets ja relativ klein halten, also pro 
Landkreis ein changeset.

Und second-guessing: Ja klar, andere Quellen habe ich nicht, sonst wäre es ja 
auch eher ein import. Aber die Korrektur mancher derzeit vergebenen Werte 
würde ich nicht mit "guessing" umschreiben, dazu jetzt mehr:

> ich sehe das ähnlich, es sieht schon so aus, als wären die Werte für den
> bollard key vielfach "falsch" oder "überflüssig", aber ohne dass man
> hinfährt und nachschaut was da eigentlich ist, bringt es nichts, die
> anzufassen. 
Gerade bei offensichtlich fehlerhaften tags sehe ich keinen Grund sie so zu 
lassen.
Beispiel: Warum sollte ich bollard=bollard drin lassen? Ganz offensichtlich 
hat dieser tag keinerlei Mehrwert.
Anderes Beispiel: bollard=metal beschreibt ganz klar das Material und nicht 
bollard-spezifische Eigenschaften. Warum also nicht in den standardisierten 
tag material=metal ändern?

Im Wiki habe ich daher ja extra einen Abschnitt "Open issue: Misleading and 
confusing tags" angelegt für Werte die verwirrend sind oder nicht direkt 
falsch aussehen wie bollard=electric oder bollard=contracted.

> Im Grunde halte ich die Probleme auch nicht für
> routingrelevant, weil es sich ja nur um den Untertyp eines Pfostens
> handelt, dass es ein Pfosten ist steht erstmal außer Frage (wenn du genau
> hinsiehst, vor Ort, wirst du vermutlich ein paar finden die keine Pfosten
> sondern etwas leicht anderes sind).
Ich denke auch nicht, dass solche Änderungen routingrelevant sind. Das 
entschärft für mich deswegen die ganze Aktion und macht sie meiner Meinung 
nach weniger "gefährlich".

> Die bollard-Werte (also eigentlich Untertypen) finde ich auch nicht ganz
> toll, weil die sich alle um eine Eigenschaft drehen, die aber aus dem
> allgemein gehaltenen key nicht hervorgeht (vereinzelt findet man in taginfo
> daher auch Werte, die einer anderen Systematik entstammen). "Falsch" ist
> bei so einem gewachsenen key, der nie formal vorgeschlagen wurde, auch ein
> bisschen hart.
Da muss ich etwas gegen halten.
Ich habe letztes Jahr eine Diskussion auf der tagging-Mailingliste gestartet 
[0] über die Werte von bollard=* mit der expliziten Frage ob ich ein proposal 
starten soll oder nicht. Es gab keine klare Stimme für die Notwendigkeit eines 
proposals, daraufhin habe ich die Wiki-Seite angepasst und es hat sich niemand 
beschwert. Klar, es gab kein proposal, aber komplett gewachsen und informal 
ist der key nun auch wieder nicht.

Darüber hinaus kam in der Diskussion raus, dass "fixed" der Wert für nicht 
entfernbare bollards sein soll. Benutzt wurden früher dafür 
bollard=unremovable oder =irremovable. Warum sollte man die so lassen, wenn 
sie a) genau das aussagen, dass der bollard nicht entfernt werden kann (also 
nach aktuellem Wiki "fixed" ist) und b) wir uns auf den "fixed" Wert geeinigt 
haben?

Zu deiner Anmerkung habe ich aber auch noch eine Frage: Du meinst es geht bei 
den bollard-Werten um "eine Eigenschaft", welche meinst du damit? Die 
Eigenschaft der "Entfernbarkeit" der bollards?

Grüße
Hauke

[0] https://lists.openstreetmap.org/pipermail/tagging/2020-February/
051179.html
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 833 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20211207/6f37b144/attachment.sig>