OSRM meidet Gambacher Kreuz

dooley · 2019-10-02T21:10:09.000Z

Auf routing.openstreetmap.de (ist wohl OSRM 5.18) (und bei mir lokal OSRM 5.22 mit dem Original car.lua) kann nicht

von https://www.openstreetmap.org/way/481432644#map=18/50.46353/8.72152
über den gemeinsamen Node https://www.openstreetmap.org/node/481030#map=19/50.46336/8.72116
nach https://www.openstreetmap.org/way/481432640 geroutet werden.

Alle 3 Objekte haben seit mindestens 2017 kein construction-Tag gesehen. Ich sehe bei allen 3 überhaupt keine Tags, die das Routing verhindern könnten. Oder ich bin blind.

datendelphin · 2019-10-02T21:15:29.000Z

Vielleicht ein “bug” mit routing inseln. Da diese Einbahnstrasse nirgends angeschlossen ist (wegen construction fehlende Autobahn), wird sie vielleicht ganz weggelassen?

MKnight · 2019-10-02T21:51:12.000Z

datendelphin:

Da Problem ist vermutlich das contruction=yes

das Problem ist ziemlich sicher ein hornalter (oder kaputter) Datenimport oder wie dooley sagt eine alte osrm-version.
Das Beispiel ist eindeutig, dort sind keine (!)* irgendwie relevanten Daten, die das Routing verhindern könnten.
Hier der Link nochmal zum 6. Mal: https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=50.46322%2C8.72108%3B50.46390%2C8.72158#map=19/50.46357/8.72126 Ankucken, staunen.

wenn Du das herbeifabulierte construction in diesem Bereich noch nachreichen könntest, wären alle schlauer und können sich eine neue Brille kaufen

Edit: ich hab mir das jetzt zum dritten oder vierten oder 5. Mal angeschaut: es gibt weder limitierende tags, noch routing-inseln. Bitte nachreichen.

kreuzschnabel · 2019-10-02T22:18:46.000Z

MKnight:

das herbeifabulierte construction

Guten Morgen! von #5 bis etwa #13 ging es um Wetzlar-Ost, nicht ums Gambacher Kreuz und da war es definihoch das construction=yes.

–ks

seichter · 2019-10-02T22:36:37.000Z

kreuzschnabel:

Guten Morgen!

OT: Ich möchte nur ganz sanft anmerken, dass die Gefahr besteht, dass so ein lockerer Ton nicht bei jedem Forumsteilnehmer im richtigen Hals landet.

kreuzschnabel · 2019-10-02T22:40:49.000Z

seichter:

dass so ein lockerer Ton nicht bei jedem Forumsteilnehmer im richtigen Hals landet.

Verstanden – ich kann immer noch nicht kommunizieren.

–ks

MKnight · 2019-10-02T23:22:49.000Z

kreuzschnabel:

MKnight:

das herbeifabulierte construction

Guten Morgen! von #5 bis etwa #13 ging es um Wetzlar-Ost, nicht ums Gambacher Kreuz und da war es definihoch das construction=yes.

–ks

Die Antwort zu den routing-inseln waren eine Antwort auf #21 und nicht auf #5. Also quasi auf #1 und wieder nicht auf #5. Sorry, nicht ganz zielführend, aber ich verstehe den Einwurf nicht. Weder ist eindeutig geklärt ob construction=yes “definihoch” der Auslöser des Problems in einem Teilthema ist/war (vlt. magst Du das nachreichen?) noch ist klar, wo das Problem aus #2 (bzw #22) herkommt.
Wenn, nachdem etliche Mapper ihre Zeit investiert haben, zu schauen was geht und konfus zurückbleiben, und jemand herkommt mit “vielleicht das und das”, dann versuch ichs das näxte Mal auch mit “Guten Morgen”.
Wenn das zielführender ist.

@seichter: ich hab kein Problem mit lockerem Ton

tl:dr: wenn man nich alles lesen und verstehen will oder kann, #22,#20,#19,#undirgendwo weiter vorne ist der heisse shit, dort gibt’s keine Erklärung für die Probleme. aber vlt.hab auch ich wa überlesen hier. Hilft mir wer?

dooley · 2019-10-03T12:32:20.000Z

Obwohl ich es noch nicht ganz verstehe, scheinen construction-Tags, welche irgendwo in Routen- (oder anderen?) Relationen vorhanden sind, aber nicht auf den betroffenen Teilstücken zwischen Start und Ziel der gewünschten Route, Auswirkungen in OSRM zu haben.

Ich habe eben Hessen neu generiert (ganz Deutschland dauert Stunden auf meinem Laptop) mit dem Datenstand von gestern abend (da waren wohl diese fehlerhaften construction-Tags schon gefixt), und siehe da, man kann jetzt von der A5 auf die A45 über das Gambacher Kreuz kommen. Das sollte dann nach einem Update der Daten auf routing.openstreetmap.de auch funktionieren.

Edit: Zwischen Wetzlar-Ort und Kreuz Wetzlar gehts mit dem neuen Datenstand jetzt auch.

datendelphin · 2019-10-07T19:22:20.000Z

In Bezug auf #23
Das construction, das ich meine, ist https://www.openstreetmap.org/way/324045585 in Version 6. Das Problem hat sich in Einbahngegenrichtung verbreitet, weil man zwar auf die Strasse rein kommt, aber nicht mehr raus, da die “Ausfahrt” durch das construction tag blockiert ist. Ich vermute das wird bei OSRM gleich behandelt wie eine Routing Insel und es wird nicht darüber geroutet. Darum war die Autobahn ab diesem Segment https://www.openstreetmap.org/way/481432640 nicht routbar. Finde ich jetzt nicht optimal, aber ich will eigentlich nur den routing server betreiben und nicht maintainer von OSRM werden. Aber OSRM könnte einen maintainer brauchen, falls jemand Zeit hat.

Ich kann nichts dafür, wenn MKnight sich das 5 mal anschaut. Aber vielleicht sollte ich das nicht so persönlich nehmen.

abrensch · 2019-10-07T21:44:06.000Z

datendelphin:

Finde ich jetzt nicht optimal, aber ich will eigentlich nur den routing server betreiben und nicht maintainer von OSRM werden. Aber OSRM könnte einen maintainer brauchen, falls jemand Zeit hat.

Wenn’s tot ist muss man auch irgendwann den Stecker ziehen, und nicht die Reputation von OSM da dran hängen. OsmAnd hat’s ja auch kürzlich rausgeschmissen.

Ich betreibe bei BRouter einen erheblichen Aufwand mit den “suspect-scans”, um genau solche Probleme wie dort in Wetzlar zu vermeiden ( und Wetzlar Ost war da auch Patient: https://forum.openstreetmap.org/viewtopic.php?pid=748441#p748441 ), und es wäre natürlich toll, wenn auch alle Router, die eine gewisse Sichtbarkeit haben, davon profitieren würden. Aber das ginge nur, wenn sie auch alle den selben Regelsatz verwenden würden. Und mit “selber Regelsatz” meine ich nicht nur, dass man sich über Regeln unterhält, sondern diesen Regelsatz in maschinenlesbarer Form austauschen kann.

MKnight · 2019-10-08T00:08:40.000Z

abrensch:

datendelphin:

Finde ich jetzt nicht optimal, aber ich will eigentlich nur den routing server betreiben und nicht maintainer von OSRM werden. Aber OSRM könnte einen maintainer brauchen, falls jemand Zeit hat.

Wenn’s tot ist muss man auch irgendwann den Stecker ziehen, und nicht die Reputation von OSM da dran hängen. OsmAnd hat’s ja auch kürzlich rausgeschmissen.

Ohne widersprechen zu wollen, aber OSRM hat nicht falsch geroutet, sondern, soweit ich das nachvollziehen kann, Fossgis hatte (zu einem bestimmten Zeitpunkt der Diskussion) einen nicht ganz aktuellen Datenstand. Ich hab spätestens am 2.10, 19:30 http://map.project-osrm.org/?z=18&center=50.463393%2C8.721712&loc=50.462954%2C8.720924&loc=50.463801%2C8.721519&hl=en&alt=0 gecheckt und dort lief nach kreuzschnabels edit kurz nach Mittag das routing richtig - im Gegensatz zu osm.org
Das sagt natürlich genau garnix aus, weil, soweit ich mich richtig entsinne, vor dem Edit nur der OSRM-Router auf osm.org geprüft wurde, und nicht klar ist, ob das map.project-osrm.org vorher schon “richtig geroutet” wurde.

@datendelphin: Deine Interpretation des Problems scheint mir sinnig zu sein. (Und gut zu verstehen) Aber kompliziert zu erklären wie richtig zu routen ist.
Variante 1: Ich will von a nach b: Router gibt mir eine Route von a nach b (würde ich erwarten)
Variante 2: Ich will von a nach b: Router gibt mir keine Route, weil man, wie in diesem Fall hier die Route zwar befahren kann kann, aber niemals weiter/zurück weil Einbahnstrasse/Sackgasse
Ich würde V1 bevorzugen aber V2 ist irgendwie trotzdem richtig.

GeorgFausB · 2019-10-09T09:41:25.000Z

Moin,

MKnight:

Variante 1: Ich will von a nach b: Router gibt mir eine Route von a nach b (würde ich erwarten)
Variante 2: Ich will von a nach b: Router gibt mir keine Route, weil man, wie in diesem Fall hier die Route zwar befahren kann kann, aber niemals weiter/zurück weil Einbahnstrasse/Sackgasse
Ich würde V1 bevorzugen aber V2 ist irgendwie trotzdem richtig.

jaaiin - wenn ich von a über b nach c anfrage, dann soll der Router das berücksichtigen.
Aber wenn nur von a nach b, dann soll der Router eigentlich nicht “vorauschauend” verweigern.
Woher will er denn wissen, dass ich da wieder weg will?

Grüße
Georg

Nakaner · 2019-10-09T10:17:18.000Z

Hallo,

MKnight:

abrensch:

datendelphin:

Finde ich jetzt nicht optimal, aber ich will eigentlich nur den routing server betreiben und nicht maintainer von OSRM werden. Aber OSRM könnte einen maintainer brauchen, falls jemand Zeit hat.

Wenn’s tot ist muss man auch irgendwann den Stecker ziehen, und nicht die Reputation von OSM da dran hängen. OsmAnd hat’s ja auch kürzlich rausgeschmissen.

Ohne widersprechen zu wollen, aber OSRM hat nicht falsch geroutet, sondern, soweit ich das nachvollziehen kann, Fossgis hatte (zu einem bestimmten Zeitpunkt der Diskussion) einen nicht ganz aktuellen Datenstand. Ich hab spätestens am 2.10, 19:30 http://map.project-osrm.org/?z=18&center=50.463393%2C8.721712&loc=50.462954%2C8.720924&loc=50.463801%2C8.721519&hl=en&alt=0 gecheckt und dort lief nach kreuzschnabels edit kurz nach Mittag das routing richtig - im Gegensatz zu osm.org
Das sagt natürlich genau garnix aus, weil, soweit ich mich richtig entsinne, vor dem Edit nur der OSRM-Router auf osm.org geprüft wurde, und nicht klar ist, ob das map.project-osrm.org vorher schon “richtig geroutet” wurde.

map.project-osrm.org ist eine nicht wirklich gepflegte OSRM-Instanz, die unter der Kontrolle Mapbox steht und bei der nicht klar ist, ob da nicht etwa modifizierte OSM-Daten (Stichwort Verkehrsinformationen) oder ein modifizierter OSRM zum Einsatz kommt (Mapbox verwendet für seine Kartentiles keine originalen OSM-Daten, bei Routing halte ich das für möglich). Der Server leidet unter Überlastung und anderen Problemen.

routing.openstreetmap.de ist die OSRM-Instanz des FOSSGIS e.V., deren Admin datendelphin ist. Das OSRM-Routing auf www.openstreetmap.org verwendet seit mindestens einem Jahr den Server des FOSSGIS e.V., da dort ein originaler OSRM mit originalen OSM-Daten zum Einsatz kommt. AFAIK werden die Daten alle ein bis zwei Tage aktualisiert.

OSRM hat die A 45 im Bereich Gambacher Kreuz/Gießener Südkreuz vermieden, weil er alle Kanten verwirft, die ein construction=*-Tag haben, das nicht construction=no ist. Da ich den Eindruck habe, dass eine Reihe an Leuten in diesem Thread noch nicht kapiert hat, wozu das führt, erläutere ich das einmal:

highway=motorway → wird verwendet
highway=motorway + construction=yes → wird verworfen
highway=motorway + construction=no → wird verwendet
highway=motorway + construction=motorway → wird verworfen
highway=motorway + construction=temporary → wird verworfen
highway=motorway + construction=salad → wird verworfen
highway=construction + construction=motorway → wird verworfen
highway=residential + construciton=primary → wird verworfen

Wenn eine Einbahnstraße (z.B. die Richtungsfahrbahn einer Autobahn) als Sackgasse ins Nichts führt, weil die sich daran anschließende Kante verworfen wurde, handelt es sich um eine Routing-Senke. Analog ist eine Einbahnstraße, die im Nichts beginnt, eine Routing-Quelle. Beide werden von OSRM in der Graphen-Aufbereitung verworfen. Übrigens, das OSRM-Programm “osrm-components” gibt diese Kanten als GeoJSON aus.

Die Daten von routing.openstreetmap.de waren wahrscheinlich so aktuell, wie man das mit OSRM hinbekommen kann (einmal die gesamte Welt auszurechnen dauert etwa einen halben bis ganzen Tag und benötigt je nach Profile über 170 GB RAM). Der Vorwurf, die Daten des Servers seien veraltet, ist daher wahrscheinlich nicht zutreffend.

Das Ziel des FOSSGIS-Routingservers (routing.openstreetmap.de) ist, eine öffentliche Instanz des OSRM anzubieten, da Mapbox das nicht mehr tut bzw. nicht klar ist, welche Modifikationen an den OSM-Daten und der Software vergenommen worden sind. Es war bei der Einrichtung des Servers nicht geplant worden, dass der Server eine gepatchte OSRM-Version nutzen soll. Stattdessen soll es sich bei dem Server um einen Vanilla-OSRM handeln.

Viele Grüße

Michael

abrensch · 2019-10-09T13:08:29.000Z

Nakaner:

… weil er alle Kanten verwirft, die ein construction=*-Tag haben, das nicht construction=no ist.l

… oder construction=minor

Da ich den Eindruck habe, dass eine Reihe an Leuten in diesem Thread noch nicht kapiert hat, wozu das führt

Es führt zu sowas hier, das ist schon klar:

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=50.0538%2C8.5892%3B50.0542%2C8.5918

Natürlich räumt sowas keiner weg, ist ja in der Karte nicht zu sehen, die QS ist nunmal überwiegend optisch.

Aber bei wem liegt denn Deiner Meinung nach der Fehler?

ToniE · 2019-10-09T13:46:38.000Z

abrensch:

Natürlich räumt sowas keiner weg, ist ja in der Karte nicht zu sehen, die QS ist nunmal überwiegend optisch.

Ich werde das mal in ptna.openstreetmap.de als Prüfung aufnehmen, als Hinweis. Dann fällt es wenigstens dort auf, wo Buslinien gemapped sind.

Edit:

Was heute schon geprüft wird:

Route: eingeschränkte Befahrbarkeit (‘motor_vehicle’=‘no’) auf Weg ohne dass ‘psv’ = ‘yes’, ‘bus’ = ‘yes’, ‘bus’ = ‘designated’, oder … angegeben ist: Way ‘Obere Hauptstraße’ 4682969 (iD, JOSM)

Route: eingeschränkte Befahrbarkeit (‘highway’=‘construction’) auf Wegen ohne dass ‘psv’ = ‘yes’, ‘bus’ = ‘yes’, ‘bus’ = ‘designated’, oder … angegeben ist: Way ‘EBE 13’ 624216665 (iD, JOSM), Way ‘Brucker Straße’ 697521930 (iD, JOSM), Way ‘EBE 8’ 697521933 (iD, JOSM)

Was noch geprüft werden könnte:

Route: suspicious ‘construction’ = ‘%s’ on ‘highway’ = ‘%s’: %s

chris66 · 2019-10-09T15:17:20.000Z

abrensch:

Aber bei wem liegt denn Deiner Meinung nach der Fehler?

mMn sollte ein Router bei construction=minor / construction=yes nicht annehmen, dass man da nicht durch kommt.

Dies sollte alleinig vom highway-Tag abhängig gemacht werden (highway=primary vs. hw=construction zB.)

ToniE · 2019-10-09T17:59:02.000Z

chris66:

abrensch:

Aber bei wem liegt denn Deiner Meinung nach der Fehler?

mMn sollte ein Router bei construction=minor / construction=yes nicht annehmen, dass man da nicht durch kommt.

Dies sollte alleinig vom highway-Tag abhängig gemacht werden (highway=primary vs. hw=construction zB.)

Da bin ich voll bei Dir …

Interessant aber, was bei der Analyse in PTNA so alles an Kombinationen raus kommt:

construction=motorway_link
highway=motorway_link
highway:1968-01-01–1968-12-31=construction
note= … irgendwas, was auf das Baudatum der damaligen Autobahn und heutigen -Auffahrt schließen lässt

Ab morgen sichtbar auf https://ptna.openstreetmap.de/, speziell mit vielen Autobahnen: https://ptna.openstreetmap.de/results/EU/EU-Flixbus-Analysis.html (Suche nach: “verdächtige”).

Oder: speziell morgen als Diff zu heute: https://ptna.openstreetmap.de/results/EU/EU-Flixbus-Analysis.diff.html

streckenkundler · 2019-10-09T18:50:36.000Z

abrensch:

Nakaner:

… weil er alle Kanten verwirft, die ein construction=*-Tag haben, das nicht construction=no ist.l

… oder construction=minor

Das wäre eine Frage von mir gewesen, die für mich beantwortet ist.
Dieses construction=minor hatte ich hier in Lübben eingesetzt, da die Hauptdurchfahrtsstraße erneuert wurde (eigentlich noch wird, das schlimmste ist aber vorbei)

abrensch:

Nakaner:

Da ich den Eindruck habe, dass eine Reihe an Leuten in diesem Thread noch nicht kapiert hat, wozu das führt

Es führt zu sowas hier, das ist schon klar:

https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=50.0538%2C8.5892%3B50.0542%2C8.5918

Natürlich räumt sowas keiner weg, ist ja in der Karte nicht zu sehen, die QS ist nunmal überwiegend optisch.

Aber bei wem liegt denn Deiner Meinung nach der Fehler?

Meiner Meinung nach fehlt eine Fehlerprüfauswertung, die nur alles (!!) construction, proposed, planed oder was in die Richtung geht, separat auswertet und visualisiert. Mit alles meine ich auch Gebäude, Bahnstrecken, ect.

Ich könnte mir das z.B. als separate Untergruppe im RoutingView in OSMI gut vorstellen.
So oder so ähnlich wäre es möglich, diese Baustrecken zu beobachten…

Sven

flohoff · 2019-10-10T17:14:33.000Z

miche101:

Macht das was: ??

https://www.openstreetmap.org/way/333311469/history
construction=yes

Ja - OSRM meidet alle wege die ein construction=* tragen.

Flo

dooley · 2019-10-10T19:27:04.000Z

flohoff:

Ja - OSRM meidet alle wege die ein construction=* tragen.

Falsch. Alle unten in der Whitelist aufgeführten Values für das construction-Tag behindern das Routing in OSRM nicht.


construction_whitelist = Set {
  'no',
  'widening',
  'minor',
},

https://github.com/Project-OSRM/osrm-backend/blob/master/profiles/car.lua#L185