Worldwide routable Garmin maps: URL REMOVED

Railway stations were always rendered, but in the latest Basecamp releases they are rendered only at a very high zoomlevel. It looks like garmin hate trains, because they seem to ignore railways in their own maps too…

In Mapsource you can set the display of pois on “on” instead of “automatic”, to render railway stations earlier on the map.

There is a new version available: http://www.openfietsmap.nl/downloads/europe

GRi, can you test this map and see if it works on your Edge?

Thanks.
I have loaded W and N2 in Mapsource. Will check the Edge in a few days.
Searching in Mapsource works allright in W, however not in N2. It does find the places in the country in the upper area of the search window, however pressing find doesn’t yield any results on the map.

Do you look for a particular place in Norway perhaps?

It looks like there is something wrong in the OSM boundary data, if you search Oslo, Mapsource can find it without specifying the country, but not if you specify Norway.
If I search Stockholm, SWE then I could find it.

I searched for several places, none of them found. But all of them with Norway specified yes.
Without, it can find everything indeed.

Denmark is ok as well.

Done

I’d love to see this—I currently switch back and forth between an official Garmin map (which has good elevation data but awful trail/road data) and OSM, depending on where I am, and having a unified map would be fantastic.

@Ligfietser: The EU card works fine on the Edge 705, even adress search (NL). Had a hard time to find my adress as it seems the villages are part of the Towns in The Netherlands.

Regards,
Bert

Hi Bert,
Can’t you find your address in Mapsource or Basecamp too? Because this should work since Sebastic has imported all place boundaries (woonplaatsgrenzen) in the Netherlands recently and they should be complete in the Europe map as well. Dont know if this is a Edge problem or a general issue.

Hi all,

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.

Thank you in advance!

Best wishes,

Thomas.

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.

WanMil

Hi WanMil,

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.

Best,

Thomas.

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:

 --name-tag-list=name:en,int_name,name:zh_py,name:engels,name

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.

Thanks, Lambertus - I don’t think I get the complete message, but at least I understand what codepages are.

So is there any way I can fix Umlauts, or would it require extensive tuning of the logic behind your website?

Thank you! This will help in case I come across this problem (so far all maps were fine, knock on wood…).

Happy Easter!

All the best,

Thomas.

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:

<node id="472822" lat="51.5208622" lon="7.2363666">
	<tag k="bus" v="yes"/>
	<tag k="highway" v="bus_stop"/>
	<tag k="name" v="HER-Vöde-/Bergstraße"/>
	<tag k="network" v="VRR"/>
	<tag k="operator" v="HCR"/>
	<tag k="public_transport" v="stop_position"/>
	<tag k="ref" v="Vöde-/Bergstraße, Herne"/>
	<tag k="name:engels" v="HER-Vode-/Bergstrasse"/>
</node>

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.

Yes, it’s caused by the transliteration step:

Indeed.

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!

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