I just used http://garmin.openstreetmap.nl/ to create small maps that fit in the internal memory of my Garmin Oregon 450. This speeds up its map display dramatically - I used OSM Freizeitkarte (http://www.freizeitkarte-osm.de/de/index.html) before, which has to be saved on the SD card because it’s too large to fit into the internal memory.
Works pretty well, but I noticed that all Umlauts in city, steet etc. names get lost (ö → o, ä → a etc.). Is there anything I can do about that? Umlauts work fine in OSM Freizeitkarte.
Good question, I think it has to do with the codepage options that Lambertus uses?
Another question for Lambertus, why are the typ files not updated?
It is important that every time I update the style files, the typ files are updated as well.
Dont know if your scripts automatically load the latest versions?
Please be careful!! If you copy a corrupt map to the internal memory your GPS might get broken too so that you have to send it to Garmin to repair.
Instead you can always remove an SD card if it contains a corrupt map.
are you sure? Why should this happen? As long as the device boots up (and I don’t change anything in its operating system) I should be able to access it as USB mass storage device. If a corrupt map however prevents it from booting up, I would consider this a severe design flaw.
You can fix it yourself if that happens; all you need is to put the Oregon into the ‘Forced USB Mass Storage Mode’. It is described here for the Montana, but the same procedure applies to the Oregon: http://garminmontanagpsr.wikispaces.com/Recovery
First you’ll have to look at my maps from an international perspective:
There are hundreds of languages and scripts and only few people are able to read Roman, Cyrillic, Thai as well as Kanji to name only a few. So when I started this service I decided that Roman script and English language would be the base for my maps. Other map makers will have to provide localized maps, like Freizeitkarte.
Technically this translates to:
Before the OSM data is rendered by Mkgmap I use a custom built transliteration application to convert Cyrillic script to Roman. This application can transliterate more then just Cyrillic but the definitions for other scripts are lacking. After this step Mkgmap is used to create the Garmin tiles. For this I use the following Mkgmap parameter:
This selects which name tag to use in the Garmin tiles in the order from left to right. All the name tags are documented in the OSM wiki with the exception of ‘name:engels’ which comes from the transliteration step. So the normal ‘name’ tag is only used when none of the other tags is available. This may be the cause of your missing Umlauts for cities but I think it’s unlikely the cause for the street names.
Another (remote) possible cause may be the “–latin1” Mkgmap parameter which should translate to CP1252 but this code page includes Umlauts so should not be the problem.
Typ file updating has been a manual operation up to now. I’ll include automatic updates in the scripts for the next map update.
I understand, the whole process is quite complicated to grasp at first. However, I’ve looked at the various steps in my toolchain and this is what finally goes into Mkgmap:
I notice that the name tag contains the ö and ß still, but there’s also the name:engels tag from the transliteration step. And because Mkgmap is instructed to choose the name:engels over the name tag the ö and ß is lost in the final map.
The question is: should the transliteration step transliterate German special characters? And how about French ç or Turkish ş etc? I.e. do we only want to transliterate when the original script is not compatible with CP1252 or do we want to transliterate everything that is not compatible with the English script?
Is it a transliteration? I think it is English name, for example German München is Munich in English.
If you create map of the world, then you don’t have much choices. I think for now only CP1252 and int_name/name:en could be used.
Here is my experience with the new EU OFM map with an Edge 705.
I have loaded it in Mapsource / Basecamp and used it offroad on a Mountainbike and onroad on a racing bike.
In Mapsource I can say I like it very much, for the moment it is my favorite map for planning cycetours.
Really good.
For the gps there are 2 subjects to discuss however: performance and styles.
1a. performance offroad.
While Mountainbiking I use “Courses”. This means I can navigate without Turn information. This is because in terrain with a lot of turns the Edge 705 zooms out for a turn-information-screen, showing all the nearby turns you will encounter so you see nothing but a white screen left.
Navigating this way (with courses, without turn-information) only the map has to be shifted, not too much to be done for the gps, and this works fine with the EU map.
1b. performance onroad.
In this case I use turn-information. The Edge 705 comes up with a special screen showing the next -plus nearby- turn(s).
This performs bad. You hear a beep (“turn is coming”). Then you look and see an empty screen.
Checking again you may see the background drawn, then the navigation line comes and finally also the rest of the map is coming.
It performs comparable with the Open MTB map.
For me this means that at the gps I will keep using the OFM Light, since that one really performs much better.
HOPEFULLY the OFM Light will stay available in an up to date version!
Styles
a. Navigation-line.
On my Edge 705 the navigation line is drawn before the pathes and roads.
This means that when pathes and roads are drawn in a wide style they hide the navigaton line. Maybe someone could tell how to change priorities such that the navigation line would come on top of everything.
However, I didn’t find it and therefore I allways change the road-styles such that I can always see the navigation line still.
b. Small gps-screen.
The Edge 705 has a very small screen where the map is shown. Just like an Etrex, by the way.
This means not too much information should be shown at the same time since then you won’t see “the trees through the forest” anymore (in a dutch saying).
Also wide road-styles in combination with a high density of roads / cyclepathes plus a navigation-line make the screen quite unreadable.
Here again is a reason for narrow line-styles.
c. Navigating offroad.
Styles for offroad lines (pathes) need to be more clear for offroad navigating.
2a is another reason to use the OFM Light on the gps: only show the things that are really necessary to find your way while navigating.
Conclusion: for me OFM EU is a great map in Mapsource / Basecamp.
At the gps (Edge 705) I really prefer the light version (with adapted styles).
Thanks for your input GRi,
About 1b: I don’t know if the Edge has night mode display, you can try if this renders better in the full EU version
2a It’s a Garmin bug that they put the navigation line behind the road lines. In all the later units the navigation is always on top and big. You can’t change it, only making the lines much thinner, but I won’t make another typ file. You can edit the typ files and make a custom one that suits your needs.
Yes, there is no point about a typ file, i have my own typ file for every map I use. But hopefully you will continue to supply the OFM Light here as you do now, since that’s the best performing map at the Edge 705.
GRi, since you are living in the NL’s (I suppose), there will be still a light version of the benelux available at openfietsmap.nl
Because the NL’s is a very heavily mapped country you will notice the differences in performance.
For other regions in Europe I’m not so sure if the full EU version is really so much slower because it’s not so well mapped. So I’m still not convinced if a world wide lite version next to a full version is making sense. Other opinions are welcome.
Yes, I’m living in the nl. And cycling in Europe. Germany is more interesting for me than Belgium or Luxembourg.
Is it more work for mapgeneration when the area gets bigger? I can imagine that processes run longer, and maybe you need more powerfull hardware?
Hi, I apologize if this has been requested in the past but I was not able to find this info: where is it possible to know which version of mkgmap - and maybe which command line params - are used to build the maps?
It would be nice to know this to be aware of which new functionality are available… in the past I tried the maps there but since the mkgmap version used was not that up to date I was missing the address search functionality so I switched to build maps myself using geofabick pbf, spltter and the latest mkgmap… and I’m still doing that! But I would swicth back to lambertus maps if I knew the way the map is build and find out it is matching my needs.
The tiles are generated on osm.pleiades.uni-wuppertal.de and then copied to osm2. The Mkgamp on osm2 is only used to create the gmapsupp and -I think- not related to recent improvements in the search capabilities as those concern the indexes in separate tiles. But I could be mistaken ofcourse.
The commandline parameters have been posted at various places in this topic