Hallo zusammen,
ich brauche Unterstützung bei einem Projekt auf Basis von OpenStreetMap. Ich arbeite an einer Webseite, deren Aufgabe es ist, eine Route entlang einer Straße zu finden. Die Straße ist zweigeteilt und hat jeweils einen Radweg und einen Gehweg.
Trotz intensiver Tests (seit über einer Woche) ist es mir bislang nicht gelungen, exakt die Radwege, die an der Straße liegen, so zu erfassen bzw. in der Routenerstellung zu nutzen, dass eine funktionierende Demo entsteht. Mein Ziel ist langfristig eine App zur Planung von Radtouren, aber aktuell scheitere ich schon an einer lauffähigen Web-Demo.
Viele der Seiten/Beispiele, auf die verwiesen wird, helfen mir leider nicht weiter, weil dort kein nachvollziehbarer Code bereitgestellt wird oder der Code für mich kaum verständlich ist.
Was ich vorbereitet habe
Ich schicke/teile zwei Dateien mit, die fast identisch sind – der einzige Unterschied ist die Position der ausgewählten Strecken. Damit möchte ich mein aktuelles Dilemma zeigen.
So lässt sich das Problem nachvollziehen (Repro):
Seite öffnen
auf „Route erstellen“ gehen
Ergebnis: Es ist aktuell nicht möglich, eine sinnvolle Route zu erstellen (wirkt wie „geht irgendwie nicht“ / „Blockade“).
Meine Bitte / Frage an euch
Habt ihr eine Idee, wie man Routing entlang getrennt geführter Radwege (parallel zur Straße, getrennt vom Gehweg) in OSM-basierten Anwendungen sinnvoll umsetzt, sodass ich erstmal eine funktionierende Demo als Grundlage aufbauen kann?
Mir geht es zunächst um den richtigen Ansatz (Datenmodell/Tags/Netz-Anbindung und typische Routing-Setups), damit die Routenerstellung zuverlässig klappt.
Danke euch vorab!
Viele Grüße
Lutz
Ich steh auf dem Schlauch, was du genau meinst. Könntest du einen Screenshot posten, wie es gerade ist auf der Karte bei dir dargestellt wird und einen, in den du reinmalst was du erwartest?
Zumindest OSRM macht da einen komischen unnötigen Schlenker:
OpenStreetMap
Vergiss OSRM fürs Fahrradrouting! Die Berechnung der Kantengewichte für path und footway sind seit Jahren fehlerhaft und bedürfen grundlegender Überarbeitung. Da wurden Parameter ungünstig benannt, sodass sie in den Parameterdateien falsch benutzt werden (statt Faktoren sind Geschwindigkeiten definiert). Zudem ist die Verrechnung der Parameter für surface, smoothness etc mit den jeweiligen Grundgeschwindigkeiten (alles wird einfach multipliziert) nicht sehr sinnvoll. Folge. Je mehr Attribute erfasst sind, um so unsinniger werden die Gewichte.
Hallo Metzor, wie gewünscht zwei Screenshots. Wie man auf den Bildern sehen kann, ist neben der Straße jeweils ein Radweg. Auf der Seite: “https://www.openstreetmap.org/way/869018133” kannst du nachlesen, dass es sich hierbei um einen Einrichtungsradweg handelt. Das Problem ist, dass man den Radweg nicht mit einer JavaScript-Abfrage, nicht mappen kann.
in der Debugmap kannst du die fehlerhaften Gewichte sehen. Die Fußwege sind mit 127 km/h natürlich viel schneller zu befahren ;)
https://map.project-osrm.org/debug/bike.html#15.9/52.5148/13.3585
Wenn es um das Routing von Radfahrern und Fußgängern geht, solltest du die auf osm.org vorhandenen Router ignorieren.
Schau dir besser “brouter” an, z.B. unter https://bikerouter.de. Die damit erstellten Routen sind in der Regel, auch in deinem Beispiel, sehr gut.
Vergiß nicht, es sind sogar 1024 km/h …, siehe Merkwürdige Fahrradroutenfindung - #16 by whb
… und Dein Bugreport ist immer noch offen: Incorrect weights for highway=path · Issue #6552 · Project-OSRM/osrm-backend · GitHub
aber zurück zum Topic hier:
Ich habe das Konzept noch nicht verstanden:
Mit Javascript von einem Router eine Route abfragen und anschließend mit Overpass zu schauen, was davon Radweg ist?
Selbst wenn man seine eigene Router- und Overpass-Instanz aufsetzt, sieht das nicht gerade sinnvoll aus.
Mir ist bewusst, dass es bereits verschiedene Router gibt (z. B. BRouter), die für Radfahrer und Fußgänger sehr gute Ergebnisse liefern. Genau deshalb habe ich mir diese Lösungen auch intensiv angeschaut.
Mein Ziel ist jedoch nicht, einen bestehenden Router zu ersetzen, sondern einen eigenen Router zu entwickeln, der sehr spezifische Anforderungen erfüllt, die mit bestehenden Lösungen so nicht oder nur sehr schwer abbildbar sind. Viele grundlegende Komponenten funktionieren bei mir bereits zuverlässig.
Das eigentliche Problem, an dem ich aktuell festhänge, betrifft die korrekte Behandlung von Radwegen auf Basis von OSM-Daten.
Konkret:
– In Overpass Turbo sehe ich einen sauberen, logisch nachvollziehbaren Verlauf von Radwegen (z. B. parallel zur Straße).
[out:json][timeout:25];
way"highway"~“path:bicycle|cycleway”;
out geom;
– Versuche ich jedoch, dieselbe Logik programmatisch (JavaScript) umzusetzen, bekomme ich dieses Ergebnis nicht reproduziert.
Ich habe mir den Code existierender Router angesehen, allerdings ist dieser oft stark optimiert, sehr speziell oder historisch gewachsen und dadurch kaum noch nachvollziehbar – selbst für KI-Tools nicht sinnvoll analysierbar. Die vorhandene Dokumentation hilft an dieser Stelle leider nicht weiter, da sie eher beschreibt dass etwas funktioniert, aber nicht warum oder nach welchen Entscheidungsregeln.
Mir geht es also nicht darum, „das Rad neu zu erfinden“, sondern zu verstehen:
-
welche OSM-Tags und Relationen für Fahrrad-Routing wirklich entscheidend sind
-
wie diese logisch gewichtet bzw. priorisiert werden
-
und wie man diese Logik sauber in eigenen Code überführt
Falls jemand hierzu konkrete Hinweise, Entscheidungslogiken oder eigene Erfahrungen aus der Praxis hat (insbesondere zur Diskrepanz Overpass ↔ programmgesteuerte Auswertung), würde mir das sehr helfen.
Vielen Dank!
Ich habe ein paar Dateien gebastelt, die als Entscheidungshilfen dienen sollen – sie sind aber noch nicht final.
wayRotationSystem.js.txt (15,9 KB)
osmCyclewayResolver.js.txt (29,3 KB)
bicycleContraflow.js.txt (27,8 KB)
cyclewayRotation.js.txt (25,8 KB)
cyclewayTopology.js.txt (47,2 KB)
Hallo,
ich arbeite seit fast zehn Jahren mit GraphHopper als Routing-Engine und habe für Kunden mehrfach Routing-Profile geschrieben. Von daher ist meine Arbeit bzgl. der Wahl der Routing-Engine etwas betriebsblind und das, was für mich „einfach“ ist, ist für jemanden ohne Kenntnis der Codebasis umständlich.
Die Nutzung der Overpass-API in einer neuen Anwendung ist in den meisten Fällen eine Fehlentscheidung. Wenn man nicht die Beziehung zwischen Relationen und ihren Mitgliedern oder die Referenzierung von Nodes durch Ways benötigt, sondern lediglich nur Punkt-, Linien- und Flächengeometrien in Form von Simple Features (GeoJSON beispielsweise) möchte und mittels räumlicher Abfragen abfragt, ist eine PostgreSQL-Datenbank mit der PostGIS-Erweiterung die schnellere und kurzfristg und langfristig sorgenärmere Alternative. Mit Postpass gibt es einen Online-Dienst ähnlich wie Overpass, nur mit einer PostgreSQL-Datenbank als Backend und SQL als Abfragesprache.
Im Kontext einer Routinganfrage ist aber auch das möglicherweise unnötig. Wenn man sich nur dafür interessiert, welche Attribute die benutzten Straßenstücke haben, kann man GraphHopper nutzen. Dessen /route-Endpunkt bietet einen Parameter details an. Diesem kann man Werte wie maxspeed, surface oder road_class übergeben. Die Antwort wird dann angeben, welche Stücke welche Attribute haben.
Aus Performance-Gründen (Speicherplatzoptimierung) sind nicht die Tags direkt, sondern davon abgeleitete Werte verfügbar. Die OSM-Tags werden je nach Key als Integer (ggf. mit Faktor), Boolean oder Enums abgelegt. Es wird nur eine bestimmte Auswahl an Tags unterstützt. Sie ist aber erstaunlich lang.
Um weitere zu unterstützen, muss man GraphHopper forken und in folgenden Packages Änderungen vornehmen: com.graphhopper.routing.ev, com.graphhopper.routing.util.parsers und in der Klasse com.graphhopper.routing.ev.DefaultImportRegistry. Das ist recht einfach, wenn man etwas Java und die Grundprinzipien objektorientierter Programmierung beherrscht.
Die Feststellung, ob ein gegebener Weg ein Radweg ist, ist anhand der Tags etwas umständlich. Es genügt nicht, allein highway=* auszuwerten. Ein highway=path kann ein Radweg (ggf. mit Freigabe für andere Verkehrsarten) sein, je nach dem, welche Access-Tags daran erfasst sind. Es kann aber abhängig von den Access-Tags auch ein Reitweg sein. Du müsstest also allein deswegen einen Encoded Value HorseRoadAccess ähnlich FootRoadAccess implementieren. Client-seitig müsstest du aus den Encoded Values für foot=*, bicycle=*, horse=* und highway=* die Straßenklasse ermitteln (oder serverseitig und in einen eigenen Encoded Value schreiben).
Für das Vorhandensein von Radwegen ist ein bunter Strauß an Tags relevant: cycleway=*, cycleway:(left|both|right)=*. Dafür gibt es keinen Encoded Values.
BRouter-Profile sehen zwar auf den ersten Blick so aus, als könnte man dort auf OSM-Tags direkt zugreifen. Das täuscht aber. Auch dieser legt nur eine – wenn auch größere Auswahl – an Tags effizient im Graphen ab. (Meine Erfahrung mit BRouter beschränkt sich auf ein paar Patches zu diversen Profilen)
Viele Grüße
Michael
Ich habe da mal ein kleines 
OSM-Radwege-Analyse-Tool gebastelt. Damit ist es möglich, verschiedene Radwege anzeigen zu lassen und deren Tags auszulesen.
A*-Algorithmus bzw. Dijkstra-Algorithmus, wenn ich es noch richtig im Kopf habe, aber zumindest gibt es einen speziellen Algorithmus, mit dem die Router arbeiten. Dann gibt es die Gewichtung der Kanten. Die ist routerspezifisch. Aber das ist reine Mathematik.
Am offnesten und am leicht zugänglichsten ist brouter, da kann man nach Herzenslust experimentieren.
Und es wird vermutlich rauskommen, wenn “dein” Router die Radwege zu deiner Zufriedenheit ansteuert, dass es soviel negative Seiteneffekte hat, sodass das Ganze nicht zu gebrauchen ist. Starke Gewichtung von preferierten Weg führt zu weiten Umwegen.
Du schreibst, dass Du sehr spezifische Anforderungen erfüllen möchtest, die andere Router nicht erfüllen können. Deine Fragen sind aber sehr allgemein.
Vielleicht beschreibst Du diese spezifischen Anforderungen mal. Dann könnte man da gezielter darauf eingehen. Vielleicht habe ich sie auch einfach nur überlesen.
Du kannst z.B. so darauf antworten (sinngemäß, gerne noch in deinem Stil glätten):
Ich glaube, wir reden aneinander ein wenig vorbei – mein aktuelles Tool ist wirklich nur ein Zwischenschritt, um genau diese „Warum?“‑Fragen der Router-Entscheidungen besser zu verstehen. Die kleine OSM‑Radwege‑Analyse, die ich verlinkt habe, soll mir vor allem zeigen:
-
welche Wege überhaupt als „Radweg“ in Frage kommen (inkl. Seitenradwege etc.),
-
welche Tags dort konkret gesetzt sind (z.B. cycleway=, bicycle=use_sidepath, sidewalk=, access‑Tags usw.),
-
und wie diese Kombinationen im Datenbestand in der Praxis vorkommen.
Die automatisch generierte Hilfe ist mir bewusst bisher nicht gut – die habe ich mir nur aus der Konfigurationsdatei erzeugen lassen, um schnell eine erste Basis zu haben, die ich im nächsten Schritt überarbeite. Das alles fließt aber in das eigentliche Projekt ein, bei dem ich einen eigenen Router mit sehr speziellen Anforderungen aufbauen möchte.
Wenn ihr möchtet, kann ich im nächsten Beitrag gerne genauer beschreiben,
-
welche Situationen mein Router besonders gut abdecken soll (z.B. getrennte Rad-/Gehwege, bestimmte Konfliktsituationen, spezielle Bevorzugung/Benachteiligung bestimmter Infrastrukturtypen),
-
und welche Entscheidungen mir bei bestehenden Routern problematisch erscheinen (z.B. Umweggrenzen, Umgang mit use_sidepath, Komfort vs. Kürze der Strecke).
Dann wird wahrscheinlich klarer, in welche Richtung die „sehr spezifischen Anforderungen“ konkret gehen sollen.
Jo, mach das doch mal bitte.
Fehler mit copy & paste?
Verwende bitte keine KI (LLM) um Dir Antworten schreiben zu lassen. Hier wird sehr viel Wert darauf gelegt, dass echte Menschen miteinander kommunizieren. Und das ist jetzt noch sehr wohlwollend ausgedrückt.
So pauschal und grundsätzlich möchte ich mich dem nicht anschließen. Wenn diese jemanden erst ermöglichen sich hier zu beteiligen - aus welchen Gründen auch immer -, dann ist das für mich OK.
Ein Hinweis, dass LLM verwendet werden, wäre aber gut.
@OSM_RogerWilco, @Mammi71, danke – ich gehe gern konkreter darauf ein.
Vorab ein Transparenzpunkt zur KI-Diskussion: Durch einen Unfall habe ich Schwierigkeiten, meine Gedanken ohne Hilfe schnell und sauber in Text zu bringen. Deshalb nutze ich ein selbst gebautes Tool für Sprache → Text und eine automatische Rechtschreib-/Grammatikprüfung. In manchen Fällen nutze ich zusätzlich ein LLM, um Text zu strukturieren oder sprachlich zu glätten. Inhaltlich ist das aber mein Text: Anforderungen, Beispiele und Schlussfolgerungen kommen von mir, und ich beantworte Nachfragen selbstverständlich selbst.
Zum eigentlichen Thema (Router/Route-Workflow): Mein Ziel ist eine Tour, die reale Abläufe abbilden kann, z. B.:
-
Start zu Hause mit dem Fahrrad → Bahnhof
-
Zugfahrt (mit sinnvollen Zwischenhalten/Umstiegen)
-
Weiterfahrt mit dem Fahrrad
-
ggf. Übersetzen per Fähre (z. B. Elbe/Fährhafen)
-
am Ende Export als eine GPX-Tour
Dabei ist mir wichtig:
-
Die Route soll als zusammenhängende Tour vorliegen (nicht ständig in separate Teilstücke zerfallen).
-
Die Führung soll praktikabel und korrekt sein (z. B. Radwege/Wegeführung, sinnvolle Seiten-/Richtungslogik dort, wo relevant).
-
Ich brauche einen Workflow, der das Zusammenstellen solcher Touren schnell möglich macht.
Deshalb mache ich das in Teilprojekten: z. B. ein Modul, das mir Bahnstrecken zwischen Start-/Zielbahnhof inkl. Zwischenbahnhöfen (aus dem Fahrplan) als Strecke zeichnet, damit ich die Tour unterwegs auch verfolgen kann.
Und als aktuelles Zwischenprojekt: Ein Tool, das vorhandene Radwege/Wege-Abschnitte in einem Gebiet explizit sichtbar und anklickbar macht, damit man sich daraus eine Route „zusammenklickt“ – also nicht „Router sagt dir den Weg“, sondern „ich wähle gezielt die Infrastruktur, die ich fahren möchte“.
Was man damit konkret macht:
- Ziel: Ich will nicht nur „kürzeste Strecke“, sondern z. B. bewusst an einer bestimmten Straße entlang, auf einer bestimmten Radwegführung, mit bestimmten Kreuzungsentscheidungen. Das Tool soll mir dabei helfen, aus dem OSM-Netz genau die passenden Segmente zu wählen.
So funktioniert der Workflow aktuell:
-
Positionieren / Startbereich finden
In der linken Sidebar gibst du einen Ort, eine Adresse oder einen POI ein. Das Tool navigiert die Karte dorthin. Je präziser die Eingabe ist, desto besser passt der Startpunkt (und die spätere Segment-Auswahl wird übersichtlicher). -
Grobe Orientierung setzen
Mit einem Klick lässt du dir eine erste grobe Route/Orientierung erzeugen. Das ist noch nicht „die finale Route“, sondern eher ein Hinweis: in diese Richtung soll es grundsätzlich gehen. Das erleichtert die Auswahl der relevanten Segmente. -
Radwege/geeignete Wege visualisieren
Danach klickst du in der Sidebar auf „Wege laden“. Erst dadurch werden die in OSM vorhandenen Radwege/geeigneten Wege im aktuellen Kartenausschnitt eingeblendet (inkl. der ableitbaren Richtungs-/Einbahnlogik). -
Route manuell aus Segmenten zusammenstellen
Dann wählst du per Klick einzelne Wege-/Straßenabschnitte aus und fügst sie deiner Route hinzu. Das ist bewusst „händisch“: Ich will nicht, dass ein Router „irgendeine“ Strecke vorschlägt, sondern ich will die Route so zusammensetzen, dass sie meinen Kriterien entspricht. Typische Entscheidungen sind z. B.:-
nehme ich den separaten Radweg oder die Fahrbahn?
-
gehe ich auf eine ruhige Nebenstraße statt auf die Hauptstraße, auch wenn das 200–500 m Umweg bedeutet?
-
Gerade an Kreuzungen unterscheiden sich die Optionen oft stark, und „automatisches Routing“ nimmt dort nicht immer die Variante, die man als Mensch bevorzugt.
-
-
Wichtig: Man muss nicht jeden Meter anklicken. In der Praxis reicht es meistens, die längeren, klaren Hauptabschnitte auszuwählen. Kurze Stücke entstehen häufig nur als „Lücken“ im Übergang an Kreuzungen, Einmündungen oder bei sehr kleinteiligen OSM-Geometrien. Diese Lücken kann man später entweder gezielt ergänzen oder – wenn es passt – über den Button zum Lücken schließen automatisch verbinden lassen.
https://gabischatz.de.cool/tools/osm-radwege/rad.html
Also wenn ich das Ganze händisch machen würde, was vielleicht Dir als Blaupause für Deinen automatisierten Prozess dienen kann, dann wäre die Vorgehensweise folgende:
- Relevante Wegsegmente des Zielgebietes mit Overpass-API runterladen,
- als GPX abspeichern,
- als Ebene in BRouter laden.
Damit siehst Du, wo die von Dir präferierten Wege sind.
- Dann würde ich das Routing-Profil sicherste Verbindung verwenden,
- dort vielleicht Deine präferierten Wegearten noch höher gewichten,
- rechnen lassen,
- in Deinem Sinne korrigieren.