DE:All in one Garmin Map

mihof · February 8, 2010, 9:13pm

Könnte sein, dass die Frage hier an der falschen Stelle steht:
Ist die öpnvkarte.de auch als downloadbare Version für den Garmin verfügbar, ggfs. wo?
Danke!
mihof

mike_hd · February 9, 2010, 1:55pm

Meiner Meinung nach ist die AIO derzeit die beste OSM-Karte für die Garmins, vorallem aber auch die aktuellste.

Es sind mir aber ein paar Dinge aufgefallen:

Zuvor wurde schon beschrieben, dass Friedhöfe nicht dargestellt werden. Seltsamerweise werden aber einige angezeigt, andere nicht!?
In MapSource werden Polylinien 0x17 (Rennbahn) und 0x39 (Straßenbahn) nicht dargestellt, auf dem Gerät schon.
Und es ist egal, wie man das Typ-File ändert, in MS geht es nicht. Bei Typ-Files anderer Karten werden diese Elemente nicht verwendet.
Zumindest auf dem Oregon wird das Icon 0x2c 0x19 (Wasserturm) nicht dargestellt, auf MS aber schon.

Habe ich nur das Problem, oder ist das anderswo auch so?

Mike

chris66 · February 9, 2010, 4:10pm

zu 1) Werden vielleicht von anderen Flächen zB residential überdeckt ?

zu 2) Das ist richtig, MS kann nicht alle Lines darstellen, die das Gerät anzeigen kann, des weiteren sind nur
bestimmte Linientypen fürs Routing geeignet.

Chris

mike_hd · February 9, 2010, 8:45pm

Nein, sie fehlen einfach. Aber wie gerade feststelle, fehlen alle Friedhofflächen. Meine das war früher anders.

Tja, dann könnte man doch für diese Linien andere Typen verwenden.

Noch was festgestellt: barrier = fence (0x33) wird in MS nicht angezeigt, auf den Geräten schon.

master · February 10, 2010, 2:14am

Also warum Mapsource hier manche Sachen nicht anzeigt, kann ich leider nicht sagen.
Ich habe in letzter Zeit verdammt viele Sachen umgebaut und neu gemacht. Schaut euch zum Beispiel mal den neuen Straßenlook an und gebt Meinung ab.

Es gibt jetzt auch für jede Teilkarte einen eigenen Mapsource-installer. Vielleicht nützt es dem ein oder anderen ja.

Die Sache mit den Friedhöfen lag an einem Schreibfehler meinerseits. Es heißt nicht cemetary sondern cemetery!
Danke für den Hinweis.

Die nächste Version ab morgen sollte alle Friedhöfe korrekt enthalten!

Grüße
Christoph

mike_hd · February 10, 2010, 3:23pm

Das warum ist klar, weil es Elemente sind die MS nicht kennt. Darum einfach andere Nummern nehmen.

Es ist halt typisch Garmin, dass die Geräte was können was MapSource nicht kann und umgekehrt, Hausaufgaben halt nicht gemacht …

Das ist sicher eine gute Sache.

Prima!

master · February 11, 2010, 2:33pm

Meinst du mich oder Garmin? Wenn die zu scheiße sind mal vernünftiges Standards zu machen, kann ichs auch nicht ändern.
Aber hast du ne Idee, welche Elemente nicht gehen?
Ich hab die Typen ja relativ beliebig belegt. Ich hab auch schon festgestellt, dass sich manche einfach mal anders verhalten als andere.
Das ist aber von Gerät zu Gerät verschieden und dann auch noch von Software zu Software, eben auch in Mapsource.

Ich persönlich benutze Mapsource höchstens um mal fix meinen Installer zu testen (hab mir extra n virtuelles WindowsXP zugelegt), aber sonst auch nicht.
Aber es soll ja Leute geben, die ernsthaft irgendwie sinnvoll mit Mapsource arbeiten.
Ich dachte ja, dass mit dem Typfile eigentlich festgelegt sein sollte, wie sich die Typen zu verhalten haben, aber das ist offenbar nicht so richtig der Fall.

Hast du vielleicht ne Idee, welche Typen ich vermeiden sollte und welche ich beruhigt nehmen kann? Gibts da ranges?

Eine Sache würde mich noch interessieren, falls die jemand weiß: Wie bekommt man es hin, dass im Find-menü neue Kategorien angelegt werden? Sind die wirklich hard gecodet oder geht da was?
Falls sie hardgecodet sind, würde mich trotzdem interessieren, ob man wenigstens die Unterkategorien benennen kann.
Beispielsweise habe ich ja einige Restaurants oder Shops dabei, die zwar in der entsprechenden Kategorie auftauchen, aber eben als Unterkategorie “Sonstiges” heißen.
Einen Namen im Typfile zu vergeben, reicht offenbar nicht. Kann man da noch was machen?

geopia · February 11, 2010, 5:52pm

In deinem Archiv http://dev.openstreetmap.de/aio/styles/styles.tar.bz2 (Datei masterstyle/polygons) sind beide Schreibweisen (cemetary und cemetery) enthalten. Es sollten also beide angezeigt werden.

Das styles-Archiv trägt das Datum 2009-10-23. Kann es sein, dass das Archiv nicht auf dem aktuellsten Stand ist?

Welche Styles und TYP-Dateien verwendest Du zur Zeit für den Bau der AIO?

Mich interessieren auch brennend die aktuell von dir verwendeten Aufrufparameter für mkgmap.

Sind die hier http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map#Technik angegebenen Parameter aktuell?

Ich versuche gerade die seit dem Jahreswechsel massiv auftreteten Routingfehler mit der AIO zu ergründen.
Dazu habe ich die Karte in Anlehnung an die o.g. Anleitung im Wiki nachgebaut.

Folgende Dinge sind mir dabei aufgefallen:

Die Datei mit den OSBs http://www.gary68.de/osm/qa/gpx/allbugs.gpx lässt sich nicht wie angegeben verarbeiten:
ungültige xml-Datei: Hinter folgt noch weiterer Text.
Abhilfe: Text hinter dem ersten entfernen.

cat download/allbugs.gpx \
  | tr -d '\n\r' \
  | sed 's|</gpx>.*|</gpx>|' \
  | sed -E 's|closed>|name>|g;s|</?extensions>||g' \
  | gpsbabel -i gpx -f - -o osm -F build/bugs_germany.osm

OSBs haben immer den Text 0.
Wenn ich die original Datei fixme_layer_style/points

# Openstreetbugs:
note = * & name='0' [0x7111 resolution 20]
note = * & name='1' [0x7112 resolution 20]
note=* | fixme = * | FIXME=* |Fixme=* {name 'Notiz: ${note}' | 'Notiz: ${fixme}' | 'Notiz: ${FIXME}' | 'Notiz: ${Fixme}' } [0x7110 resolution 20]

durch folgende ersetzte ist die Anzeige wieder wie gewohnt:

# Openstreetbugs:
note = * & name='0' {name '${note}'} [0x7111 resolution 20]
note = * & name='1' {name '${note}'} [0x7112 resolution 20]
note=* | fixme=* | FIXME=* | Fixme=* {name '${note}' | '${fixme}' | '${FIXME}' | '${Fixme}'} [0x7110 resolution 20]

Zurück zu den Routing-Problemen mit etrex VISTA HCx:
Mit den Original-AIO Karten (Deutschland) gibt es neuerdings hier in einem relativ großflächigen Gebiet fast immer Abbrüche mit ‘Routenberech.-Fehler’.

Die original AIO-Karten bis 2009-12-29 haben in dem Gebiet sehr gut funktioniert. Es kam extrem selten zu Abbrüchen.
Die folgenden original AIO-Karten die ich ausprobiert habe (2010-01-19, 2010-01-20, 2010-01-23, 2010-01-27, 2010-01-31, 2010-02-06) führen in 99% der Routing-Versuche zu einem Abbruch mit ‘Routenberech.-Fehler’.

Ich habe mal als konkretes Beispiel irgendeine Straße in der Nähe als Start und einen 50 m davon entfernten Punkt als Ziel verwendet. Zur Verdeutlichung die Route mit Cloudmade:
http://maps.cloudmade.com/?lat=51.243442&lng=6.786895&zoom=18&directions=51.24325372137843,6.787528395652771,51.24367349542995,6.787179708480835&travel=car&styleId=1&opened_tab=1

Das Problem tritt bei fast allen Start oder Zielpunkten in diesem Gebiet auf. Die zugrunde liegenden Daten der Straßen haben sich meines Wissens seit Dezember nicht verändert. Ich habe in dem Gebiet im Laufe des letzten Jahres sehr viele Straßen im Hinblick korrektes Routing aktualisiert und dabei das Verhalten der AIO-Karten ausführlich nach jeder meiner Änderungen getestet. Bis Dez. 2009 funktionierten hier die AIO-Karten hervorragend. Änderungen an den Straßen hatten (meistens) die erwarteten Auswirkungen.

Im Januar wurden lediglich in dem Gebiet sehr viele landuse-Flächen und Gebäude hinzugefügt. Das sollte aber keinen Einfluss auf das Routing haben.

Hat sich beim Bau deiner Karte mit dem Jahreswechsel etwas geändert was Ursache für die Abbrüche sein könnte?

Die beschriebenen Fehler treten übrigens nur bei neueren AIO-Karten auf. Aktuelle andere Karten (Radkarte, teddy-de-rout, Blue Map)haben in dem betreffenden Gebiet keine Routingprobleme.

Zur Ergründung der Ursache habe ich die AIO mit folgenden Befehlen nachgebaut. Die so erstellte Karte zeigt exakt die gleichen Routing-Probleme:


# Für den Bau werden mindestens 12 GB Festplattenplatz benötigt.

# aktuelles Verzeichnis für alle weiteren Befehle:

cd ~/QLandkarteGT/Karten/Garmin/gmapsupp/all_in_one/own


# tilesplitter holen, auspacken und splitter.jar kopieren

[ ! -d download ] && mkdir download
(cd download; wget -N http://www.mkgmap.org.uk/splitter/splitter-r105.tar.gz)
[ ! -d download/splitter ] && mkdir -p download/splitter
tar xf download/splitter-r105.tar.gz -C download/splitter
[ ! -d bin ] && mkdir bin
cp ./download/splitter/splitter-r105/splitter.jar ./bin/.


# mkgmap latest holen, auspacken und mkgmap.jar kopieren:

[ ! -d download ] && mkdir download
(cd download; wget -N http://www.mkgmap.org.uk/snapshots/mkgmap-latest.tar.gz)
[ ! -d download/mkgmap ] && mkdir download/mkgmap
tar -xf download/mkgmap-latest.tar.gz -C download/mkgmap
[ ! -d bin ] && mkdir bin
tar -tf download/mkgmap-latest.tar.gz \
  | grep '/mkgmap.jar$' \
  | sed 's|^|cp download/mkgmap/|' \
  | sed 's|$| bin/.|' \
  | sh -x


# gmaptool holen, auspacken, kopieren:

[ ! -d download ] && mkdir download
(cd download; wget -N http://www.anpo.republika.pl/files/lgmt042a.zip)
[ ! -d download/lgmaptool ] && mkdir -p download/lgmaptool
unzip -o download/lgmt042a.zip -d download/lgmaptool/lgmt042a
[ ! -d bin ] && mkdir bin
cp ./download/lgmaptool/lgmt042a/gmt ./bin/.


# Styles holen und auspacken, kopieren, mit eigenen Aenderungen verschmelzen:

[ ! -d download ] && mkdir download
(cd download; wget -N http://dev.openstreetmap.de/aio/styles/styles.tar.bz2)
[ -e download/styles-aio ] && rm -r download/styles-aio
[ ! -d download/styles-aio ] && mkdir download/styles-aio
tar xf download/styles.tar.bz2 -C download/styles-aio
[ ! -d styles ] && mkdir styles
cp -R "download/styles-aio/osm/garmin/aio/styles/"* styles
[ -d styles-own ] && meld styles styles-own


# OSM-Worldfile von geofabrik holen (ca. 726 MB download)

[ ! -d download ] && mkdir download
(cd download; wget -N http://download.geofabrik.de/osm/europe/germany.osm.bz2)


# OSM-Daten auspacken (ca. 7.8 GB ausgepackt):

[ ! -d build ] && mkdir -p build
[ -e download/germany.osm ] && rm download/germany.osm
bunzip2 -k download/germany.osm.bz2 && mv download/germany.osm build/


# tiles-Ordner anlegen und OSM-Daten splitten (ca. 796 MB):

[ ! -d build/tiles ] && mkdir -p build/tiles
rm build/tiles/*
(cd build/tiles;
  java -Xmx1000M -jar ../../bin/splitter.jar --mapid=63240345 --max-nodes=1000000 ../../build/germany.osm)


# Daten für OSB-Layer holen:

[ ! -d download ] && mkdir download
(cd download; wget -N http://www.gary68.de/osm/qa/gpx/allbugs.gpx)


## Daten für OSB-Layer in OSM-Datei umwandeln:

[ ! -d build ] && mkdir -p build
[ -e build/bugs_germany.osm ] && rm build/bugs_germany.osm
cat download/allbugs.gpx \
  | tr -d '\n\r' \
  | sed 's|</gpx>.*|</gpx>|' \
  | sed -E 's|closed>|name>|g;s|</?extensions>||g' \
  | gpsbabel -i gpx -f - -o osm -F build/bugs_germany.osm


# gmapsupp.img fuer einzelne Layer erstellen (ca. 1.1GB ohne Hoehenlinien):

[ ! -d build/layer/basemap ] && mkdir -p build/layer/basemap
rm build/layer/basemap/*
(cd build/layer/basemap;
  java -Xmx1000M -jar ../../../bin/mkgmap.jar \
  --max-jobs \
  --description=`date +%d.`" $USERNAME "'OSM' --country-name=germany --country-abbr=DE \
  --family-id=4 --product-id=45 --series-name='OSM-AllInOne-DE-bmap' \
  --family-name=OSM --area-name=DE \
  --latin1 \
  --mapname=63240345 --draw-priority=10 \
  --add-pois-to-areas --make-all-cycleways --link-pois-to-ways --remove-short-arcs \
  --net --route --gmapsupp \
  --style-file=../../../styles/masterstyle \
  ../../tiles/*.osm.gz \
  ../../../styles/master.TYP)

[ ! -d build/layer/addr ] && mkdir -p build/layer/addr
rm build/layer/addr/*
(cd build/layer/addr;
  java -Xmx1000M -jar ../../../bin/mkgmap.jar \
  --max-jobs \
  --description=`date +%d.`" $USERNAME "'Adressen' --country-name=germany --country-abbr=DE \
  --family-id=5 --product-id=40 --series-name='OSM-AllInOne-DE-Addr' \
  --family-name=ADRESSEN --area-name=DE \
  --latin1 \
  --mapname=63241345 --draw-priority=20 \
  --no-poi-address --no-sorted-roads --add-pois-to-areas \
  --transparent --gmapsupp \
  --style-file=../../../styles/addresslayer_style \
  ../../tiles/*.osm.gz \
  ../../../styles/addr.TYP)

[ ! -d build/layer/boundary ] && mkdir -p build/layer/boundary
rm build/layer/boundary/*
(cd build/layer/boundary;
  java -Xmx1000M -jar ../../../bin/mkgmap.jar \
  --max-jobs \
  --description=`date +%d.`" $USERNAME "'Boundary' --country-name=germany --country-abbr=DE \
  --family-id=6 --product-id=30 --series-name='OSM-AllInOne-DE-boundary' \
  --family-name=boundary --area-name=DE \
  --latin1 \
  --mapname=63240625 --draw-priority=21 \
  --no-poi-address --no-sorted-roads \
  --transparent --gmapsupp \
  --style-file=../../../styles/boundary_style \
  ../../tiles/*.osm.gz \
  ../../../styles/boundary.TYP)

[ ! -d build/layer/fixme ] && mkdir -p build/layer/fixme
rm build/layer/fixme/*
(cd build/layer/fixme;
  java -Xmx1000M -jar ../../../bin/mkgmap.jar \
  --max-jobs \
  --description=`date +%d.`" $USERNAME "'Fixme' --country-name=germany --country-abbr=DE \
  --family-id=3 --product-id=33 --series-name='OSM-AllInOne-DE-Fixme' \
  --family-name=FIXME --area-name=DE \
  --latin1 \
  --mapname=63242345 --draw-priority=22 \
  --no-poi-address --no-sorted-roads \
  --transparent --gmapsupp \
  --style-file=../../../styles/fixme_layer_style \
  ../../tiles/*.osm.gz \
  ../../../styles/fixme.TYP)

[ ! -d build/layer/osb ] && mkdir -p build/layer/osb
rm build/layer/osb/*
(cd build/layer/osb;
  java -Xmx1000M -jar ../../../bin/mkgmap.jar \
  --max-jobs \
  --description=`date +%d.`" $USERNAME "'OSB' --country-name=germany --country-abbr=DE \
  --family-id=3 --product-id=33 --series-name='OSM-AllInOne-DE-OSB' \
  --family-name=OSB --area-name=DE \
  --latin1 \
  --mapname=63243345 --draw-priority=23 \
  --no-poi-address --no-sorted-roads \
  --transparent --gmapsupp \
  --style-file=../../../styles/fixme_layer_style \
  ../../bugs_germany.osm \
  ../../../styles/fixme.TYP)


# gmapsupp.img fuer Hoehenlinien Layer erstellen (ca. 81 MB):

[ ! -d download ] && mkdir download
(cd download; wget -N http://www.glade-web.de/GLADE_geocaching/maps/TOPO_D_SRTM.zip)
unzip -o download/Topo_D_SRTM.zip -d download/Topo_D_SRTM
[ ! -d build/layer/hoehe ] && mkdir -p build/layer/hoehe
cp "download/Topo_D_SRTM/Topo D SRTM/"* build/layer/hoehe/
[ -e build/layer/hoehe/gmapsupp.img ] && rm build/layer/hoehe/gmapsupp.img
./bin/gmt -j -f 5,25 -m HOEHE -o build/layer/hoehe/gmapsupp.img build/layer/hoehe/*.img


# alle Layer zu einer gmapsup.img zusammenfuegen:

[ -e gmapsupp.img ] && rm gmapsupp.img
./bin/gmt -jo gmapsupp.img \
  build/layer/basemap/gmapsupp.img \
  build/layer/addr/gmapsupp.img \
  build/layer/boundary/gmapsupp.img \
  build/layer/fixme/gmapsupp.img \
  build/layer/osb/gmapsupp.img \
  build/layer/hoehe/gmapsupp.img

Walter_Schlögl · February 11, 2010, 6:09pm

Hallo master,

die Garmin-Kategorien scheinen hardcodet zu sein, noch dazu unterschiedlich je nach Gerät.
Es ist daher gar nicht so leicht, einen Plan für verschiedene Geräte zu erstellen.

Ich hatte vor, in meinem Oregon Plan ca. 25 bis 30 shops per Symbol zu unterscheiden.
Die ersten 11 (von 2e01 bis 2e0b) werden im Find-Menü zur Suche angeboten, die restlichen (bis 2e1f) leider nicht.
Das ist wohl von Garmin boshafterweise in der Firmware disabled worden.

Bei Restaurants war Garmin etwas großzügiger und zeigt bei der Suche alles bis 2a12 an, von 2a13 bis 2a1f wird wieder beinhart ausgeblendet.

So geht es dann auch weiter.
Bei Unterkunft kann nach 2b06, 2b07 nicht gesucht werden,
bei Sport findet er ab 2d0c nichts mehr,
Attraktionen sind ab 2c11 nicht mehr zu finden,
die Kategorie “Gemeinde” ist eine Mischung aus 2c… 30… und 2f…
Obstructions (1c01 bis 1c0a) hat ein etwas seltsames Verhalten, kann aber verwendet werden,
noch ärger sind Tides (1d03, 1d06) und Currents (1d05), aber ebenfalls verwendbar.
Geografische Punkte (64… 65… 66…) habe ich noch nicht vollständig erforscht, sind aber nur in 3 Gruppen untergliedert.
Others (2f09 bis 2f15) verwende ich recht gerne für Spezialsachen, hier habe ich auch die road-name-pois hingelegt.

Mit einer etwas sinnvolleren Suchmöglichkeit hätte Garmin sich leicht von anderen Navis deutlich absetzen können,
aber auch so ist bei geschickter Ausnutzung vieles aus einer OSM-Karte durchsuchbar anzulegen.

Walter

mike_hd · February 12, 2010, 8:33am

War schon Garmin gemeint. Es ist so wie Du sagst …

Das ist ja das Elend, dass man nicht generell sagen kann, was geht und was nicht geht.
Es bleibt vermutlich nur try-and-error um heraus zu finden, was tatsächlich funktioniert. Oder man nimmt vorhandene Typ-Files, von den man weiss dass sie funktionieren, als Vorlage.

Werden wohl die meisten sein. QLandkarte GT ist sicherlich nicht sehr weit verbreitet.

Jo, sollte man meinen, aber es ist halt Garmin … Es ist wohl so, dass die Geräte alles das anzeigen können, was MapSource auch anzeigen kann. Zumindest hatte ich noch keinen Fall, wo das nicht so war.

WrongWayGC · February 12, 2010, 6:26pm

Gibt es eigentlich irgendwo eine Übersicht, welche Typen sich auf welchen Garmin-Geräten wie verhalten? Falls ich diese übersehen habe, dann bitte ich um Nachsicht und einen Verweis dorthin, wo ich die Informationen finden kann. Falls nicht, möchte ich eine solche Übersicht anregen, bspw. als Wiki-Seite.

master · February 12, 2010, 7:51pm

Au weiha! Ich hab festgestellt, dass ich seit Oktober den ganzen Stylekram mal überhaupt nicht aktualisiert hab. Ich hatte früher mal ne Routine, die immer den aktuellen Style ins downloadverzeichnis haut und bin einfach davon ausgegangen, dass das auch so klappt, ohne nachzuschaun. Jetzt hab ich gesehen, dass ich diese Funktionalität irgendwie rausgehaun hatte. Jetzt ists wieder drin und sollte klappen.
Ab morgen ist alles roger. Wer jetzt gleich aktuelle Styles braucht, schaue mal bei meiner Haiti-karte ins downloadverzeichnis rein.

Nö sind sie nicht. Ich müsste mal sehen, ob ich es hinbekomme die Parameter aus meinem Skript zu extrahieren und ständig aktuell irgendwo hinzulegen.
Das ändert sich einfach immer zu schnell und ich hab keinen Bock die Anleitung im Wiki ständig zu erneuern. Vor allem, wenn ich mal was testen will etc.

Nee, garys OSB-dumps benutze ich schon ne Weile nicht mehr. Ich habe mein eigenes Konvertierskript gebaut und verwurste damit den täglichen SQL-dump von Openstreetbugs.
Das hab ich auch etwas dokumentiert, schau mal hier:
http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map#Openstreetbugs

Probier bitte mal ab morgen mittag den neuen Deutschlandauszug und sag mir, ob die Routingprobleme in der Art weiter bestehen. Ich konnte sie auf meinem Garmin 60CSx nicht nacherzeugen, hab aber auch nicht die Karten getestet, die du getestet hast, sondern neuere.
Ich hab den Verdacht, dass ich den Fehler unbewusst beseitigt hab, aber teste lieber erstmal.

Ach ja - für alle:
Die Karte ab morgen, hat ein etwas neues rendering und unterscheidet Wälder nach Nadel-, Laub-, und Mischwald.
Außerdem hab ich ein bissel am Nachtmodus bei einigen Sachen gearbeitet.
Dann könnt ihr mal schauen, ob das Meer da ist, wo es hingehört und nix überflutet ist.

Viele Grüße und viel Spaß dabei!
Christoph

geopia · February 12, 2010, 8:21pm

Super.

Das wäre schön.

Könntest Du nicht zu jeder Karte auf http://dev.openstreetmap.de/aio/ auch die zugrunde liegenden Styles und Parameter im Unterverzeichnis der Karte ablegen? Man könnte dann sehr gezielt die jeweiligen Änderungen testen und die Verbesserungen würdigen.

master:

Zurück zu den Routing-Problemen mit etrex VISTA HCx:
Mit den Original-AIO Karten (Deutschland) gibt es neuerdings hier in einem relativ großflächigen Gebiet fast immer Abbrüche mit ‘Routenberech.-Fehler’.

Die original AIO-Karten bis 2009-12-29 haben in dem Gebiet sehr gut funktioniert. Es kam extrem selten zu Abbrüchen.
Die folgenden original AIO-Karten die ich ausprobiert habe (2010-01-19, 2010-01-20, 2010-01-23, 2010-01-27, 2010-01-31, 2010-02-06) führen in 99% der Routing-Versuche zu einem Abbruch mit ‘Routenberech.-Fehler’.

Probier bitte mal ab morgen mittag den neuen Deutschlandauszug und sag mir, ob die Routingprobleme in der Art weiter bestehen. Ich konnte sie auf meinem Garmin 60CSx nicht nacherzeugen, hab aber auch nicht die Karten getestet, die du getestet hast, sondern neuere.
Ich hab den Verdacht, dass ich den Fehler unbewusst beseitigt hab, aber teste lieber erstmal.

Das werde ich morgen testen. Bin gespannt.

r-michael · February 13, 2010, 9:30am

Sorry, bin nicht ganz auf dem Laufenden - wo finde ich dieses ?

Die ganze All in one Garmin Map könnte nämlich entschieden brauchbarer sein, wenn sich mal bei den Styles etwas bewegen würde!

Grüße, Michael

geopia · February 13, 2010, 9:35am

Hier: http://dev.openstreetmap.de/aio/haiti/styles.tar.bz2

r-michael · February 13, 2010, 10:57am

Danke, hab’s gefunden und getestet.
Leider kann ich gegenüber dem “alten Style-File” vom Oktober’09 keine grundlegende Verbesserung erkennen, außer dass die Hintergrundfarbe von Weiß auf Gelb gewechselt wurde.
Wahrscheinlich wirkt’s sich nur in Haiti aus?

flux · February 13, 2010, 2:33pm

gmapsupp.img.20100213

Ein vernünftiges Routing ist in folgenden Fällen nicht mehr möglich. Regensburg - Düsseldorf bricht sofort mit einem Routenberechnungsfehler ab (Vista HCx und Oregon 300). Regensburg - Reutlingen wird trotz schnellster Route mit über 130 km Umweg berechnet, der Rückweg mit über 160 km Umweg (Vista HCx und Oregon 300).

Die Darstellung der Straßen auf dem Vista HCx ist überdimensioniert (ab der Zoomstufe 800 m und höher, also 1 km, 2 km und mehr sind die Straßen so breit, dass die Route nicht mehr angezeigt werden kann, der Kartenaufbau friert fast ein).

Ich vergleiche die heutige gmapsupp.img mit einer von Dezember 2009, die korrekt berechnete, keine Routingfehler hatte und von der Darstellung her in allen Zoomstufen in Ordnung war.

Wenn ich eine Karte aus OSM-Rohmaterial mit dem Stylefile vom September 2009 erstelle (auf dem Server als styles.tar.gz zu erhalten, masterstyle genannt), dann funktioniert die Karte top, bestes Routing, alles ok. Erstelle ich die gleiche Karte mit dem Stylefile von gestern (basemap_style), dann habe ich die oben genannten Probleme auch in meiner Karte. mkgmap ist die gleiche Version, die fehlerhafte Karte erhalte ich mit allen mkgmap-Version der letzen 2 Wochen und auch mit alten mkgmap-Versionen vom Herbst 2009, sobald ich das aktuelle Stylefile (basemap_styles) verwende.

Ich bitte das als Bericht zu sehen, nicht als Kritik an den bisher tollen Karten!!!

flux.

Weide · February 13, 2010, 4:36pm

Vielleicht sind kürzere Strecken fürs Testen besser…

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.24751&lon=6.7831&zoom=17

Weide

geopia · February 13, 2010, 6:09pm

Test mit etrexVISTA HCx: Oha! Die neuen Straßenbreiten erschlagen alles.
Damit ist die Karte nur noch in sehr großen Zoomstufen (<30m) lesbar.
Zoomstufen mit mehren hundert Metern oder Kilometern werden nur noch als Matsch dargestellt.
Kann man die Straßenbreiten nicht abhängig vom Zoom dünner machen?

Die Ostsee überflutet große Teile von Meck.-Pomm.

Leider kann ich keine Verbesserung bezüglich des Routings mit dieser Karte gegenüber den Vorgängern feststellen:
Es bleibt dabei: In dem getesteten Gebiet kommt es fast immer zu Abbrüchen mit ‘Routenberech.-Fehler.’
Schade.
Bei den heutigen Tests konnte ich die seit Jahresanfang gewohnten Routing-Fehler mit folgenden Karten beliebig oft reproduzieren:

original-AIO-Karte 2010-01-13 http://dev.openstreetmap.de/aio/germany/20100213/gmapsupp.img.20100213.bz2
mit einer von mir selbst gebauten Karte
(OSM-Daten von Heute, mkgmap-r1568.20100210, mit deinen neuen styles von 20100212-2035 http://dev.openstreetmap.de/aio/germany/styles.tar.bz2))
mit einer weiteren von mir selbst gebauten Karte
(OSM-Daten von Heute, mkgmap-r1568.20100210, mit deinen alten styles http://dev.openstreetmap.de/aio/styles/styles.20091023.tar.bz2))
Allerdings kenne ich noch nicht die von dir z.Zt. verwendeten Parameter für mkgmap. Ich habe noch die weiter oben von mir geposteten Parameter verwendet.

Der Fehler wurde soeben auch von Benutzer Weide in dem betreffenden Gebiet bestätigt. http://forum.openstreetmap.org/viewtopic.php?pid=59556#p59556

Diesbezüglich hat sich also dein Verdacht leider nicht bestätigt.
Was kann die Ursache für die Abbrüche sein?

flux · February 13, 2010, 6:36pm

Die Fehler in Düsseldorf kann ich bestätigen (ich habe wieder eine kurze Strecke in der Eulerstraße berechnet, Routenberechnungsfehler auf Vista HCx und Oregon 300). Von Regensburg aus erreiche ich Düsseldorf per Routing nicht mehr.

Eine Karte mit den Styles vom 23.09.2009 (mit mkgmap von heute gerechnet) klappt dagegen fehlerfrei. Ich habe die Dateien aus masterstyle übernommen, lediglich lines und polygons bearbeitet.

flux.