Ich möchte dieses Thema unter einem anderen Gesichtspunkt noch einmal aufgreifen. Einerseits wird das Löschen von Objekten in OSM ja recht kritisch gesehen, da wird auch gerne schnell mal das V-Wort ausgepackt. Und ich selber finde auch, dass man so sparsam wie möglich damit umgehen sollte, Informationen zu löschen, die von anderen Mappern zusammengetragen wurden.
Andererseits wird bei jedem Splitten eines Weges die Historie für das neue entstehende Wegstück “gelöscht”. Es bleiben zwar alle Tags erhalten, aber der abgesplittete Teil wird als “neuer” Weg (Version 1) in die DB eingetragen. Ich finde das keine glückliche Lösung und kann mir nicht vorstellen, dass es besonders schwierig sein sollte, mit den übernommenen Tags auch die Historie auf den abgesplitteten Wegteil zu übertragen.
Das Thema ist ja schon seinerzeit kontrovers diskutiert worden - gibt es da vielleicht mittlerweile einen Trick, den ich noch nicht kenne, mit dem man ohne großen Aufwand die Historie auf den neuen Weg kopieren kann?
Die Historie hängt doch an der id des Objekts, und die muss eindeutig sein. Ein neuer Weg hat nun mal keine Historie.
Schön wäre aber ein Tool, welches einem schnell und einfach ermittelt, dass der “neue” Weg zuvor wahrscheinlich Teil des alten war.
Oder man erfindet ein neues Meta-Attribut, welches die Editoren beim Splitten (und anderen Operationen?) am neuen Element hinzufügen können. Könnte so aussehen: derived_from="elementtype/id operation"
Für Wege kann das komplex werden. Man kann beliebig viele Wege splitten und die neuen Abschnitte miteinander verwurschteln. Das neue Objekte hätte dann sehr viele Vorgänger. Hier müsste man effektiv die Menge aller Wege betrachten, die die Knoten des neuen Wegs vor der Änderung enthielten.
In der Praxis reichen meistens ein paar Klicks in der Nähe eines Weges mit niedriger Version und man findet den offensichtlichen Vorgänger. Wenn man gar nicht weiterkommt, lässt sich die Zeit mit overpass zurückdrehen.
Komplex nur in dem Sinne, dass man in das (XML-)Attribut eine Liste kodieren müsste. Z.B. komma-separiert sollte das konfliktfrei gehen. Und eventuell ist die “Operation” bei umfangreichen Splits+Merges nicht klar, vielleicht kann man das weglassen. Und wenn man spätere Merges berücksichtigen möchte, dann könnte man vielleicht die Versionsnummer mit kodieren.
Das ist schon klar, aber ich denke, es sollte kein Problem sein, die Historie auf den abgesplitteten Teil des Weges zu übertragen. Der abgesplittete Teil ist ja de facto kein neu erzeugter Weg, sondern ein bereits existierender, der lediglich einer Bearbeitung unterworfen wird, auch wenn dafür eine neue ID erzeugt werden muss.
Komplex m.E. weniger, aber die Historie würde sich mit jedem Split um ein Element verlängern, das könnte bei den zahlreichen Splits, die ständig aus den unterschiedlichsten Gründen gemacht werden, schon unübersichtlich werden.
Mich wundert bei diesem Thema in erster Linie, dass einerseits auf die Historie großen Wert gelegt wird (bloß nichts löschen und neu anlegen, um die Historie zu erhalten), andererseits bei jedem Split dieselbe aber in den Tiefen der Datenbank verschwindet, wo man sie mit einfachen Mitteln zunächst mal nicht wiederfindet.
@chris66 mich würde interessieren, warum Du meine Frage ohne Erläuterung mit einem kommentierst - ist die Frage Deiner Meinung nach nicht legitim und sollte daher nicht gestellt werden?
Nach meinen Verständnis wird die Historie berechnet. Dazu werden die einzelnen Versionen aus der Datenbank anhand der id zusammengesucht. Wie soll das mit einer neuen id funktionieren? Der Editor kennt die noch nicht mal, die wird ja erst vergeben, wenn die Daten hochgeladen werden. Mal abgesehen davon wäre das total verwirrend, wenn durch einen Split ein neuer Weg eine Historie bis in die Anfänge der Zeit hätte. Die müsste dann ja irgendwie in alle alten Sicherungen der Datenbank “reingemogelt” werden und das würde totales Chaos bedeuten.
Das wird sicher so sein, auch wenn sich die Handhabung meiner Kenntnis entzieht.
Ich betrachte den Vorgang als Mapper aber primär nicht von der programmtechnischen Seite, sondern von der Nutzerseite:
Da ist eine Straße in der Version 15 mit 12 tags, u.a. maxspeed=100. Wegen einer neuen Beschilderung splitte ich die Straße an 2 Stellen und ändere bei dem abgesplitteten Teil von maxspeed=100 zu maxspeed=80.
Es entstehen 3 Wege (vor dem Split, der herausgesplittete Weg, nach dem Split). Alle 3 haben nach wie vor 12 tags, die beiden Wege vor und nach dem Split sind nach wie vor unverändert (und müssten daher auch die Version 15 behalten), der abgesplittete Teil müsste wegen dem Change der maxspeed die Version 16 erhalten.
So wäre es m.E. von der Nutzerseite her logisch. Programmtechnisch behält aber nur der Weg vor dem Split die Version 15, die beiden anderen Wege werden auf Version 1 gesetzt, behalten aber die vorhandenen (= historischen) Tags.
Ich kann damit durchaus leben, finde aber nach wie vor, dass das keine besonders elegante Lösung ist.
Nö, es entstehen zwei neue Wege und ein alter wurde geändert, er hat ja dann weniger Knoten und ist damit kürzer. Evlt. ist auch der mit dem geänderten Tag “der alte”, das kommt drauf an, welchen Teil man da auswählt.
Es stimmt, dass die aktuelle Situation suboptimal ist. Ein wege-splittender Mapper wird zum “Original-Erfasser” das abgesplitteten Stücks (Version 1) und könnte Jahr später gefragt werden, warum er denn eigentlich das obskure Tag danger=suspicious_residents erfasst hat, obwohl das schon seit 10 Jahren am Vorgängerweg klebte.
Leider ist es alles andere als einfach, die History irgendwie in der Datenbank zu übernehmen, aus Gründen, die hier schon genannt wurden - wer das zu spitzfindig findet, der möge sich einfach überlegen, was denn bei der gegenteiligen Operation passieren soll. Ich führe zwei Wege zu einem zusammen - und welches ist jetzt dessen History?
Cool wäre es, wenn die API komplexere Operationen verstehen könnte. Derzeit ist es ja so, wenn Du einen Weg aufsplittest, muss der Editor an die API melden: “Erstelle eine neue, kürzere Version dieses alten Weges, und erstelle ausserdem ein komplett neues Way-Objekt mit diesen Tags und diesen existierenden Nodes”. Die API weiss überhaupt nicht, dass Du im Editor die Split-Funktion benutzt hast. Wenn es die Möglichkeit gäbe, dass der Editor an die API den Befehl sendet “führe Split aus für Way 1234 an Node 3456”, dann könnte die API das wiederum in einem Prozess-Log speichern - dass der neue Way aus eben genau dieser Operation entstanden ist. Und dann könnte die API einem auch dabei helfen, die “echte” Entstehungsgeschichte eines Objekts nachzuverfolgen.
Aber das ist Wunschdenken, dazu müsste man eine Menge umbauen. Das ganze irgendwie in Tags abzubilden halte ich für einen wilden Hack.
Wirklich praktikabel ist eigentlich nur eine historische Analyse der Nodes - zu welchem Way hat dieser Node vorher gehört, das ist dann vermutlich auch der Vorgänger des Ways, zu dem der Node nun gehört. Dafür gibt es aber keinen bequemen Webservice, da muss man tatsächlich das History-File bemühen…
Aber wäre schon schön, wenn es da irgendwas gäbe. Ich habe auch schon einige Male den falschen Mapper angeschrieben wegen irgendwelcher fraglichen Tags und dann - mehr oder weniger zu Recht - ein “war ich nicht, war schon so” zurückbekommen. Was ich mir da wünsche wäre dann eine bequeme Möglichkeit, die Daten um das fragliche Objekt (bbox + 1m) zu einem Zeitpunkt ganz kurz vor der Änderung durch den CS das anderen zu bekommen. Müsste ja dank overpass möglich sein, aber ist auch sicher kein Einzeiler. Beim fraglichen Objekt geht es ja evtl. auch um eine nicht mehr vorhandene Version, man brächte also erstmal die bbox von damals, die dann etwas größer, und dann davon die Daten etwas äter.
Das sollte nur ausdrücken, dass ich den Vorschlag für nicht praktikabel halte…
Vielleicht sollte der hier auch abgeschafft werden, so wie auf anderen Plattformen bereits…
An der API in absehbarer Zeit so etwas geändert zu bekommen ist in der Tat unrealistisch. Die Abbildung solcher Informationen über vom Editor automatisch gesetzte Changeset-Tags scheint mir dagegen durchaus praktikabel. Klar ist das ein Hack, aber es hat den sehr großen Vorteil, dass man sich darüber nicht erst einig werden und/oder etwas an der zentralen API ändern muss. Stattdessen reicht es, wenn mindestens ein Editor und mindestens ein Changeset-Analyse-Tool damit auf eigene Faust loslegen.
Danke für Eurer feedback und Darlegung der Hintergründe, die mir bislang nicht bekannt waren. Wie bereits gesagt, halte ich die aktuelle Handhabung für unbefriedigend, aber ich kann natürlich damit leben.
OT:
Danke für die Info. Die Reaktion hat mich nur deswegen erstaunt, weil ich ja eigentlich keinen Vorschlag gemacht, sondern primär eine Frage gestellt hatte, und das passt dann m.E. nicht zusammen.
Für einen unsinnigen Vorschlag dagegen finde ich das durchaus angemessen, und da die Benutzung hier im Forum eher zurückhaltend erfolgt, würde ich das auch nicht abschaffen wollen.
kommentierst - ist die Frage Deiner Meinung nach nicht legitim und sollte daher nicht gestellt werden?