So wars angedacht ja. Im Moment hab ich einen delay von 5s zwischen den Abfragen eingebaut
Habs glaub ich eh schon mal erwähnt.
Ich möcht regelmäßig route Relationen auf Durchgängigkeit prüfen.
Die Abfrage erfolgt Anhand der Relations ID.
Daraus erstelle ich einen Graphen den ich dann überprüfen kann.
Das Ergebnis wird mir dann per Mail geschickt.
Damit ich nicht immer alle Relationen händisch mit osmsurround überprüfen muss.
@Nakaner: Ja die Seite hab ich mir eh schon reingezogen. Danke
Mit den 10000 Anfragen und 5 GB/Tag wirst du sicher auskommen. Man wird die Grenze wohl etwas relativ sehen müssen. Vermutlich wären 10000 komplizierte Anfragen mit kräftig erhöhtem Timeout ein Problem. Da du bei deinen Anfragen die ID schon hast, sollte dies für die Overpass-API aber extrem einfach sein und der Aufwand ergibt sich nur noch durch die Datenmenge.
Ein kleiner zeitlicher Abstand zwischen den Anfragen ist natürlich nicht verkehrt, zumal er nicht stören dürfte. Wenn das ganze automatisch gestartet wird, würde ich eine krumme Uhrzeit verwenden. Nicht das z.B. um 2 Uhr nachts von diversen Nutzern gleichzeitig automatische Abfragen starten.
Normalerweise wäre ein aussagekräftiger User-Agent schon hilfreich, damit bei Problemen schneller klar ist, woher die Anfragen kommen und wer ggfs. kontaktiert werden kann. Allerdings werden 100-120 Relationen pro Woche komplett im Grundrauschen untergehen, also hier ein eher vernachlässigbares Problem.
Die Usage Policy wurde schon genannt. Wenn die Anfragen zu viel Last erzeugen (würden) und/oder zu kurz aufeinanderfolgen, wird normalerweise ein HTTP 429 Fehlercode zurückgegeben. In dieser Situation hilft es, einfach die Pausen zwischen den Abfragen hochzusetzen. In einigen Fällen waren Timeout oder maxsize astromisch groß gewählt, so dass die Abfragen immer abgelehnt wurden. Beides lässt sich für die eigene Query selbst entsprechend anpassen.
Fehlercodes auswerten wurde auch genannt und ist ein wichtiger Punkt. Es gab in der Vergangenheit den einen oder anderen nicht ideal implementierten Client, der ohne Rücksicht auf den Return-Code einfach fleissig weiter Abfragen abgesetzt hat.
Vielleicht mal ein gutes Thema für die Wiki-Seite…