ODBL: Dirty Map Realisierung

Hallo,

die letzte Phase vor der finalen Löschung startet ja bald. Und mir kam da ein Gedanke…eigentlich schon vor einer Weile. Wie wäre es, wenn man eine “Dirty” Karte hätte, die nur Objekte anzeigt, die von Nicht-Zustimmern bearbeitet/erstellt wurden. Wozu das gut sein sollte, wird ja jeder wissen. Wir sollten ja schon versuchen, den Verlust zu minimieren.
Ich sehe da momentan zwei Möglichkeiten:

1.) Pre-Rendered Slippy Map
Ich hatte ja oben unter “Kleine Fragen” mal gestestet, was das bedeutet. Ich könnte momentan bis Zoom Level 13 hosten, eventuell bis Level 14 wenn ich das Hosting Packet von odbl.de erweitere. Es ist weniger die Speicherkapazität als die Anzahl der Dateien.

2.) WMS
Ein WMS würde theoretisch auch eine OL Slippy Map ermöglichen. Primär denke ich aber daran, dass als Hintergrund in JOSM zu benutzen.

So jetzt zu den Problemen. Generell habe ich nichts dagegen, wenn jemand sagt, ich finde die Idee toll und mache das jetzt alleine. Dann kann ich mich wieder zurücklehnen. :wink: Falls nicht, brauche ich Hilfe.

1.) Daten Filtern
Ich bin zu blöd um die Tools, die Frederik Ramm hier neulich als Ergebnis einer Diplomarbeit vorgestellt hat, zu benutzen. Kann da jemand eine IGA (Idiotensichere GebrauchsAnleitung) machen?

2.) Webspace für Pre-Rendered Tiles
Mir wäre es das wert, den Webspace zu erweitern um auf Zoom 14 zu gehen, aber dann zahle ich schon inkl odbl.de, Schwarzplan und eines bald startenden Projekts dreistellig pro Jahr. Eigentlich wäre Zoom 15 zum Arbeiten notwendig, also ca. 1,5 Mio Tiles und vielleicht 12GB Webspace. Das ist erstmal nur eine Schätzung, ich hatte das mal mit ca. 250.000 Tiles gemacht, das waren ca. 2GB. Hat jemand Webspace über? Beim Rendern dachte ich an Maperitive. Die Datenmenge der “dirty” Objekte sollte ja hoffentlich nicht so groß sein.

3.) WMS für Nutzung mit JOSM
Eigentlich bräuchte man einen richtigen Server dazu. Hat jemand einen? Notfalls stelle ich einen. Der wäre dann aber ziemlich langsam, vor allem wenn mehrere drauf zugreifen und noch odbl Stats berechnet werden. Auch fällt der so alle 1-2 Monate mal aus weil das Netzteil einen Wackelkontakt hat.

Wie auch immer sich das entwickelt, mag jemand mithelfen das ein wenig zu treiben? Ideen, Tipps, CPU, Webspace…alles ist willkommen. Mir ist nur wichtig, nicht eines Tages neben einem großen Loch in der Karte aufzuwachen.
Einen Full Blown Server mit Postgres/PostGIS und Mapnik + Mapserver wäre natürlich das beste, aber das ist Träumerei.

Danke schonmal
P.S. Ich würde darum bitten, hier keine Lizenzdiskussion zu führen.

Also die Idee finde ich sehr gut. Webspace gibt es kostenlos. Jedenfalls wenn man keine Datenbank braucht. Bei http://www.square7.ch/ gibts immerhin 7 GB. Weitere Accounts anmelden ist kein Problem. Ajossen hat schon Erfahrungen gemacht mit dem Upload von vielen Tiles.
Allerdings sollten die Tiles dort in eine Website eingebunden sein.

Super Idee!

Das Problem hatte ich mit meinen Karten auch. Zu wenige Inodes, gell? Da hilft nur, die Platte anders zu formatieren. Geht aber meist nicht, wenn man einen Virtuellen Server verwendet, so war das auch bei mir. Eine andere Alternative ist, “Metatiles” zu nutzen, also z.B. 16 Tiles in einer .png-Datei zu speichern. Hab ich nicht hinbekommen, aber das heißt nix. Vielleicht magst du es mit deinem System mal probieren…
Ansonsten: eventuell aufstocken. Beispielsweise 3000 inodes und 50 GB Webspace (virtueller Server mit root-Zugriff) gibts für ca. 13 Euro im Monat.

Wenns nicht zu aufwändig ist, schreib ich einen Filter dafür. Was genau wäre zu filtern?

Unterschreib ich sofort. Ich respektiere beide Ansichten, beide haben ihre Berechtigung, und für beide gibt es Pro- und Contra-Argumente.

Es geht darum Objekte anhand des Erstellers zu filtern. und zwar je nach Auslegung. Nur Ablehener oder überwiegend Ablehner oder der letzte Bearbeiter gleich Ablehner. Alles andere kann eigentlich drinbleiben und wird dann beim Import in die Datenbank gefiltert. Alternativ kann man sich aber auch einen Kartenstil überlegen und dann die unnötigen Elemente gleich mit entfernen.
Interressant wäre ein Programm zum einlesen von o5m in eine Postgisdatenbank. Dann kann man aus einem PBF gleich ein o5m erstellen, filtern und in die Datenbank schieben.
http://wiki.openstreetmap.org/wiki/Planet.osm/full

Guter Anfang…einfach ALLE Objekte (rein)filtern, die von Nicht-Zustimmern (Ablehnern, Nix-Sagern) angefasst wurden, also deren ID nicht in users_agreed steht und nicht über xxx(hab ich gerade nicht im Kopf) ist und in der History des Objekts des Full-History-Planet stehen. Wenn Du das schreibst, wäre die Möglichkeit toll, ein Bounding Polygon (notfalls eine BBox) anzugeben. Dann können andere Länder das auch nachmachen.

Die Arbeit von Zurzeit-Ablehnern zu löschen und einfach umzulizenzieren, fällt wohl unter Vandalismus!

Ehrlich gesagt würde ich jedes Objekt als “dirty” betrachten, das je ein NIchtzustimmer angefasst hat. Das macht uns unabhängig von den späteren OSMF Definition. Wenn der Output eine “normale” *.osm Datei ist, kann man die in PostGIS laden oder sonstwas damit machen…notfalls auch mit Osmosis schneiden und schauen, wo in dem interessanten Bereich da etwas zum neu erfassen ist.

Hattest Du mein P.S. überlesen? Ob das Neuerfassen Vandalismus ist oder nicht (ich sehe das anders), können wir gerne in einem anderen Thread klären

Das wäre die Aufgabe von dieser OSMF und Stefan Küste gewesen. Millionen Doller einsacken und am ende zahlt wieder Deutschland :frowning:

Hallo Thomas

Das halte ich für zu kurz gegriffen.

Meiner Meinung nach sollte nach Erstellen und Ändern auf jeden Fall unterscheiden.
Ebenso nach “hat abgelehnt” und “hat sich (bisher) nicht entschieden”.

  • Ersteller hat abgelehnt ==> Objekt muss wahrscheinlich gelöscht werden.
  • Ein oder mehrere Bearbeiter haben abgelehnt == Objekt muss geändert werden.

Weiter muss man wohl unterscheiden zwischen trivialen Edits (z.B. created_by gelöscht, Punkt um weniger als 1m verschoben), die nicht entfernt werden müssen und anderen nicht trivialen Edits. Sicher wird bei ablehnenden Bearbeiter nur deren Änderung entfernt. Alles andere wäre eine Missachtung aller folgenden Bearbeiter.

Das ganze Thema ist eine Schlangengrube und keineswegs mit einer Hauruck-Methode zu lösen.

Übrigens gibt es bereits eine Visualisierung nach “Zustimmung”, “keine Äußerung”, “Ablehnung” (zugegeben nur für Wege) von Fabian Schmidt unter http://osm.informatik.uni-leipzig.de/map/.
Kann man auf dessen Arbeit nicht aufbauen und diese wo notwendig verfeinern und erweitern (Häuser, Wasser, …)?

Das Ergebnis als WMS/TMS für Editoren zur Verfügung zu stellen, ist natürlich ein neuer Aspekt.
Allerdings frage ich mich, ob es nicht sinnvoll(er) wäre, (zusätzlich) das Versionsprotokoll von JOSM um die Zustimmung der einzelnen Bearbeiter zu erweitern. Damit kann sich jeder sein eigenes Urteil bilden.

Edbert (EvanE)

Nicht, daß ich gegen so einer Karte bin, aber ein JOSM-Filter-Plugin soll bereits fertig sein. Man kann mit dem in JOSM die Wege entsprechend Filtern. Sobald Ablehner gesperrt werden (Phase 4/5) wird das veröffentlicht werden. Ich warte schon sehnsüchtigst drauf.

Hi Thomas,

ich halte von der ganzen Sache überhaupt nichts.
Das einzige, was damit erreicht wird, ist die Stillung einer verständlichen Neugier, was denn wohl wird, wenn die Umstellung -endlich- gemacht wird.
Aus dieser oder den verschiedene bereits vorhandene Auswertungen abzuleiten, was demnächst wohl fehlen wird, bring mir absolut garnichts.

a) ich soll/darf keine Rettungsaktionen machen
b) ich könnte mir bein Rumspazieren kritische Gegenden ansehen.
c) ich kann sonst sowieso nichts dran ändern

a+c sollte klar sein, b) kann ich immer noch machen - muss nicht gerade jetzt sein.

Ich halte das für eine sinnlose Verschwendung von Arbeitszeit, Ressourcen und sogar Geld für ein Projekt, nach dem in 6 Monaten kein Hahn mehr kräht.

Gruss
Walter

Alle bisherigen Auswertungen scheitern daran, dass die Versionsgeschichte nicht vollständig vorhanden ist, nämlich im Falle von Teilungen und Vereinigungen von Wegen.

Was mir bisher auch glaub noch nicht wirklich in Diskussionen begegnet ist:
Was wird aus Löschungen von Nichtzustimmern?
Wenn ein Mapper ein altes Objekt gelöscht und durch ein bis mehrere neue bessere Objekte ersetzt hat?
POI → building
einfache Straße / Bahnstrecke → getrennte Fahrbahnen / Gleise?

Eigentlich müsste bei der Relizenzierung der Zustand von vorher wiederhergestellt werden → altes Objekt wieder da → doppelt, wenn jetzt planlos rumgepfuscht wird anhand halbgarer Tools.

Und ohne die volle Versionsgeschichte incl. Teilungen/Vereinigungen ist der Relizenzierungsprozess angreifbar, weil ohne volle Versionsgeschichte Objekte drinblieben, die nicht drinbleiben dürften. Ein Tool zur Ermittlung der kompletten Geschichte MUSS m.E. zwingend kommen und dann sind sämtliche jetzigen Visualisierungen und Aktionen etc. für die Tonne. Trotz mehrfacher Nachfrage meinerseits (zuletzt anlässlich der Karlsruher Arbeit in talk-de) ist aber nicht bekannt, dass irgendwer schon an dieser hochwichtigen Sache arbeitet …

Ganz davon abgesehen hält der ganze Prozess explizit die Option offen, eine Ablehnung bis kurz vor Toresschluss umzuwandeln (umgekehrt geht’s nicht), demnach ist jegliche Aktion der diskutierten Art verfrüht.

Das Argument kann ich nachvollziehen. Bei der aufzubauenden Übersicht geht es aber nicht um rechtlich wasserdichte Verfahren, sondern um einen sehr groben Überblick. Wegteilungen und -vereinigungen sind im Vergleich zu übrigen Aktionen nicht sooo häufig und können für einen unverbindlichen Überblick vernachlässigt werden.

Vermeiden würde ich vor allem, auf aktuellen Full-History-Daten aufzusetzen. Sonst könnten manche Leute wirklich auf die Idee kommen, schon mal vorab rumzueditieren - im positiven und im negativen Sinn. Das wäre - egal welcher Meinung man bezüglich der Lizenz sein mag - der schlechtere Fall.

Wenigstens hat mich die Idee dieses Threads motiviert, mich mit dem Full-History-Format zu befassen. Die neue Version von osmconvert wird dann auch Full-History-PBFs lesen und in .o5m umwandeln können. Schadet schon mal nichts. Um den Filter kümmere ich mich auch noch - sofern gewünscht. Im Prinzip muss nur o5mfilter entsprechend angepasst werden.

Naja ich denke das ist gar nicht so selten. Wenn man ÖPNV Linien einbaut oder Höchstgeschwindigkeiten oder Oberflächen. Immer dann wird der alte Weg in ein oder mehrere getrennt.

Geschwindigkeits und Parkvorschriften, Breite, Höhenbeschränkungen, Anzahl Fahrspuren, Benutzungsvorschriften…
Alles Informationen die oft nachträglich erfasst werden und zur Aufteilung führen können, oder verloren gehen können wenn der Erfasser des Vektors nicht zustimmt.