Ich entwickle aktuell eine Anwendung, die aufgezeichnete GPS-Tracks (Radrouten) automatisiert in routingfähige Strecken überführen soll. Grundlage sind dabei OSM-Daten, die ich zur Laufzeit über die Overpass API abfrage.
Das zentrale Problem: Die Anwendung erzeugt zwangsläufig viele, teilweise sehr ähnliche bzw. sich überlappende Overpass-Abfragen entlang der Strecke (z. B. segmentweise Auswertung von Ways im Umkreis der Trackpunkte). In der Praxis führt das regelmäßig zu folgenden Effekten:
HTTP 500 / 504 (Gateway Timeout)
Abgebrochene Requests („Failed to fetch“, „signal is aborted without reason“)
Verbindungsfehler (ERR_CONNECTION_TIMED_OUT)
CORS-Probleme bei einzelnen Instanzen
Am Ende: kompletter Ausfall aller getesteten Overpass-Server
Beispiel aus dem Log:
Error: Alle Overpass-Server nicht erreichbar
at fetchOverpass (…)
at async loadRoute (…)
Meine Vermutung ist, dass ich durch die hohe Frequenz und Ähnlichkeit der Anfragen in Rate-Limits, Query-Timeouts oder serverseitige Schutzmechanismen laufe. Besonders kritisch scheint die wiederholte Abfrage nahezu identischer Bounding Boxes entlang der Route zu sein.
Rahmenbedingungen:
Clientseitige Webanwendung (Fetch API)
Dynamisch generierte Overpass-Queries
Verarbeitung erfolgt abschnittsweise entlang des Tracks
Kein eigener Server / keine lokale OSM-Datenhaltung bisher
Bisher getestete Ansätze:
Wechsel zwischen verschiedenen Overpass-Instanzen
Reduktion der Query-Größe (kleinere BBoxes)
Retry-Logik bei Fehlern
→ ohne nachhaltige Verbesserung
Meine Fragen:
Welche Strategien sind für diesen Use Case sinnvoll, um Overpass-Abfragen effizienter zu gestalten? (z. B. Query-Batching, Generalisierung, Zusammenfassen von Segmenten)
Ist clientseitiges Arbeiten mit Overpass hier grundsätzlich ungeeignet?
Würde sich der Einsatz einer eigenen Overpass-Instanz oder alternativ ein anderer Stack eher anbieten? Und wie kann ich eine solche Instanz erzeugen?
Gibt es Best Practices, um solche „Track → routingfähige Geometrie“-Probleme OSM-konform zu lösen?
Falls jemand ähnliche Probleme hatte oder einen etablierten Ansatz kennt, wäre ich für Hinweise sehr dankbar.
So wie ich heute immer nichts von Overpass bekomme, würde ich sagen, das Problem liegt nicht bei dir. Ich hatte heute keine einzige erfolgreiche Anfrage.
Aaaalso… wenn du bei einem Track mit einem Aufzeichnungsintervall von 1m oder 5m so für jeden Trackpunkt eine Overpass-Abfrage erstellst würde ich an deiner Stelle drüber nachdenken eine eigene Overpass-Instanz aufzusetzen oder etwas mehr Gehirnschmalz in deine Anwendung zu stecken ;)
Hier ist eine kleine Testversion, um einen bestimmten Routenbereich abzufragen.
Letzter Test: 3 Minuten, bis er überhaupt die Relationenabfrage angezeigt hat, um die zwei Punkte setzen zu können.
Die Overpass-Server sind mehr oder weniger tot. Bedanken dürft ihr euch dafür bei AI-unterstützter Programmierung, die tonnenweise Code erzeugt, der dann als Massenanfrage auf den Servern endet. Machen kann man da nicht viel, da oft die Anwender nicht einmal wissen, dass diese Anfragen passieren und entsprechend Fehlerrückmeldungen oft nicht mal bemerkt werden.
Wenn sich jemand engagieren möchte, die Server gegen die AI-Code-Armee fit zu machen, gerne bei mir oder jemanden anders von der Fossgis-Servergruppe melden.
Und ja, die angesprochene Anwendung ist ein Beispiel für die Probleme mit denen die Server-Admins zu kämpfen haben. Die “Cloud” ist nicht so ein virtuelles Ding, was einfach herumschwebt, sondern hinter jeder Anfrage stehen Rechenresourcen, die irgendwie aufgebracht, bezahlt und gemanagt weden müssen. Und Overpass wird eben nicht von irgendeinem Internet-Giganten betrieben, der eh zuviel Geld verdient, sondern von einer Handvoll Freiwilligen und einem Verein, der nicht gerade reich an Resourcen ist.
Hallo zusammen,
ich möchte als Entwickler eines gemeinnützigen Tools zur Validierung von Radstrecken meine Erfahrungen und Fragen zur Nutzung der Overpass-API teilen – insbesondere aus der Perspektive kleiner, nicht-kommerzieller Projekte, die keine Massenabfragen stellen, sondern sinnvolle, serverfreundliche Lösungen entwickeln möchten.
1. Das Kernproblem: Warum scheitern kleine Projekte oft?
Keine einheitliche Abfrage für Radwege: In OSM gibt es keinen einzelnen Tag wie radweg=ja. Stattdessen müssen Dutzende Kombinationen (z. B. highway=cycleway, bicycle=designated, cycleway:right=lane, relation[route=bicycle]) abgefragt werden. Eine „Alles-in-Einem“-Abfrage wäre ineffizient und serverbelastend.
Fehlende klare Leitfäden: Viele offizielle Links sind veraltet oder unvollständig. Es gibt keine zentrale Anleitung, wie man Radwege-Abfragen effizient und serverfreundlich gestaltet – besonders für Entwickler:innen ohne OSM-Erfahrung.
Risiko der Server-Überlastung: Ohne klare Beispiele neigen Unerfahrene dazu, zu breite Abfragen zu stellen (z. B. „alle Radwege in Deutschland“), was die Infrastruktur unnötig belastet.
Mein Ziel ist es, eine saubere Routenprüfung für Radstrecken zu entwickeln, die auch anderen frei zur Verfügung steht – ohne die Server zu überlasten.
2. Was würde kleinen Projekten helfen?
a) Ein „Best-Practice“-Dokument für typische Use Cases
Vorgefertigte Beispielabfragen für gängige Szenarien:
„Alle klassischen Radwege (highway=cycleway) in Bounding-Box X“
„Alle Radrouten (relation[route=bicycle]) mit Netzwerk-Tag (z. B. network=ncn)“
„Radfahrstreifen an Straßen (cycleway=lane) in Stadt Y“
Erklärungen, warum welche Tags relevant sind (z. B.: „Warum bicycle=designated und nicht nur highway=cycleway?“).
b) Klare Richtlinien für serverfreundliche Nutzung
Wie begrenzt man den Bereich? (Nutzung von {{bbox}} oder {{geocodeArea:City}})
Wie vermeidet man Timeouts? (Hinweis auf timeout:30; oder maxsize:1073741824)
Wie cachet man Ergebnisse lokal? (Beispielcode für SQLite/JSON-Speicherung)
Wann lohnt sich ein lokaler Overpass-Server? (Anleitung für Docker-Installation)
c) Unterstützung für Entwickler:innen ohne OSM-Erfahrung
Warnung vor „Alles-in-Einem“-Abfragen: „Eine Abfrage wie way[bicycle]({{bbox}}) klingt einfach, belastet aber den Server extrem – besser mehrere kleine Abfragen für highway=cycleway, cycleway=lane etc.“
Empfehlung für Testumgebungen: „Nutzen Sie Overpass-Turbo zum Ausprobieren, bevor Sie Abfragen in Ihr Programm einbauen.“
3. Meine konkreten Fragen an die Community
Da ich keine kommerzielle Anwendung entwickle, sondern ein kostenloses Tool für Radfahrer:innen, würde ich mich über Antworten zu folgenden Punkten freuen:
Gibt es bereits empfohlene Limits für nicht-kommerzielle Nutzung?
(Z. B. „Maximal 1 Abfrage pro Sekunde“ oder „Bounding-Box nicht größer als 50 km²“?)
Wo finde ich aktuelle Beispielabfragen für Radwege/Radrouten?
(Viele Links im OSM-Wiki sind tot – gibt es eine gepflegte Sammlung?)
Wäre ein lokaler Overpass-Server oder ein Cache-Ansatz für meinen Use Case sinnvoll?
(Ich möchte die App auch anderen zur Verfügung stellen – wie vermeide ich, dass Nutzer:innen unbewusst die Server überlasten?)
Wie richte ich einen lokalen Overpass-Server ein?
(Gibt es eine einfache Anleitung für Docker/Offline-Tests?)
4. Mein Appell: Kleine Projekte brauchen klare Leitlinien – nicht harte Einschränkungen
Ich verstehe die Notwendigkeit, die Overpass-Server zu schützen. Gleichzeitig sollten private oder gemeinnützige Entwickler:innen nicht durch fehlende Dokumentation ausgebremst werden, sondern durch praktische Beispiele und Best Practices unterstützt werden.
Mein Ziel ist es, eine Lösung zu entwickeln, die sowohl technisch korrekt als auch serverfreundlich ist – und die anderen als Vorlage dienen kann.
Falls jemand Beispielcode, aktuelle Links oder Tipps hat, wäre ich sehr dankbar!
Mit freundlichen Grüßen,
Lutz Müller
PS: Falls es bereits ein „Best-Practice“-Dokument gibt, das ich übersehen habe – bitte gerne verlinken! Viele offizielle Quellen sind leider veraltet oder unvollständig.
Okay, ich verwende KI, das habe ich nie bestritten. Ich hatte mich auch schon mal dazu geäußert. Für mich ist es ein Werkzeug, um meine Gedanken zu ordnen und sie auf den Bildschirm zu bekommen. Ich versichere Dir, Du willst nicht meine Rechtschreibung, Grammatik usw. lesen. Du würdest nicht verstehen, was ich überhaupt zum Ausdruck bringen möchte. Viele Leute, die meine Briefe vor KI-Zeiten gelesen haben, werden sagen, dass ich Verschachtelungen verwende, die erst einmal in Einzelteile zerlegt und wieder zusammengesetzt werden müssen. Ich denke halt nicht geradlinig.
Und der Starter des Threads ist ein Beispiel dafür. Wer die Maschine arbeiten lässt, anstatt sich vernünftig Gedanken über ein gescheites technisches Design zu machen, braucht sich nicht wundern, wenn unnötig viele Anfragen an Server gestellt werden. Bei manchen Anwendungen ist eine eigene Datenhaltung mit eigener API sinnvoller.
Manchmal ist die naheliegende Lösung, Daten einfach irgendwie räumlich abzufragen, zwar sehr gebräuchlich, aber nicht für den eigenen Anwendungsfall passend. Dabei gab es im Thread zur Anwendung schon einen ersten Hinweis.
Ich habe leider nicht die Kapazität, hier fachliche Entwurfshinweise zu geben. Mein verfügbares Zeitbudget ist begrenzt. Das investiere ich dort, wo ich davon ausgehe, dass der Empfänger in der Lage ist, mit den gegebenen Hinweisen selbstständig sein Wissen weiter zu erweitern, oder wenigstens künftig Leute beim Suchen darauf stoßen. Vielleicht scheitert es vorliegenden Fall einfach am Verständnis der Fachbegriffe und an der Fähigkeit, die genannten Begriffe als Ansatzpunkte für eigenständige Recherchen zu verwenden?
Im Thread zur Anwendung gibt es mittlerweile eine weiteren, konkreteren Hinweis, wie man die Aufgabenstellung richtig löst.
Das tue ich auch jetzt nicht. Ich habe nur auf dein “PS” geantwortet.
Aus den anderen Themen entnehme ich, dass du dir so ziemlich alles von KI erstellen lässt. Das fängt beim Quellcode an und endet bei kompletten Forenbeiträgen. Das kannst du ja alles machen, aber am Ende bist du verantwortlich für das, was dabei herauskommt. Du und niemand anderes.
Daher mein Tipp: Wenn du nicht weisst, was deine Anwendung eigentlich so im Hintergrund macht und was das für Auswirkungen hat, solltest du es besser sein lassen. Oder, und da schließe ich mich @Nakaner an, du setzt dich hin und entwirfst basierend auf den bereits gegebenen Tipps etwas eigenes.
Ich möchte noch einmal eines klarstellen: Ich habe seit 1994 in der PC-Branche gearbeitet und bin ausgebildeter Wirtschaftsinformatiker. Also ich weiß sehr wohl, was ich tue.
Das würde gehen, wenn Mapper die Abfragen erstellen. Aber wenn ich eine Webservice betreibe, der bei Aufruf alle Parkbänke im Stadtpark lädt nicht mehr, weil dann kommt die Abfrage ja von meinem Kumpel. Ich denke an sinnvollen Ideen mangelt es nicht.
Aber eine “Fast-Lane” für “aktive Mapper” wäre zumindest im Sinne von OSM. Muss halt nur wer programmieren → Siehe der Aufruf
on this forum.