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

Alex supaplex at riseup.net
Mi Dez 8 09:00:11 UTC 2021


Hallo Hauke,

im Gegensatz zu einigen anderen "Tagging-Korrektur-Kampagnen" hast du 
dein Vorgehen offenbar - in Relation zur Größenordnung - gut durchdacht 
und dokumentiert und du scheinst dir einer gewissen Vorsicht bzw. 
Gewissenhaftigkeit bewusst zu sein, die es für so eine Aktion braucht. 
Bei den meisten von dir im Wiki vorgeschlagenen Changes sehe ich daher 
ehrlichgesagt keine Bedenken, sie so durchzuführen, da die intendierte 
Bedeutung offensichtlich ist. Vielleicht (falls nicht ohnehin geplant) 
kannst du dir im Änderungsprozess noch ein Luftbild drunterlegen, um 
Situationen zu erkennen, in denen sich der bauliche Zustand 
grundsätzlich geändert hat, um dort nichts veraltetes zu manifestieren. 
Auch eine vermeintlich "geringe" Relevanz sollte kein Grund sein, sowas 
nicht zu tun (OSM hat ohnehin keine Relevanzkriterien, sondern höchstens 
einzelne Mapper).

Die von dir benannten open issues würde ich hingegen auf keinen Fall 
anfassen - das sieht tatsächlich nach raten aus und wird OSM im 
Zweifelsfall nicht verbessern. Bei der pauschalen Ergänzung von 
"barrier=bollard" solltest du auch vorsichtig sein und beispielsweise 
prüfen, ob es andere Primärtags gibt, man evtl. etwas auf Luftbildern 
erkennt, was einen Poller plausibel macht oder es sich ggf. gar nicht um 
Poller handelt. Oder - je nach Anzahl der Objekte - im Zweifelsfall das 
Glück bei Mapillary/Kartaview versuchen...

Grundsätzlich finde ich die hier auf der Liste geäußerten Bedenken zwar 
nachvollziehbar, aber nicht in dieser Absolutheit. Inzwischen scheinen 
zunehmend QS-Tools Anwendung zu finden, um beispielsweise 
Rechtschreibfehler zu korrigieren. Erst in einer der letzten 
Wochennotizen wurde beispielsweise user:Mueschels Liste "neuer Keys" 
erwähnt (http://osm.janmichel.eu/taginfo/newkeys.htm), bei denen es sich 
oft um Rechtschreibfehler oder Unwissen neuer Mapper handelt und die 
einige gezielt korrigieren. Das hat - je nach dem, wo man die Grenze von 
"offensichtlich" oder "plausibel" ansetzt - Vor- und Nachteile und ich 
habe mich auch schon öfter mal geärgert, wenn jemand remote "in meiner 
Ecke" vorbeikam und ungewöhnliche, aber bewusst gewählte Tags "gerade 
biegen" wollte, damit sie in irgendeine enge Klassifikation passen. 
Dafür ist die Realität aber oft zu komplex und es gehört ja gerade zu 
den Grundprinzipien von OSM, dass man grundsätzlich erstmal "alles" 
taggen kann (und sich damit oft evolutionär herausstellt, dass eine 
dokumentierte Klassifikation noch nicht ausgereift ist).

Also belasse es - meiner Meinung nach - am Besten bei den wirklich 
offensichtlichen Verbesserungsmöglichkeiten, von denen es ja ausreichend 
gibt :)

lg, Alex

Am 07.12.21 um 15:59 schrieb 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
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de


Mehr Informationen über die Mailingliste Talk-de