ODbL Zustimmung /ODbL Agreement rate

Ja funktioniert. Dabei bedeutet gelb: Mindestens ein Bearbeiter hat sich noch nicht entschieden und rot mindestens ein Bearbeiter hat (bis jetzt) abgelehnt.

Leider wird nicht nach Version 1 oder spätere Version problematisch unterschieden.
Das wäre allerdings wichtig, da es doch einen großen Unterschied macht, ob ein Objekt wahrscheinlich gelöscht werden muss oder ob ein Objekt verändert werden muss aber als Objekt (eventuell unvollständig oder mit Fehlern) erhalten bleiben kann.

Edbert (EvanE)

Im JOSM Plugin ist das dann enthalten. Da gibts

  • Data Loss (Creater has rejected CT)
  • Possible Data Loss (Creator has not (yet) accpeted CT)
  • Data Reduction (Object modified by user(s) who have rejected, or not agreed to, CT)

Genauso habe ich mir das vorgestellt. Wann wird das allgemein verfügbar sein?
Bei Objekten, die einen interessieren, immer die Versionsgeschichte ansehen, kann ganz schön lästig sein.

Edbert (EvanE)

Die Versionsgeschichte wird trotzdem wichtig bleiben. Ich spiele gerade damit rum. Ich habe hier eine Straße, die von einem Ablehner erstellt wurde. Die Edits danach waren gemischt. Der Ablehner hat die Straße nur als residential (ohne Namen) angelegt. Mittlerweile hat sie Namen und Maxspeed Tags. Jetzt muss man bei jedem Tag schauen, ob es von einem Zustimmer eingegeben wurde. Eins erscheint mir komisch. Oft sind Straßen “sauber”, aber die Nodes drunter stammen manchmal komplett von Ablehnern. Ich weiß nicht, wie das geht.

Wann das Plgun kommt, weiß ich leider nicht. Ich habe es mir selbst komiliert.

Das ist mMn der Fall wenn eine Straße geteilt wurde (z.B. beim hinzufügen von maxspeed).

Gruß BBO

… oder beim Vereinigen.
Solange beides etc. nicht berücksichtigt wird, sind sämtliche Tools ein Muster ohne Wert

Knoten kann man nicht vereinigen/trennen.
In dem Punkt ist das Tool also sauber. Wobei man natürlich fragen kann, ob eine Menge an Knoten (nur Koordinaten, keine Taggs) überhaupt eine Schöpfungshöhe besitzten. Genauso, das Verschieben von Knoten unter den gleichen Bedingungen.

Endlich kann man Probleme durch die Ersteller sichtbar machen. Dass dabei noch nicht alle möglichen Kombinationen abgedeckt sind, ist für eine Software in einem so frühen Stadium schlicht nicht zu vermeiden. Schliesslich hat die OSMF resp. die LWG noch nicht einmal entschieden, was als triviale Edits anzusehen ist, wie mit dem Verschieben von Knoten oder ganzen Objekten zu verfahren ist oder wie mit Änderungen von Eigenschaften umgegangen werden soll. Insbesondere wie mit dem Trennen/Vereinen von Wegen umzugehen ist, wurde noch in keiner Weise festgelegt.

Insgesamt empfinde ich deine Haltung als ausgesprochen negativ. Statt dich zu freuen, dass es endlich ein Tool gibt, mit dem man wenigstens einen Teil der Probleme anzeigen kann, meckerst du nur rum, was das Tool noch(!) nicht kann. Ich finde es gut, dass es jetzt eine Basis gibt, auf der man aufbauen kann und die man in absehbarer Zeit sicher auf speziellere Fälle erweitern kann. Aber ohne eine solche Basis als Ausgangspunkt hätte man heute noch gar nichts.

Dass die OSMF/LWG sich zu vielen Punkten noch nicht festgelegt hat, kann man sicher als ungünstig betrachten. Aber einer neuen Software vorzuwerfen, dass sie diese Punkte noch nicht abdeckt, obwohl es noch keine Festlegung gibt, ist schlicht fehl am Platz.

JM2C
Edbert (EvanE)

Soweit ich weiss, ändert sich beim Verschieben einer Straße (oder Teile davon) die Version nicht, da ja ein way nur die ID der nodes enthält und die ändern sich ja nicht. Die nodes bekommen jedoch neue Koordinaten und daher auch eine neue Version.

Edit: Ich habe im Wiki noch die Bestätigung gefunden: http://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps#The_Problem

Tschau, Andreas

Es ging bei SunCobalt darum das Ways sauber sind, die darunter liegenden Knoten aber nicht. Daher bezieht sich das vereinigen trennen sicher auf die Ways und nicht auf die Knoten.
Ja jetzt wirds spannend. Wenn ich also einen Knoten einfüge, dann ist das trivial. Das kann man ja so auslegen, dass alle edits in OSM trivial sind. Denn jeder hinzugefügte Knoten ist trivial. Erst in einem zweiten Schritt wird dem Knoten ein Tag gegeben. Also mit dieser Interpretation bin ich nicht einverstanden. Denn das würde heißen alles außer importe ist perse trivial.
Ich muss Mueck auch rechtgeben, dass wenn man nicht berücksichtig ob das Objekt aus einer Teilung oder Vereinigung hervorgegangen ist, nicht entscheiden kann ob der Way sauber ist oder nicht. Ich bin sicher auch Besitzer einiger Straßen nachdem ich ÖPNV routen eingefügt habe.
Das nächste Problem ist was passiert wenn man POIs aus Knoten in Flächen umwandelt und dann die Tags kopiert und den Knoten löscht? Dann scheint der Way auch sauber zu sein. Und wenn das über mehrere Changesets geschieht ist es eigentlich gar nicht nachvollziehbar.
Ich hatte auch an anderer Stelle bereits beschrieben, wie ein Objekt wechselseitig aufgebaut werden kann. Hat man dann keine Rechte mehr, weil jeder einzelne Edit an sich trivial war?

Das ist aber auch andersrum so. Wenn ein Ablehhner ein Gebäude einzeichnet und die POI Tag vom Node an den Way des Gebäudes kopiert. Es würde dann in der nächsten Phase das Gebäude gelöscht werden ohne das der Node wieder hergestellt wird. Ich denke in Summe gleicht sich das aus oder ist gar leicht zum Vorteil der Ablehner, die diese oft überdurchschnittlich aktiv waren.

Ich halte es wie Evan. Weniger rummeckern und mehr mappen. Dadurch verringert sich der Datenverlust wesentlich besser als durch monatelanges Rummeckern.

Können die Ablehner eigentlich heute noch editieren?

Unrecht mit Unrecht auszugleichen war 1. Selbstjustitz und 2. noch nie haltbar vor Gericht.
Wenn du nochmal lesen möchtest was Frederik geschrieben warum das Plugin noch nicht leichtzugänglich ist:

Ich glaube wir reden aneinander vorbei. Mir gefällt es ebenso wenig wie Dir. Aber ich bin Pragmatiker und versuche, die Probleme zu lösen. Das ist in meinen Augen leichter als an den Ursachen etwas zu ändern.

Ablehnende User können ja immernoch Daten hochladen. Bspw hier
http://www.openstreetmap.org/user/balrog-kun/edits
ID laut hier http://odbl.de/planet-latest.html ist 20587
und er steht immernoch in users_disagreed.txt
http://planet.openstreetmap.org/users_agreed/users_disagreed.txt

Er scheint selber davon überrascht, denn ein Changesetkommentar ist “More builings tracing from Bing to test phase 4 implementation.”

Gut, die zugehörigen LWG-Minutes sagen ja eigentlich auch nur “the switch to be thrown this Sunday June 19th or as soon thereafter convenient to technical volunteers”. Scheint also halt nicht passiert zu sein. Denn technisch sollte das ja kaum schiefgehen.

Vielleicht geschieht dies auch erst mit dem Serverumzug.

Gut, dann wähle ich bei der nächsten OSMF Wahl jemanden, der eine besserere Kommunikation verspricht. Nee halt, das ging schonmal daneben.

Potlatch 2.2 ist gerade Live gegangen. Unter anderen mit den folgenden Features

  • Elements where version 1 was created by someone who’s declined
    ODbL+CT: solid red
  • Elements where a later version was edited by a decliner: transparent red
  • Elements with a version edited by someone who hasn’t decided yet:
    transparent orange

Da man für den Serverumzug am Donnerstag (23.6.2011) die API sowieso abschalten muss, wäre das sicher ein passender Zeitpunkt. Andererseits ist der Sonntag noch nicht vorbei.
Wie auch immer, die paar Tage kann ich noch abwarten.

Edbert (EvanE)

mich würde es ja auch nicht stören, wenn es erst in 2 oder meinetwegen 4 Wochen ist. Mich stört nur, dass keiner was sagt

Ich halte es fuer eher unwahrscheinlich das es mit dem Serverumzug zusammen faellt, da das zwei unabhaengige Dinge sind.

Um Phase 4 frei zu schalten benoetigt es lediglich eine config variable zu aender ( http://git.openstreetmap.org/rails.git/blob/HEAD:/config/example.application.yml#l73 ) und dann den Server neu zu starten.

Solche neustarts geschehen die ganze Zeit um neuen code einzuspielen. Z.b. vor ein paar Stunden um Bugfixes in Potlatch 2.2 einzuspielen oder vor einer Stunde um die OpenID Logos auf der login Seite zu verbessern

Der Serverumzug hingegen ist ein echter Umzug, wobei die Server abgebaut werden, dann per Auto quer durch die Stadt gefahren und in einem neuen Rechenzentrum wieder aufgebaut werden muessen. Ein echter Umzug halt. In der Zeit kann man also an der Software ohnehin nichts aendern.