Hallo,
mit dem User Reclus habe ich einige Differenzen, die ich gerne geklärt haben möchte, denn es könnte sich ansonsten zu einem Edit-War entwickeln.
Es geht um aus meiner Sicht überflüssige, manchmal falsche Tags aber auch um die Sinnhaftigkeit.
Auch meiner Sicht
a) sind die Tags layer=0 und level=0 in den überaus meisten Fällen überflüssig da sie als Default-Wert impliziert sind. Level=0 macht für mich nur in wenigen Fällen von 3D-Tagging Sinn (z.B. Einkaufszentren/Malls). Bei einem normalen Wohnhaus mit Ladenlokal im Erdgeschoß ist diese Angabe aus meiner Sicht überflüssig.
b) macht die Angabe von lanes=2 bei normalen Straßen ohne Richtungsangabe keinen Sinn, da ansonsten angenommen wird, man hat eine 2spurige Straße in einer Richtung vor sich. Eine normaler residential, tertiary, secondary oder primary highway kommt im normal ohne lane-Angabe aus, es sei denn es wird lane:forward/backward mit angegeben
c) bei einer Einbahnstraße wird lanes=1 als default-Wert gesetzt, eine lane-Angabe ist nur dann erforderlich, wenn mehr als eine lane vorhanden ist. Ebenso ist es unnötig zu erkennen, ob es der default-Wert gilt oder lane=1 explizit (und somit überflüssig) angegeben wurde. Auf lanes=1 kann im Normalfall bei einer Straße verzichtet werden. Eine Straße mit Gegenverkehr, die so schmal ist, dass nur eine Spur möglich ist, ist lanes=1 dagegen erforderlich.
d) bei POIs ist die Adressangabe zum POI überflüssig, wenn der POI z.B. einer mit Adressangabe versehenen Flache zugeordnet bzw. an dieser klebt (z.B. shop am entrance). Mit allen gängigen Auswertungstools ist m.E. die Adresse zum POI ermittelbar. Die Adresse ich aus meiner Sicht in diesem Fall redundant und somit entbehrlich. Für mich ist dies auch hier wieder Datenmüll.
Im Gegenteil, beim Umzug des POIs kann ich einfach verschieben und muss die Adresse nicht explizit ändern (Ausschaltung einer Fehlerquelle beim Warten von Daten).
e) sollten POIs im Normalfall als Node getaggt werden und nicht zur Fläche eines Gebäudes. Es gibt nur wenige Gebäude, die ausschließlich einem Zweck dienen. Vorteil ist aus meiner Sicht auch in Fällen, in denen das Gebäude nur einen Zweck hat, die einfachere Wartbarkeit. So kommen beim Gebäude unzählige Tags (z.B. heritage, level, roof, building* etc.) hinzu, die sich hinterher nur noch schwer auseinander dividieren lassen, z.B. beim Umzug des POIs (Gebäude bleibt im Normalfall an alter Adresse vorhanden).
Überflüssige Angaben sind auch meiner Sicht redundate aufblähende Daten und somit im eigentlichen Sinn Datenmüll und können problemlos entfernt werden.
Adressdaten sollten im Normalfall nur zum Gebäude und nicht ZUSÄTZLICH dem POI zugeordnet werden.
Ich weiß, dass beide unterschiedlichen Ansichten nicht grundsätzlich falsch sind, doch sollte man sich aus meiner Sicht auf die jeweils nur notwendigen Tags beschränken und keine Redundancen erzeugen. Ich weiß, dass ich als Programmierer grundsätzlich faul bin und Redundancen hasse, was andere möglicherweise anders sehen. Aber alles, was einmal vorhanden ist, sollte man wieder nutzen und das heißt auch, KEINE redundanten Daten erzeugen, wo sie nicht zwingend erforderlich sind. Bei obigen Punkten sehe ich aber keine zwingende Notwendigkeit für eine Redundanz lasse mich aber gerne überzeugen.
Es geht nicht alleine darum Speicherplatz zu sparen (ja, ich komme aus einer Generation, wo man noch um Halbbytes gekämpft hat), sonder auch darum, es den BIG-DATA Auswertern nicht unbedingt einfach zu machen (ja, ich komme auch aus einer Generation, die sich noch um Datenschutz sehr stark engagiert und auch die Volkszählung in den 80ern bekämpft hat). Aber redundante Daten machen auch zusätzlich Arbeit, da sie einer zusätzlichen Pflege bedürfen. Zudem ist bei redundanten Daten Fehler bei einem der Datensätze wesentlich schlimmer als wenn man die Daten nur einmal vorliegen hat. Sicher gibt es auch Nachteile, so dass ein Fehler in einem Datensatz für alle nachfolgenden/anhängenden Tags (z.B. POIs bei Adressen) wirkt, aber dafür sorgt auch eine Berichtigung oder korrekte Änderung (und letzteres halte ich für den Normalfall) für alle nachfolgenden/anhängenden Tags für korrekte Daten.
Wie sieht dies die Community? Wie gesagt, ich weiss, dass beide Ansichten nach Wiki-Regeln richtig sind, die Frage ist auch, ob man zwei so unterschiedliche Ansichten wirklich beibehalten will, bei dem Umfang, den das Projekt OSM mittlerweile angenommen hat, denn dies macht es auch Auswertern/Renderern meiner Ansicht nach schwerer. Ebenso werden viele überflüssige Daten mit dem Wert “no” eingetragen, obwohl nur der Wert “yes” interessant ist. Ja auch hier kann man denken, es ist eine Dokumentation, dass man die Tags kontrolliert hat, dafür sollte man dann aber meiner Ansicht nach einen einheitlichen Tag (z.B. check_date) verwenden.
Wünsche eine schöne und angehme sowie nachdenkenreiche Woche
Thoschi