OSRM meidet Gambacher Kreuz

MKnight · 2019-10-02T13:57:44.000Z

rab:

OSRM hätte weder über “construction=yes” noch über “under_construction=yes” stolpern dürfen

und noch weniger über construction=no.

Nakaner · 2019-10-02T14:03:13.000Z

Hallo,

miche101:

Macht das was: ??

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

Herzlichen Glückwunsch, das ist die Ursache.

OSRM verwirft Ways, die ein construction=*-Tag tragen, ausgenommen construction=no. Der Fehler ist bekannt.

construction=yes ist eine der ungeschicktesten Arten (aus der Perspektive eines Datenkonsumenten), wie man Tags verwenden kann. Ein untergeordnetes Tag (construction=) überschreibt die Bedeutung eines übergeordneten Tags (highway=). Wer nur das übergeordnete Tag auswertet (und dazu verleitet auch so sämtliche Doku zum Thema OSM), tappt in eine Falle, die glücklicherweise nicht allzu häufig mehr in OSM auftaucht. Zum Glück werten nur die wenigsten Dienste das aus, sodass Mapper nicht noch dabei unterstützt werden, es zu benutzen. OSRM wertet das Vorhandensein von construction=* zur sicheren Seite aus (darüber kann man sich streiten).

Die Layergruppe Hidden Non-Operational Tagging im OSM Inspector zeigt Fälle an, bei denen construction=* getaggt ist, aber nicht getaggt werden sollte. Meiner Meinung nach ist jeder Eintrag in diesem Layer ein Fehler und bedarf einer Korrektur. Vielleicht sollte man einen Patch für den JOSM-Validator schreiben?

Viele Grüße

Michael

miche101 · 2019-10-02T14:18:11.000Z

Nakaner:

Die Layergruppe Hidden Non-Operational Tagging im OSM Inspector zeigt Fälle an, bei denen construction=* getaggt ist, aber nicht getaggt werden sollte. Meiner Meinung nach ist jeder Eintrag in diesem Layer ein Fehler und bedarf einer Korrektur. Vielleicht sollte man einen Patch für den JOSM-Validator schreiben?

danke für den Link Hab ich gleich mal bei mir geschaut… sind meist überbleibsel von ehemaligen Baustellen

dooley · 2019-10-02T14:24:35.000Z

Das construction-Tag ist aber nicht der (einzige) Grund, warum das Gambacher Kreuz nicht von der A5 zur A45 in OSRM benutzt wird. https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=50.46322%2C8.72108%3B50.46390%2C8.72158#map=19/50.46357/8.72126&layers=D
Alle beteiligten highway-Abschnitte der Route sind seit 2017 unangetastet.

Hier https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=50.4729%2C8.7350%3B50.4766%2C8.7202#map=13/50.4792/8.6882 habe ich noch nicht nachgeschaut, wie der Status ist.

Ich hatte heute morgen schon ein Ticket dazu aufgemacht: https://github.com/Project-OSRM/osrm-backend/issues/5568

MKnight · 2019-10-02T17:30:29.000Z

dooley:

Ich hatte heute morgen schon ein Ticket dazu aufgemacht: https://github.com/Project-OSRM/osrm-backend/issues/5568

Das ist unter Umständen nicht der richtige Ansprechpartner, wenn ich das richtig verstehe?

Edit: Mhh Ticket nicht genau genug gelesen, Du reproduzierst das auf einer lokalen Instanz. Bin gespannt wo der Fehler versteckt ist.

datendelphin · 2019-10-02T20:05:01.000Z

Tickets bezüglich des routing Profils von routing.openstreetmap.de (OSRM auf osm.org) am liebsten hier: https://github.com/fossgis-routing-server/cbf-routing-profiles/issues/new

Da Problem ist vermutlich das contruction=yes

Ich lese da oben, dass der router dieses tag ignorieren soll. Ich finde das aber nicht so falsch, nicht darüber zu routen. Das yes kann alles heissen. Ich habe lieber wenn der router so dieses Problem aufzeigt. Es gibt übrigens eine whitelist für construction=minor.

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?