In https://www.openstreetmap.org/changeset/76764349 wurde halb London an die Wolga geschoben (s. Thread „Kurioses“).
Auffallen ist, dass die verschobenen Nodes exakt auf dortigen Gebäudeecken liegen. Das sieht mir nach einem Systemfehler aus, nicht nach einem schiefgelaufenen Edit.
Was machen wir damit?
–ks
Info: Habs in https://www.openstreetmap.org/changeset/76773501 revertet.
Der Fehler war mir zu heftig, um ihn lange in der Datenbank stehen zu lassen.
Nachvollziehbar in der History der verschobenen Nodes, z.B. https://www.openstreetmap.org/node/107896/history
–ks
Sowas ähnliches gab es neulich schon mal, allerdings ohne Rückmeldung, wie es dazu kam:
https://github.com/openstreetmap/operations/issues/317
https://www.openstreetmap.org/changeset/72987308
https://lists.openstreetmap.org/pipermail/talk-gb/2019-August/thread.html#23327
https://forum.openstreetmap.org/viewtopic.php?id=66987
https://forum.openstreetmap.org/viewtopic.php?id=66999
Es sind auch einige der damaligen Nodes erneut betroffen 108184. Allerdings gibts auch Nodes, die seit Ewigkeiten gelöscht waren und neu auferstanden, 108172. Letzteres bekommt man durch einen Bedienungsfehler in JOSM nicht hin. Irgendwie merkwürdig.
Edit: 1. Link war falsch
Hallo,
so sieht das auf der Karte aus (zufällig beim Mappen entdeckt).
Tileserver, die die Tile-Expiry (Tiles als veraltet markieren) von Osm2pgsql nutzen, markieren die Tiles als invalide und tragen sie in die Warteschlange für das Neurending ein. openstreetmap.org nutzt einen anderen Expiry-Mechanismus, der zu weniger neu zu berechnenden Tiles führt, aber nur die als veraltet markiert, in denen Nodes geändert wurden. Deshalb werden nur die paar Tiles in London und Russland direkt in die Warteschlange kommen. Das heißt, die Tiles die nicht an den Koordinaten der Nodes liegen, sehen wie oben aus, wenn in ihrem Gebiet ein Edit erfolgte, während die Daten “kaputt” waren.
Dass das jetzt zum zweiten Mal London war, ist verdächtig.
Viele Grüße
Michael
London ist ne riesige Stadt, wohl mit entsprechend viel Daten und Mappern.
Und sie liegt auf Längengrad 0.
Vielleicht gibt es einen Bug, der ganz selten mal bei 0 triggert?
Es gab auch mindestens einen Node (106662), der von Norwegen (60.0°N, 10.8°E) aus nach Osten gewandert ist.
Soweit ich gesehen habe, kamen die verschobenen London-Nodes alle aus der Gegend King’s Cross / Soho, das ist schon ein achtel Längengrad westlich von Greenwich.
–ks
PS: Der place-node von London (https://www.openstreetmap.org/node/107775) war auch an der Wolga. Wenn das mal keine diplomatischen Verwicklungen gibt – das Brexit-Referendum sollen die Russen ja auch geschmiert haben 
Wenn man das changeset anschaut dann sind die fraglichen node ids alle sehr tief (deshalb London und nahe zusammen) und im wesentlichen sequentiell, also wahrscheinlich:
JOSM Bug oder Bug in einem versteckten Importscript
Bug in der API beim ersetzen der Placeholders
eher unwahrscheinlich
Simon
Ich habe mir die Gegend an der Wolga angesehen, da gibt es jetzt eine Menge Knoten, die vorher zu Gebäuden gehörten.
Außerdem habe ich den Verdacht, das der heutige daily des planet korrumpiert ist.
Mein DACH-Exract für meinen Garmin ist 500 MB größer als gestern, dafür habe ich keine andere Erklärung
Ich kenne solche seltsamen Verschiebungen, wenn jemand z.B. mit srtm2osm Höhenlinien generiert und diese dann (für Garmin Karten) mit echten OSM Daten mischt. Das Programm generiert dann fortlaufen Node-Ids , wenn man nicht aufpasst, liegen die im Bereich der realen OSM Daten, und dann bekommen die OSM-Knoten beim Mischen neue Positionen. So weit so einfach. Schwierig ist allerdings, eine Erklärung dafür zu finden, wie dieser Unsinn dann mit JOSM hochgeladen werden kann. Der Benutzer muss ja diese Daten erst laden und dabei wird der Fehler sofort sichtbar.
Edit: Wahrscheinlicher scheint mir da ein amok-laufendes JOSM-Plugin
Hallo neuer Verschieberteil,
nördlich von Lübben/Spreewald habe ich auch einen der Fehler entdeckt.
Michael!
