Full History Planet Daten von Zustimmern filtern

Es gibt derzeit kein Tool was Full-History in irgendeiner Weise unterstützt.
Auf der Fossgis gabs aber einen Vortrag zu dem Thema. Evtl. fragst du mal bei dem Vortragenden (MaZderMind) an.

Darf ich versuchen, Dein Anliegen um 180° zu drehen?

Wenn Du eine Karte gezeichnet hast, so wie sie aussehen würde, wenn alle Daten von Nicht-Zustimmern gelöscht werden würden, wäre das absolut genial. Aber der Nutzen davon dürfte leider begrenzt sein. Ob die Karte nachher 80% oder 90% oder 99% darstellt, man würde den Unterschied gar nicht mehr erkennen können. Man könnte höchsten, die letzten Zweifler beruhigen damit.

Mein Vorschlag: Zeichne eine Karte von dem, was gelöscht wird. Hier musst Du auch wesentlich weniger rechnen und filtern. Hat ein Way nur Zustimmer, wird er unsichtbar gemacht. Hat ein Node nur Zustimmer, wird er unsichtbar gemacht. Alles, was jetzt sichtbar ist, ist von einer Löschaktion betroffen. Man könnte noch Farblich trennen, ob ein Objekt ganz verschwinden würde (v1=Ablehner) oder nur auf einen alten Stand gesetzt wird (v1=Zustimmer). Aber alles, was angezeigt wird, wäre von einer Löschung betroffen. Ist ein Gebiet am Ende "Leer", dann wird hier auch nichts gelöscht. Relations könnte man auch grafisch als "Wolke" darstellen, wobei große Relationen sicher unübersichtlich werden dürften.

Dann hat man eine schöne Karte die man nutzen kann um seine Arbeit als "Anti-Löscher" zu beginnen. Man kann seine Heimat öffnen und alle Straßen die angezeigt werden löschen und mit GPS neu vermessen. Bzw. in seiner Heimat hat man ja schon 100% GPS Erfassung, man muss also nur die Straße löschen und neu Zeichnen. Oder falls einzelne Nodes der Straße betroffen sind, kann man den Node einfach komplett löschen und bei Bedarf einen neuen Node zu setzen.

Etwas ähnliches wird hier: http://osm.informatik.uni-leipzig.de/schon versucht, was jedoch die 6 Farben bedeuten wird nicht erklärt. Nur Grün,Rot und Blau wird erklärt. Außerdem werden "Gute Wege" mit angezeigt.

Falls Du Dein Vorhaben doch umsetzen möchtest, hast Du zwei Möglichkeiten:
1) Jeden Node rückwärts auf eine alte Version zurückspielen, solange bis er ODBL ist. Gggf. V1 Objekte dann löschen.
2) Eine Leere Datenbank aufsetzen und ODBL-Objekte dort rein kopieren. Nicht-ODB-Objekte überspringen.

Ich persönlich würde (2) als den einfacheren Weg bezeichnen, aber vermutlich auch den, der mehr Rechenpower braucht.

Also schlussendlich wird man ja sowas brauchen für die Umstellung (wenn man das nicht direkt in der DB machen will), also wenn du schon so was machst, wäre die Community sicher dankbar wenn möglichst viel Gehinschmalz in das Ausfiltern von Edits die wir nicht mitnehmen können hineinsteckt wird, so dass wir ein realistische Resultat bekommen und gegebenfalls am Algorithmus/Heuristic noch nachbessern können.

So seh ich nicht ein, wieso ein Objekt zwangsläufig auf den Zustand vor dem ersten nicht Zustimmer-Edit zurückgesetzt werden muss, sondern man muss halt je nachdem entscheiden ob man ein Zwischenstand herausnehmen kann oder nicht.

Z.B. ein way

v1: highway=residential
v2: highway=residential maxspeed=50
v3: highway=tertiary maxspeed=50

wenn die Ersteller von v1 und v3 zugestimmt haben, sehe ich nicht ein wieso man den way nicht einfach auf v3 ohne die Änderungen von v2 setzen kann. Das war jetzt mit Absicht ein trviales Beispiel, es gibt natürlich Edits die von einander abhängen die dann nicht so einfach gehen.

Ein heisses Eisen dürften Positionsänderungen von Punkten sein, sind die sequentiell abhängig von einander oder nicht?

Simon

ich habe mal an woodpeck geschrieben. Er nutzt ja eine DB mit Full History für den OSM History Service. Vielleicht stellt er ja ein ODbL (oder invers ODbL) Extrakt bereit. Das würde es ungemein vereinfachen. Als ich gelesen habe wie groß der Full History Planet ist, wurde mir gleich ganz anders 😉

Entpackt sind es 450GB 😎

okay, hat sich erledigt. In nächster Zeit wird es dazu einiges geben

Nur mal zum Verständnis:
Wäre es nicht einfacher und auch schneller eine "lokale" Datenbankabfrage zu machen? Allein der Download und das Entpacken von xx GB....
OT: Mich wundert z.B. auch, warum ein Bot "Strasse" in "Straße" umwandelt. So eine Änderung wäre mit Datenbankmitteln doch schnell erledigt.

MoinMoin,

DennisB wrote:

Etwas ähnliches wird hier: http://osm.informatik.uni-leipzig.de/schon versucht, was jedoch die 6 Farben bedeuten wird nicht erklärt. Nur Grün,Rot und Blau wird erklärt. Außerdem werden "Gute Wege" mit angezeigt.

Super Link 🙂

Damit kann das Re-Lizenzierungsprogramm (Alles was nicht grün ist neu efassen) zuminderst bzgl. Wege sofort gestartet werden! 😉

Ciao,
Frank

PS
Wie ich mir anhand einiger Weg-Historien bei uns angeschaut habe handelt es sich bei den "Mischfarben" wohl um eine UND-Bedingung, z. B. türkis steht für eine Bearbeitung eines Weges sowohl durch einen Zustimmer als auch durch einen anderen Mapper, der sich noch nicht entschieden hat. Lila/Gelb entsprechend.

Ich will ja nichts sagen, aber wenn man mal runter scrollt, sind da doch alle sechs Farben erklärt...

errt wrote:

Ich will ja nichts sagen, aber wenn man mal runter scrollt, sind da doch alle sechs Farben erklärt...

Wollte vorhin schon was dazu schreiben, was nicht mehr klar ist, im Vergleich zur alten Version, ist ob die "Mischfarben" primär durch den Ersteller des Objektes bestimmt sind: also z.B. Gelb -> Ersteller hat zugestimmt, Bearbeiter abgelehnt.

Simon

Die ODBL-Daten sind angebl. von heute (1.5.11), aber ich sehe viele Straßen "ohne" Farbe, z.B. unclassified/residential in Weiß. Was ist damit? Ist der Datenbestand drunter älter?

amai wrote:

Die Daten sind angebl. von heute (1.5.11), aber ich sehe viele Straßen "ohne" Farbe, z.B. unclassified/residential in Weiß. Was ist damit? Ist der Datenbestand drunter älter?

Nein der Datenbestand darüber ist älter, der darunter ist neuer.

Ok, meine Interpretation des Begriffes ("Daten") habe ich durch mein Edit in der Frage etwas spät klassifiziert, aber ich verstehe das unterschiedliche Referenzdatum.

Ich schaue gerade auf einen Weg mit 2 Versionen: der Ersteller stimmte zu, der Bearbeiter (Querstraßen ergänzt, also Nodes) nicht. Der Weg ist komplett in "Zustimmergrün" gefärbt. Wenn nun die OSM-Daten älter sind, erklärt sich das vermutlich.

amai wrote:

Ok, meine Interpretation des Begriffes ("Daten") habe ich durch mein Edit in der Frage etwas spät klassifiziert, aber ich verstehe das unterschiedliche Referenzdatum.

Ich schaue gerade auf einen Weg mit 2 Versionen: der Ersteller stimmte zu, der Bearbeiter (Querstraßen ergänzt, also Nodes) nicht. Der Weg ist komplett in "Zustimmergrün" gefärbt. Wenn nun die OSM-Daten älter sind, erklärt sich das vermutlich.

Um das ganz klar zu machen (soweit ich das ueberhaupt kann): die ODbL-Status-Daten (user_agreed.txt etc) sind aktuell, die Daten aus dem der Overlay generiert hat sind älter und auch älter als die Daten für die darunterliegende Tiles.

Simon

Ah, es gibt eine Scrollleiste auf einer Full-Screen-Seite. Und das Mausrad zum Scrollen ist durch die Full-Screen-Karte natürlich deaktiviert für das Scrollen der Seite. Man muss wirklich ganz explizit das Mausrad NICHT verwenden sondern die Scrollleiste. Thx, ich habe die Farben gefunden.