Ich sehe das zumindest ab jetzt so.
Übrigens gibt es auch Systeme (z.b. w3.org), die zwischen missing value default und invalid value default unterscheiden.
Gruss
walter
Hätte ich auf jeden Fall jetzt auch so angenommen, find ich auch sehr viel logischer. Diese DefaultAnnahmen dass wenn nicht gesetzt = no (oder wie auch immer) find ich meistens sehr gefährlich. Es macht natürlich nur da Sinn wo es auch passt, also bei einem See brauche ich kein building=no setzen.
Allgemeiner gesagt: in einem natural=water ist das building=no schon inherent vorhanden, ein Objekt mit natural=water und building=yes sollte es nicht geben. Also kann man hier den Defaultwert building=no annehmen, und wenn dann doch dieser abslute spezialfall aufkommt, dass jemand ein Haus aus Wasser baut kann man dann ja unabhängig davon diskutieren ob das dann ein natural=water, building=yes ist.
In einem fall von highway=* kann aber eine Annahme über lit=* überhaupt nicht getroffen werden, selbst wenn 90% der Straßen unbeleuchtet sind find ich es korrekt und gut lit=no zu taggen. Auch schon aus dem Grund, dass dann andere Mapper wissen das jemand das dort gecheckt hat. Wenn ich sehe, “oh ist unbeleuchtet, ist ja der Defaultwert also tagge ich nichts”, kann man das nicht mehr unterscheiden von dem Fall wo sich einfach noch niemand um die Beleuchtung gekümmert hat.
Stellt euch mal vor, jemand will in einer Straße Autos knacken und verlässt sich dann darauf, dass sie unbeleuchtet ist und dann hat das nur keiner getaggt, schon blöd 
Was ich mit dem tollen Beispiel nur sagen will ist, dass nicht nur die Information “Straße ist beleuchtet” interessant sein kann, sondern auch die Information “Straße ist nicht beleuchtet”. Und das kann ich dann nicht aus den Daten ziehen wenn Leute das als Default annehmen und nicht taggen
In der Theorie stimmt das. Ich frage mich nur, wie man in der Praxis einen nur halbwegs akzeptablen Grad an Abdeckung sinnvoll erreichen will.
-
Der Schlüssel lit=* wurde 2009 ins Wiki aufgenommen. Wieviele Straßen gab es da schon? Wer setzt sich hin und taggt das bei allen nach, wenn er in der selben Arbeitszeit auch Neues erfassen könnte?
-
Wenn demnächst mal Straßen vermehrt überdacht werden, wer trägt bei allen bislang gemappten und nicht überdachten Straßen covered=no nach? Ist doch auch eine interessante Information, abhängig vom Wetter.
-
Zwischenfazit: Das Tagging von Elementen ist niemals vollständig, wenn der Umfang an erfaßten und getaggten Merkmalen nachträglich erweitert wird. Kaum einer setzt sich hin und taggt das in wochenlanger Arbeit bei den von ihm angelegten Straßen nach. Daher brauchen wir Defaultwerte.
-
Wer legt fest, bei welchen highway=* ein lit=* gesetzt werden soll? Oder soll das grundsätzlich geschehen, auch bei allen Bergpfaden in den Alpen, bei allen Wanderwegen im Schwarzwald?
-
Wann weiß ich, daß ich einen Weg vollständig getaggt habe? Zumindest für die nächsten 2-3 Jahre, bis die AfD an der Macht ist und access-Tags wie fee:gay=yes oder muslim=no an allen highways erforderlich werden?
–ks
Da hast du recht, Tagging kann niemals vollständig sein. Aber wenn jeder in seinem Umkreis auf Fehler und eventuell neues achtet und aktuell hält, ist das viel (mehr) wert. Und lit=no an allen Straßen ist genauso wie surface=asphalt, auch wenn in Deutschland überwiegend Asphalt als Straßenbelag vorhanden ist.
Fehlende Werte sind mir jedenfalls lieber, als wenn (automatisch oder manuell) Werte aus der Ferne eingetragen werden. Und irgendwann fasst man eine Straße an, wo man dann feststellt, da fehlt noch lit, surface, smoothness, width, …
Bei der sind mal wieder die Lichter ausgegangen.
http://lightmap.uni-hd.de/
EDIT: Kommando zurück, man muss nur ein bisschen warten.
So isses. Nützlich kann lit schon sein - zweifellos. Das einzige Problem ist doch, dass außerorts ein anderer default-Wert gilt als innerorts. Viel Spaß beim Aufbereiten der Daten - für Datenbankbesitzer möglich, für alle Anderen ein Graus.
Ich hab nochmal drüber nachgedacht und bin auch dahingekommen, dass meine Annahme von vorhin, bei highway=* ist sowohl lit=yes als auch lit=no generell sinnvoll zu weit gegriffen ist. Wahrscheinlich müsste man je Straßentyp von verschiedenen Defaults ausgehen.
highway=motorway : Default = no
highway=residential : Default = unbestimmt
(highway=?? : Default = yes)
Den dritten Fall wird (sollte) es wahrscheinlich nicht geben. Bei den entsprechenden Straßentypen (2. Fall) sollte meiner Meinung nach lit=no auch immer mitgetaggt werden. Wenn ich mir jetzt z.B. die Lightmap von Berlin anschaue ist da sehr viel mehr Dunkel als in Wirklichkeit (zumindest meiner Empfindung nach, wer weiß?). Wahrscheinlich ist der Goßteil davon einfach nur ungetaggt
Wie gesagt, in Belgien sind Autobahnen alle beleuchtet, d.h. diese Defaults müssten per Land unterschiedlich sein.
ja, das wollte ich erst auch noch sagen, aber dachte, dass das ja bei so vielen Dingen zutrifft und das ja entsprechend auf den sprachspezifischen Wikiseiten enthalten sein könnte. Obwohl Sprache != Land/Region, weiß ja auch nicht wie das in Österreich und Teilen der Schweiz ist.
Sowie ausgerechnet in Belgien
–ks
lit explizit anzugeben ist genauso notwendig wie das manuelle Angeben von maxspeed= 50, 100, none.
Eine automatische Auswertung kann es nicht geben, deshalb muss man es angeben.
Es interessieren sich nur halt nicht so viele dafür, lit zu mappen, auch weil es kaum Anwendungen dafür gibt. Ein Fußgängerrouter macht auch erst Sinn, wenn ein gewisser Erfassungsgrad vorhanden ist.
Erweitert natürlich die Tags auf der Autobahn, aber wenn man da ganz kleinlich wäre, dann könnte man in OSM so viel kritisieren, wenn der Tag lang ist: lanes=2 auf Autobahnen; lanes=2 auf Bundesstraßen; surface=asphalt auf allen deutschen Straßen usw. usf., aber ich denke das führt zu nichts.
Das unterliegt der Annahme, dass eine Autobahn / Landstraße / Wohnstraße usw. am anderen Ende der Welt das Gleiche ist wie hier.
Und: Das ist schön für Leute, die in ihrer Region bleiben und sich nicht für den Rest der Welt interessieren. Wertest Du aber die Datenbank aus und versuchst auch mal eine Karte für Land XY zu rendern scheiterst Du mit solchen Datenmodellen: Defaultwerte die nur für ein bestimmtes Land/Region gelten (können) kannst Du nicht automatisiert beim Kartenrendern einbeziehen. Soll heißen: Jegliche Defaultwerte sind für Kartenrenderer nicht nutzbar. Es ist IMO ein Fehler zu meinen es mache Sinn mit irgend welchen Defaults zu arbeiten. Habe ich zu einem Key ein “yes” oder “no” weiß ich beim Auslesen der Datenbank was Sache ist - fehlt die Angabe, kann ich keine Aussage treffen - ganz egal, ob es einen Default gibt oder nicht. Und den Fall unvollständigem Taggings wird es bei einer nie fertigen und sich stets weiterentwickelnden Aufgabe wie OSM schlicht oft & beständig geben. Selbst Dinge wie maxspeed für Deutschland als Default ins Wiki zu schreiben und zu meinen es ja wäre sinnfrei das zu taggen (“sowas gehört ins Wiki, nicht in die Datenbank” - sehr oft in diesem Forum zu lesen) - wer das meint hat nie Karten für ihm völlig unbekannte Regionen gerendert. Was soll irgend wer mit Kartendaten die ihm nur etwas über ihm bekannte Regionen erzählen können?
Und zum hier gebrachten Beispiel mit See & “building=no” als Defaultwert: Der Tag “building” ist keiner, der üblicherweise kombiniert mit einem Gewässer verwendet wird. In sofern wird da keiner irgend einen Wert annehmen wollen, das ist kein Key den irgend wer beim Auslesen untersucht. Die Kernfrage ist IMO nicht wie man die Daten schön in die Datenbank bekommt, sondern: Wie kommt man zu einer benutzbaren Datenbank.
Dem kann ich zustimmen. Es wäre schon sinnvoll, wenn sich an die “Vorlagen” (zumindest manche) gehalten würde. Arbeitet man die Liste ab, sind auch die Abfragen nach (vergessenen, unbewussten) Werten beantwortet. Einige verweisen noch auf andere Vorlagen, die natürlich bei der Bearbeitung mit erledigt werden sollten.
Natürlich ist z.B. eine Gaststätte dann nicht in 10 s erfasst, aber die erweiterten Daten sind sinnvoll.
Dazu wurde ja oben schon was geschrieben
Würde ich als Idealfall auch annehmen und ich hab kein problem damit wenn du beim Taggen von Autobahnen auch ein lit=no setzt. Das macht aber keinen Sinn, wenn das nicht auch konsequent durchgezogen wird, wenn du auf 40% der Autobahnen ein lit=no setzt wirst du eine Lightmap haben auf der 40% der Autobahnen dunkel sind und die anderen 60% rot weil du dazu keine Daten hast.
Richtig ja, sowas (rote stellen in der akrte) kann dann auch motivieren das überhaupt zu taggen, aber wir sind weit davon enfernt die Kapazitäten zu haben alles überall zu taggen, auch wenn ich (wie oben angesprochen) auch ungerne mit diesen Defaults arbeite kommt man leider nicht drumherum. Und dann finde ich es sinnvoll, nicht so eine softe Annahme zu treffen wie “Default bei Straßen ist lit=no” sondern es auf bestimmte Straßentypen (ja auch länderspezifisch, auf jeden Fall!) einzugrenzen. Soetwas müsste dann im Wiki festgezurrt werden nach dem Motto "empfohlene/notwendige Taggings für diesen Straßentyp in Deutschland/xxx)
Mit der Einstellung (“schafft man nicht”) hätte man vor 10 Jahren mit dem OSM Projekt und weißer Karte gar nicht starten dürfen.
Die Mapper in den Großstädten langweilen sich bereits, weil dort alles schon gemappt ist.
Um es klar zu sagen: es gibt in Deutschland wichtigeres als lit=no an Autobahnen zu taggen; anderseits wird man einen Fan von lit=no an Autobahnen nicht hindern so lange er glaubhaft machen kann, dass er sich von dem Nichtvorhandensein der Beleuchtung überzeugt hat und kein mechanisches Edition ohne Genehmigung durchzieht.
Das wird bei OSM aber nie anders sein - nichts ist vollständig und umfassend erfasst. Jede Auswertung die auf Statistiken abzielt kann mit OSM nicht funktionieren - sie kann nur besagen, wie “XYZ in OSM” vorhanden ist. Auch wenn Du einen Defaultwert für die Straßenbeleuchtung hast wird eine Lichtkarte definitiv falsch sein (eben weil das “lit=yes” ebenfalls unzureichend gemapt sein wird - ich z.B. habe bei keiner Straßen- oder Wegergänzung dies gemapt, dafür aber andere, für mich relevante Details). Dass Vorhandensein von “keine Info vorhanden” ist eine Tatsache bei OSM-Daten, mit der jeder beim Auswerten von OSM-Daten schlicht leben wird müssen - ganz egal, was wir definieren. Und das bedeutet auch, dass nicht alles damit möglich sein wird.
+1, wobei ich aber auch überhaupt nicht das interesse habe jemanden daran zu hindern. Ich würde aber einfach gerne begrenzte Defaults setzen um die Kapazitäten die wir momentan haben effektiver zu nutzen. Ich glaube garnicht, dass wir hier so verschiedene Meinungen haben, schliesslich ist meine Ausgangsposition ja auch, dass Defaultwerte problematisch sind
Aber ich will es auch realistisch sehen, und jetzt allen zu empfehlen auf Autobahnen lit=no zu taggen, natürlich auch nicht einfach so sondern auch on-the-ground überprüft, macht für mich keinen Sinn. Wenn jemand jetzt speziell deswegen losziehen will über die Autobahnen, gerne, mach das. Und wenn du sicher weißt, dass eine bestimmte Autobahn unbeleuchtet ist, und du Lust hast das zu taggen, dann mach das.
Da aber lit=no nicht der einzige solche Fall ist, finde ich es sehr sinnvoll einen entsprechenden Rahmen zu setzen an dem sich Mapperinnen und Auswerter orientieren können. Ich kann zwei Jahre lang Autobahnen abfahren und lit=no mappen, oder ich setze kurz einen entsprechenden (genau umrissenen) Default ins Wiki mit dem Mapper und Auswerterinnen arbeiten können.
Vor allem aber, ein Defaultwert ist meiner Meinung nach überhaupt keine Empfehlung, etwas nicht zu mappen! Ich würde es als Hilfsmittel/Übergangslösung sehen, was dich aber überhaupt nicht davon abhalten sollte lit=no (etc.) zu taggen, wenn du weißt, dass das auf eine Straße zutrifft!
Ich finde Defaultwerte extrem praktisch, wenn sie praktisch gewählt sind. Das heißt, ihre Definition muss wohl überlegt sein. Was nervt ist, wenn Defaults definiert sind darüber zu diskutieren, ob es nicht anders praktischer wäre; oder nicht schlimmer ob die Defaults nicht falsch sind.