ich bastle mal wieder an einer kleinen Statistik. Dabei ist es mir passiert, daß der API-Aufruf /api/0.6/node/xxxxx zu einem reproduzierbaren Fehler 404 führt. (Ich meine hier nicht gelöschte Objekte, die kommen nämlich mit visible=false.) Beispiel: http://api.openstreetmap.org/api/0.6/node/909050879, im Webinterface http://www.openstreetmap.org/browse/node/909050879 wird der 404 “maskiert”. Jetzt gibt es natürlich zwei Möglichkeiten:
a) Das gehört so.
b) Das gehört nicht so, Datenbank-/Serverfehler?
a) könnte ich mir so vorstellen, daß z.B. beim Upload ein Objekt angelegt bzw. die Objekt-ID reserviert wird, dem Server dann auffällt, daß das Changeset einen Konflikt enthält und Objekte nicht in die Datenbank übernommen werden, die ID aber “verbraucht” ist. (Der Datenbankserver hält zum Anlegen neuer Objekte sicher keine Liste noch freier, niedrigerer IDs vor, sondern nur die bisher höchste ID in der Datenbank.)
Ja, das siehst Du richtig, und ja, das ist mir bewußt. (Und bevor der Hinweis kommt: API usage policy habe ich gelesen.)
Allerdings denke ich nicht, daß der Server damit wirklich “gequält” wird. Es geht bei den jetzigen Tests des Programms um wenige hundert History-Abfragen für jeweils einen Punkt, wo ich auch noch eine künstliche Verzögerung eingebaut habe (eben um den Server nicht punktuell zu sehr zu belasten). Also über einige Minuten verteilt ungefähr das, was das Revert-Plugin für JOSM - natürlich gemäß der eigentlichen Bestimmung des API - in einem Aufwasch abfragt. XAPI steht im Moment nicht zur Verfügung, sonst würde ich das benutzen.
Die eigentliche Statistik, die im Moment noch nicht läuft, wird eher um die 100.000 Abfragen brauchen, was dann fraglos dem API-Server nicht mehr zuzumuten ist. Wenn Dir Alternativen einfallen, immer her damit. (Eine eigene Datenbank scheidet aus, und planet.osm nützt mangels Objekthistorie auch nichts.)
Auf der Mailingliste (Thread “JOSM: kann keine Änderungen mehr hochladen”) war gestern gerade die Rede von heftigen Datenbank-Locks, die sich gegenseitig blockierten und einzelne Objekte, u. a. auch Nodes vor Veränderungen schützten. http://munin.openstreetmap.org/openstreetmap/smaug.openstreetmap/postgres_locks_openstreetmap.html
Dies wurde durch einen “Tritt gegen den Server” bereits behoben.
Laut der (aktuell leider bereits unvollständigen) Statistiken könnte sich das bereits schon ab dem 18. aufgebaut haben.