JOSM: Was ist mit der history passiert?

Communities Deutschland (Germany)
1

Mir ist bei der Arbeit mit JOSM zum wiederholten Male aufgefallen, dass unter bestimmten Umständen die history von bearbeiteten, zuvor schon vorhandenen Objekten plötzlich vollständig verschwindet (bzw. zu verschwinden scheint) und ich als erster und einziger Bearbeiter aufgeführt werde. Als Beispiel seien hier die ways 31583429 und 199754364 herangezogen.

Beide ways waren bereits vorhanden, bevor ich Hand angelegt habe. Den way 31583429 habe ich mehrfach bearbeitet, was auch so in der von JOSM dargestellten history zum Ausdruck kommt.

Das, was jetzt als way 199754364 von JOSM (und auch von der Datenbank) als highway=tertiary und ref=BR-419/MS-419 vorhanden ist, soll ich laut von JOSM dargestellter history erstmalig und allein so editiert haben, was kompletter Unsinn ist, da ich z.B. von der ref überhaupt keine Ahnung hatte und diese einfach an dem bisherigen Objekt drangelassen habe. Was ist da mit der history los? Oder habe ich, ohne mir dessen bewusst zu sein, den ursprünglichen way etwa tatsächlich unbeabsichtigt gelöscht? Wie kämen dann aber die Daten an den jetzigen way 199754364, der von mir lediglich verschoben und teilweise mit weiteren tags versehen wurde. Und, noch viel interessanter: Weshalb zeigt sich dasselbe Phänomen auch in Fällen, in denen von mir einfach ways anhand der Bing-Bilder verlängert wurden. Auch da ist es mir schon aufgefallen, dass ich plötzlich insgesamt in der history laut JOSM als erster und einziger Bearbeiter geführt werde, obwohl doch jedenfalls bezüglich des ursprünglichen ways andere Mapper schon Vorarbeit geleistet hatten.

Übersehe ich hier vielleicht etwas?

Ach ja, ich kann mich erinnern, dass eine ähnliche Diskussion im Rahmen des Lizenzwechsels schon einmal geführt wurde, als plötzlich in bestimmten Fällen, ich glaube aufgespaltene Wege, als clean angesehen wurden, weil der ursprüngliche Lizenzablehner nicht mehr in der history auftauchte. Handelt es sich hier etwa um ein grundsätzliches Problem der Datenbank?

Ich möchte mich jedenfalls nicht mit fremden Federn schmücken und Edits zugeschrieben bekommen, die ich gar nicht gemacht habe!

2

Ja, Du übersiehst da was. Du hast Weg 31583429 im Änderungssatz 14544223 aufgespalten; dabei ist Weg 199754364 entstanden, der natürlich auch die gleichen Tags erhalten hat, die zuvor schon an Weg 31583429 vorhanden waren (und noch sind).

3

Das müsste aber imho in der history von way 199754364 ersichtlich sein, oder? Wieso ist das nicht der Fall? Und der way 199754364 hat unter anderem dieselben tags, die auch schon vorher dran waren. Ich meine im Übrigen auch, den überschießenden Teil von way 31583429 gelöscht zu haben und nicht das, was jetzt da als way 199754364 dasteht. Ich versteh’s einfach nicht :roll_eyes:

4

Jein. Der Weg wurde in dem Änderungssatz erzeugt - daß er nur durch Abspalten entstanden ist, wird nirgendwo hinterlegt. Bei genauerem Hinsehen erkennt man aber, daß einige seiner Knoten nicht im selben Änderungssatz erzeugt wurden, sondern deutlich älter sind. Und wenn man sich dann mal die History des angrenzenden älteren Wegs 31583429 auf der Website statt in JOSM ansieht, fällt auf, daß er im selben Änderungssatz kürzer geworden ist. Du scheinst aber in der Tat noch mehr abgespalten oder zusammengefaßt zu haben als nur 31583429 → 199754364. Unter anderem wurde Weg 31567961 gelöscht und ist in 199754364 aufgegangen: http://www.openstreetmap.org/browse/way/31567961/history Vermutlich hast Du zwischenzeitlich Wege zusammengefaßt und das Ergebnis später aufgespalten.

5

Es stimmt, dass im Weg 199754364 im weiteren Verlauf Stücke zusammengefasst sind. Eine Aufspaltung hat meines Erachtens nicht stattgefunden. Was passiert war war, dass ich ursprünglich das, was jetzt als way 31583429 dasteht, ein Stück fortgesetzt hatte, bevor ich erkannte, dass das, was jetzt der Weg 199754364 ist, die eigentliche Fortsetzung darstellt. Deshalb habe ich das “Überstück” an der jetzigen Verbindungsstelle von 31583429 und 199754364 gelöscht.

Nun ja, wenn ich dich richtig verstehe, ist die Datenbank (oder JOSM?) an der Stelle nicht in der Lage, die tatsächliche Entwicklung nachzuzeichen. Es scheint sich also zu empfehlen, nicht zu viele Änderungen auf einmal vorzunehmen, schon gar nicht, wenn sie mit der Abspaltung oder Verbindung von ways zusammenhängen :/. Ich werde mir jedenfalls jetzt und künftig überlegen, in solchen Fällen diejenigen Tags, die nicht meinen Kenntnissen entsprechen, zu löschen. Tut mir zwar leid um die Arbeit der früheren Mapper, aber ich möchte nicht gern in einem schiefen Licht darstehen.

6

Sowohl Aufspalten als auch Zusammenfassen kann aus vielerlei Gründen gemacht werden. Da ist nichts ehrenrühriges dran, wenn die bestehenden Taggs dabei übernommen werden.

Man mag es als unzureichend ansehen, dass dabei in der History nicht vermerkt wird, dass der so entstandene Weg zuvor ein Teil eines/mehrerer Wege war. Aber so ist das zur Zeit eben. Irgendwann kommt die API Version 0.7. Die ‘Unzulänglichkeit’ bisheriger API-Versionen sind schließlich keinem einzelnen Mapper zuzurechnen.
Du kannst auf der Brainstorming-Seite dazu, einen Vorschlag einreichen, dass Aufspalten/Vereinen mit in die History aufgenommen werden.

Es ist weder eine Schande noch anmaßend, die Erkenntnisse früherer Mapper auch im Fall von Aufspalten/Vereinen weiter zu verwenden. Wie gesagt, es ist normal und in keiner Weise ehrenrührig. Schließlich bauen wir in vielen Fällen auf den Erkenntnissen anderer Mapper auf und verwerfen nicht ihre Arbeit, nur weil wir einige Details nicht selber wissen.

Edbert (EvanE)

7

Beispiel: Du trennst eine Straße an einer Kreuzung auf, weil du eine Abbiegebeschränkung eintragen willst. Die aufgetrennte Straße hat viele Einzelheiten gemappt, lit=yes, maxweight=3.5, maxspeed=20, maxheight=3.9, surface=paving_stones, crossing=uncontrolled, sidewalk=both, cycleway=track, usw. Du hast nicht so auf diese Straße geachtet, kannst also die meisten dieser Eigenschaften nicht aus eigenem Wissen verifizieren. Also löschst du nach obiger Aussage diese Tags.

In meinen Augen grenzt das an Vandalismus.

8

Das wird so wohl nicht möglich sein. Die API müsste dazu überhaupt zuerst solche Operationen kennen, im Augenblick findest das alles im Editor statt (und das wird wohl so bleiben).

IMHO muss man sich einfach im Klaren sein, dass die eigentlichen OSM Objekte die Nodes sind, und dass beim Bearbeiten nur Nodes erstellt, gelöscht oder anders gruppiert werden (z.B. in einem neuen Way).

Simon

9

Ich finde deine Wortwahl doch etwas unpassend. “Vandalismus” ist schon anderswo (Wikipedia) immer das Totschlagargument. Hier liegt es absolut daneben. Ich habe meine Motivationsgründe, denke ich, hinreichend aufgezeigt. Diese Gründe kann man teilen oder auch nicht. Jedenfalls aber besteht kein Grund, mir hier auch nur ansatzweise Zerstörungswut zu unterstellen! :frowning:

Ich finde, mein Problem berührt einen Kernpunkt des Modells, auf dem OSM beruht, nämlich die Integrität der Datenerfassung und insbesondere auch die Nachvollziehbarkeit der Quellen. Es dürfte wohl Konsens sein, dass in der Datenbank nur Daten sein sollen, die “sauber” sind, also frei von Rechten Dritter. Das trifft im Wesentlichen auf solche Daten zu, die aus eigener Kenntnis eingetragen werden. Kann augenscheinlich eine solche eigene Kenntnis nicht vorhanden sein, weil z.B. lediglich von Luftbildern gemappt wird, stellt sich imho immer die Frage, woher eingetragene Eigenschaften kommen, die aus der Karte nicht ersichtlich sind. Schätzung? Interpolation? Erzählung Dritter? Vor-Ort-Besichtigung? Usw… Um diese Dinge klären zu können, ist u.a. die history da. Daneben ist jeder Mapper aufgerufen, sich über die Integrität seiner Edits Gedanken zu machen, um nicht OSM als Ganzes in Gefahr zu bringen. Imho führt das dann eigentlich zwingend dazu, dass dann, wenn ich die “Sauberkeit” meiner eigenen orginären Edits nicht garantieren kann, diese nicht in die Datenbank aufnehmen darf. Warum soll das anders sein, wenn mir plötzlich Edits aufgrund fehlender history zugeschrieben werden, hinsichtlich derer ich keine eigene Kenntnis und auch sonst keine zulässige Datenquelle habe/haben kann? Ich finde, es muss zumindest erlaubt sein, darüber nachzudenken, diese Daten zu löschen.

10

Naja, deine Beweggründe mögen ja löblich sein, aber der Lösungsansatz erscheint mir zumindest nicht der einzig mögliche und als der radikalste sicherlich der, der am meisten Gegenwind provoziert.

Anstatt Daten zu löschen, bei denen der Bezug zum Ersteller durch die mangelnde Verbindung zum Originalobjekt beim Aufspalten von Wegen nicht mehr einfach nachvollziehbar ist, wäre es ja auch denkbar, diese Verbindung z.B. über Changeset-Kommentare herzustellen. Klar ist das mühsam, weil man dann für jedes durch Teilen erstellte Objekt ein eigenes Changeset bräuchte. Unmöglich ist es nicht.

Oder alternativ: Vorher abwägen, ob das was du zu einen Wegabschnitt hinzufügen möchtest einen eindeutigen Mehrwert über das hat, was du dafür an Informationen löschen willst (vgl. das Bsp. Aus Zartbitters Post oben).

11

Sehe ich genau so. Wer auch immer diese Tags ursprünglich mal eingetragen hat, wird sich mit Sicherheit etwas dabei gedacht haben. Wenn eine Straße mit diesen Attributen getaggt ist, kannst du es glauben oder anzweifeln. Und wenn du Zweifel daran hast, steht es dir frei, es zu überprüfen - und wenn es nicht stimmt, kannst du es ändern oder löschen. Die Daten aber einfach ohne jede Überprüfung zu löschen, damit es “nicht so aussieht, als ob du sie eingetragen hättest”, ist grober Unfug und nicht im Sinne des Erfinders. OSM ist nun einmal ein Community-Projekt bei dem jeder Daten beisteuern kann, so gut er sie eben kennt, und dabei die Daten ergänzt, die andere bereits vorher gesammelt haben. Das ist ein konstruktiver Prozess und kein destruktiver.

12

Wenn man diese Nachvollziehbarkeit wirklich haben möchte, dann ist im Augenblick wohl das einfachste an den neuen Weg ein zusätzliches Tag anzubringen, z.B. note:splitway=“split from way #id”. Damit ist alles gesagt, das ist für jeden Nutzer verständlich, kann automatisch geparst werden und ist schnell erstellt. Man kann es auch als optionales Plugin in JOSM einbauen, dann kann derjenige der diese Information setzen möchte sie auch mit einem Klick generieren.

13

Ich persönlich betrachte dein Problem als übertrieben. Dennoch ist es für dich offensichtlich ein Problem.

Wie kann man das lösen? Eine Möglichkeit ohne Änderungen an der API abzuwarten, wäre die Abhängigkeit von dem vorigen Weg im Source-Tagg des Objektes zu dokumentieren in der Art: “Split/Merge from way ( )”. Dann hast du die in OSM als legal betrachtete Quelle (= andere Mapper) eindeutig identifiziert, und kannst die bisherigen Daten ohne Gewissenskonflikte weiter verwenden.

Das ist ein typisches Henne - Ei Problem.
Da es keine Unterstützung in der API gibt, Split/Merge Abhängigkeiten in der History eines Objektes zu speichern, kümmern sich die Editoren nicht darum. In der Tat sind es die Editoren, die das Wissen über Split und Merge haben. Wenn es möglich sein wird, solche Abhängiglkeiten per API in der History zu vermerken, dann wird das in den Editoren (zumindest JOSM und Potlatch-2) sicher schnell umgesetzt werden. Aber solange es diese Möglichkeit nicht gibt, besteht kein Handlungsbedarf für die Entwickler der Editoren.

Daher mein Hinweis diese Fähigkeit für die API 0.7 zu wünschen/anzuregen. Solange der Wunsch nicht festgehalten ist, wird es sicher keine Realisierung geben.

Edbert (EvanE)

14

Guten Morgen.

Das ist kein Problem, sondern ein Feature. :slight_smile:

Die Datenbank-API kennt das Konzept des “Split” und “Join” eines Weges nicht.

Wenn der Editor einen bestehenden Weg splittet, teilt er das für die Datenbank in zwei Happen auf:

  1. Modify: alten Weg: Verkürzen duch Entfernen eines Teils der Knoten.
  2. Create: neuen Weg: der bekommt die entfernten Knoten und den gemeinsamen Verbindungsknoten.

Dabei werden die Tags vom alten Way an den neuen Way kopiert.

Das ist auch richtig so, denn die Tags gelten für jedes Teilstück der alten Weges in der alten Version, also auch für alle Teilstücke des modifizierten alten Weges und auch für alle Teilstücke des neuen Weges. Deshalb solltest Du die Tags auch nicht löschen!

Die API übernimmt den Modify und den Create zwar im gleichen Changeset, weiß aber nichts von deren Zusammenhang. Die Datenbank legt ein neues Way-Objekt an mit einer (natürlich) leeren History.

Und diese leere History hat Dich überrascht.

Keine Sorge: das tust Du nicht. Wirklich nicht.

Die “technische” Historie der Datenbank drückt die wirkliche™ Bearbeitungsgeschichte nur unvollständig aus. Insbesonders bei Create und Delete muss man den Kontext des ganzen Changesets berücksichtigen.

Damit die Datenbank die wirkliche™ Bearbeitungsgeschichte kennte, müsste der Editor der API beim Create übergeben, aus welchem alten Objekt der Way entstanden ist, und beim Delete, wohin der gelöschte Inhalt integriert wurde. Du kannst das für die API 0.7 vorschlagen; ich halte es aber für sehr unwahrscheinlich, dass dieser Aufwand gemacht für den doch eher marginalen Nutzen, insbesonders weil auch alle Editoren angepasst werden müssen.

Zu dieser Überschätzung der Bedeutung der Historie hat möglicherweise auch der Missbrauch beigetragen, aus der Anzahl der Creates ein Ranking der Bearbeiter abzuleiten. Oder die Häufigkeit eines Benutzers als letzter Bearbeiter eines Objektes in einer Region. Die technischen Daten tragen diese Belastung einfach nicht.

Ich hoffe, das beruhigt Dich ein wenig.

Gruß Wolf

.oO( Note to myself: gleich “Die Top-10-Mapper in ” als Titel schützen lassen und als Idee für ein Sendeformat an Brainpool verkaufen )

15

Das ist eine Grundsatzfrage, die Frederik Ramm auch schon einmal gestellt hat. Es gibt zwei Positionen:

  1. Alles, was NICHT urheberrechtlich oder datenbankrechtlich geschützt ist, darf in die Karte eingetragen werden.
  2. Der Mapper muss nachweisen, dass seine Beiträge korrekt sind.

Bislang hat die Mehrheit der OSM-Mapper sich für Variante 1 entschieden. Zahlreiche Daten sind durch Interpolation, Schätzung oder Auswertung öffentlicher Quellen zusammengetragen worden. Würde man JETZT von allen Mappern einen Nachweis verlangen, indem JEDE eingetragene Straße oder Haltestelle mit Schildern usw. fotografiert werden muss, so würde ein Großteil der Daten verlorengehen.

Es geht nicht an, dass ein EINZELNER diesen Kurswechsel alleine durchzieht. Dazu ist unsere Gemeinschaft viel zu verletzlich. Wenn Du möchtest, kannst Du alle selbst erfassten Straßen zusätzlich mit source=survey oder survey=yes kennzeichnen. Dies wird beispielsweise bei den Strommasten praktiziert, um selbsterfasste Strommasten von interpolierten Strommasten zu unterscheiden.

Du darfst gerne einen Extrakt der OSM-Karte erstellen, der nur selbsterfasste Daten (source=survey) enthält. Wenn diese Karte 10% der OSM-Daten enthalten würde, wäre es schon großartig.

Die History wird vielleicht in naher Zukunft dahingehend überarbeitet werden, dass sie Änderungen vor dem Split berücksichtigt.

Dafür gibt es FIXME. Bitte einen Ortskundigen per OSMBugs um Überprüfung und wenn sich in zwei Jahren niemand meldet, dann merkst Du, wie einsam und verloren ein Mapper bei der Erfassung seiner riesigen Heimatregion ist.

16

Das hast Du zwar im Grunde recht, aber Du beruecksichtigst eines nicht: Wir bauen hier ja alle auf der Arbeit von anderen auf. Dass Du beim Mappen von anderen OSM-Objekten “abzeichnest”, indem Du die Grenze des Waldes direkt neben die schon existierende Strasse legst oder indem Du einem Haus das gleiche addr:postcode-Tag gibst was, was die Haeuser links und rechts davon haben, das ist normal - deswegen schreibt niemand in sein Changeset “Quelle: Openstreetmap” hinein. Wenn also irgendwann mal jemand kommt und sagt “warum hast Du an diesem Way maxspeed=30 eingetragen”, dann ist die Antwort “ich habe einen vorhandenen Weg in zwei aufgeteilt und die Eigenschaften dabei uebernommen” voellig legitim.

Es stimmt, dass es schoen waere, wenn wir in der Datenbank vermerken koennten, welche Operation jemand durchgefuehrt hat. Eventuell koennte es sich mit kuenftigen API-Versionen sogar dahin entwickeln, dass der Editor beim Aufspalten eines Ways nicht mehr an die API sendet:

“Lade neue Version von Way 13 hoch, mit den folgenden 10 statt vorher 15 Nodes, und erzeuge ausserdem einen neuen Way mit den folgenen 5 Nodes…”

sondern

“Teile Way 13 an Node 10 in zwei Teile…”

aber davon sind wir noch ein Stueck entfernt. Mit der naechsten API-Version wird es immerhin eventuell sowas wie partielle Edits geben, so dass man nicht mehr jedesmal den kompletten Way hochlaedt, sondern nur das, was man aendern will.

Bye
Frederik