Guten Morgen, der Fehler im Routing könnte daran liegen, dass "lanes = 4" gefehlt hat. Habe ich eben ergänzt. Bitte noch einmal testen! Ulrich
Am 15.12.18 um 11:34 schrieb Ulrich Wehmeier:
Guten Morgen,
der Fehler im Routing könnte daran liegen, dass "lanes = 4" gefehlt hat. Habe ich eben ergänzt. Bitte noch einmal testen!
Ulrich
Moin! Noch funktioniert es nicht. Das ist wahrscheinlich nur ein Problem der Aktualität. Das Routing verwendet wahrscheinlich nicht die Originaldaten sondern erzeugt eine spezielle Routing-Datenbank. Das geschieht bestimmt nicht stündlich. Die Anzahl der Fahrspuren halte ich nicht für relevant. Die hast die Überfahrten zwischen den Richtungsfahrbahnen eingezeichnet und das "oneway" für den Teil raus genommen, der nun auch in Gegenrichtung genutzt wird. Das müsste reichen, wenn das Routing nicht für Autobahn das "oneway" als zwingend annimmt. So habe ich getestet: Auf https://www.openstreetmap.org oben links auf den Pfeil neben dem Suchfeld geklickt. Die grüne/rote Start-/Ziel-Marke kann man alternativ zu einer Sucheingabe mit der Maus in die Karte ziehen. Mit "Richtung umkehren" wird die Strecke benutzt. -- Frank
GraphHopper (über den das Routing läuft) arbeitet auf eigenen Graphen die in regelmäßigen Abständen auf basis eines world.pbf's aus den OSM-Daten generiert werden... Da der interne Storage von GraphHopper keine Deltas unterstützt müssen die Server immer wieder die komplette Datenbasis durchhauen - und das dauert eben - bei dem OpenRoutingService.org (bei dem ich mitarbeite) der zum Teil auf GraphHopper Code basiert aktualisieren wir die Daten einmal in der Woche... Wie oft das bei Peters original GraphHopperServern passiert ist mir nicht bekannt... aber ganz bestimmt nicht stündlich - da die Laufzeit für das komplette world.pfb > 4h ist. Am Sa., 15. Dez. 2018 um 13:02 Uhr schrieb Frank Jäger <urbi@orbi.space>:
Am 15.12.18 um 11:34 schrieb Ulrich Wehmeier:
Guten Morgen,
der Fehler im Routing könnte daran liegen, dass "lanes = 4" gefehlt hat. Habe ich eben ergänzt. Bitte noch einmal testen!
Ulrich
Moin! Noch funktioniert es nicht. Das ist wahrscheinlich nur ein Problem der Aktualität. Das Routing verwendet wahrscheinlich nicht die Originaldaten sondern erzeugt eine spezielle Routing-Datenbank. Das geschieht bestimmt nicht stündlich.
Die Anzahl der Fahrspuren halte ich nicht für relevant. Die hast die Überfahrten zwischen den Richtungsfahrbahnen eingezeichnet und das "oneway" für den Teil raus genommen, der nun auch in Gegenrichtung genutzt wird. Das müsste reichen, wenn das Routing nicht für Autobahn das "oneway" als zwingend annimmt.
So habe ich getestet:
Auf https://www.openstreetmap.org oben links auf den Pfeil neben dem Suchfeld geklickt. Die grüne/rote Start-/Ziel-Marke kann man alternativ zu einer Sucheingabe mit der Maus in die Karte ziehen. Mit "Richtung umkehren" wird die Strecke benutzt. --
Frank _______________________________________________ OSM mailing list OSM@gt.owl.de http://gt.owl.de/cgi-bin/mailman/listinfo/osm
-- Matthias Marquardt http://about.me/matthiasmarquardt [FileScout | iMazing | Iconify | TOMPlayer | LittleBrother | GPSLogger II | GPSiesConnect] http://www.emacberry.com <http://about.me/matthiasmarquardt>
Am 15.12.18 um 13:02 schrieb Frank Jäger:
Am 15.12.18 um 11:34 schrieb Ulrich Wehmeier:
der Fehler im Routing könnte daran liegen, dass "lanes = 4" gefehlt hat. Habe ich eben ergänzt. Bitte noch einmal testen! Ulrich
...
Die hast die Überfahrten zwischen den Richtungsfahrbahnen eingezeichnet und das "oneway" für den Teil raus genommen, der nun auch in Gegenrichtung genutzt wird. Das müsste reichen, wenn das Routing nicht für Autobahn das "oneway" als zwingend annimmt. ...
Eins fehlt noch: Im Bereich der Baustelle wird nun eine Richtungsfahrbahn, also ein "way", in beide Richtungen verwendet, das "oneway" ist dafür rausgenommen. Das "erlaubt" dem Routing nach den Querverbindungen prinzipiell auch ein Links-Abbiegen auf die Gegenspur. Die tatsächlichen Fahrspuren dürften aber entgegen dem derzeitigen "Modell" weiterhin streng getrennt sein. Es sollten daher noch Abbiege-Regeln drauf. -- Frank
On Sat, Dec 15, 2018 at 01:02:26PM +0100, Frank Jäger wrote:
Moin! Noch funktioniert es nicht. Das ist wahrscheinlich nur ein Problem der Aktualität. Das Routing verwendet wahrscheinlich nicht die Originaldaten sondern erzeugt eine spezielle Routing-Datenbank. Das geschieht bestimmt nicht stündlich.
Ich berechne die Daten alle 2 Stunden auf aktuellen Daten. D.h. ich update einen OWL Extract, konvertiere das für meine eigene OSRM Instanz und berechne da drauf ~60000 Routen für OWL - Derzeit nur für einige Kommunen. Bei änderungen der länge um mehr als 30m bekomme ich eine mail das sich routen geändert haben. Für mich ist die A30 demnach immer noch nicht befahrbar.
Die Anzahl der Fahrspuren halte ich nicht für relevant.
Ist es auch nicht.
Die hast die Überfahrten zwischen den Richtungsfahrbahnen eingezeichnet und das "oneway" für den Teil raus genommen, der nun auch in Gegenrichtung genutzt wird. Das müsste reichen, wenn das Routing nicht für Autobahn das "oneway" als zwingend annimmt.
Flo -- Florian Lohoff f@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away
On Sat, Dec 15, 2018 at 11:34:48AM +0100, Ulrich Wehmeier wrote:
Guten Morgen,
der Fehler im Routing könnte daran liegen, dass "lanes = 4" gefehlt hat. Habe ich eben ergänzt. Bitte noch einmal testen!
Aeh - also ich habe nur mal ab AS Löhne richtung Bad Oeynhausen gesucht und sofort Fehler gefunden: access=no https://www.openstreetmap.org/way/4981727 Davor gibt es eine verbindung zwischen den beiden Richtungsfahrbahnen https://www.openstreetmap.org/way/654734783 allerdings stößt die auf die ggü. liegende Richtungsfahrtbahn die ein oneway=yes hat in Gegenrichtung. Damit ist das nicht durchgehend befahrbar von OS Richtung H. https://www.openstreetmap.org/way/32549516 Was ist denn da jetzt Phase? Ich dachte das die A30 in beide Richtungen befahrbar ist? Die Daten geben das gerade nicht her. Ich werde das jetzt nicht ändern weil ich den Zustand vor Ort nicht kenne aber die Daten passen zu dem Routing was gerade nicht geht. Flo -- Florian Lohoff f@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away
participants (4)
-
Florian Lohoff -
Frank Jäger -
Matthias Marquardt -
Ulrich Wehmeier