Trennen von Wegen, Vererbung der History

Das Thema ist nicht neu aber im Rahmen der “watch everything, everyone all the time and much as possible tools” immer wieder aktuell.
Problem:
Wenn ich z.B. Wanderwegerealationen anlege, muss ich öfters bestehende Wege oder Strassen zerschneiden. Aus 1 mach zwei und für den neuen Schnippsel wir ein neuer Teilweg angelegt. Hier werde ich dann als neuer Ersteller in der History geführt, der Ursrüngliche ist nur noch im laten Teil als solcher drin. Nun, dieses missfällt leider einigen Kollegen wohl, da:

  • die schöne Strasse einfach in zwei zerlegt wurde
  • Sie ggf. nicht mehr als Urheber der ursprünglechen Strasse im neuen Schnippsel geführt werden
    Frage:
  • Ist es nicht möglich die ursprünglichen Urheber beim zerschnippseln solche Wege, MPs oder sonstwas mit in den neuen Datensatz zu übernehmen?

Mir selber ist sowas ziemlich egal ob ich oder jemand anders als Urheber eines Weges gilt. Persönliche Performance Statistiken interessieren mich wie der umgefallenen Sack Reis in China und hab eine eigen Meinung dazu. Die sind sicher nicht im Sinne des Ganzen, aber es gibt sie nun leider mal und viele nutzen sie. Im Rahmen einer guten weiteren Zusammenarbeit und dem Erhalt der persönlichen Duftmarken sollte das irgenwie mal geregelt werden.

Nachtrag: Auch sehr beliebt ist dann immer, die neuen Wege wieder zu löschen und die alte Strasse entsprechend zu mit samt der Relation zu verlängern. Macht immer wieder Freude ständig die betroffenen Relationen entspechend zu “ent-igeln” und im Verlauf zu berichtigen.

Es braucht nicht einmal dein Eitelkeitsproblem. Wie man hier in dem Thread http://forum.openstreetmap.org/viewtopic.php?pid=481103#p481103 sehen kann, wäre das auch für Bereinigungen von “Konflikten” hilfreich.

Was mich eigentlich schon immer interessiert hat, wenn ich einen Weg zerschneide, wie wird die ID des Weges bestimmt. Einfach vergeben oder irgendwie berechnet aus der ID des Ursprungsweges?

Wenn an den Wegen als solches nicht herum gezerrt wird, müsste sich das durch die identischen Punkte irgendwie herausfinden lassen?

Nun, möglicherweise ist das der Kern des Problems. Ich errinnere mich noch schwach an eine Aktion vor etwa einem Jahr, wo dies von einem Kollegen angeführt wurde “damit geht auch die source verloren und es ist im Rahmen möglicher Rechtsstreitigkeiten wegen URV schwer zu belegen, woher und von wem dei Daten stammen”. Seinerzeit hatte ich es einfach ausgeblendet, (was will der von mir eigentlich Filter) mea culpa aber lösen kann ich das Problem leider selber nicht. Ich liefere nur “Natur” aber ob und wie hier SW zu erstellen ist, keine Ahnung.

Neue Wege bekommen im Editor eine temporäre (negative) ID. Beim Hochladen der Daten vergibt der OSM Server die ID. Dabei zählt er einfach von der größten, bisherigen way-ID um 1 hoch. Aus den IDs kann kein Zusammenhang hergestellt werden, man erkennt nur ob ein Objekt älter oder jünger ist.

bye, Nop

Die neue ID wird von der Datenbank als fortlaufende Nummer vergeben. Die API erfährt gar nicht, dass dieser Weg eine Abspaltung ist. Der Editor erzeugt einen neuen Weg über alte Punkte und eine neue Version des alten Weges. Diese neue Version unterscheidet sich von ihrer Vorgängerin dadurch, dass sie die entsprechenden Punkte nicht mehr enthält.

Jo, man könnte sich einen Punkt des neuen Weges suchen und nachsehen, ob der in früheren Versionen des alten Weges war. Dazu muss man aber in der Geschichte der Wege nachsehen, beim Punkt steht das nicht.

Mit der derzeitigen API sehe ich keine Chance, bestenfalls könnte man in irgendeinem Tag noch “ich bin eine Abspaltung von Weg xxx” unterbringen, aber spätestens bei der nächsten Teilung wird das echt mühsam… Die komplette History mit vererben (also: “ich spalte einen Weg der Version 8 und erzeuge vom alten Weg eine Version 9 und gleichzeitig einen neuen Weg der Version 9, der die Historie des alten Weges mitbekommt”) wird kompliziert. Weil dann hätten wir zwar einen neuen Weg in der Version 9 mit einer bestimmten ID, aber eine Version 8 mit dieser ID gäbe es nicht, weil die ID wurde ja eben erst geschaffen. Auch da bräuchten wir also einen Querverweis, dass die Historie des neuen Weges in der des alten zu finden ist.

So grundsätzlich kann man ja nachvollziehen, wie ein Weg entstanden ist. Im gleichen Changeset muss ja auch der ursprüngliche Weg enthalten sein, der zerteilt wurde. Das ist oft mühsam nachzuvollziehen, aber immerhin möglich. Es scheitert natürlich bei manchen Fällen, falls ich z.B. heute einen Weg kürze und morgen in einem anderen Changeset den Teil des Weges neu eintrage, aber dagegen ist die API so oder so machtlos.

Sowas wie einen Querverweis kann man natürlich machen, müsste man halt “nur” allen Editoren beibringen. Für wichtig halte ich es nicht. Wenn ich bei einem Projekt mitmache, zu dem eine Horde unbekannter Leute beitragen soll, muss ich damit klar kommen, dass die Horde auch mein Zeug ändert. Man muss dabei Andenken an meine User-Id und meine Changesetkommentare nicht absichtlich vernichten, aber wenns passiert, dann passiert es eben…

Grüße, Max

Das ist eine Editor-Frage. Nur der Editor weiß, daß ein Weg durch eine Funktion “Trennen” entstanden ist. Für den Server sind das einfach alles neue Wege, egal wie sie reingekommen sind.

Man könnte also

  • ein Tagging Schema für den letzten Bearbeiter eines Wegs vor der Trennung erfinden
  • die Autoren der Editoren davon überzeugen, das Setzen dieses Tags in ihre Trennen-Funktion aufzunehmen

Die Frage ist aber, ob man wirklich den letzten Bearbeiter meint, oder den ursprünglichen Ersteller. Letztere Info ist normalerweise beim Bearbeiten nicht verfügbar, dafür müßte man die komplette History zusätzlich runterladen.

Vielleicht wäre es auch sinnvoller, ein Tagging Schema für “ID des Vater-Objektes bei Trennung” zu entwickeln. Die ID bleibt im Gegensatz zum User über die ganze Lebenszeit gleich.

bye, Nop

Hallo,

Wer “ver-igelt” denn Routenrelationen (d.h. macht das “Stacheln” durch das Mergen von Ways wieder dran)? Dadurch macht der User die Relation kaputt, sprich das ist Vandalismus und dagegen sollte vorgegangen werden. Du kannst IMHO ruhig Namen nennen.

Ich finde den Weg über irgendwelche Spezialtags schlecht. Das funktioniert nur, wenn alle Editoren (oder zumindest, die mit denen 99,5% der Änderungen getätigt werden) das unterstützen. Wie unser schlechtestes Beispiel zeigt, ist das von iD nicht zu erwarten. Es wäre deutlich sinnvoller, wenn es einen API-Call “Split” gäbe, der einen Way aufsplittet. Ein Teil behält die ID, der zweite Teil bekommt eine neue ID, hat aber in der History einen Verweis auf die vorhergehende Version des anderen Teilways. Das könnte man zwar erst mit der nächsten API-Version einführen, weil man mit einer abwärtsinkompatiblen API 0.7 einen Anpassungszwang auf alle Editoren ausübt. Das hat auch gute Seiten. :slight_smile:

Wenn source=* am Changeset angegeben ist, ist das kein Problem. Dann haben nämlich nach dem Splitten eines Ways die Nodes immer noch die Quellangabe (bloß halt in der History versteckt und nicht so leicht mit 08/15-Tools wie Overpass-API und Standard-PostGIS-DB-Schemata auffindbar). Erst wenn der “bösartige” User (siehe oben) den alten Weg wieder verlängert und dabei die Nodes neu zeichnet (sprich alte Nodes löschen, neue ergänzen), geht dieser Quellverweis verloren. Aber dann sind es neue Nodes mit einer anderen Datenquelle.

Viele Grüße

Michael

Wenn es “mühsam, aber möglich” ist, müsste sich das doch an und für sich automatisieren lassen. Man könnte also theoretisch ein Tool basteln, das für einen gegebenen Weg dessen History abruft, frühere Changesets untersucht und nachsieht, ob z.B. bei der Erstellung des Weges im gleichen Changeset ein anderer Weg modifiziert wurde, dem die Nodes entstammen, die nun den neuen Weg bilden. Das Beispiel funktioniert natürlich nur, wenn ein Weg aufgetrennt wurde und nicht, wenn er teilweise neu erstellt wurde.

So schnell oute ich keinen öffentlich, das sollen die mal schön selber machen! Ich schreibe meist nur die Leute an und unterscheide dabei erst mal ob es ein Newbie oder ein Senior ist. Bei Newbies setze ich meine “Erklärbärbrille” auf, bei Erfahrenen frage ich freundlich. Die meisten sind ja schnell einsichtig, manche rühren sich aber gar nicht und ein paar sehr sehr wenige sind beratungsresistent. Aber das wäre wirklich mal eine Option die hier zukünftig mal zu outen. Bisher habe ich es dann halt selber repariert bevor ich mich da lang rumstreite und warte auf den lieben Godot ob er nun kommt oder nicht. Im Moment bin ich dabei mal wieder alle Relationen der Wanderwege in der Franken Alb zu sichten, da hat sich im Laufe der Zeit wieder ganz schön was “aufge-igelt” und im Datennirvana ins nichts aufgelöst.

Denke nicht daß das funktionieren kann. Dann müßtest Du beim Editieren erst mal das aktuelle Changeset hochladen, die API-Funktion Split aufrufen und dann den Editor neu starten/die Daten neu runterladen um weiterzuarbeiten. Und diesen Wechsel hast Du bei jedem Split.

Das wird niemand machen - ganz besonders nicht weil Du keinen Editor davon abhalten kannst, seine bereits vorhandene, bequeme Split-Funktion weiter zu benutzen.

bye, Nop

PS: Ich habe nichts darüber gesagt wie wahrscheinlich ich die Umsetzung so eines Features in den Editoren beurteile

es wäre nett wenn ihr fundierte und gebräuchliche begriffe nehmen könntet. was ist bitte “ver-igelt”? ein neues tagg zu einem igelbau?

Ist doch anschaulich klar: Wenn man Wege zusammenführt, von denen nur ein Teil Mitglied einer Relation sein sollte, dann wird nach dem Zusammenführen der ganze Weg zum Mitglied der Relation. Der Teil, der nicht dazugehören sollte, ist dann ein überstehender “Stachel”. Aus der Relation, die eigentlich eine durchgehende Route sein sollte, wird durch solche “Stachel” ein “Igel”. Das ist “ver-igelt”.

Ich sehe schon, das ist kein leichtes Thema und mit einer kurzfristigen; wenn überhaupt Lösung zu rechnen. Ich fasse mal zusammen, eine Nachvollziehbarkeit (warum auch immer) wäre möglich. Das mit der “Eitelkeit” muss halt von den Urhebern toleriert werden. Wenn ich einen Baum pflanze, muss ich auch damit rechnen, dass den mal einer umsägen wird. Ich glaube, die wenigsten von uns legen auf “mein Haus, mein Auto, meine Frau” Wert im Sinne der ganzen Sache und bei weiteren Beschwerden verweise ich auf diese DIS.

Das Auftrennen des Weges zum Erstellen einer Relation ist vollkommen legitim. Niemand hat ein Erbrecht auf “seinen” Weg.

Möchten man den ursprünglichen Erstelller eines Weges ermitteln, ist dies fast immer anhand der Wegpunkte möglich.
Die ältesten Wegpunkte, d.h. die mit der kleinsten ID, welche nicht Teil eines anderen Weges sind, stammen normalerweise vom Urheber des Weges.

Einmal wurde ich von so einem kindischen Mapper angegriffen… Angeblich hatte ich eine von “seinen” Straßen “gelöscht und selbst neu gezeichnet” :smiley: Natürlich war es nicht der Fall, ich habe einfach diese (mehrere Kilometer lange) highway=tertiary in viele Teile zerschnitten, um die dazugehörende Brücken zu erfassen. Nur ein kurzes Stück hat die ursprüngliche History behalten, in der History der einzelnen Punkte stand aber noch alles.

In so einem Gesellschaftsprojekt wie OSM geht es um Zusammenarbeit und inkrementelle Verbesserung. Nur jemand der es nicht versteht beschwert sich darüber, dass “seine” Objekte von anderen berührt werden.

Mit zunehmender Detaillierung der Karte werden längere Wege immer wieder in kürzere aufgetrennt und das ist vollkommen normal. Die ganze History bleibt immer da in der Datenbank, trotz nicht immer einfach abrufbar.