Nun meine Antwort bezog sich nicht auf den Text von SunCobalt (der war nur für den Zusammenhang zitiert, genauso wie der von BBO) sondern auf den Text von Mueck: … oder beim Vereinigen. Solange beides etc. nicht berücksichtigt wird, sind sämtliche Tools ein Muster ohne Wert.
Unabhängig davon werden Versionen der Knoten durch teilen/vereinen von Wegen nicht geändert.
Ich habe ja explizit und bewusst Knoten (nur Koordinaten, keine Taggs) geschrieben.
Übrigens ist es nur beim Live-Edit von P1 üblich, zuerst nur die Koordinaten hochzuladen und dann weitere Versionen für alle Taggs zu erzeugen. Natürlich gibt es auch Fälle bei denen ein Knoten erst später Taggs erhält (klassisch z.B. barrier=gate). Aber ich meinte (offensichtlich nicht deutlich genug) natürlich Knoten, so wie sie aktuell in der Datenbank stehen, also inklusive aller ergänzten/geänderten Taggs.
Um es noch einmal klar auszudrücken:
Für Knoten die aktuell (und in ihrer ganzen Geschichte) keine Taggs außer den
impliziten Taggs wie Koordinaten/Version/User/User-ID/Timestamp/Visible/…?
oder created_by (in diversen Versionen) enthalten, kann man die Frage stellen,
ob sie überhaupt eine Schöpfungshöhe haben.
Denn Geokoordinaten sind Fakten und created_by=* wurde automatisch von den Editoren hinzugefügt.
Und Fakten und/oder Automatismen kann man schwerlich eine Schöpfungshöhe zurechnen.
Deine Interpretation erscheint mir willkürlich und greift in keiner Weise.
Natürlich sind die Probleme Vereinen/Teilen von Wegen und POI-Knoten ↔ Gebäude-POI noch nicht gelöst. Aber da muss sich die OSMF/LWG erst mal äußern, wie sie solche Fälle erkennen und behandeln will. Erst dann kann eine Software nach diesen Regeln solche Fälle handhaben und gezielt anzeigen.
Nur wegen des Fehlens dieser Funktionalität eine Software zu verdammen, obwohl die Regeln noch nicht festgelegt sind, dagegen verwehre ich mich.
Da wenn ich mich richtig erinnere bei allen Kandidaten im Manifesto stand das sie die Kommunikation verbessern wollen, hilft das nicht sonderlich bei der Entscheidung der Wahl.
Mich wird man wählen können. Ich räum bei diesem Sockenpuppentheather auf und entmachte Stefan Küste! Danach wird die neue EHIR Lizenz durchgeboxt und alles wird wieder sauber werden.
Wenn ich einen Umriss in der Natur oder einer Siedlung erfasse dann lege ich dazu Knotenpunkte geographisch fest die diesen Umriss begrenzen. Die Schöpfung beginnt dann wenn ich diesen Umriss nach meinem Ermessen festlege. Aus einem Umriss mit 14 Winkeln wird einer mit 6 Winkeln der die Form erkennbar und unterscheidbar wiedergibt, aber nicht der natürlichen/gebauten Form gleicht. Dies geschieht in der Kartographie bei jedem Umriss oder auch bei Wegverläufen im Laufe der Zeit, spätestens beim rendern/zeichnen. Dies sind dann Knoten ohne die oben genannten Tags die mit Sicherheit eine Schöpfungshöhe besitzen.
http://odbl.de/licensechange.zip
Darin enthalten ist das License Change Plugin von Frederik. Ins JOSM Plugin Verzeichnis kopieren. Es hat scheinbar noch einige Bugs aber eignet sich sehr gut, um sich einen Überblick über seine Gegend zu verschaffen. Vor Säuberungen kann man ja auch noch ein paar Tage abwarten.
Ob es mit josm-latest funktioniert, weiß ich nicht. Ich habe es mit beiliegender josm-custom benutzt. Da jetzt Phase 4 startet und die gleichen Funktionen in Potlatch live sind, wäre es auch an der Zeit, es für JOSM Nutzer bereitzustellen.
Sorry, ein Umriss ist ein Weg und darüber habe ich nicht geredet.
Wenn ein Zustimmer die Knoten erfasst aber nicht den Umriss als Weg und dann ein Ablehner den Umriss (=Weg im OSM-Sinn) erfasst, dann bleiben die Knoten isoliert erhalten und der OSM-Weg (=Umriss) muss gelöscht werden.
Jo…neue Wege werden als Datenverlust gekennzeichnet. → Objekte, die noch nicht hochgeladen wurden, sollte man ausschließen. Haben die im josm nicht eine negative ID? Dann sollte das kein großes Problem sein.
Da kann man in der Tat neidisch werden. Hast Du auch mal einen entsprechenden Auszug aus planet-full ausgewertet? Das ist nämlich manchmal für einige Überraschungen gut.
Ich habe mal für meine Umgebung gleich große Auszüge aus planet und planet-full erstellt und die Mapper mit ihren Beiträgen gezählt - also etwa das, was odbl.de auch macht, nur nicht so hübsch aufbereitet. Und aus 486 Mappern als letzte Bearbeiter wurden satte 1530 in der gesamten Bearbeitungshistorie. Die “1” vor “530” ist kein Tippfehler.
Meine Gegend ist zweifellos nicht repräsentativ (mit u.a. drei Staatsgrenzen, an denen schon hunderte Mapper herumgebastelt haben), einen Faktor drei wird man also nicht überall finden, aber der Blick in einen planet-full-Auszug lohnt m.E. in jedem Fall.
Dieser blinde Fleck von odbl.de & Co. ist natürlich bekannt, aber seine Größe hat mich doch überrascht. Warum werden so viele Mapper “übersehen”? Einen Grund hatten wir weiter oben in diesem Thread schon ausgemacht: Anfänger, die nur ein paar Punkte eingetragen haben, haben oft auch viele Fehler gemacht, welche nachfolgend jemand anders korrigiert hat, sodaß der Ersteller nicht mehr letzter Bearbeiter ist.
Es werden aber auch Mapper mit deutlich größeren Beiträgen übersehen. In meinem planet-full-Auszug gibt es z.B. 23 Mapper mit mehr als 100 Bearbeitungen (angefaßten Objekten), die im heutigen planet überhaupt nicht mehr auftauschen; davon fünf mit mehr als 500. (Zur Orientierung: der planet-full-Auszug zeigt insgesamt gut 500’000 Bearbeitungen.) Zwei Gründe dafür:
Frühe Versionen von Potlatch haben auch gleich alle Knoten eines Wegs “angefaßt”, auch wenn nur der Weg selbst bearbeitet wurde. Mapper A trägt einen highway=unclassified mitsamt allen Knoten ein; Mapper B macht mit Potlatch einen highway=residential draus, ohne einen einzigen Knoten anzufassen - und Potlatch macht ihn dennoch zu deren letztem Bearbeiter.
created_by-Putzaktionen. Unglücklicherweise haben frühe JOSM-Versionen buchstäblich alle Objekte mit created_by-Tags beklebt - und wer mit einer solchen Version gearbeitet hat, ist nirgends letzter Bearbeiter, wenn in der entsprechenden Gegend seitdem jemand systematisch created_by’s gelöscht hat.
Zu Punkt 2: Auch frühere Potlatch-Versionen (0.0x + 0.1x) haben an jedes Objekt ein created_by gehängt. Vor Einführung der Changesets mit API 0.5/0.6(? )schien das den Editor-Entwicklern wohl notwendig/sinnvoll. Nach Einführung der Changesets dämmerte es erst langsam, dass im Grunde ein created_by als Changeset-Kommentar reicht. Es hat aber eine Weile gedauert, bis sich das auch in den Programmen durchgesetzt hatte.
Punkt eins kannte ich noch nicht.
Es gibt noch weitere Gründe für mehr als eine Version eines Knoten:
LiveEdit Modus in Potlatch-1: Erstellen eines Knoten und Ergänzen von Tags werden jedesmal sofort hochgeladen, so dass ein Knoten mit 4 Taggs mindestens 5 Versionen hat.
Eintragen von rechtwinkligen Objekten PI-mal-Daumen. Ein Folgemapper macht das Objekt später dann rechtwinkelig (typisch mit JOSM). Damit haben alle Knoten des Objektes eine neue Version.
Zurechtrücken eines Objektes anhand besserer Luftbilder oder der relativen Lage zu anderen Objekten (z.B. Straßen / GPX-Spuren). Auch dabei erhalten alle Knoten neue Koordinaten und damit eine neue Version.
Wirklich an jedes? Bisher hatte ich den Eindruck, daß Potlatch nur bei Wegen und getaggten Knoten sein Revier markiert hat, nicht aber bei Knoten ohne Tags. JOSM hingegen hat auch da ein Gackerl hinterlassen.
Mit Deinen weiteren Beispielen hast Du natürlich vollkommen Recht, auch da verschwindet der Erstbearbeiter als letzter Anfasser (und evtl. auch aus den Statistiken); aber das sind für mich “echte” Edits, wo der spätere Mapper wirklich das betreffende Objekt bearbeiten wollte, während es sich bei dem Potlatch-Feature um eine “Nebenwirkung” handelt. Das war mir an einigen Wegen der deutsch-belgischen Grenze vor meiner Haustür aufgefallen, wo mehrere Leute den Weg umgetaggt haben, ohne einen einzigen Knoten zu bewegen, aber auch in der Historie der Knoten stehen. Ob das alle Bearbeitungen mit einer bestimmten Version betrifft oder nur unter bestimmten Bedingungen passiert ist, kann ich aber auch nicht erkennen.
Ich bin mir nicht wirklich sicher, glaube aber dass ich auch ungetaggte Knoten mit c_b=Px.x gesehen habe.
Allerdings finde ich auf die Schnelle kein Beispiel dafür.
Ja meine Beispiele sind “echte” Edits. Ich habe die vor allem erwähnt, weil die Auswirkung auf die History der Knoten möglicherweise vielen nicht bewusst ist.
PS: Mehr als 28 Millionen Knoten (rund 40%) haben noch ein created_by Tagg.
Vielleicht kann man die bei der Umstellung auf die ODBL Datenbank entfernen.
Zumindestens bei Knoten ohne Tagg und den großen Editoren Potlatch 1/2 *,
JOSM *, Merkaartor *, Mapzen * (jeweils über 1000 Nutzer)
Das sind Leute, die anonyme Edits gemacht haben. Davon sind die meisten anhand ihrer User-Id durchaus identifizierbar und können angeschrieben werden.
Ob die Leute heute noch an OSM interessiert sind und dann die notwendigen Schritte() unternehmen, um den ODBL/CT zuzustimmen, steht natürlich auf einem anderen Blatt. Solche anonymen Accounts müsste man eventuell gezielt anschreiben, da deren Prozedere() (falls sie zustimmen/ablehnen wollen) etwas anderes ist.
Ohne Entscheidung werden die dann behandelt wie jede(r) andere, der/die sich nicht entschieden hat.
(*) Anonymen Account auf nicht-anonym umstellen, dann der Lizenz zustimmen.
Ich sehe nicht, warum der erste Schritt nötig sein sollte. Die Datenbank weiß, wer welchen Edit gemacht hat, sie verrät es uns Normalsterblichen nur nicht. Und die Umstellung wird sicher direkt in der Datenbank selbst, nicht über die API abgewickelt werden, dabei kann also auf die Information zugegriffen werden.
Unschön ist halt, daß die Community anonyme Bearbeiter nicht kontaktieren (und etwa um ihre Zustimmung bitten) kann. Aber das ist nun mal das Grundübel anonymer Edits.
Wenn man sich in einen anonymen Account einlogt, dann ist der bertreffende User ausgesperrt, weil er noch den Status anonyme Edits hat. Man kommt dann zuerst auf eine Seite, mit der man diesen Status auf nicht-anonyme Edits umstellen kann. Erst danach ist die Seite für die Entscheidung ODBL/CT ja/nein überhaupt zugänglich.
So habe ich das irgendwann in der Mailingliste gelesen. Ob das so ist, kann ich mangels anonymen Account nicht nachprüfen.
Die Community kann User mit anonymen Accounts nicht erreichen, soweit ist das richtig.
Aber hinter dem Account (identifiziert durch die User-Id) steht wahrscheinlich trotzdem eine Mail-Addresse. Auf die haben Leute mit passenden Rechten sicher Zugriff. Die betreffenden User sind also im Prinzip (sofern die Mail-Adresse noch gültig ist) per Mail erreichbar.
bmog, die Nummer 9 in DE stimmt heute oder morgen wahrscheinlich auch zu. Es brauchte nur ein wenig Hilfe und Vermittlung. Nicht wegen der grndsätzlichen EInstellung sondern wegen eines Imports. Die Ablehner sind von 406 im Peak auf 390 gesunken. Das ist das erste mal, dass die Zahl der Ablehner sinkt wenn man es auf Wochenbasis sieht. Auch Australien ist nicht mehr so geschlossen. Sie interessieren sich nach dem Nearmap Statement auch für den Lizenzwechsel. In der letzten Woche habe ich 2 Mails von da bekommen wegen odbl.de Stats. Vorher gar nichts.