161

Natürlich, alle Karten routen hier richtig. Auch alte AIO. Nur genau die neue AIO von 2009-02-18 eben nicht!

Es ist allgemein bekannt, dass Cloudmade nicht korrekt routen kann. Restriktionen wurden sehr lange völlig falsch behandelt, z.Zt. werden Restriktionen gar nicht mehr beachtet. Aber es geht hier nicht um die Fähigkeiten von Cloudmade. Ich habe Cloudmade hier nur verwendet, um die Route darzustellen. Man kann ja hier leider keine Screenshots des etrex VISTA hochladen.

Oh. Als ich die Gegend kartiert habe, ist mir gar kein Bahnhof aufgefallen. :wink:

Ach ja, Danke für das fixme http://www.openstreetmap.org/browse/changeset/3918377. Die Stelle war ein Fehler von mir!

162

Die beiden Routingfehler am Friedhof lagen an falschen Daten (oneway, service-Roads ohne access rights).

Nicht direkt. Aber mit Garmins ximage und einem Dienst wie picr.de gehts.
Chris

163

Du hast recht. Selbstverständlich lagen genau diese von dir zitierten Routingfehler an den falschen Daten.

Die Diskussion von Ergebnissen des Cloudmade-Routers halte ich in diesem Kontext allerdings nicht für zielführend.
Die korrekte Behandlung von Abbiege-Restriktionen durch Router ist ein Trauerspiel.
Mir ist, trotz intensiver Suche, kein einziger WEB-basierter Router auf Basis von OSM-Daten bekannt, der in der Lage ist, korrekt mit den OSM-Abbiege-Restriktionen umzugehen! Gibt es einen solchen der das kann?

Aber das lenkt vom eigentlichen Thema ab:
Der von mir zitierte Routing-Fehler mit der AIO-Karte liegt nicht an falschen OSM-Daten. Oder sehe ich das falsch?
Die neueste AIO-Karte scheint die Bedeutung von ‘only_*’ zu invertieren. Kann das irgendjemand bestätigen oder bilde ich mir das nur ein? Mit diesem Verhalten wäre die AIO-Karte in Gegenden mit korrekt kartierten Restriktionen für das Routing nicht mehr zu gebrauchen.

Im Gensatz zu den mir bekannten web-basierten Routern ist der im etrex VISTA HCx eingebaute Router sehr wohl in der Lage, mit den Abbiege-Restriktionen aus OSM-Daten korrekt zu arbeiten. Die bisherigen AIO-Karten waren der Beweis dafür. Mit der aktuellen AIO-Karte (2009-02-18) ist das allerdings leider vorbei.

Wie sieht es denn in deiner Region mit den kartierten Abbiege-Restriktionen aus?
Sind dort überhaupt welche erfasst?
Welche Erfahrungen hast Du mit deinem mobilen Router im Live-Betrieb im Zusammenhang mit Restriktionen?

Mir ist schon klar, wie ich Screenshots machen kann und dass man auf irgendwelchen anderen Servern auch Daten hochladen und hier verlinken kann. Das will ich nicht.
Hier in diesem Forum geht das Hochladen leider nicht!
Deshalb der Notbehelf mit dem Cloudmade-Link

164

Interessant wären für mich Stylefiles (insbesondere ‘lines’), mit denen das Routing auch so funktioniert, wie man es erwartet. Also bei schnellere Route die schnellere, bei kürzere Route die kürzere.

Mein Beispiel ist Regensburg - Reutlingen: die AIO routet über Nürnberg, 25 km weiter als über München und auch 10 Minuten länger als über München.

Computerteddy’s Karte routet über München, noch immer nicht die schnellste, aber besser als über Nürnberg, am Rückweg aber über Würzburg!!! Mehr als 90 km Umweg und wesentlich längere Zeit.

Beide Karten routen über die B300 nach Reutlingen, wenn ich Höhe Ulm auf der A8 einen Routenpunkt setze. Da wird dann plötzlich die schnellste und auch kürzeste Route berechnet.

Verstehen muss man das nicht …

Wer hat ein Stylefile, das korrekt routet?

Danke,

flux.

165

Also die Router-Einstellungen ‘Kürzeste Zeit’ oder ‘kürzeste Strecke’ sind auch ein sehr interessantes Thema.
Der Router des etrex VISTA HCx liefert hier mit der AOI-Karte schon mal Ergebnisse, die überraschend sind: Es kommt vor, dass die Route für ‘kürzeste Strecke’ deutlich länger ist als die Route für ‘Kürzeste Zeit’.
Hier sind die Ergebnisse in der Tat nicht so wie man es Wortsinne ‘kürzeste’ erwartet.
Die Ursache hierfür vermute ich aber im Algorithmus des Routers und eher nicht in der Karte.

166

Dann wäre es aber bei allen Karten gleich und das ist es nicht … die falschen Ergebnisse liefern Vista HCx und Oregon 300 gleichermaßen.

flux.

167

Na ja. Hinter beiden steckt derselbe Router? Ich halte das defintiv für einen Fehler des Routers. Ein Algorithmus, der bei Einstellung ‘kürzest’ etwas längeres liefert als sonst, ist kaputt. Das gilt unabhängig von den zugrunde liegenden Daten.

168

In “meiner” Stadt bin ich bisher mit einer einzigen Turn-Restriktion ausgekommen. :wink:

Eine schönes Testgebiet ist die Stadt Hameln, dort gibt es duzende Restriktionen.

http://osm.virtuelle-loipe.de/restrictions/?zoom=15&lat=52.10329&lon=9.36257&layers=B00TT

Chris

169

Na ja. Es gibt halt Gebiete wo man fast keine Restriktionen braucht.

Oh ja. Sehr interessante Gegend.

170

Wenn man das genau untersucht, könnte man dort aber auch einige rausschmeissen, da sie sich allein schon durch die Einbahnstraßenregelung ergeben.

Christian

171

Konkretes Beispiel?

172

Also ich hab mal ein paar Routingprobleme gezielt debuggt. Ich hab dazu Mapsource verwendet in der Annahme, dass dort der gleiche Routingalgorithmus verwendet wird, wie auf den Geräten.

Probleme scheint es immer dann zu geben, wenn Kachelgrenzen ins Spiel kommen. Es scheint für das Garmin deutlich besser bewertet zu sein, wenn es auf der gleichen Kachel bleibt, statt von einer Kachel in die andere zu fahren und an anderer Stelle weider zurück.

Beispiel:

                      Weg 2
  _________________________________________
 |                                                                       |

----|---------------------------------------------------------|---------- Kachelgrenze
| |
A B
| |
| |
| |
| |
| |
| Weg 1 |
| ________________________________________|

Um von Punkt A zu Punkt B zu gelangen, wird das Garmin immer Weg 1 vorschlagen (sofern Weg 2 nicht im Überlappungsbereich der Kacheln liegt) und damit den längeren Weg wählen, weil er auf der selben Kachel liegt.
Komplizierter wird es, bei meherern Kachelübergängen. Meistens gewinnt die Route mit den wenigstens Kachelüberschreitungen.

Ich frag mich, wieso Garmin solche bescheuerten Algorithmen baut.

Wenn meine Erkenntnis korrekt ist, dann ist das Routing sowieso eher Glückssache und ist stark von der Kachelung der Daten abhängig. So weit ich weiß, verwendet Computerteddy ein festes Raster. Ich nehme den Tilesplitter und habe dabei ein dynamisches Raster.
Wenn einige von euch testen, dann ladet ihr bestimmt euer Testgebiet in dem ihr euch auskennt runter und müsst eventuell gar nicht kacheln. Dann sollten die Routen sogar ganz gut aussehen.

Kann meine Beobachtung bezüglich der Kachelgrenzen jemand bestätigen?

Grüße
Christoph

173

Das Gebiet, in dem bei mir die häufigen Abbrüche lagen, scheint von einer Kachelgrenze durchzogen zu sein.
Bei Experimenten mit von mir selbst gebauten Karten konnte ich auch eine Abhängigkeit von den Splittereinstellungen feststellen.
Eine unterschiedliche Heapgröße für Java führte bei ansonsten gleichen Einstellungen zu unterschiedlicher Kachelung und auch zu unterschiedlichen Routingergebnissen. Routen über eine Kachel-Grenze hinweg waren teilweise unmöglich oder wurden mit sehr seltsamen Umwegen berechnet.
Deshalb habe seinerzeit auch so hartnäckig nach deinen exakten Splittereinstellungen gefragt.

Na ja, möglicherweise werden aber die Daten vom Splitter an den Kachel-Grenzen zerstört. Kann der Splitter z.B. mit Abbiege-Restriktionen über Kachel-Grenzen hinweg umgehen.

Ich stelle mir diesen Split-Vorgang extrem kompliziert vor.

… was dann natürlich zu völlig anderen Ergebnissen führen kann. Bei meinen Tests habe ich mit Bedacht immer die Karte für ganz Deutschland erzeugt.

p.s.
Deine aktuellen original AIO-Karten (2020-02-18 und 2010-02-22) haben jetzt keine ständigen Routing-Abbrüche in dem betreffenden Gebiet mehr.
Allerdings sind die Karten jetzt wegen des Fehlers mit den Abbiege-Restriktionen mit ‘restriction=only_’ in dem betreffenden Gebiet wieder nicht zu gebrauchen. Ich konnte den 'restriction=only_’-Fehler inzwischen auch noch an anderen Stellen einwandfrei nachvollziehen. Dieser Fehler war vorher nicht enthalten. Was hast Du denn diesbezüglich geändert?

174

Ich habe eine gegenteilige Erfahrung gemacht: Je kleiner die mit dem Splitter erstellten Kacheln sind, desto besser ist das Routing.

–max-nodes=600000

bringt mir ein völlig korrektes Routing von Regensburg nach Reutlingen, schnellste Route ist die schnellste! Über die B300, die sonst nur mit Zwischenpunkt berechnet wird.

Das schaut sehr gut aus …

flux.

175

Möglicherweise führen in dem Fall dann alle Routen über irgendwelche Kachelgrenzen, mit der Folge, dass er keine “falsche” Route mehr ausgibt, nur weil die zufällig gerade auf einer Kachel liegt.

176

Nein, ich nehme alles zurück …

Das waren wohl atmosphärische Störungen, die mein Vista HCx da geritten haben. Heute routet das Vista HCx wieder genauso falsch wie die Tage zuvor.

Ausschalten gestern abend in der Freude, dass alles passt, anschalten heute und Ernüchterung. Die Einstellungen sind unverändert, definitiv.

flux.

177

Ich überlege, ob es sinnvoll sein könnte aus dem OSM-File zunächst alle Straßen zu extrahieren und diese in einen separaten Layer zu packen.
Die Kacheln könnten somit aufgrund der geringeren Daten größer werden. Vielleicht sollte ich auch ein festes Raster verwenden.

Punkte, Flächen und übrig gebliebene Linien könnte ich dann in einen anderen Layer packen.
Ich könnte mir vorstellen, dass das funktioniert, müsste aber ganz schön viel testen dazu.

Mal sehen, ob da was geht. Vielleicht findet ja auch noch jemand was anderes raus, was hier helfen könnte.

Viele Grüße!
Christoph

PS: Seh ich eigentlich irgendjemanden von euch zur FOSSGIS?

178

Eine Trennung der Straßen von anderen Objekten ist wahrscheinlich eine gute Idee.

Man könnte aber auch noch einen Schritt weiter gehen und sämtliche für das Routing relevanten Elemente vollständig von den Elementen für die Darstellung der Karte trennen.

  • Dabei würde eine dedizierter (optisch unsichtbarer) Layer ausschließlich Informationen zum Routing enthalten.
  • Weitere (sichtbare) Layer würden dann zusätzlich die Darstellung der Straßen (und Flächen, …) enthalten.

Dabei hätte man dann zwar in Summe viele Elemente (nämlich die Wege) doppelt, aber man hätte eine völlige Trennung zwischen der Routing-Informationen einerseits und der grafischen Darstellung andererseits.

Der Routing-Layer könnte dann mit viel weniger, möglicherweise sogar ohne, Kachelung auskommen.

Das hätte auch den Vorteil, dass man bei der grafischen Darstellung nicht mehr auf Einschränkungen bei der Definition der routing-spezifischen Eigenschaften Rücksicht nehmen müßte.

179

Sagt wie ihr das anpacken wollt (technisch, mit splitter/mkgmap) und ich kann mithelfen, testen, habe Zeit dazu und Interesse auch!

flux.

180

Ich habe auch bereits Beeinträchtigungen beim Routing über Kachelgrenzen hinweg festgestellt,
habe es aber meist auf schlecht verbundene Wege geschoben.

Nach welcher Methode trennt der Splitter eigentlich die Kacheln auf, dass mkgmap über die Grenze hinweg überhaupt routen kann?
Vielleicht liegt ja gerade darin das Problem, dass diese Trennung nicht wieder sauber zusammengefügt wird.

Walter