I actually removed them because they cluttered the map. Especially when people were importing them massively from several sources so there where double pois for one bus stop. I noticed that since the new license a lot of them have been deleted so maybe I can bring them back on the map. We will see, I can make them almost invisible or a very small dot? If they are searchable and editable with the typ file, its ok with me.
Yes, a small dot.
Same for railway stations (maybe as a small rectangle like on other maps)
That would be nice!
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.