Grundsatzfragen - Redundanz der Daten

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

+1
Geschäfte sind am einzelnen node im Gebäude besser als am entrance.

Hi Thoschi,

also da du ja nicht gerade unaktiv im Forum bist, kann ich mir gerade kaum vorstellen, dass du die immer wiederkommenden Diskussionen bzgl. POI und Adresse nicht mitbekommen hast, das ist also keine Sache zwischen dir und reclus sondern dir un der Community:
POIs ohne redundante Adresse weil ermittelbar VS. POIs mit redundante Adresse der Einfachkeithalber (auch für Nichtsoftwareentwickler)
Und das geht meistens 50% zu 50% aus.

Zum Thema Default/implizierte Werte, was willste machen, wenn sogar JOSM Maintainer beim Thema, ob drinkable=yes (implizit laut Wiki) zu amenity=drinking_water trotzdem noch setzbar sein muss die Antwort kommt

(https://josm.openstreetmap.de/ticket/14415)

Um an deine allgemeinen nachdenklichen Aussagen/Argumente anzuschließen: Definiere “Datenbank”. Also Softwareentwickler (alter Garde) ist man geneigt sofort an “normalisierte Daten” zu denken. Aber nur weil die OSM Daten meist in einer PostgreDB mit PostGis hängen ist das nicht der Fall. Aktuell würde ich aufgrund der fast unstrukturierten OSM Datensammlung eventuell eine NoSQL für sinniger halten.

Letztendlich solltest du dich damit wohl abfinden … das sagt dir jemand, der mittelfristig hauptberuflich die IT verlassen hat. Und um beim Nachdenken zu bleiben, wie lautet gerade ein Artikel im entwicklerspezial: “Perfektionismus - Steht er Entwicklern im Weg?”

Datenmüll ist nicht das primäre Problem. Schlecht wird es wenn es unübersichtlich wird, wie bei den POIs mit Adressen. Daher wäre dies der einzige Punkt wo ich dir zustimme. Ich wandle POIs auch immer von Flächen in Punkte um, weil man die leichter findet. Dabei bleibt dann die Adresse auf der Fläche.

Beim reinen Verschieben des POI’s gehen dir aber Informationen verloren (Historie; Möglichkeit hier etwas zu betreiben, falls jemand auf der Suche ist). Besser in meinen Augen wäre umtaggen mit z.B. http://wiki.openstreetmap.org/wiki/DE:Key:disused: (auch wenn es wohl erst zweimal benutzt wird) oder zur Not http://wiki.openstreetmap.org/wiki/DE:Tag:shop%3Dvacant o.ä.

Wie viel macht die Adresseangabe am POI (oder am entrance) in der Datenbank aus?

Ich bin dafür einfach → speziell → kompliziert zu mappen.

Ein Geschäft kann seinen POI besser nutzen, wenn er einfach ist. Und das wollen wir ja erreichen, die einfache Nutzung (und eventuell selbstständige Aktualisierung) der OSM-Daten.

Bei einigen Schlüsseln (z.B. check_date) sehe ich da schon mehr Potential, diese zu “vereinheitlichen”.

Die Qualitätsprüfungen / Aktualisierung in “seinem” Gebiet zu betreiben, ist wesentlich sinnvoller.

Dieser Annahme muss ich widersprechen. lanes=* kodiert die Gesamtzahl der Fahrstreifen, in beiden Richtungen. Bei einem geraden Wert ohne richtungsspezifische Angabe wird vom Auswerter angenommen sollte der Auswerter annehmen, dass jeder Richtung die Hälfte der Fahrstreifen zur Verfügung steht. lanes=2 ist damit eine ganz normale Landstraße mit markierter Mittellinie. Nur bei ungeraden Werten von lanes=* ist es sinnvoll, die Anzahlen pro Richtung anzugeben (womit lanes=* IMHO ganz wegbleiben kann, da redundant – es lässt sich ja durch eine simple Addition von :forward und :backward ermitteln).

lanes=2 an einer Landstraße kodiert somit die Tatsache, dass zwei Streifen markiert sind, im Gegensatz zu unmarkierten Straßen, wo sich beide Richtungen einen (ausreichend breiten) Fahrstreifen teilen und stärkere Aufmerksamkeit erforderlich ist.

–ks

Edit: umformuliert

Sieht so aus, als ob hier wieder zwei “Sturköpfe” aufeinander treffen. Beide meinen es nur gut, aber eben aus unterschiedlichen Sichten.

Letztendlich is OSM keine gepflegte Datenbank, dass muss man akzeptieren auch wenns (mir ebenfalls) schwer fällt. Eigentlich ist es nur ein Haufen von Daten, aus denen man sich die brauchbaren raussuchen muss. Dass dies jede Menge Arbeit ist und sehr viel Redundanz und für manchen Asuwerter damit unbrauchbar sollte klar sein. Für “meine Kunden” lösche ich viel irrelevantes und bereite mit Skripten auf, bevor ich die Daten weitergebe, damit können dann schon viele besser leben.

Redundanz ist ein typisches OSM “Problem”. Wer irgendetwas auswerten möchte muss unterschiedliche Tags, unterschiedliche Informationen oder fehlende berücksichtigen. Das machts nicht leichter. Wer etwas zählen will muss Duplikate entfernen … Aus Programmierersicht ärgerlich.

Jüngstes Beispiel, bei mir in der Gegend fügt ein junger Mapper überall addr:country addr:county!! und addr:street hinzu, selbst wenn ein addr:place bereits da ist. Begründung: JOSM meckert anscheinent wegen unvollständiger Adressen. Kann ich nicht nachvollziehen, aber wenn er meint … wieder etwas mehr “Datenmüll”.

Im Grundsatz bin ich dafür alles “so einfach wie möglich” zu mappen.

Noch ein Hinweis: Das “Entfernen” von redundanten/impliziten Tags bläht die Datenbank noch weiter auf, da die alte Version in der History erhalten bleibt und Du eine neue Version samt unnötigem Changeset erzeugst.

Von daher besser alles was nicht schädlich, sondern nur überflüssig ist, in Ruhe lassen.

bye, Nop

Hier muss ich aber ein bisschen Korinthen kacken: Von der aktuellen Version eines Objekts sind immer 2 Kopien in der zentralen Datenbank (in der “current_xxx”-Tabelle und in der “xxx”-Tabelle); von historischen Versionen nur eine. Wenn ich also ein Objekt durch das Enfternen von Tags so verkürze, dass die neue Version weniger als halb so lang ist, dann könnte das Gesamt-Datenvolumen in der Datenbank dadurch tatsächlich zurückgehen

Oder rechnerisch: Alte Version hat 1000 Bytes, ist 2x drin, d.h. 2000 Bytes in der Datenbank; erzeuge ich nun eine neue Version davon, die nur noch 500 Bytes hat, dann ist die alte einmal und die neue zweimal drin, macht auch 2000 Bytes, und wenn meine neue Version noch kleiner ist…

Bye
Frederik

b) -1
e) -1

a) Ich stimme da zu
b) Stimme ich nicht zu
c) Stimme ich nicht zu, es ist sonst schwer zu erkennen ob da nun eine Straße nicht erfasst wurde, oder einfach nur eine spur hat. Ich versuche in meiner gegend möglich flächendeckend die Spuren zu erfassen, da tagge ich auch an Einbahnstraßen ein lanes=1, davon ab gibt es genug Einbahnstraßen mit mehr als einer spur.
d & e) Stimme ich nicht komplett zu. Adressen sollten immer ans Gebäude. POI Infos auch, es sei denn, es sind mehre POI im selben Gebäude.

Doch, macht Sinn.

1. als Indikator für die Straßenqualität (abhängig von der Region, in Schottland gibt es viele einspurige Straßen)
2. wird es bei ITOmap angezeigt
   http://product.itoworld.com/map/179

Das Taggen von impliziten Werten kann auch andere Gründe/Vorteile haben. Bspw. dass man sieht, dass sich das schon jemand genau angeschaut hat.
Bspw. die Beispiele hier von level(=0) und lanes(=2) geben mir eine klare Ansage: Wo ist der Der Laden? In Parterre. Die Strasse hat (gesamt) 2 Fahrspuren und nicht vielleicht doch 3 und nicht 4 und nicht eine.
Ich persönlich (gehe davon aus, dass ich da in einer Minderheit bin) bin der Meinung, dass lanes=2 überall (mind. an primary und secondary etc.) getaggt werden sollte, wo es sich auch so verhält. Soll jeder machen wie er will, nur eben nicht (solche) “Redundanzen” löschen.

Datenmüll nunja, wenn tag=no (bsp.) implizit ist, finde ich es unsinniger, wehtun tut’s trotzdem keinen.

Meine Sicht dieses Konflikts: Thoschi hat vor kurzem mit Lösch- und Ummap-Aktionen gegen von mir in meiner Heimatstadt (teilweise sehr detailliert) erfasste Objekte gestartet. Dabei richtet er viel Schaden an.

Bisheriger Höhepunkt ist Changeset 46798649. Hier hat versucht, die Tags des Ruder-Clubs Witten von seinem Bootshaus zum Haupteingang umzumappen. Dabei hat er gelöscht:

• Namen und Alternativnamen des Clubs

• Kontaktdaten (Webseiten, Telefonnummer, Facebookseite)

• Informationen für Rollstuhlfahrer (Tür ist wheelchair=no wie man auf dem Foto auch sehen kann. Thoschi hat sie zu wheelchair=limited umgemappt.)

Zu Punkt vs. Fläche: Womit assoziiert man den Ruder-Club geographisch? Mit seinem Clubhaus oder mit dem Vereinsgelände (ähnlich wie bei Schulen), sicher aber nicht mit dem Haupteingang. Argument von Thoschi für solche Ummap-Aktionen ist dann die vermeintlich bessere Wartbarkeit. Schon das Clubhaus ist aber über 90 Jahre alt und der Verein wird in naher Zukunft auch sicher nicht umziehen. Selbst falls das tatsächlich mal passieren sollte, wäre es sehr leicht, die Tags an das neue Objekt zu kopieren. Schwieriger wäre es, die Tür aus dem Gebäude zu lösen, zu verschieben, dann doch Tags zu ändern und dann am Gebäude eine neue Tür einzutragen. Damit macht Thoschi mir, der ich tatsächlich diese Daten warte, viel Arbeit.

Zu explizit vs. implizit: Bei nicht gesetzten Werten kann man nicht unterscheiden, ob der Wert unbekannt oder bekannt und der Default-Wert ist. Daher setze ich bestimmte Werte, z.B. bei Straßen lanes, gerne explizit. (Argument wurde hier auch schon genannt.)

Zu level: Praktisch alle Gebäude in Witten sind in 3D gemappt. Die Angabe von level (also dem Geschoss) bei Geschäften, Praxen & Co. korrespondiert damit.

Zu den Adressen an Geschäften, Praxen etc.: Das wird einerseits im Wiki explizit empfohlen und macht auch Sinn wenn man mit unvollständigen Daten arbeitet. Typisches Anwendungsbeispiel: Suche auf Mobilgerät nach Apotheken in der Umgebung. Mobilgerät startet eine Overpass-Abfrage nach Apotheken im Umfeld. In der Antwort sind dann die Adressinformationen des Gebäudes, in dem sich die Apotheken befinden, nicht drin.

Zu Datensparsamkeit vs. “Bloat”: lanes und level machen nur einen sehr, sehr kleinen Teil der Daten aus. Z.B. verglichen mit den 3D-Daten in Witten ist das völlig zu vernachlässigen. Und wenn man bedenkt, dass in Zukunft z.B. auch Straßen als Fächen gemappt werden, wird sich das noch weiter verschärfen. Der Vorteil des expliziten Werts überwiegt meiner Meinung nach eindeutig.

Und übrigens füllt Thoschi im Gegensatz zu mir die Datenbank mit Dingen wie Fußwegen zwischen Bus-Haltestellen und Steigen, die in der Realität nicht vorhanden sind, oder innerstädtische Flaggenmasten, von derem Mappen im Wiki explizit abgeraten wird.

Hallo Reclus,

halt mal den Ball mit Deinen Anschuldigungen flach.
a) die gelöschten Daten beim Ruderclub waren ein versehen und keine Absicht
b) Fußwege zwischen Bushaltestelle und Steig sind ziemlich alt und mittlerweile hat mich sich darauf geeinigt, das diese nicht erforderlich sind. Ich lösche sie seit Woche dort, wo sie mir auffallen (bei dem Datenwust fallen sie mir leider nicht überall auf). Aber ich habe festgestellt, dass Mentz diese teilweise wieder setzt.
d) Nirgendwo steht im Wiki, dass Flaggenmasten nicht gesetzt werden sollen. Die Aussage im Wiki bezieht sich auf “kleinere” Flaggen, wie jene am Golfplatzloch oder die Eisfahne am Kiosk. Markante Fahnen sind hingegen die hohen Fahnenmasten an Einkaufzentren, Autohäusern etc.

Alles andere ist wie oben schon ausgeführt, durchaus Geschmackssache, wobei ich mich explizit gegen lanes=2 bei Straßen mit Gegenverkehr OHNE lanes:forward oder :backward ausspreche. Dies suggiert, wie Dir schon geschrieben, dass ich die freie Spurwahl habe, was ja wohl nicht stimmt. Überholmöglichkeiten werden durch change:lanes bzw. overtaking (bei expliziten Hinweisschildern) geregelt. Trotzdem sind diese Daten überflüssig, da alle Straßen von residential bis primary eine zweispurige Straße mit Gegenverkehr abbildet, diese Daten dort also impliziert sind. Die Notwendigkeit zu erkennen, ob sich jemand die Straße schon mal angeschaut hat, erkenne ich nicht. Wenn ich da langfahre und z.B. eine vierspurige Straße vorfinde, die nur 2spurig getaggt ist, ist es mir egal, ob sich das schon mal jemand angeschaut hat, ich tagge es vierspurig um.

Hallo Reclus,

halt mal den Ball mit Deinen Anschuldigungen flach.
a) die gelöschten Daten beim Ruderclub waren ein Versehen und keine Absicht
b) Fußwege zwischen Bushaltestelle und Steig sind ziemlich alt und mittlerweile hat man sich darauf geeinigt, das diese nicht erforderlich sind. Ich lösche sie seit Woche dort, wo sie mir auffallen (bei dem Datenwust fallen sie mir leider nicht überall auf). Aber ich habe festgestellt, dass Mentz diese teilweise wieder setzt.
d) Nirgendwo steht im Wiki, dass Flaggenmasten nicht gesetzt werden sollen. Die Aussage im Wiki bezieht sich auf “kleinere” Flaggen, wie jene am Golfplatzloch oder die Eisfahne am Kiosk. Markante Fahnen sind hingegen die hohen Fahnenmasten an Einkaufzentren, Autohäusern etc.

Alles andere ist wie oben schon ausgeführt, durchaus Geschmackssache, wobei ich mich explizit gegen lanes=2 bei Straßen mit Gegenverkehr OHNE lanes:forward oder :backward ausspreche. Dies suggiert, wie Dir schon geschrieben, dass ich die freie Spurwahl habe, was ja wohl nicht stimmt. Überholmöglichkeiten werden durch change:lanes bzw. overtaking (bei expliziten Hinweisschildern) geregelt. Trotzdem sind diese Daten (also lanes) im Normalfall überflüssig, da alle Straßen von residential bis primary eine zweispurige Straße mit Gegenverkehr abbildet, diese Daten dort also impliziert sind. Die Notwendigkeit zu erkennen, ob sich jemand die Straße schon mal angeschaut hat, erkenne ich nicht. Wenn ich da langfahre und z.B. eine vierspurige Straße vorfinde, die nur 2spurig getaggt ist, ist es mir egal, ob sich das schon mal jemand angeschaut hat, ich tagge es vierspurig um.

Meine Meinung:
Wenn jemand “vor Ort” etwas mappt - sei es detailiert oder mit MP-Relationen oder … - sollte man von außerhalb nur Fehler korrigieren.
Ich bin z.B. auch für Eingänge oder POI’s mit allen Angaben, weil ich dann zu dem Eingang geroutet werden kann und nicht auf der Rückseite des Hauses lande, weil die Straße näher am Hausumriss liegt.
Eine Bushaltestelle braucht z.B. einen Anschluss an einen Fußweg fürs Routing.

Das mit lanes=2 zu lanes=4 ist ja dann auch ein “Fehler”, der korrigiert werden sollte. hw mit lanes=2 zu löschen ist falsch, da dies kein “Fehler” sein kann.

EDIT: einigt euch vielleicht auf die K11 als “Grenze” …

Das Thema sollte jetzt eigentlich geklärt sein, oder? Oder muss ich jetzt auf diesem Niveau weiterdiskutieren? Oder soll ich weitere Bespiele von merkwürdigen Ummap-Aktionen von Thoschi aufführen, bei denen seinen persönlichen Geschmack gegen Konsens/Wiki durchsetzen wollte und Schaden angerichtet hat?

Thoschi hat sie gestern lanes übrigens mit der Beschreibung falsche lanes antfernt gelöscht. Das ist alles so sehr neben der Spur, dass mir dazu überhaupt nichts mehr einfällt.

Die Grenze ist die Stadtgrenze. Er wohnt in Wetter und ich in Witten. Ich kümmere mich fast nur um Witten und versuche die Änderungen dort wegen Vandalismus im Auge zu behalten.