Worldwide routable Garmin maps: Missing/incorrect feature requests

Sorry I missed that one, can you send me a link from the osm.org map?
I noticed some long shield names too, but that is because mappers misused the ref tags on osm.

It’s here: http://osm.org/go/0E4@@QLXG- , but the ref tag is clean. In the img the label=~[0x4]S116 IJTUNNEL, which is probably correct. For some reason my Zumo tries to display all of that in one little box. In MS it’s correct, so I guess it’s yet another firmware bug that Garmin won’t fix.

The IJ-tunnel looks fine without shields on the Nuvi and Dakota. So maybe it is a Zumo bug.

Awesome work guys!

Ligfietser, I’m still slowly -as time permits- working through the test map (and POI list) you sent me some time ago and making notes. Should I continue or does this new test map make that work superfluous?

In the latest test map releases the polygons are rendered better, and maybe some lines too so I should switch to the newer version…
But your old notes can be still usefull.

Here’s some shots from a GPS Map 76 CSx using your test map:



Given the small palette on this GPS, there’s a lack of contrast which is more clear on the unit than it is on these screenshots, but overall this looks like a good job.

Thanks Charlie, I notice the natural=scrub fields seem to have a grey background instead of green. There are still some incompatible colours in the typ file (selected colour is not part of the garmin palette), I’ll check this out.

Nice work!

A couple of screenshots of your test map on a nüvi205:




Haven’t tried out the “world-test” style/typ yet, but a quick test of “world” looks quite nice, at least better than than the mkgmap default. The only thing i missed in “world” (which is included in “world-test”) is natural=beach for polygons.

/jetthe

Thanks for your comments and screen shots. I’m not a great fan for including too many polygons: these maps are primarily intended for navigation and we want them to work on the largest range of units possible. The more data we put into the finished map the more cluttered it will be and the slower it will be drawn.

On my Zumo the Openfietsmap can take over 30 secs to be drawn. That’s unacceptable, especially while riding.

I agree, we still have to find a balance what too show and what not. Keep in mind that the test area is one of the densily mapped areas in OSM in the whole world due to importing of topographic data. Some landuse elements we can leave out of the map like the scrub you see ( I made it more transparent) or landuse=farm. Buildings I like to keep, but that depends also on other users. Buildings are only shown at the highest detail level. Tests on the nuvi 310 and an old Etrex Venture were positive, the map was not too slow. I uploaded a newer version of the gmapsupp.img and added night mode. Older GPS units still can use the night mode (Oregons and Dakotas not) and this can be used for better contrast ( a lot of landuse is made transparent).

If you want to make a map from your own area, you can use test-world style and typ with these mkgmap settings:

styles: http://code.google.com/p/mkgmap-style-sheets/source/browse/#svn%2Ftrunk%2Fstyles%2Fworld-test
typ file: http://code.google.com/p/mkgmap-style-sheets/source/browse/#svn%2Ftrunk%2Ftyp%2Fworld-test
bounds file: http://navmaps.eu/index.php/developers/bound


family-id: 20001
product-id: 1
draw-priority: 20
description: OSMWR_test
country-name: World
country-abbr: WRLD
generate-sea: extend-sea-sectors,close-gaps=6000,floodblocker,land-tag=natural=background
style-file: c:\Garmin\mkgmap\world routable\styles\world-test\
bounds:  c:\Downloads\bounds
location-autofill: bounds
tdbfile
latin1
code-page: 1252
reduce-point-density=4
reduce-point-density-polygon=8
min-size-polygon: 10
adjust-turn-headings
name-tag-list=name:en,int_name,name:zh_py,name:engels,name
remove-short-arcs
add-pois-to-areas
make-opposite-cycleways
link-pois-to-ways
add-pois-to-areas
merge-lines
preserve-element-order
keep-going
net
route
index
nsis

I certainly agree with you that there should be a good balance between speed and level of detail.
Unfortunately I haven’t had time to fully test the world-test style yet but I will try it out as soon as I get a chance.

Btw, I noticed while driving last night (using the “world” style in my Nüvi) that a road tagged with highway=construction/construction=trunk was rendered as a trunk road. Just thought I’d give you an heads up if this is not already an known issue.
Location: http://www.openstreetmap.org/?lat=58.8784&lon=14.89576&zoom=17&layers=M

engels? Surely, that’s not a valid tag? Isn’t there also a syntax error in there?

Looks like a typo but I copied/pasted Lambertus’ parameters. If you google on this parameter you will find it anywhere in Lambertus posts. Maybe you have solved another bug!
Have to ask Lambertus when he is back from holidays.

The “name:engels” tag comes from the transliteration step that transliterates non-Latin character sets (well, only Cyrillic currently, but it could be expanded to other character sets like Thai, Arabic, Israeli etc if someone has the knowledge to make the transliteration tables) to English. The application that does this (named: translit) adds the transliterated name as the new tag “name:engels” to the intermediate OSM data before the data is processed by Mkgmap.

This roundabout in Apeldoorn appears incorrect on the Garmin maps:

http://www.openstreetmap.org/?lat=52.18819&lon=6.004571&zoom=18

On the Garmin maps, the outer ring (highway=cycleway) appears the same as the inner ring (highway=tertiary)

Any thoughts on unpaved roads? I’ve seen some discussions about this, apparently there are two ways to tag these:

highway=track (I’ve seen “unpaved” as well, but this seems to be an incorrect value)

or

highway=tertiary (or another classification)
surface=unpaved (or sand, gravel, grass, etc.)

Only the first example apears as unpaved on the Garmin maps. The second example should be marked unpaved as well in my opinion.

That’s because the default styles don’t make a difference for roundabouts in highway types, they all use the same line. In the modified styles I have made a correction.
You can see the changes in the latest test map, because this area is a little larger and it includes Apeldoorn as well: http://code.google.com/p/mkgmap-style-sheets/downloads/list

This is how the test map renders the roundabout now (you can download the mapnik.typ file and rename it to default.typ to see it in Mapnik ‘style’)

That is already covered by the routing. If you set the routing to ‘avoid unpaved roads’, the highway=tertiary road with surface=gravel will be avoided.
You can’t see the difference on the map between a road with surface=gravel or surface=asphalt though.

This is how the mkgmap styles handle unpaved roads:

Flag unpaved roads.

highway=*
& (surface=cobblestone | surface=compacted | surface=dirt |
surface=earth | surface=grass | surface=grass_paver |
surface=gravel | surface=grit | surface=ground | surface=mud |
surface=pebblestone | surface=sand | surface=unpaved |
mtb:scale=* |
tracktype ~ ‘grade[2-6]’ |
smoothness ~ ‘.(bad|horrible|impassable)’ |
sac_scale ~ '.
(mountain|alpine)_hiking’ |
sport=via_ferrata)
{ add mkgmap:unpaved=1 }
(highway=bridleway | highway=path | highway=track | highway=unsurfaced)
& surface!=* & tracktype!=* & smoothness!=* & sac_scale!=*
{ add mkgmap:unpaved=1 }

Excellent, that’s exactly what it looks like!

Installed the test maps and I see you also managed to refill the Noordzee and IJmeer :slight_smile:
Plus this weekend I drove a route where at some point I expected a “right turn” prompt, but I did not get one. With the test map that’s fixed as well.

Right, that’s fine than. Never new the Garmin maps had this kind of info in them that’s invisible on the screen.