Kann es sein dass Overpass-api nicht mehr aktualisiert

Da ist irgendwas grundlegendes in der Replikation kaputt. Das Problem lässt sich auf allen 3 Instanzen (overpass-api.de, overpass.osm.rambler.ru und api.openstreetmap.fr) reproduzieren. Frag mal am besten auf IRC unter osm-dev nach.

node(2097733279);out meta;

couchmapper wrote:

Frag mal am besten auf IRC unter osm-dev nach.

node(2097733279);out meta;

Wie geht das?

Die Änderung ist in der minute replication drin:

␣<delete>
<node␣id="2097733279"␣version="2"␣timestamp="2015-02-04T09:15:10Z"␣uid="577895"␣user="gmbo"␣changeset="28606682"␣lat="51.4584871"␣lon="7.1981289"/>
</delete>

http://planet.openstreetmap.org/replica … 215.osc.gz

Von 08:01 bis zu dieser Datei um 09:18 gab es der Datei-Liste nach eine Pause (siehe http://planet.openstreetmap.org/replica … e/001/252/ ), die Datei ist jedoch relativ groß (1.7M), also vermutlich alles drin.

Hab gerade mal im irc auf #osm-dev nachgefragt. Es gab heute morgen einen kleinen Schluckauf mit den "minutely diffs", das wurde aber wieder gefixt.
Nominatim und Mapnik sehen aktuell ok aus, es liegt also definitiv nicht an der Replikation.

Was mit den 3 Overpass-Instanzen los ist, weiß ich leider auch nicht. Finde diesbzgl. keine Infos.

In Mapnic sehe ich den Punkt noch auch wenn er eigentlich ja weg ist.
wie ich das in Nominatim finde oder nicht weiß ich nicht.
http://overpass-turbo.eu/s/7ua
findet immer noch eine Apotheke obwohl sie heute morgen gelöscht wurde.
Könnte es also sein, dass ich die zu einem ungünstigen Zeitpunkt gelöscht habe und der nicht von den Diffs erfasst ist.

Hallo,

gmbo wrote:

Könnte es also sein, dass ich die zu einem ungünstigen Zeitpunkt gelöscht habe und der nicht von den Diffs erfasst ist.

wenn Du den Punkt einfach noch mal löschst?

In Mapnik kann ich das Löschen auch nicht nachvollziehen. TomH meinte aber, dass die pharmacy bei ihm nicht mehr gerendert wird. Für Nominatim habe ich einfach mit dem Namen der Apotheke in Bochum gesucht, da kam nichts mehr hoch.

Könnte es also sein, dass ich die zu einem ungünstigen Zeitpunkt gelöscht habe und der nicht von den Diffs erfasst ist.

Siehe #4, das Löschen ist in den Diffs drin.

ikonor wrote:

Die Änderung ist in der minute replication drin:

Von 08:01 bis zu dieser Datei um 09:18 gab es der Datei-Liste nach eine Pause (siehe http://planet.openstreetmap.org/replica … e/001/252/ ), die Datei ist jedoch relativ groß (1.7M), also vermutlich alles drin.

Aus dieser Datei sind einige Sachen nicht übernommen worden, nicht nur die gelöschte Apotheke...

Ja, fehlt wohl mehr als drin ist, mal ein paar Stichproben:

//␣creates
(
node(3329590092);␣//␣2015-02-04T08:01:17Z␣-␣vorhanden
node(3329610493);␣//␣2015-02-04T08:12:56Z␣-␣fehlt␣(pharmacy)
node(3329593222);␣//␣2015-02-04T08:15:54Z␣-␣fehlt
node(3329639378);␣//␣2015-02-04T09:12:56Z␣-␣fehlt␣(restaurant)
node(3329656924);␣//␣2015-02-04T09:17:53Z␣-␣fehlt
);
out␣meta;

http://overpass-turbo.eu/s/7uq

Weiß Roland eigentlich schon Bescheid?

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.

drolbr wrote:

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.

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

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

gormo wrote:

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

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.

gmbo wrote:

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.

wambacher wrote:

gmbo wrote:

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?

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

gormo wrote:

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.

couchmapper wrote:

gormo wrote:

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/ … 02.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.

couchmapper wrote:

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.

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" 😉

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.