TomH meinte vorhin auf #osm-dev, dass Roland das Problem wohl heute morgen gemeldet hatte. Ich weiß nicht, was da ansonsten so läuft, um die 3 Instanzen wieder ‘on track’ zu bringen. Also besser mal nachfragen?
Ich kann ihn doch nicht mehr löschen, in Josm wird die Apotheke nicht mehr geladen.
An den beiden Apotheken Hattingerstr. 794 und 858 habe ich die addr: Tags drangehängt.
Apotheke zwischen den Kirchen wird von Nominatim mit Adresse gefunden.
Die Adressen bekomme ich mit Josm auch angezeigt über Overpass nicht.
Habe trotzdem ein paar Tests gemacht.
Die Adresstags der ersten Apotheke sind nach dem Löschen des country-Tags und Verschieben des Nodes auch in Overpass zu sehen.
Danach habe ich den anderen Node minimal verschoben und hochgeladen.
Danach sind die Adressentags auch in Overpass sichtbar.
Ich hoffe das hilt bei der Suche, denn ich kann mir nicht vorstellen, dass ich der einzige Mapper war zu der Zeit.
Danke fürs Bescheid geben. Die Erklärung ist relativ einfach, die Behebung des Problems wird aber komplizierter.
Die Overpass-Server haben eine Version des Diffs 1252215 um 2015-02-04 08:02:09 UTC bezogen, die folgende Transaktionen enthält:
#Wed Feb 04 08:02:02 UTC 2015
sequenceNumber=1252215
txnMaxQueried=656743978
txnReadyList=
timestamp=2015-02-04T08\:02\:02Z
txnMax=656743978
txnActiveList=
Wichtig als Indikatoren sind “timestamp” und “txnMaxQueried”. Im Gegensatz dazu weist exakt diese Datei jetzt aus:
#Wed Feb 04 09:18:22 UTC 2015
sequenceNumber=1252215
txnMaxQueried=656753157
txnReadyList=
timestamp=2015-02-04T09\:18\:02Z
txnMax=656753157
txnActiveList=
Anders ausgedrückt: Dieser Diff ist offenbar nochmal neu erzeugt worden. Das haben die Server nicht mitbekommen und mit dem Diff 1252216 weitergemacht.
Die Änderungen aus diesem Diff fehlen jetzt, und ich werde überlegen, wie man die am störungsfreiesten wieder hineinbekommt.
Ich hatte überlegt, den gelöschten, aber in Overpass- turbo enthaltenen Node in den Josm zu laden , das geht wenn ich dann direkt hochladen sage gibt es zwar nichts zum hochladen, aber ich könnte den Node anfassen (weelchair löschen) und so eine Änderung erzeugen und dann zurückladen.
Wenn er dann noch da ist, ließe er sich lüschen.
Das Problem sollte sich auf der Hauptinstanz erledigt haben.
Ich habe den normalen Update-Ablauf unterbrochen und den fehlenden Diff neu eingespielt. Das löst nicht alle Probleme, denn seit diesem Diff geänderte Elemente stehen jetzt auf der falschen Version aus dem gerade eingespielten Diff. Das betrifft aber wesentlich weniger Elemente: aus dem Diff fehlen 1.5 Mio. Änderungen, jetzt stehen nur noch etwa 1000 Elemente im falschen Zustand. Leider ist auch das noch zu viel, um die Fehler von Hand zu beheben.
Ab etwa Mitte März wird das Problem dann dauerhafter behoben: es wird einen neuen Server geben, und in dem Zuge lässt sich dann auch eine saubere Historie wiederherstellen.
Die liebe ich gerade nicht.
In diesem Fall Glück, dass ein neuer Server aufgesetzt wird.
Ansonsten ist es immer gut einen Fehler erkannt zu haben, um dadurch Wiederholumg vermeiden zu können.
Ich nehmen an, ihr sprecht hier vom Overpass-Server? Was soll ein neuer Server bei solchen Problemen bringen?
Wenn er aus UK ein falsches oder gar doppeltes DIFF bekommt und das nicht merkt - wie denn auch? - gibt es mWn nur eine einzige Lösung:
State.txt auf das letzte Diff vor dem Problem setzen und ab dort den Import neu machen. Alles andere ist Kokolores.
Ich schaue mir jetzt mal die Logs meines Servers an und schaue mal, wann das genau war und was da sonst abgegangen ist.
Den großen Ausfall vor 2-3 Tagen hab ich aber gut überstanden.
Gruss
walter
Edit: Hab den Import zurückgesetzt auf #1252213 und lass die paar Minuten halt nochmals laufen - sicher ist sicher.
Ja, full history geht wohl nicht. Das Laden der Overpass DB startet mit dem ersten ODbL-planet an (irgendwas im September 2012) und pumpt dann alle nachfolgenden Diffs rein.
So gibt’s die komplette Historie seit 09/2012 im Zugriff und nicht nur den Stand des aktuellen Planet.