Kann es sein dass Overpass-api nicht mehr aktualisiert

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 mache trotzdem mal ein Issue auf.

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.

https://github.com/drolbr/Overpass-API/issues/194

Danke für die Meldung.

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.

Viele Grüße,

drolbr

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.

Viele Grüße,

drolbr

Habe den Node 2097733279 über Overpass in Josm geladen Tag dispensing=yes gelöscht und danach versucht hochzuladen.

Ich bekam die Meldung
Hochladen fehlgeschlagen, da Server neuere Version … hat.
Der Punkt mit ID 2.097.733.279 löste den Konflikt aus.

Ich habe dann der Empfehlug nach den Datensatz synchronisiert.
Nach kurzer Zeit hatte Overpass den Punkt nicht mehr.
ich brach also das Hochladen ab.

Ich liebe Probleme die sich durch abwarten und nichtstun meinerseits erledigen :slight_smile:

Danke für deine Arbeit (und für die API an sich, die ist Gold wert!)

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.

Dann wird die Datenbank neu aus einem Planet-dump eingespielt, und (spätestens) dann ist die DB wieder konsistent.

Nö, dann fehlen da noch fast 2,5 Jahre Daily diffs, die da auch noch rein müssen.

Hä? der aktuelle dump ist http://planet.openstreetmap.org/planet/2015/planet-150202.osm.bz2

und der full-history ist vom selben Datum.

Gruss
walter

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.

Er sprach nur von Konsistenz, nicht von Aktualität…

Baßtölpel

LOL, was mach ich mit einer konsistenten, aber veralteten DB komplett ohne Historie?

Mal im Ernst: das neu Aufsetzen ist nicht in 2 Stunden gemacht, das dauert eher mal ne Woche oder so. Planet einspielen ist da noch das kleinste Übel.

Wenn ich das richtig verstehe, kann der Overpass-Import den Full-History-Planet nicht verarbeiten und benutzt daher die “Krücke” mit den Diffs?

Arnold würde dazu sagen: “Schwerer Fehler - ganz schwerer Fehler” :wink:

Gruss
walter

Genau richtig erkannt, der Import ist nicht für den Full history Planet ausgelegt.

Auf der anderen Seite sind im Full history Planet nochmal einiges mehr an Versionen drin, nämlich alles ab OSM Tag 0 im Jahr 2006 2005.