Changesets mit Merkwürdigkeiten

Communities Deutschland (Germany)
1

Hallo zusammen,

gleich zwei Changesets werfen bei mir Fragen auf, auf die ich keine Antworten finde:

https://www.openstreetmap.org/changeset/115022918: Der User hat hier eine Straße aufgetrennt, dabei wurden aber die Busrelationen nicht geändert. Normalerweise übernimmt JOSM automatisch die neuen Abschnitte in die Relationen - zumindest, wenn ich das nachstelle. Hier offenbar nicht. Wie kann das sein?

https://www.openstreetmap.org/changeset/115070227: Hier wurde an verschiedenen Häusern in Weiler-Langweiler etwas geändert. Ich kann aber nicht feststellen was, weder mit OSMCha (https://osmcha.org/changesets/115070227/) noch mit achavi (https://overpass-api.de/achavi/?changeset=115070227). Lediglich bei Nr. 10 sind die Änderungen klar (Umriss). Hat jemand eine Erklärung?

Gruß aus Aachen

2

Also https://overpass-api.de/achavi/?changeset=115070227 zeigt hier ergänzte Adressen und ein paar ergänzte Straßennamen, ein neues Gebäude mit Adresse, ein POI…

zur anderen Frage kann ich nichts dagen.

Sven

3

z.B. indem man per Overpass nur Ways & Nodes lädt und die Relation beim Runterladen auslässt.

4

@streckenkundler: Hier unterscheidet sich achavi von OSMCha. Während OSMCha https://www.openstreetmap.org/way/141103659 als “geändert” anzeigt, macht das achavi nicht.

@jengelh: Das wäre auch für mich die einzige plausible Erklärung und könnte zur Antwort des Users passen. Sinnvoll, gerade bei Straßen, ist das aber eher nicht.

5

JOSM fragt beim Auftrennen eines Weges, über den Relationen laufen, nach, ob fehlende Relationsmitglieder zuvor heruntergeladen werden sollen:
Da ist “Nein” keine gute Wahl, denke ich.

6

Ein “Nein” würde aber nicht zum beschriebenen Fehler führen. JOSM wüsste dann nur zB nicht, ob der neue Abschnitt vor oder hinter dem bestehenden in die Relation gehört. Reintun wird er ihn aber auf jeden Fall.

7

Stimmt, da hast du recht. Zu kurz gedacht meinerseits.

8

Das fragt JOSM aber nur für anhängende Relationen, von denen Kenntnis besteht. Wenn keine Relationen geladen sind, wird nicht überprüft, wenn nur ein Teil vorhanden ist, dann wird nur der Teil beachtet. Das Problem betrifft sämtliche Relationen und führt auch bei Grenzen und Multipolygonen immer wieder zu Lücken…

9

achavi zeigt nichts an, wenn es keinen Unterschied gibt. Way 141103659 hat zwar eine neue Version 3, aber keine Änderungen bei Tags oder Nodes.

Das kann man auch manuell über die API überprüfen, hier als Linux Kommandozeilen-Diff, es unterscheiden sich nur die Metadaten (user anonymisiert):


diff \
 <(curl -s https://www.openstreetmap.org/api/0.6/way/141103659/2) \
 <(curl -s https://www.openstreetmap.org/api/0.6/way/141103659/3)

3c3
< <way id="141103659" visible="true" version="2" changeset="89586065" timestamp="2020-08-18T16:25:55Z" user="xxx" uid="xxx">
---
> <way id="141103659" visible="true" version="3" changeset="115070227" timestamp="2021-12-17T19:56:59Z" user="yyy" uid="yyy">

Änderungen an den referenzierten Nodes (Koordinaten-Verschiebung) sind hier nicht berücksichtigt, aber die sind auch unabhängig von der Way-Version.

Kann man aber auch noch zusätzlich mit der Overpass API und einer “date”-Abfrage mit “out geom” prüfen, auch hier keine Änderung:


diff \
<(curl -s http://overpass-api.de/api/interpreter?data=%0A%5Bout%3Ajson%5D%5Bdate%3A%222021-12-17T19%3A56%3A58Z%22%5D%3Bway%28141103659%29%3Bout%20meta%20geom%3B) \
<(curl -s http://overpass-api.de/api/interpreter?data=%0A%5Bout%3Ajson%5D%5Bdate%3A%222021-12-17T19%3A57%3A00Z%22%5D%3Bway%28141103659%29%3Bout%20meta%20geom%3B)

13,17c13,17
<   "timestamp": "2020-08-18T16:25:55Z",
<   "version": 2,
<   "changeset": 89586065,
<   "user": "xxx",
<   "uid": xxx,
---
>   "timestamp": "2021-12-17T19:56:59Z",
>   "version": 3,
>   "changeset": 115070227,
>   "user": "yyy",
>   "uid": yyy,

Das sind diese beiden Abfragen


[out:json][date:"2021-12-17T19:56:58Z"];way(141103659);out meta geom;
[out:json][date:"2021-12-17T19:57:00Z"];way(141103659);out meta geom;

als URL: in Overpass Turbo mit “Export” > Rechtsklick auf “Rohdaten direkt von Overpass API” und “Link-Adresse kopieren”. Die Zeitstempel sind
die “created_at” und “closed_at” aus dem “Änderungssatz-XML”-Link im Changeset 115070227 ganz unten, für den Stand davor eine Sekunde abgezogen.

10

Dann frage ich mich aber, warum eine neue Version 3 erzeugt wurde.

11

Wenn ich in eine Linie einen Knoten einsetze und den wieder herauslösche, oder einen neuen Tag setze und wieder lösche, usw. (nicht mit UNDO, sondern manuell), dann wird diese Linie hochgeladen, die Änderungen - in diesem Fall zwei - haben aus der Sicht eines Dritten nichts geändert. Mit nur einer Änderung kann das nicht passieren :wink:

12

Treffer @Hungerburg :sunglasses:. Das konnte ich in JOSM auch nachstellen: Punkt zu Gebäude hinzufügen, manuell wieder löschen, Upload => das Gebäude soll hochgeladen werden, obwohl (theoretisch) nichts geändert wurde.

13

Das ist mir auch schon aufgefallen.

Wenn man aber vor dem Hochladen “Daten aktualisieren” ausführt, wird nichts mehr hochgeladen.

14

Da bleibt JOSM auch nichts anderes übrig: Jede Änderung an einem Objekt führt dazu, dass es als “dirty” markiert wird und damit hochgeladen werden soll.
Sonst müsste JOSM jede weitere Änderung verfolgen, ob sie irgend eine frühere Änderung rückgängig macht oder ob sogar mehre Änderungen zusammen frühere Änderungen revertieren. Das würde einen Riesenaufwand für relativ seltene Fälle verursachen. Es geht ja letztlich nur um die Versionsnummer.

Das “Daten aktualisieren” macht das, ohne auf die Historie achten zu müssen. Es vergleicht ja nur den Zustand im System (d.h. vorher, wenn nicht von anderen geändert) und jetzt (lokal). Es muss dann aber über alle geladenen bzw. ausgewählten Objekte laufen und kann ein Weile dauern.
Denkbar wäre es, von Zeit zu Zeit einen Snapshot der lokalen Daten zu machen und die aktuellen Daten dagegen abzugleichen, d.h. ein “Aktualisieren” ohne Herunterladen von OSM. Ob sich dieser Aufwand lohnt, wage ich zu bezweifeln.

15

Moin!

Nach Hinweis von aixbrick im Changeset und als Verursacher der Irritation melde ich mich kurz mal.
Genau das was Hungerburg beschreibt ist passiert.
Ich hatte bei den Gebäuden in Weiler Langweiler (geiler Name btw) das Tag “addr:street” hinzugefügt, vor dem Upload aber noch einmal in die Wiki-Seite zum Thema Adressen geguckt. Da dort stand, dass addr:street und addr:place nicht gleichzeitig an einem Objekt sein sollten hatte ich addr:street wieder entfernt.

Dass eine derartige Aktion einen Versionssprung bedeutet, war mir nicht bewusst. Merke ich mir aber für’s nächste Mal, um weitere Irritationen zu vermeiden. :smiley:

16

Danke @geomaniX, irgendwie hatte ich geahnt, dass du ein addr:street hinzugefügt und wieder gelöscht hast :P.

Mir war dieses Verhalten auch nicht bekannt, sodass ich bestimmt auch schon mal solche Versionsänderungen “verursacht” habe. Das lässt sich auch kaum vermeiden, wenn man im Laufe der Bearbeitung bemerkt, dass eine frühere Änderung nun doch nicht nötig ist und ein Undo viel zu viel rückgängig machen würde.

17

Das macht jede Software so: Öffne mal einen Text in deiner Textverarbeitung, füge irgendwo einen Buchstaben ein und lösch ihn danach wieder mit Entf oder Backspace. Die Software wird immer noch sagen “Ungespeicherte Änderungen vorhanden”. Da wird nicht vorher und nachher verglichen, da wird nur nachgeschaut, ob frische Änderungen im Undo-Stack stehen. Und da stehen jetzt zwei Stück, auch wenn sie sich auf Null summieren.

Deshalb nimmt man Irrtümer immer mit Strg-Z zurück und bessert sie nicht manuell aus.

18

Das geht nur, wenn man den Irrtum frühzeitig bemerkt.

19

Wenn man einen Fehler zu spät bemerkt, um ihn via Undo loszuwerden, hat JOSM noch die schöne Funktion ‘prunepurge’ in petto: vergiss das markierte Objekt (inklusive aller etwaiger Änderungen). Shortcut Ctrl-shift-p, siehe https://wiki.openstreetmap.org/wiki/JOSM/Advanced_Tricks.
Das hat mir schon etliche mal viel Mühe erspart.

Aber Vorsicht: zugehörige Nodes werden auch vergessen (bzw umgekehrt: wenn man einen Node vergessen will, der zu einem Weg gehört, verschwinden auch alle Änderungen am Weg und an anderen zugehörigen Nodes). Das ist nicht immer, was man will.

Edit: die Funktion heißt purge, nicht prune. URL dabei.

20

Guter Tipp! Ich selber will ja möglichst wenig Historie anlegen, nicht meinen Namen in alle Bücher schreiben, außer hier, natürlich :slight_smile: Das ist viel einfacher als purgen, man will das Teil ja dann u.U. doch im Visier behalten, muss es also dann eh wieder holen…

Den Editor kann man da jedenfalls nicht belangen, ist ja vorrangig ein sogenannter Editor, kein Assistent, der einen beobachtet und dann haufenweise Vorschläge macht, was man sonst noch tun könnte, oder wie man es besser mache könnte…