DE:All in one Garmin Map

master · 2010-02-17 12:01:38

geopia wrote:

Könntest Du das auch noch für die Ausgabe der Parameter des Splitters einbauen?
Welchen Splitter verwendest Du?

den aktuellen 105.
Die Parameter lohnen kaum. Sind immer:
splitter.jar --mapid=63240345 --max-nodes=1000000
und ein Cache directory.

Die Parameter für den Bau des OSB-Layers fehlen.
Wie baust den OSB-Layer konkret.
Wenn ich deiner Beschreibung mit osbsql2osm in
http://wiki.openstreetmap.org/wiki/DE:A … streetbugs folge, dann erhalte ich ein anderes Ergebnis als in der original AIO-Karte:
- Bei der original AIO-Karte werden nur offene Bugs angezeigt
- Bei meiner mit osbsql2osm selbst gebauten Karte werden offene *und* geschlossene Bugs angezeigt.

Stimmt - ich schieb das hinterher noch durch osmosis und beschränke das auf die boundingbox des osmfiles (hab ein sed-skript, was die BBOX aus dem OSM-File holt und ein bisschen makefile-spaß), sowie alle offenen bugs:
osbsql2osm | osmosis --rx - --bb $(BBOX) --nkv keyValueList="type.0" --wx ausgabe.osm

Warum werden eigentlich die Layer für 'fixme' und 'OSB' im etrex VISTA HCx Layer-Ein-und-Abschalt-Menü beide mit dem gleichen Namen 'Fixme' angeboten?
Im Beispiel im Wiki werden beide Layer mit --family-id=3 und --product-id=33 erzeugt. Ist das korrekt?
Die TYP-Dateien fixme.TYP und osb.TYP sind identisch! Ist das korrekt?

Naja ursprünglich wollte ich das alles in einen Layer tun, aber so richtig ist das dann doch nicht geworden. Sauber getrennt hab ichs eben nie. Werde ich wohl mal machen müssen.
Der kommt aber auch damit klar, denke ich, wenn die Dateien eigentlich gleich sind.

Das mit einem svn wollte ich auch schon anregen. Damit wird die Erzeugung deiner Karte für alle transparent.
Das hätte in vielerlei Hinsicht Vorteile.

Hab das mal angefragt. Mal sehen, wann das läuft.

Grüße
Christoph

Weide · 2010-02-18 10:17:18

Weide wrote:

In Düsseldorf tritt der Fehler mit der o.g. Karte auf der geraden 500m langen Strecke von
Start: Ecke Ulmenstraße/Weißenburgstraße
Ziel: Ecke Ulmenstraße/Wörthstraße
auf.
Vista HCx, Auto/Motorrad, kürzere Zeit, folge Straße, vermeide nichts
http://www.openstreetmap.org/?lat=51.24 … 31&zoom=17

Dieser Fehler ist in der heute morgen geholten Karte weg. Die anderen auch?

Weide

flux · 2010-02-18 11:30:36

Problem ist nach wie vor die Berechnung von Routen.

Beispiel:

Regensburg - Reutlingen wird mit 345 km und 3:18 Stunden berechnet, obwohl es eine Route mit 312 km und 3:04 Stunden gibt und eine mit 294 km und 2:56 Stunden.

Es wird also trotz "Kürzere Zeit" nicht die korrekte Route berechnet.

Die Style-files aus mkgmap ohne Bearbeitung routen die Strecke mit 312 km und 3:04 Stunden.

Dies tritt auf dem Vista HCx und dem Oregon 300 gleichermaßen auf. Die Geschwindigkeitsklassen in Verbindung mit den beiden Geräten scheinen nicht zusammen zu passen.

An einer Lösung wäre ich sehr interessiert.

flux.

Weide · 2010-02-18 15:42:59

Weide wrote:

Dieser Fehler ist in der heute morgen geholten Karte weg.

flux wrote:

Regensburg - Reutlingen wird mit 345 km und 3:18 Stunden berechnet, obwohl es eine Route mit 312 km und 3:04 Stunden gibt und eine mit 294 km und 2:56 Stunden.
Es wird also trotz "Kürzere Zeit" nicht die korrekte Route berechnet.

Das sieht nach zwei verschiedenen Problemen aus.

Bei der von mir erwähnten Strecke geht es um Bereiche der Karte, in denen jedes Routing im Garmin abbricht. Dieses Problem ist jetzt entweder gelöst oder es tritt jetzt an anderen Stellen auf.

Da wäre jetzt die Frage an alle, die reproduzierbare Berechnungsabbrüche bei Routen hatten, ob das Problem auch bei ihnen weg ist.

Beim von Dir erwähnten Problem geht es um schlechte Lösungen von Routingproblemen, weil augenscheinlich irgendwelche Möglichkeiten ausgeschlossen werden, die zur besten Lösung gehören.

Da wäre die Frage, ob man das Problem lokalisieren kann. Z.B. indem man auf der nicht gefundenen besten Route Teilstücke routen läßt. Mit etwas Glück werden die meisten Teilstücke optimal geroutet und man kann irgendwelche Besonderheiten im Rest erkennen.

Weide

flux · 2010-02-18 16:19:29

Die Routingprobleme scheinen mit der Karte von gestern gelöst zu sein. Regensburg - Düsseldorf und Düsseldorf/Eulerstraße (das waren meine Teststrecken) gehen wieder.

Routing allgemein: Erstelle ich eine Karte mit den Style-files von mkgmap (default), dann wird von Regensburg nach Reutlingen richtig geroutet (kürzere und schnellere Autobahnstrecke). Das Problem tritt mit der AIO auf. Ich verwende identischen Routingeinstellungen.

Setze ich einen Routenpunkt irgendwo zwischen Regensburg und Reutlingen, wird sogar eine B300 mit berücksichtigt und die Strecke wird um mehr als 50 km kürzer und mehr als 20 Minuten schneller.

Erklärbar ist es nicht ...

flux.

Weide · 2010-02-18 19:58:59

flux wrote:

Setze ich einen Routenpunkt irgendwo zwischen Regensburg und Reutlingen, wird sogar eine B300 mit berücksichtigt und die Strecke wird um mehr als 50 km kürzer und mehr als 20 Minuten schneller.
Erklärbar ist es nicht ...

Das ist ein wichtiger Hinweis! Es ist also nicht so, dass die Route nicht genommen wird, weil sie irrtümlich als nicht passierbar gilt. Sie scheidet also vermutlich aus, weil sie bei einer Vorprüfung durchgefallen ist.
Diese Vorprüfungen entscheiden erstmal, welche Wegstücke überhaupt in welchen Richtungen in Frage kommen. Wenn man da zuviel drin lässt, dann wird das Routing elend lahm.

Die B300 ist in der Mitte des Stücks "highway=trunk" und sonst "highway=primary". Wenn also nach irgendeinem Plausibilitätskriterium für die Stücke weitab von den Wegpunkten nur z.B. motorway und trunk berücksichtigt wird, dann wäre das eine Erklärung. Vielleicht ist da bei der Umsetzung in Garmindaten eine Besonderheit...

Weide

flux · 2010-02-18 20:12:46

Wenn die B300 als Nicht-Autobahn ohne zusätzlichen Routenpunkt nicht gewählt wird, dann ist das ja auch erklärbar.

Warum aber beide Garmin mit der AIO von Regensburg über Nürnberg nach Reutlingen fahren und nicht die kürzere und schnellere Strecke über München wie mit der Karte ohne spezielles Stylefile, das erschließt sich mir nicht.

Und warum die AIO beim Setzen eines Routenpunktes auf der A8 Höhe Ulm nicht die Autobahn über München fährt sondern die B300 wählt und damit plötzlich die kürzeste und schnellste Strecke, das bleibt auch ein Geheimnis.

flux.

Last edited by flux (2010-02-18 20:13:25)

Weide · 2010-02-19 07:12:15

flux wrote:

Warum aber beide Garmin mit der AIO von Regensburg über Nürnberg nach Reutlingen fahren und nicht die kürzere und schnellere Strecke über München wie mit der Karte ohne spezielles Stylefile, das erschließt sich mir nicht.
Und warum die AIO beim Setzen eines Routenpunktes auf der A8 Höhe Ulm nicht die Autobahn über München fährt sondern die B300 wählt und damit plötzlich die kürzeste und schnellste Strecke, das bleibt auch ein Geheimnis.

Ja.
Wenn das bei jedem Stylefile passieren würde, dann könnte man vermuten, dass das ziemlich lange Stück bis München gar nicht erst geprüft wurde: weite Strecke , kaum Annäherung ans Ziel, kann nicht sein. Beim Ziel Ulm liegt München schon eher in der Nähe der Luftlinie. Aber die Abhängigkeit vom Style-File kann ich mir so nicht erklären.

Weide

geopia · 2010-02-19 20:01:49

Weide wrote:

Weide wrote:
In Düsseldorf tritt der Fehler mit der o.g. Karte auf der geraden 500m langen Strecke von
Start: Ecke Ulmenstraße/Weißenburgstraße
Ziel: Ecke Ulmenstraße/Wörthstraße
auf.
Vista HCx, Auto/Motorrad, kürzere Zeit, folge Straße, vermeide nichts
http://www.openstreetmap.org/?lat=51.24 … 31&zoom=17
Dieser Fehler ist in der heute morgen geholten Karte weg. Die anderen auch?
Weide

Kann ich bestätigen:
Die ständigen Abbrüche mit "Routenberech.-Fehler." in diesem Düsseldorfer Bereich sind mit der original AIO-Karte von 2010-02-18 verschwunden. Klasse!
Die letzte von mir getestete Version mit dem Fehler war 2010-02-15.
@master: Was hast Du denn geändert?

Leider gibt es aber bei dieser Karte (2010-02-18) jetzt ein neues Problem das vorher nicht vorhanden war:
Abbiege-Restriktionen werden völlig falsch interpretiert.

Beispiel Route in Cloudmade:
http://maps.cloudmade.com/?lat=51.25360 … ened_tab=1

Der Router des etrex VISTA HCx berechnet mit der AIO-Karte den Weg von Punkt A nach Punkt C mit einem Umweg nach rechts mit Wende an der nächsten Kreuzung.
Der direkte Weg über die Kreuzung wurde vom Router mit alten AIO-Karten problemlos gefunden. Mit der neuen Karte kann der Router die Kreuzung nicht mehr direkt überqueren.

Ursache kann die dort kartierte Abbiege-Restriktion sein.
Es handelt sich um eine Restriktion 'only_straight_on'. Diese Restriktion wird scheinbar fälschlich als 'no_*' interpretiert.
Was läuft da falsch? Wenn ich nicht irre, haben Restriktionen mit der alten AIO-Karte durchaus korrekt funktioniert.
@master: Was hat sich diesbezüglich geändert? Es wird jetzt scheinbar bei Restriktionen statt 'only_*' immer 'no_*' angenommen.
Das ist extrem kontraproduktiv.

Hier die Stelle mit dem OSM Restriction Analyzer:
http://osm.virtuelle-loipe.de/restricti … yers=B00TT
(Achtung: Es kann Minuten dauern, bis man die Restriktion tatsächlich sieht.)

chris66 · 2010-02-19 20:57:22

Die BlueMap routet dort gerade aus drüber.

Interessant ist noch folgendes CloudeMade Routing quer über den Friedhof:

http://maps.cloudmade.com/?lat=51.25654 … ened_tab=1

Wenn man A und B vertauscht kann er überhaupt keine Route finden, da sollte man sich die
Einbahnstrassen nochmal genau anschauen. Ich habe da das kleine Stück von
der "Am Nordbahnhof" Schleife und der Johannstraße im Verdacht.

Edit: Habe den Südzugang mal mit motorcar=no getaggt. Fahrräder dürfen ja nicht rein, deshalb gehe ich
davon aus, dass Autos auch nicht rein dürfen.

Chris

Last edited by chris66 (2010-02-19 21:26:02)

geopia · 2010-02-20 01:33:39

chris66 wrote:

Die BlueMap routet dort gerade aus drüber.

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

chris66 wrote:

Interessant ist noch folgendes CloudeMade Routing quer über den Friedhof:
http://maps.cloudmade.com/?lat=51.25654 … ened_tab=1
Wenn man A und B vertauscht kann er überhaupt keine Route finden, da sollte man sich die
Einbahnstrassen nochmal genau anschauen.

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.

chris66 wrote:

Ich habe da das kleine Stück von
der "Am Nordbahnhof" Schleife und der Johannstraße im Verdacht.

Oh. Als ich die Gegend kartiert habe, ist mir gar kein Bahnhof aufgefallen. ;-)

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

Last edited by geopia (2010-02-20 01:56:59)

chris66 · 2010-02-20 11:32:23

geopia wrote:

Es ist allgemein bekannt, dass Cloudmade nicht korrekt routen kann.

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

geopia wrote:

Man kann ja hier leider keine Screenshots des etrex VISTA hochladen.

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

Last edited by chris66 (2010-02-20 11:40:30)

geopia · 2010-02-20 19:17:32

chris66 wrote:

geopia wrote:
Es ist allgemein bekannt, dass Cloudmade nicht korrekt routen kann.
Die beiden Routingfehler am Friedhof lagen an falschen Daten (oneway, service-Roads ohne access rights).

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?

chris66 wrote:

geopia wrote:
Man kann ja hier leider keine Screenshots des etrex VISTA hochladen.
Nicht direkt. Aber mit Garmins ximage und einem Dienst wie picr.de gehts.
Chris

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

flux · 2010-02-20 20:08:57

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.

Last edited by flux (2010-02-20 20:18:15)

geopia · 2010-02-20 20:48:14

flux wrote:

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.

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.

flux · 2010-02-20 21:04:25

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.

geopia · 2010-02-20 21:30:35

flux wrote:

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.

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.

chris66 · 2010-02-20 22:30:18

geopia wrote:

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?

In "meiner" Stadt bin ich bisher mit einer einzigen Turn-Restriktion ausgekommen.

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

http://osm.virtuelle-loipe.de/restricti … yers=B00TT

Chris

geopia · 2010-02-20 23:27:57

chris66 wrote:

geopia wrote:
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?
In "meiner" Stadt bin ich bisher mit einer einzigen Turn-Restriktion ausgekommen.

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

chris66 wrote:

Eine schönes Testgebiet ist die Stadt Hameln, dort gibt es duzende Restriktionen.
http://osm.virtuelle-loipe.de/restricti … yers=B00TT
Chris

Oh ja. Sehr interessante Gegend.

brogo · 2010-02-21 11:17:21

chris66 wrote:

Eine schönes Testgebiet ist die Stadt Hameln, dort gibt es duzende Restriktionen.
http://osm.virtuelle-loipe.de/restricti … yers=B00TT

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

Christian

geopia · 2010-02-21 19:07:07

brogo wrote:

chris66 wrote:
Eine schönes Testgebiet ist die Stadt Hameln, dort gibt es duzende Restriktionen.
http://osm.virtuelle-loipe.de/restricti … yers=B00TT
Wenn man das genau untersucht, könnte man dort aber auch einige rausschmeissen, da sie sich allein schon durch die Einbahnstraßenregelung ergeben.
Christian

Konkretes Beispiel?

master · 2010-02-22 18:39:43

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

geopia · 2010-02-22 19:15:15

master wrote:

Probleme scheint es immer dann zu geben, wenn Kachelgrenzen ins Spiel kommen.

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.

master wrote:

Ich frag mich, wieso Garmin solche bescheuerten Algorithmen baut.

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.

master wrote:

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 ...

... 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?

flux · 2010-02-22 23:03:04

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.

MHohmann · 2010-02-23 00:01:04

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.

Announcement

#151 2010-02-17 12:01:38

Re: DE:All in one Garmin Map

#152 2010-02-18 10:17:18

Re: DE:All in one Garmin Map

#153 2010-02-18 11:30:36

Re: DE:All in one Garmin Map

#154 2010-02-18 15:42:59

Re: DE:All in one Garmin Map

#155 2010-02-18 16:19:29

Re: DE:All in one Garmin Map

#156 2010-02-18 19:58:59

Re: DE:All in one Garmin Map

#157 2010-02-18 20:12:46

Re: DE:All in one Garmin Map

#158 2010-02-19 07:12:15

Re: DE:All in one Garmin Map

#159 2010-02-19 20:01:49

Re: DE:All in one Garmin Map

#160 2010-02-19 20:57:22

Re: DE:All in one Garmin Map

#161 2010-02-20 01:33:39

Re: DE:All in one Garmin Map

#162 2010-02-20 11:32:23

Re: DE:All in one Garmin Map

#163 2010-02-20 19:17:32

Re: DE:All in one Garmin Map

#164 2010-02-20 20:08:57

Re: DE:All in one Garmin Map

#165 2010-02-20 20:48:14

Re: DE:All in one Garmin Map

#166 2010-02-20 21:04:25

Re: DE:All in one Garmin Map

#167 2010-02-20 21:30:35

Re: DE:All in one Garmin Map

#168 2010-02-20 22:30:18

Re: DE:All in one Garmin Map

#169 2010-02-20 23:27:57

Re: DE:All in one Garmin Map

#170 2010-02-21 11:17:21

Re: DE:All in one Garmin Map

#171 2010-02-21 19:07:07

Re: DE:All in one Garmin Map

#172 2010-02-22 18:39:43

Re: DE:All in one Garmin Map

#173 2010-02-22 19:15:15

Re: DE:All in one Garmin Map

#174 2010-02-22 23:03:04

Re: DE:All in one Garmin Map

#175 2010-02-23 00:01:04

Re: DE:All in one Garmin Map

Board footer