GraphHopper Routenplanung verbessern

Als einer der Entwickler der GraphHopper Routingengine wollte ich mal recherchieren, welche Verbesserungen aus Sicht der OSM-Community notwendig wären. Also bei den Routen die GraphHopper auf openstreetmap.org oder graphhopper.com/maps vorschlägt (egal welche Fahrzeugprofile). Ich bin vor allem an Fehlermustern die häufig passieren und an gefährlichen Routenvorschlägen interessiert.

Cross-posted: https://forum.openstreetmap.org/viewtopic.php?pid=814799

Nutze mal die Gunst der Stunde, um auf dieses ungelöste OSM-Problem hinzuweisen:
https://wiki.openstreetmap.org/wiki/User:Jo_Cassel/Oweia#2020-08
kombiniert mit der Frage, ob Interesse an dieser Lösungs-Idee besteht, die sinnvoll nur zusammen mit Router-Verantwortlichen umsetzbar ist:
https://wiki.openstreetmap.org/w/index.php?title=User:Jo_Cassel/Schreibtisch&oldid=2023296

Hmm, es soll sicherheitsrelevant sein? Ich könnte da dienen: das Wanderprofil wertet Höhenmeter nicht richtig aus, es wird immer so getan, als ginge es nach unten. Falsche Zeitvorstellung können sich nachteilig auf das Erlebnis der Leute auswirken, unter Umständen so sehr, dass Notrufe abgesetzt werden. Die meisten die um Hilfe rufen werden unverletzt geborgen, nur eben erschöpft. Ich will nicht übertreiben, schon gar nicht jemandem da eine Verantwortung unterstellen, aber Graphhopper wird von Leuten verwendet um Wanderungen zu planen, so viel steht fest. Auch wenn die Anwendung nur eine Nische ist ohne Kundenbezug noch dazu, es geht besser. Brouter macht es vor, komoot, mapy usw. weiß ich nicht Bescheid. Also wenn einmal Zeit ist: vgl. #1597 #1679 auf github.

Was ich nicht verstehe, ist wieso Grashopper keine Fähren benutzen möchte. Auf dem Weg von Deutschland nach Schweden werden immer die Brücken als einzige Alternative vorschlagen, obwohl die puttgarden- rodby Fähre billiger, kürzer und schneller ist… Und auch noch viele andere Optionen bestehen

Edit: Den Kritikpunkt kann man vergessen, denn dass liegt an einer seltsamen Voreinstellung einer Webseite, die Grashopper verwendet und nicht an der Software selber.

Bei mir nimmt Graphhopper die Fähre.

Hi,

Graphhopper hab ich mal im zusammenhang mit ÖPNV mapping verwendet :slight_smile: Also Bus-Relationen erstellen… Am anfang noch recht primitiv Bushaltestellen zusammengesucht und dann diese einem Routing unterzogen. Dabei ist schön das Graphhopper viele “Via”-Punkte nimmt :slight_smile:

Was fehlt ist natürlich das “Bus” Routing-Profil, weil der Bus manchmal Straßen nimmt die für den normalen Verkehr gesperrt bzw. beschränkt ist :confused:

Später hab ich mich mit Overpass gespielt um die Wegeliste für die Relation zu erhalten… Anhand des gpx-Datei vom Routing. Das geht auch sehr gut wenn man mit overpass die Highway sucht an einem Punkt und diesen mit den drauf folgenden Punkt verschneidet. Aber dabei ist mir aufgefallen das hier graphhopper optimiert :confused: und Punkte weg lässt. Das ist im normalgebrauch kein Problem aber in diesem Fall fehlen dann einzelne Wegstücke. Da wäre es schön wenn man die Optimierung mit Parameter steuern könnte…

Bei den Feuerwehren ploppt auch immer wieder mal das Thema Routing auf… “Feuerwehr”-Profil würd dürfen uns über einiges hinwegsetzen :wink:

Gruß Miche

PS: den letzte Trick war bei Brouter das “Auto”-Profil zu nehmen und dort das access-Tagging platt zu machen das ich mein Bus-Routing hin bekomme :smiley:
**PPS: **hier bei GTFS Analyse hab mir das sogar fest eingebaut… mit #Routing #Bus #Graphhopper :wink: z.B. https://ptna.openstreetmap.de/gtfs/DE/single-trip.php?feed=DE-BY-MVV&release_date=&trip_id=16.T0.19-463-s20-2.17.H

Da muss ich in 2 von 3 Teilen wiedersprechen.

Hamburg-Kolding-Køge laut Graphhopper: 4h05m, 452km = 30 l x 1,309 tanken = 40 EUR + 19 EUR Maut
Hamburg-Rødby-Køge laut Graphhopper: 3h53m, 286km(+20km Wasser) = 25 EUR tanken + 40 EUR Fährticket
aber reell: 1h30 (Deutsche Autobahn) + 0h30m (rechtzeitig dort sein) + ??? (Fähre zu spät eingetroffen) + 0h20m (Einladen) + 0h40m (Wasserfahrt) + 0h20m (Ausladen) + 1h10m (Dänische Autobahn) = 4h30m + ?
[Definition Hamburg: 53.3732N 10.0228E, Køge: 55.4796N 12.1460E]

  • Ausgabe mehrerer Routenvorschläge für ein gewähltes Basisprofil (wie Google).

  • Diagnosewerkzeug, dass aufzuzeigen hilft, warum ein bestimmer OSM-Way nicht gewählt wurde. Kann man vielleicht heute schon mit nem Zwischenziel lösen. Entweder ist dann durch die Kilometer- oder Zeitansage klar, warum er nicht präferiert wird, oder man sieht visuell eine Umkehr.

Als jemand der seit fast 10 Jahren QA für Routing macht (Erst mit navit, jetzt mit der OSRM Engine) finde ich es immer wieder wichtig das für die unterschiedlichen Standardprofile klar ist welche Tags das routing beeinflussen und wie. Denn es geht ja beim fixen von Routing immer um “relative Gewichtung” der unterschiedlichen Wege. D.h. wenn man rat-race strecken fixen will muss eben die schlechter werden oder die zu nehmende Hauptroute besser. Oftmals reicht dann schon sowas wie lanes, surface, maxspeed mal richtig einzutragen. Das mache ich aber mit dem wissen der OSRM Profile weil ich die regelmäßig lese.

Und es gibt ja millionen von tags: shoulder, smoothness, surface, lanes, priority_road, maxspeed und width oder auf knoten so dinge wie barrier, stop, give_way, kerb, traffic_calming, traffic_lights, crossing etc etc

Schön wäre sowas eben mal für die unterschiedlichen routingengines/profiles zu erfassen.

Und wenn alles Stricke reissen und man das nicht in den griff bekommt die rat-race strecken abzustellen wäre irgendwie auch ein “routemetric: -3” oder so schön um eben unabhängig von physischer Beschaffenheit im routing eingreifen zu können d.h. schlechter oder besser zu machen"

Sowas wie ±5 oder so - oder in % oder wie auch immer man das am schlausten implementiert. Soll ja nicht auf “0” gehen die Kosten oder auf 1000fache Kosten - Aber so eine Nuonce Streckenabschnitte besser oder schlechter werden zu lassen.

Flo

Hallo,

ich habe in den letzten Jahren immer wieder für Kunden Sachen am GraphHopper-Quellcode angepasst oder ihnen erklärt, wie sie es selber tun können. In Zuge dessen sind mir folgende Dinge aufgefallen:

  • Es gibt keine großen Unterschiede zwischen dem foot- und hike-Profil. Letzteres nimmt ein sac_scale=* mehr als das foot-Profil, das war es dann aber auch. Man könnte diesem Profil ggf. eine leichte Präferenz für dreckige Wege und Abneigung für große Straßen spendieren. Andererseits ist das Ziel des Routings, ans Ziel zu kommen, nicht der Weg dorthin. :roll_eyes:
  • smoothness wird bei den Fahrradprofilen nicht ausgewertet, obwohl das für viele Radfahrer eine nicht unwichtige Eigenschaft der Straßenoberfläche ist.
  • StreetComplete sorgt gerade dafür, dass Zusatztags für die Oberfläche von Geh-/Radwegen, die von der Fahrbahnoberfläche abweichen, erfasst werden. In Zukunft (jetzt noch nicht) könnte man sich da bedienen.
  • GraphHopper hat keine Unterstützung für die Durchfahrtsverbotsstufen “destination” und “delivery”.
  • Ampeln kosten Zeit, BRouter ist besser als GraphHopper, weil er Ampeln berücksichtigt (GraphHopper über die Kaiseralle vs. BRouter über die Sophienstraße).
  • Sehr exotisch: Es gibt ein Tag für die durchschnittliche Schließdauer beschrankter Bahnübergänge: railway:level_crossing:closure:average=. Es wird aber nur selten verwendet.
  • Wenn die Höchstgeschwindigkeit die Standardgeschwindigkeit der Straße in dem Land ist, ist die Schätzung der Geschwindigkeit aufgrund der Kurvenradien (Überhöhung gibt es in OSM nicht) in Gebirgen eine bessere Schätzung der Fahrtzeit.
  • Dass die Fahrradprofile mit Ausnahme von bike2weight die Höhendaten nicht berücksichtigen, hat mich erschreckt, als es mir beim Blick in den Quellcode auffiel.
  • Flächenrouting für Fußgänger

GraphHopper kann seinen Routinggraphen als MVT-Tiles ausgeben, sodass man die im Graphen enthaltenen Kanten auf einer Karte anschauen kann (keine Ahnung, ob das online irgendwo geht).

Viele Grüße

Michael

Alleine über die Nummer kann man ja seitenweise Abhandlungen schreiben. Korrigiere mich wer da genaueres kennt aber “destination” wird halt typischerweise in den Routingengines als “höhere kosten” auf diesen Kanten im Graph realisiert was grundsätzlich falsch ist aber die einfachste Näherung.

Defakto gibt es ja wenn man denn Anlieger ist keine Notwendigkeit diese Wege “so schnell wie möglich” wieder zu verlassen. D.h. nicht die Strecke AUF einer “destination” muss (Höhere) Kosten verursachen sondern der Übergang von “non destination → destination” muss einmalige Kosten verursachen, alternativ darf der Übergang in der route nur “einmal” erfolgen d.h. nur “non → destination” niemals danach von “destination → non”.

Kosten je Strecke sind ja identisch.

Und damit kommen wir wieder auch zu OSM tagging Problemen. Mitunter gehen ja auch mehrere “Anlieger Frei” ineinander über die aber eigentlich getrennt sind. D.h. T Kreuzung. Ost und West sind “Zeichen 250 Anlieger Frei” - Dann ist es fraglich ob ein Übergang vom östlichen in den westlichen teil rechtlich in Ordnung wäre. IMHO nicht. Hier wäre dann tagging technisch wichtig das eben um die Kreuzung die 10m dann kein vehicle=destination tragen. Aber das sind eben so kleine Randerscheinungen - die Frage ob es den Aufwand wert ist.

Flo

Besteht die Möglichkeit, diese Fahrrad-Umlauf-Sperren zu berücksichtigen (und auszuschließen)?
Das Elektromobil meiner Frau ist zwar nur 70 cm breit - ist aber weder entsprechend kurvengängig noch lässt es sich inkl. Fahrerin mal eben herumwuchten. :wink:
Und wenn ich an das geplante Dreirad-Tandempedelec oder -E-Roller denke - wird das sich kaum ändern.

Vielen Dank schon jetzt für eure Antworten!

In der Vergangenheit haben wir immer nur schon durchgesetztes Tagging-Schema verwendet. Auch wenn ich persönlich das für keinen schlechten Vorschlag halte, würden wir so etwas vermutlich nicht umsetzen.

:smiley:

Der Plan auf unserer Seite ist da ein “alles erlaubendes Profil” zu erstellen und dann mittels dem customizable routing beliebige Einschränkungen umzusetzen: https://www.graphhopper.com/blog/2020/05/31/examples-for-customizable-routing/

Da planen wir gerade auch ein Update, was dann noch etwas mächtiger werden soll: https://github.com/graphhopper/graphhopper/pull/2209

Für alternative Routen gibts schon Unterstützung in der Engine, nur noch nicht in der UI: https://graphhopper.com/maps/?point=Chemnitz&point=Berlin&algorithm=alternative_route

Ja, da ist sicher die MVT Ansicht hilfreich bei lokaler Installation. Das Thema werden wir aber sicher auch noch weiterverfolgen, da wir das ja fast täglich selber brauchen.

Da kann evtl. unser customizable routing feature helfen?

Solche Anwendungsfälle die ein bestehendes Profil minimal abwandeln sind perfekt für das customizable routing.

Ja, da gibt es https://github.com/graphhopper/graphhopper/pull/2108 Weiß aber grad nicht was da der Stand ist.

destination unterstützen wir für Auto und delivery weiß ich nicht ob man das im Normalfall unterstützen sollte.

Bei diesen tags gibt es dann aber die von flohoff genannten Probleme: https://github.com/graphhopper/graphhopper/issues/733#issuecomment-580927983

Nur Ampeln allein würde das Routing kaputt machen: https://github.com/graphhopper/graphhopper/issues/75#issuecomment-94378735

Ja, das wäre sehr leicht umzusetzen und sehr fein. Wir werden da ein curvature Parameter einführen, den man dann mit customizable routing ansprechen kann.

Warum sollte ein Mountainbiker Berge vermeiden wollen :slight_smile: ? Aber ja, für die Zeitanpassung (Berg hoch langsamer, Berg runter schneller) wird da ein elevation Parameter kommen, den man auch wieder übers customizable routing anspricht.

Ja, die Anfrage ist schon recht alt, aber wir sind bisher nicht dazu gekommen :slight_smile: https://github.com/graphhopper/graphhopper/issues/82

Generell versuchen wir die open source GraphHopper routing engine natürlich möglichst fähig und gut aufzustellen. Allerdings werden wir nie ohne die Community alle Anwendungsfälle optimal behandeln können. Daher wäre es toll, wenn jemand Lust am Programmieren hat, da mich zu kontaktieren und/oder hier mal zu lesen: https://github.com/graphhopper/graphhopper#contribute

Z.B. mussten wir durch Mangel an Energie&Zeit auf meiner Seite den direkten Support fürs offline routing einfrieren: https://github.com/graphhopper/graphhopper/issues/1940 Also da GraphHopper in Java geschrieben ist wird es auf dem neuesten Android sicher immer noch gut funktionieren, aber richtiger Android Support oder generell offline-routing Support wäre natürlich sehr toll. Da gibt es aber leider sehr viel zu tun.

Auch find ich die Navigations-App für Android die wir für den play store schon veröffentlich haben ganz cool. Da haben wir das mapbox Navigation SDK geforked, alles closed source rausgeschmissen und einen extra Endpunkt dafür eingerichtet der das richtige Format ausgibt und so könnte man auch auf iOS so etwas bauen. Eine andere Idee wäre auch das ganze für f-droid zu veröffentlichen, da es ja 100% open source ist, sollte das auch ohne Probleme gehen, man müsste evtl. nur ein paar Google Abhängigkeiten loswerden.

Auch nutze ich diese Navigations-App regelmäßig und bekomme so natürlich gute Rückmeldung zu unserem Routing (für Navigationszwecke). Das nervigste Problem sind gar nicht die fehlende Staudaten bei OSM, sondern die fehlenden Baustellendaten :frowning:

BTW: für Sachsen gibts die sogar als Open data, aber die werden durch deren attributierungspflicht nicht in OSM reinkommen. Jedoch wäre hier ein Plan die einfach auf unserer Seite zu vermengen und die dann zu nennen. Aber die schiere Menge an unterschiedlichen Daten schreckt mich da noch sehr ab :). Ein Grund warum ich die Datenquellen erstmal nur sammle: https://github.com/graphhopper/open-traffic-collection

Alles erlaubtes Profil hört sich interessant an :slight_smile: ich hab jetzt ein wenig probiert aber das was ich will geht denk ich noch nicht oder? :confused:

http://148.251.46.152:8989/maps/?point=48.196271%2C11.808243&point=48.196088%2C11.805797&locale=en&elevation=true&profile=car&use_miles=false&layer=OpenStreetMap

priority:
 road_access: 
    yes: 1.0
    other: 1.0
    no: 1.0

Gruß Miche

Ja, genau, das geht aktuell nicht, da man beschränkten access von “car” nicht wieder aufheben kann (nur weiter einschränken). Daher die Idee das man ein generisches “base_road” Profil braucht was dann auf allen Straßen fahren kann, auch die Einbahnstraße verkehrt herum oder private etc.

In seltenen Fällen stolpere ich über Fahrrad-Routen, die mich über Treppen schicken wollen, während das PKW-Profil die richtige Route nimmt.

mit dem Fahrrad-Profil betrügen für ein Bus-Routing :laughing: ist aber denk ich ineffizient :wink:

http://148.251.46.152:8989/maps/?point=48.201543%2C11.813489&point=48.20089%2C11.812309&point=48.196525%2C11.809283&point=48.19606%2C11.805668&point=48.195895%2C11.804466&locale=en&elevation=true&profile=bike&use_miles=false&layer=OpenStreetMap

priority:
 road_access: 
    yes: 1.0
    other: 1.0
    no: 1.0

 road_class:
   service: 0.01
   living_street: 0.3
   track: 0.1
   path: 0
   cycleway: 0
   footway: 0
   track: 0

Gruß
Miche

PS: Kam drauf weil ich schon mal mit einem Kollegen über einen Fuß-u.-Radweg fahren musste um eine Anlage zu erreichen :laughing:

Hmmh, ja, schwierig. Leider erlauben wir das (unter starker Bestrafung), weil es viele Szenarien gibt wo es nur kleine Abschnitte sind und der Umweg sonst sehr groß wäre und wir annehmen das Erwachsene das Rad kurz tragen. Beim customizable routing kann man diese dann leicht ausschließen:
https://github.com/graphhopper/graphhopper/blob/840c79c63be9ee72e6e0ec08be101b7b32542bc8/web/src/test/resources/com/graphhopper/http/resources/cargo_bike.yml

Hier würde ich das “Leider” streichen, weil die Annahme grundsätzlich schon richtig ist.
Wichtig ist in dem Szenario, dass man hier “step_count” (oder hilfsweise die Länge der Treppe) stark berücksichtigt. 1-3 Stufen sind schon anders zu sehen, als 8 und mehr :wink: Wenn ich daran denke, zähle ich daher immer die Stufen, weil die dafür wichtiger ist, als die Weglänge, die gerade bei Treppen, die an Straßen anschließen, in OSM meistens “zu lang” werden (wegen dem Anschluss zur Straßenachse).
Dass es da nicht die eine richtige Lösung gibt, dürfte allen klar sein.

Edit:
Den Vorschlag von GraphHopper (und OSRM) https://www.openstreetmap.org/directions?engine=graphhopper_bicycle&route=49.35303%2C11.22988%3B49.35076%2C11.22923#map=17/49.35189/11.23194
über die Treppe https://www.openstreetmap.org/way/25727411/history mit den von mir erfassten 62 Stufen bergauf in sechs Minuten finde ich schon hart :sunglasses: