Kann es sein dass Overpass-api nicht mehr aktualisiert

Ich habe heute morgen einen Node in der Datenbank gelöscht.
Die Overpass-Turbo Abfrage liefert jetzt auch nach 7 Std noch immer den Node.
In OSM http://www.openstreetmap.org/node/2097733279 und im Josm ist er weg.
Die Zeiten
“timestamp_osm_base”: “2015-02-04T16:08:02Z”,
“timestamp_areas_base”: “2015-02-04T05:24:03Z”,
aus der Overpass-Turboabfrage kann ich nicht deuten, aber osm-base läuft weiter.
Direkte Anfrage bei der Overpass-Api liefert auch immer noch den Node.

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;

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/replication/minute/001/252/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/replication/minute/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,

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.

Siehe #4, das Löschen ist in den Diffs 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.