Hallo Forum,
in OSM Inspector gibt es jetzt eine Bereich in dem Informationen zur Lizenz dargestellt werden.
auf der linken Seite kann man folgende Optionen auswählen:
raster overview
clean nodes
clean ways
harmless nodes
harmless ways
modified nodes
modified ways (centrepoints)
modified ways
created nodes
created ways (centrepoints)
created ways
Leider kann ich damit nichts anfangen. Kann es mir das bitte jemand erklären oder gibt es irgendwo eine deutschsprachige Beschreibung.
Vielen Dank
Ciao Holger
clean dürfte alles mit einem odbl=clean sein
harmles ist alles, was Frederiks Skript als harmlose Probleme einstuft, also wenn der Ablehner nur ein createdby gelöscht hat oder allgemein: Alle Änderungen, die kein Werk darstellen
modified ist alles, was von einem Zustimmer erstellt wurde und dann von einem Ablehner bearbeitet wurde
created ist alles, was von einem Ablehner erstellt wurde.
Übrigens in Weimar hab ich nur die wesentlichen Gleise neu erfasst.
created = Erstersteller des Objekts hat noch nicht zugestimmt.
created nodes brücksichtigt aber keine mittlerweile verschobenen Knotenpunkte
created ways berücksichtigt nicht, dass die erste Version möglicherweise ein namenloser GPX-Track war.
modified = Erstersteller hat zugestimmt, ein (Noch)Nichtzustimmer hat nachher daran gearbeitet
modified nodes = Erstersteller hat zugestimmt, (Noch)Nichtzustimmer hat verschoben
modified ways = Erstersteller hat zugestimmt, (Noch)Nichtzustimmer hat Eigenschaften ergänzt
harmless = (Noch)Nichtzustimmer hat FIXME oder created_by entfernt
clean = es gibt noch keine eindeutige Definition, ob z.B. manuell verschobene Knotenpunkte oder ursprünglich namenlose Wege als clean bezeichnet werden dürfen. Die Hardliner in der LWG fürchten sich vor einem Gerichtsurteil.
Unsinnige Beispiele (Knotenpunkte wurde schon bis zu 82mal verschoben, aber der Erstersteller ist vielleicht schon gestorben und seine Witwe hat das Passwort vergessen) gibt es massenweise!
modified = Erstersteller hat zugestimmt, ein (Noch)Nichtzustimmer hat nachher daran gearbeitet
modified nodes = Erstersteller hat zugestimmt, (Noch)Nichtzustimmer hat verschoben
modified ways = Erstersteller hat zugestimmt, (Noch)Nichtzustimmer hat Eigenschaften ergänzt
harmless = (Noch)Nichtzustimmer hat FIXME oder created_by entfernt
FIXME, created_by usw. sind sogenannte Anmerkungen.
Die gehören nicht zum eigentlichen (Gemeinschafts)Werk.
Das ist wie ein Hafti am Bildschirm mit irgendeiner Notiz.
created_by ist darüber hinaus in der Regel eine automatisch erstellte Anmerkung und genießt schon dadurch keinen Urheber-Schutz.
Diese Anmerkungen müssen also nicht zurückgesetzt werden.
Das gilt auch für Löschungen (z.B. von Taggs) von Nichtzustimmern.
Derartige Fragen kann noch niemand mit Gewißheit beantworten, weil die Regeln für die Umstellung noch nicht feststehen. Nach gesundem Menschenverstand jedoch: nein. Deswegen werden Objekte, an denen (Noch-)Nichtzustimmer nur “triviale” Bearbeitungen (u.a. die obengenannten) vorgenommen haben, in OSMI ja auch als “harmlos” gekennzeichnet. In den “modified”-Fällen ist davon auszugehen, daß die betroffenen Objekte auf einen früheren Stand zurückgesetzt werden und dann versucht wird, noch soviel wie möglich von späteren Bearbeitungen zu retten, die unabhängig von den Modifikationen des (Noch-)Nichtzustimmers sind.
Beispiel: Zustimmer1 erstellt amenity=pub, Nichtzustimmer1 ändert dies zu amenity=restaurant. Zustimmer2 ergänzt name und opening_hours, Zustimmer3 smoking und wheelchair, Zustimmer4 aktualisiert opening_hours. Dann würde mutmaßlich, s.o., amenity=pub wiederhergestellt, aber die nachfolgenden Änderungen von Zustimmer2 bis Zustimmer4 als unabhängig von der Bearbeitung durch Nichtzustimmer1 angesehen und blieben erhalten.)
Wenn ich mir die Tortengrafiken unter der Karte auf http://osm.informatik.uni-leipzig.de/map/ ansehe, habe ich allerdings den Eindruck, daß so komplizierte Beispiele wie von mir gerade konstruiert doch eher selten sein werden. Rein zahlenmäßig sind die meisten Objekte entweder von Zustimmern oder von Ablehnern/Unentschiedenen/Unerreichten bearbeitet worden, nur ein sehr kleiner Teil hat eine gemischte Historie. Da sollte es doch möglich sein, den Umstellungsbot so zu optimieren, daß möglichst wenig “Kollateralschäden” entstehen, obwohl unter den Knoten natürlich besonders die “wertvollen” Objekte, sprich POI, besonders betroffen sein werden, weil die einfach häufiger bearbeitet werden als schnöde Wegknoten.
(Mir ist klar, daß die Tortengrafiken nicht alles sind, aber es handelt sich um die kompakteste und verständlichste Darstellung des Sachverhalts. Und klarerweise haben die reinen Wegknoten in der Torte ein großes Gewicht, sodaß die von Mehrfachbearbeitungen betroffenen POI-Knoten in der Grafik stark unterdrückt sind. Dennoch zeigt sich, daß die “gemischte Historie” insgesamt relativ selten ist - aber natürlich werden POI sowie wichtige Straßen und große Relationen davon besonders betroffen sein, vgl. http://odbl.poole.ch. Routenrelationen für Autobahnen und Bundesstraßen etwa sowie Grenzrelationen >= Bundesland-Ebene werden wir wohl komplett abschreiben können, egal wie ausgefuchst der Umstellungsbot letztlich programmiert wird.)
Deshalb wird ja auch vorher dazu aufgerufen, die Daten neu zu erfassen…je weniger der Bot am Ende machen muss, desto geringer ist die Anzahl an Fehlern die er macht. Sei es dass er nun zu viel löscht oder veraltetes wieder als aktuell rauskramt.
Die von dir angesprochen Tortengrafik bezieht sich nur auf Straßen und Wege.
Häuser, Landflächen, Gewässer, Relationen und vieles andere mehr sind dort gar nicht enthalten.
Sehr viel aussagekräftiger finde ich die Statistik von Frederiks QuickHistoryService.
Die ist zwar nicht ganz so kompakt, aber dafür werden alle OSM-Objekte betrachtet.
Und man klar Tendenzen in der Entwicklung erkennen.
Interessant sind auch die allgemeinen Statistiken und zum Alter von OSM-Objekten.
Hm, bist Du da sicher? Die Karte stellt nur Straßen, Wege und Bahngleise dar, aber gilt das auch für die Tortengrafiken? Aus der (veralteten) about-Seite wird mir das nicht wirklich klar. Zumal es einfacher wäre, die Daten ungefiltert zu importieren und dann nur bestimmte Objekte zu rendern als erst zu filtern.
Die sind in der Tat interessant, danke für den Hinweis. Vor allem die Abnahme der Anzahl problematischer Objekte fällt stärker aus als ich erwartet hätte. Da tut sich anscheinend mehr als ich dachte. Fehlt bloß eine Aufschlüsselung analog zu den Torten…
Oder meinst du nach Ablehner/Unentschieden ? Im Endeffekt spielt das keine Rolle da beides zum gleichen Ergebnis führt.
Betreffs “Tendenzen in der Entwicklung erkennen” würde ich noch 3 Wochen abwarten mit einer Einschätzung. Aber wenn es in dem Maße weiter gehen würde bis April sieht es echt passabel aus…
Also ich habe jetzt schon ein paar Sachen gesehen die auf der Inspektor Seite mit rotem Kringel markiert sind, diese stammen aber allesamt von Zustimmern.
Hast Recht, steckt eigentlich schon alles wichtige drin, hatte ich noch nicht komplett überblickt. Höchstens noch die Entwicklung “sauberer Altdaten” wäre evtl. zum Vergleich interessant.
Das kann verschiedene Gruende haben. Erstmal koennte der OSMI einen Bug haben.
Dann gibt es aber auch ein bekanntes Problem mit Leuten, die erst kuerzlich aus der Anonymitaet aufgetaucht sind; deren Beitraege sind dem OSMI noch als “Beitrag eines anonymen Nutzers” bekannt und muessen in einem relativ aufwendigen Prozess dem nun-nicht-mehr-anonymen User zugeordnet werden. Sowas erkennt man daran, dass der OSMI behauptet “userid: 0”. Wenn man dann auf den Detail-Link (Uhr) klickt und sieht, dass alle zugestimmt haben, ist die Sache ok und man kann es ignorieren (ich arbeite daran, dass das vernuenftig angezeigt wird).
Schliesslich ist es auch denkbar, dass die betr. Person erst vor wenigen Stunden zugestimmt hat und der OSMI, der nur einmal am Tag aktualisiert wird, noch alte Daten hat. Im “worst case”, wenn man gerade vor der Aktualisierung morgens um 7 draufschaut, kann das, was man sieht, 30 Stunden alt sein.
Wenn es unerklaerliche Faelle gibt, freue ich mich ueber eine E-Mail an frederik@remote.org, um die genauer untersuchen zu koennen.