Gab es da irgendwo einen Wettbewerb: Wer den größten Landstrich in Level 10 einfärbt, hat gewonnen? Das schlägt noch die landuse=farmland-ganze-Verbandsgemeinde-taggen-Landschaftsmaler.
http://www.openstreetmap.org/browse/way/246602883
Und dann noch die Chuzpe haben als note reinzuschreiben “Genauen Gebietsverlauf noch finden”
Das dürfte eine etwas freizügige Interpretation der Tags monument und attraction sein, außer das Mittelrheintal wurde mittlerweile überdacht. Eher angemessen wäre wohl protected_area.
Aber sehen wir’s positiv: Jetzt ist die chinesische Mauer nicht mehr das einzige Monument, das aus dem Weltraum mit bloßem Auge zu erkennen ist. 
bye, Nop
Und das Wikipedia-Tag ist auch gut gewählt 
Als gebürtige Darmstädterin kann ich bezeugen, dass das nicht die Grube Messel ist. Ich bin entsetzt ob dieser Ignoranz 
Moin,
also wirklich falsch ist doch da nur das historic=monument und den irreführenden wikipedia-Link …
Das tourism=attraction entspricht doch nun wirklich der Wahrheit - der man nunmal ins Auge sehen muss!
Und mit dem layer=-2 hat er/sie/es sich doch wirklich Mühe gegeben, die Auswirkung abzumildern …
Gruß
Georg
HHHiiiilfe, das war ich…:o
Hatte bei der Betrachtung der historischen Karte gesehen, dass die Grube Messel aufgeführt als UNESCO-Erbe aufgetaucht, aber das Obere Mittelrheintal nicht trotz historischer Bedeutung. In Anlehnung an das Tagging von Messel habe ich wohl ein Tag (area?) zuviel übernommen…
Cepesko
PS: Bin noch auf der Arbeit, kann jemand schneller das Problem für mich lösen?
Nahmd,
[×] done
Protected area möge noch jemand nachtragen, der sich damit auskennt.
Gruß Wolf
Danke, Wolf, für die schnelle Korrektur meines Fehlers.
Cepesko
@NOP:
War in Gedanken der Begrifflichkeit der “National Monuments” in USA. Info: Dort ist ein “monument” oft ein großes Gebiet (monument), z.B. mit 34.000 qkm so groß wie ganz NRW.
@Nadjita/Georg:
Habe beide Orte besucht: Das Rheintal ist höchst attraktiv, z.B. Bacharach, Kaub, etc. Aber bei der Grube Messel müssten wir tourist=attraction ganz schnell entfernen. Wenn du da reinläufst, siehst du fast nix, außer Bitumen und der ehem. Müllumladestation, den gelagerten YTONG-Steinen am Horizont und viel Zaun. Enttäuschend. Vielleicht wäre ein Täg attraction=horror besser.
PS: Hatte jemand Dresden UNESCO-mäßig (um-)getaggt? disused/abandonned/depreciated/protected=no/punished=yes
OSMand zeigt diese Region mittlerweile auch in zartrosa
Ja, ist halt immer Glücksache, solange wir kein “stable-version” unserer Daten haben.
“stable-version”??? Gab es mal einen “stable moment”?
Bitte nicht falsch verstehen. Aber für Unternehmen ist gerade das vielleicht der Haken bei OSM.
Und ich bin gerne bereit, an Überlegungen und Vorschlägen hierzu beizutragen (ohne dass ich jetzt schon Patentrezepte hätte…).
Vermutlich nicht. Mal ist hier was kaputt, mal dort.
Patentrezept hab ich auch nicht. Folgenden Gedanken hatte ich mal:
In der letzten Woche jeden Monats sind nur noch Reparaturen an den Daten erlaubt. Anfänger etc. sind dann nicht zugelassen, so dass man Ende des Monats halbwegs saubere Daten hat. 
Ich bin Informatiker. Das klingt für mich nach einer Art von “Code-Freeze”-Phase vor einem Release. Aber das passt vielleicht nicht so super zur dynamischen und “agilen” Ausrichtung von OSM.
Andere Begriffe, die mir zum Thema noch einfallen, sind: Continuous Integration mit automatisierten Tests (auf Server-Seite!) und Continuous Delivery. Derzeit haben wir quasi schon Continuous Delivery nur leider ohne die eigentlich obligatorischen Tests.
Das ist genau das Problem bei einer professionellen Nutzung, für das es derzeit keine Lösung gibt.
bye, Nop
Ein alternativer Weg wäre, die interessierenden Daten zu extrahieren (Entkopplung von der Live-Datenbank), diesen Extrakt zu korrigieren und das Ergebnis verfügbar zu machen. Nachteil: der Aufwand für die Korrekturen kommt nicht der eigentlichen Datenbank zugute. Vorteil: Eben weil man nicht in der Live-Datenbank herumfuchtelt, kann man auch relativ grobmotorische automatische Korrekturen laufen lassen, die in OSM selbst nicht akzeptabel wären, etwa Objekte mit strukturellen Defekten schlichtweg löschen.
Für Mapper wäre es natürlich höchst unattraktiv, sich z.B. monatlich am Aufräumen eines Länderextraktes zu beteiligen, und weitaus sinnvoller, die Fehler stattdessen einmalig in der Datenbank zu beheben, auch wenn man so nie völlige Fehlerfreiheit - ohnehin nur bezüglich definierter Fehlerklassen - an einem Stichtag erreicht. Bleibt noch eine automatisierte “Veredelung”, die natürlich auch nur eine (eher kleine) Teilmenge aller Fehler beheben oder zumindest symptomatisch behandeln kann. Daß bisher niemand so etwas anbietet, mag einen Hinweis auf das Ausmaß der Nachfrage geben. Zumal die höchst variablen Anforderungen verschiedener Nutzer schon mit der Nutzung verschiedener, unterschiedlich fehlertoleranter Renderer und sonstiger Programme anfangen.
Eigentlich müßte nur die Geofabrik mit jeder Aktualisierung des OSM Inspector die gefundenen Fehler zählen. Am besten gleich länderweise und die Ergebnisse auf der Download-Seite für die Extrakte anzeigen; und schon könnte ein Anwender entscheiden, einen aktuellen Extrakt nicht zu verwenden, wenn sich etwa die Anzahl der Routingfehler gegenüber dem Vortag verdoppelt hat. (Der OSM Inspector findet natürlich - wie jedes andere Tool - nur eine Teilmenge aller Fehler, aber als relativer Indikator taugt die gefundene Anzahl allemal.)
Ich bin der Meinung, dass wir da ein grundsätzliches Problem anschneiden, das es verdient hätte, aus dem rosa Anstrich herausgelöst zu werden (sprich ein eigener Thread).
Eine Schwäche des Projektes OSM ist es, dass wir ein continuous delivery ohne ernsthafte Qualitätssicherung haben. Die Revert-Aktionen nach Meteoreinschlag in München, beleidigten Förstern, iD-Quadraturen etc. passieren ja erst, nachdem das Kind schon in den Brunnen gefallen ist.
Mapping ist aber so verschieden von SW-Entwicklung oder Wikipedia, dass die dortigen Mechanismen nur äußerst eingeschränkt übernommen werden können. Aktualität ist eine Kerneigenschaft, die mMn nur durch die Möglichkeit zum sofortigen Eintragen von Informationen erreichbar ist. Auch die Motivation sänke rapide, wenn das nicht mehr sofort möglich wäre.
Andererseits ist bereits eine so wertvolle Informationsbasis aufgebaut, dass man diese nicht schutzlos jeder gewollten oder ungewollten Aktion preisgeben sollte. Kommerzielle Nutzbarkeit ist sicher nicht das Hauptanliegen von OSM, aber nur für die Blumenvase ist die ganze Arbeit zu schade.
Bei “stable version” kommt mir der Gedanke, in der Richtung sich auch etwas für OSM zu überlegen.
Ich könnte mir eine “live version” vorstellen, in die alles wie bisher eingetragen wird. Aus der werden die neuen Einträge aber erst nach grober Plausibilitätsprüfung (siehe iD-Unfall-Diskussion), abhängig vom Umfang und nach einer Wartefrist automatisch in die stable übernommen. In dieser Wartefrist kann jeder gegen einen Neueintrag Einspruch erheben und der wird dann zunächst gegen Übernahme gesperrt. Wie und durch wen dieser Konflikt aufgelöst würde, müsste noch festgelegt werden.
Auch gegen Trolle könnte in dieser Karenzzeit viel effektiver vorgegengen werden.
Das ist ebenfalls kein Patentrezept und dass dieses Vorgehen noch viele andere Fragen aufwirft, dürfte klar sein: Welche Version soll als Standardkarte angezeigt werden, wie erkenne ich, ob ein Eintrag noch “live” oder schon “stable” ist, was passiert mit Änderungen, die auf verworfenen “live”-Änderungen aufbauen, usw.
Ich bin aber der Meinung, dass OSM inzwischen so weit gediehen ist, dass es sich lohnt, sich auch über solche Probleme mal Gedanken zu machen.
kurz und bündig:
++++1
Eine stabile Version, die mehr Zuverlässigkeit bietet als die live. Solch einen Gedanken hatte ich ebenfalls schon. Ich habe, wie wohl andere auch, schon die Datenqualität angesprochen. Ich kann so eine Zweiteilung nur befürworten.
So ein Vorgehen wäre theoretisch wünschenswert. Das Konzept kann aber nicht funktionieren, da die Änderungen nicht einfach zeitverzögert übernommen werden können, weil alles miteinander verflochten ist. Das ist schon bei einem Revert ein Problem, daß er schnell erfolgen muß bevor jemand anders etwas geändert hat. Oder das war ein großes Problem beim Redaction bot gezielt Informationen zu entfernen.
Wenn die Übernahme abhnängig vom Umfang oder mit unterschiedlichen Wartezeiten erfolgt, können sich logisch zusammengehörende Edits überholen und es entstehen dadurch korrupte Zustände. Wenn einzelne Änderungen nicht in die stable wandern ist alles in Frage gestellt was räumlich oder logisch danach weiter editiert wird. Um das zu reparieren wären direkte, abweichende Edits auf der stable nötig, die dann aber den Unterschied zur live noch größer machen und die Diskrepanz breitet sich immer weiter aus.
Die andere Frage ist natürlich wer die Prüfung für alle Änderungen vornehmen soll. Damit baust Du einen gewaltigen Druck auf, was abzuarbeiten ist.
Ich denke der einzige technisch machbare Ansatz wäre es, eine Plausibilitätsprüfung, Begrenzungen für Anfänger und verwarnte Accounts und/oder einen Zurückweisungs- oder Freigabemechanismus in die API einzubauen, so daß verdächtige Dinge nicht direkt in der Datenbank landen. Aber auch hier hat man das Problem daß die Entscheidung sehr schnell fallen muß bevor Konflikte entstehen.
bye, Nop
Ohne jetzt groß darüber nachgedacht zu haben: Aber ist es vielleicht sinnvoll, Wartezeiten für endgültige Übernahmen zu definieren?
Ich stelle mir das grob so vor: Änderungen werden nur in einer temporären DB gemacht. Jeder arbeitet auf diesem Mirror, jeder ändert und checkt. Aber jede Änderung wird - sagen wir - eine Woche nicht in den Hauptzweig geführt. Ist also Blödsinn passiert, braucht man erstmal nur in der temporären DB zu fixen und man fasst den Hauptbranch nicht an. Aber dadurch dass alle auf dem Mirror arbeiten, dürften keinerlei Konflikte oder so auf dem Mainbranch zustande kommen, denke ich.
Hmm, mir fällt grad ein, was passiert, wenn ein Revert genau über die Wochengrenze hinweg passiert… Dann kommts zu komischen Ergebnissen… Hm…