GraphHopper Routenplaner

Ich schwinge hiermit mal etwas die Werbetrommeln für GraphHopper, insbesondere auch für GraphHopper Maps: http://graphhopper.com/maps/

Klar gibt es noch viel zu tun, gerade die Abbiegevorschriften und -anweisungen werden immer wieder genannt. Aber ich denke für Fahrradrouten ist GraphHopper nun ganz nützlich und liefert nicht nur Höhendaten mit, sondern berücksichtigt diese auch beim Routen um Berge zu vermeiden. Nebenbei: Dank an Nop! Es steht auch ein interessanter pull requests aus, der es möglich macht Touren zu planen mit mehreren Zwischenpunkten. Da ist nur noch etwas Feinarbeit notwendig, eventuell hat ja jmd Interesse auszuprobieren oder zu verbessern: https://github.com/graphhopper/graphhopper/pull/227

Ein Problem gibt es, worüber ich Eure Meinung hören würde. Wenn man z.B. von Krakau nach Berlin routen will so schlägt das fehl: http://graphhopper.com/maps/?point=krakow&point=berlin. Der Grund ist dass man von den erhaltenen Geokoordinaten im Zentrum Krakau nicht aus dem Gebiet rauskommt. Rein dagegen schon: http://graphhopper.com/maps/?point=berlin&point=krakow. Manchmal ist das ein OSM Fehler, manchmal auch etwas anderes wie verschiedene Tags wo GraphHopper in der einen Richtung die Zufahrt sperrt (access=private). Es gibt nun in der neuesten Version einen Fix dafür. Jedoch führt dieser dazu, dass die problematischen Gebiete entfernt werden und GraphHopper dadurch andere Punkte zum Routen nimmt. Dadurch werden potentielle OSM Probleme eventuell verschleiert, hmmh … obwohl: man sieht ja dass der Marker auf einer anderen Straße ist und nicht direkt am Ende der eigentlichen Route. Also: wie findet ihr den Fix mit dem Löschen dieser Gebiete? (löschen natürlich nur innerhalb graphhoppers)

Weiterhin wäre es interessant ob und wie man GraphHopper in JSOM verwenden könnte. Ist ja beides in Java.

Die GraphHopper Web API kann man auch in eigenen Applikationen verwenden. Allerdings, oh Schreck, nicht kostenlos: http://graphhopper.com/#enterprise. Mit dieser API wird es bald auch möglich sein Distanzmatrixen zu berechnen, da muss ich aber noch die genaue API festlegen.

Dass ich auch gerne etwas an die OpenStreetMap Community zurückgeben möchte, seht ihr - hoffentlich :wink: - in der folgenden Initiative wo routing endlich auch direkt auf osm.org verfügbar sein soll. Mit verschiedenen Routing providern wie GraphHopper: https://github.com/openstreetmap/openstreetmap-website/pull/716. Leider ist dieser pull request irgendwie ins stocken geraten. Also wenn es da jmd. mit JavaScript Kenntnissen gibt, gerne fixen! Apropos JavaScript devs, GraphHopper läuft auch offline im Browser: http://wp.me/p8zlh-14Q

In der GraphHopper Routing API, ist auch ein Geocoder mit weltweiter Abdeckung enthalten der durch Photon bereitgestellt wird. Photon wird von Christoph (komoot) und Yohan entwickelt und man kann hier von vielen neuen Fortschritten lesen: https://github.com/komoot/photon. Apropos komoot, siehe dazu auch http://graphhopper.com/#usecases und indirekt auch deren Blog.

Eine Frage gibt es auch häufig: wie oft liest GraphHopper die OSM Daten neu ein?
Ziel ist es das täglich zu machen und 100% zu automatisieren, aber ohne downtime. Und das ist schwieriger als gedacht, aber es wird evtl. in ein paar Woche soweit sein. Geduld ist da also gefragt oder Admins mit Java Background bei mir melden.

Eine klassische Fahrradsenke. Man sollte in Krakau (oder wie heißt das heute politisch korrekt? :slight_smile: ) einen Gebrauchtfahrradankauf aufmachen! :laughing:

Gruß,
Zecke

Finde ich ok. Ich bin es gewöhnt, dass das Ende der Tour auch mal ein Stück vom angeklicken Punkt entfernt ist. Ich bin allerdings auch ein Nutzer, der eine Route auf einer Landkarte zusammenklickt. Einer, der Adressen eingibt, sieht das vielleicht anders.
Ihr löscht aber hoffentlich nur für das Auto-Profil, für Fußgänger bleibt die Krakauer Innenstadt trotzdem erreichbar?

Schön zu lesen! Ich fände es gut, wenn osm.org mit einem ordentlichen Fußgänger- und Radrouter ausgestattet wäre (und auch für sonstige exotische Fortbewegungsarten ohne bisher entdeckte Marktrelevanz). Da sind wir in vielen Gegenden besser als andere und Auto kann jeder (*)

Grüße, Max

(*) Nicht ernst gemeint, ich habe grossen Respekt vor jedem, der Verkehrsregeln algorithmisch nachbilden kann. Ich kanns nicht.

Hi,
hier wird eine Straße nicht dargestellt in Lyrk:

http://graphhopper.com/maps/?point=51.761326%2C7.890737&point=51.760635%2C7.892915&vehicle=foot&elevation=true

Na, immerhin stellt die Map auch den indoor tag highway=corridor dar, und gibt den richtigen Weg für Fußgänger aus. Ist doch ok.
Vermisse bloß in den Innenstädten den tag bei den sehr beliebten Passagen. Kennt den noch keiner? OK, Indoor-Mapping. Sehr suspekt. :confused: :roll_eyes:

http://graphhopper.com/maps/?point=50.815012%2C7.155404&point=50.813629%2C7.156729&vehicle=foot&elevation=true

Anhang: Sorry, mit “immerhin” meinte ich die Fußgänger-Navigation.

Für’s Auto in der Innenstadt von Köln eine absolute Katastrophe. Bei dem Routing in der Innenstadt wird jeder Fremder “wahnsinnig”. :confused:

http://graphhopper.com/maps/?point=50.928114%2C6.989858&point=50.944125%2C6.931429&vehicle=foot&elevation=true

Hallo,
ich kenne das Dilemma (Fehler für Community zeigen oder für Nutzung auszubügeln) recht gut. Meine Entscheidung ging zum versuchten Ausbügeln. Das “Tool” ist halt kein Fehlerfindetool, sondern ein Router und der sollte in erster Linie gute Routen berechnen.

Eben. Warum nutzt es in der Innenstadt (hier von Köln) nicht die Einstufung der Durchgangsstraßen, die schon seit 2-3 Jahren optimiert wurden auf das Verkehrsaufkommen.
( Hatte seinerzeit einige Diskussionen geführt und dann wurde diese Einstufung beibehalten ).
Statt dessen die “kürzeste” Verbindung durch die Innenstadt, man ist dann ungefähr doppelt so lange unterwegs… und verirrt sich hoffnungslos…

Sorry, keine gute Route. Selbst mein Standard-TomTom arbeitet hier nicht optimal. Aber der ist auch schon ein paar Jahre alt…

Oh, ich merke, ich hatte mich verklickert. Sorry. Das Routing für KFZ ist:

http://graphhopper.com/maps/?point=50.928114%2C6.989858&point=50.944125%2C6.931429

Aber auch hier nicht optimal. Warum gehts nicht über die Severinsbrücke? Der Fehler über die Komödienstraße kenn ich auch vom TomTom.

Ich will hier nichts abwerten. Es geht immer etwas optimaler. Daher wünsche ich viel Erfolg mit zukünftlichen Optimierungen.

( Aber mein Tipp: Die Stadtstraßen sollten eigentlich nach Verkehrsaufkommen und demnach nach optimalen “durchkommen” getaggt sein. )

Anhang: Bin der Frage nach der nicht optimalen Route über die Deutzer Brücke mal nachgegangen ( mit Osmand, der auch so führt ). Das rechtsrheinische Routing wäre 150m kürzer. Allerdings mit 4 Ampeln gegenüber 1 über die Severinsbrücke und mit erhöhter Staugefahr. Die Wegezeit ist ca. 5 Min. länger ( ohne Stau ).
Die Bevorzugung liegt wohl darin begründet, das der östliche Zubringer ein Stück gleichzeitig Autobahn A559 und primary L 124 ist. Und solange keine Alternative angeboten wird ( was schade ist ), ist die Sache klar.

Ich habe bisher Fußweg mit Tunnel benutzt - es wäre eben schön, wenn so etwas auch im WIKI eingetragen würde.

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dcorridor

Aber Danke geri-oc, jetzt gibt es auch einen tag für Rolltreppen, kannte ich auch noch nicht, so kann man auch die Passageebenen taggen…

http://wiki.openstreetmap.org/wiki/Key:conveying

Hallo zusammen,

ich habe in letzter Zeit für einen Kumpel die Anfahrtsbeschreibungen von Webseiten auf OSM umgebaut.

Da es außer OpenRouteService scheinbar nur den Mapquest Router gibt, bei dem man einen Link bekommt wenn man nur den Zielort angibt habe ich diesen verwendet.
Durch den anderen Kartenstyle sieht das ganze dann jedoch etwas zusammengebastelt aus.
http://www.verein-bwh-wuppertal.de/kontakt.html

Schön wäre eine Funktion mit der einfach ein Link erstelt werden kann mit Ziel und Kartenstyle den man in die Webseiten oder Mails integrieren kann. Der Interessierte setzt seinen Starpunkt selber.
Dann sieht das mit den Standart OSM-Layer wie aus einem Guss aus.

Gruß
Michael

Vorschlag GraphHopper mit Start=Ziel

OSRM kann das auch: Beispiel und mehr Infos

Danke für Eure Antworten! Werde nun auf die einzelnen eingehen …

bilderhobbit

das wird kommen

das wird erst später kommen.

contributions welcome :slight_smile: ! Also im Ernst: sollte ja nicht so schwierig sein. Ein bissle JavaScript etc

Rogehm

Wie ist das explizit getagged?

Danke. Schau ich mir an.

Wie sollte das gehen ohne Verkehrsinformationen? Oder kennst Du eine zuverlässige Open Data Quelle? Am besten auch noch weltweit :slight_smile: ?

Meinst du alternative Routen? Da gibs schon ein prototyp. Dauert aber noch etwas.

aighes und maxbe

Ok, werd ich dann so in den nächsten Tagen ausrollen.

chris66 und Rogehm

Danke - an Lyrk weitergeleitet!

maxbe

Auto und Fahrrad, da Fahrrad ja auch oneway beachten sollte. Es wird auch nicht komplett gelöscht, nur die Einbahnstraßen aus denen entweder nix rausführt oder in die nichts reinkann.

Nun, wahrscheinlich wie in jeder Stadt. Die Wichtigkeit der Straße bezüglich Verkehr ist als Secondary und Primary Road festgelegt.
Damals ( ist doch erst 1,5 Jahre her ) wurden diese Einstufungen vorgenommen, wobei dann auch schon mal Bundesstraßen zu secondary herabgestuft wurden und ich damals darüber ziemliche Bauchschmerzen bekam. Ein User konnte das Verkehrsaufkommen mit Zahlen nachweisen, frag mich bloß nicht nach der Quelle. Sonst muß ich meinen alten kleinen PC durchforsten. Von meiner Seite achtete ich damals schon auf optimierte Routenführung für OSM Navigation.
Ansonsten wurden diese Einstufungen rein subjektiv, natürlich mit entsprechenden Erfahrungswerten, getätigt. Und die jetzige ist wohl ein Konsens daraus.

Eine Rückfrage: Inwieweit werden ways-Stufen ( primary…) und die Anzahl der Ampeln in den Routing Algorithmen berücksichtigt?
Wenn’s nur nach der Wegstrecke ginge, habe ich hier nichts mehr weiter zu sagen.

Das ganze bitte nur innerstädtisch interpretieren. Außerstädtisch gibt es für mich keine “Runterstufung” von z.B. Bundesstraßen.

Der Weg über die Severinsbrücke ist als der richtige Weg zur Innenstadt ausgeschildert und auch der optimale Fahrweg. Außerdem eine Bundesstraße als primary.
Aber leider 130m länger … ( was mich verwundert, eigentlich “gefühlte” 500m kürzer … )

Als Alternative ist klar eine mindestens alternative Streckenführung ( meinetwegen: Schnellste / Kürzeste … ) gemeint.

Vielen Dank für euer Bemühen. Noch vor 18 Monaten war die Navigation mit OSM fast unmöglich. Mittlerweile ist sie FAST optimal. Ihr seid ganz schön fleißig…

Grüße Rolf

Anhang: Möglicherweise fehlen diverse tags für die Streckenführung über die Severinsbrücke, ohne jetzt “für den Renderer oder sonstige Anwendungen” zu taggen.
Aber eigentlich möchte ich hier das Problem gelöst wissen, da ich nicht weiss, woran liegt’s. TomTom leitet richtig. So möchte ich’s auch mit OSM Routing.
( Auch OSRM ! )

Ich vermute das Problem liegt an Folgendem. GraphHopper nimmt ja die schnellste Route (nicht die kürzeste) und dafür muss er die Geschwindigkeit gut schätzen. Und fast alle Straßen in dem Beispiel haben maxspeed=50, bis auf den östlichen Teil des Zubringers (trunk), dadurch nimmt GraphHopper fälschlicherweise höhere Geschwindigkeiten als innerorts erlaubt da die Ortsboundaries noch nicht berücksichtigt werden. Auch werden Ampeln noch nicht berücksichtigt. (steht beides auf der TODO Liste)

Dass könnte das Problem dann lösen, da die Strecke ja offensichtlich ein Umweg ist, aber evtl. auch nicht. Denn secondary vs. primary wird nicht berücksichtigt. Da habe ich nun folgende Schwierigkeit: die Geschwindigkeiten für beiden sind ja identisch und auf der primary ist die Wahrscheinlichkeit für nen Stau eher sogar noch höher. Sollte primary dennoch ne höhere Priorität bekommen?

Primary sollte höhere Prio bekommen (analog Autobahnen), da in erster Näherung besser ausgebaut. Stauvermeidung bräuchte aktuelle Verkehrsdaten, auch Ampeln sind nachts nicht immer an. Feintuning per Konfiguration für Straßentyp (gilt dann aber für alle) oder per Sperrzone. Irgendwann macht man das Routing dann allerdings fast selber.

Hi Peter,

Radrouting war besser geworden auf Graphhopper seit meinem letztem Test, und nochmal besser seit Deinem Advertisment-Post hier, da scheint sich was zu tun.

Aber muss das hier sein: http://graphhopper.com/maps/?point=50.062429%2C8.495178&point=50.025112%2C8.519726&vehicle=bike2&elevation=true

Glaub da hatten wir vor einem Jahr schonmal drüber diskutiert (und glaub mir, da ist keine Fähre, ausser jeden 1. Mai, der auf einen Sonntag in einem Schaltjahr fällt.).

Zu der Diskussion primary/secondary route beim Car-Routing wollte ich meinen Senf noch loswerden:

Letzlich muss man die Kosten einfach besser schätzen. Maxspeed ist dafür einfach ungeeignet. Die Kosten bei untergeordneten Strassen werden bestimmt nicht durch Maxspeed sondern durch Kurven, Kreuzungen und Ampeln. Diese Dinge KANN man objektiv bewerten, nur tut das keiner und deswegen orientiert sich Car-Routing normalerweise an der Hirachie der Strasssentypen. Das ist aber nur eine Vereinfachung. Aber nur Ampeln geht in die Hose, dann weden die auf Residentials umfahren, was man da braucht ist gleichzeitig eine sinnvolle Bewertung von Kreuzungen und Kurven Und dann qualifiziert sich die primary von ganz alleine, ohne dass man ihr a-priori den besseren Kostenfaktor zuweisen muss.

Gruss, Arndt

Hallo,

http://graphhopper.com/maps/?point=50.917523%2C7.031035&point=50.936648%2C6.952806

Um mal bei meinem Beispiel zu bleiben, habe ich den Weg mal spaßhalber so gefahren, wie graphhopper vorschlägt. Ergebnis. In dem Bereich von der Autobahn bis zum Endpunkt (4km): 13 Ampeln ( Wartezeit ges. 5 min. ), ein Gewusel an Spurwechseln, Kreuzungen, Tunnel, Engstellen, (Baustellen gibt es überall in Köln) usw. …
Viel einfacher und wesentlich angenehmer geht’s über die Severinbrücke mit dem Fahrthinweis “Innenstadt” (4,1 km ). 5 Ampeln ( Wartezeit 2 Min). Schön gemütlich in einer 2-er Spur. Fahrzeit 2-3 Min. schneller! Der ganze Weg wie bekannt als primary. Nur mal so zum überlegen, ob man Ampeln ( ung. WZ pro Ampel 20 sek. ) und primary-ways nicht doch berücksichtigen könnte. Dafür haben wir uns ja schließlich damals hin und her gestritten, welche Straße hier welche Einstufung bekommt.

Es gibt aber noch was drauf. :rage:

Um den Weg so kurz wie möglich zu machen, schreckt graphhopper ( aber auch osrm ) nicht davor zurück, mal schnell die Abbiege zu machen, die Rampe runterzurasen, verbotenerweise auf der Gegenrampe wieder hoch zum ursprünglichen Weg ( ist ja 20 m Abkürzung ! )

http://graphhopper.com/maps/?point=50.925112%2C7.006788&point=50.927844%2C6.990566

Ob das nicht noch Verbesserungspotenzial hat?

Gruß Rolf

Klick

Hmm, beachtet er keine TurnRestrictions[1]? Ansonsten wäre die Frage, welche Geschwindigkeit er für die motorway_links annimmt.
Explizit ist ja nichts angegeben, während der motorway nur 60-80 km/h erlaubt.

[1] https://www.openstreetmap.org/relation/2999032#map=18/50.92477/6.99986