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

[Volker Schmidt]

Natürlich war das ein Fehler: 3 von circa 3000 in Hannover. 285 von x in
Deutschland.

On Tue, 7 Dec 2021, 16:05 Hauke Stieler, <mail at hauke-stieler.de> wrote:

> 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
> <https://lists.openstreetmap.org/pipermail/tagging/2020-February/051179.html>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>