Lambertus maps incorrectly displaying arabic names in Basecamp

Hi folks,

please excuse if this has already been discussed before, I’m sure this must have been discussed, but I couldn’t find a solution yet.

I’m happily using Lambertus’ wonderful service to install maps into my Basecamp or Mapsource, and then later on transfer them to one of my devices (60CSx, 276C, Montana).

So I recently download tiles for Tunisia, as I’ll be travelling Tunisia again in 2014.

But the many arabic names (towns, street names, POIs) don’t get displayed in a readable manner.

Sidi Bou Said (a small town nearby Tunis): In Basecamp displayed as “Sydy Bws `Yd”

Or: Who can guess what “Ql`@ ?L’Ndls” shall mean ???

OSM online maps show these arabic towns using arabic characters (which I can’t read at all)

Sidi Bou Said :
Other town :

This makes the Tunisian maps almost unusable in the Garmin world.

I have tried installing the Lambertus maps using either “Generic Routable” or “Generic Routable (testing new style)”, with or without the Mapnik TYP file.
No difference.

Any ideas ?

Thank you for reading.

I forgot to mention:

Basecamp 4.2.5. on Windows 7
Mapsource 6.16.3

Basecamp 4.x ? on Mac OSX 10.8

Browsing some of the last of the 82 pages of Worldwide routable Garmin maps …

I discovered the following:


I assume this is the rule how the POI name is built from the OSM data, using the first matching name.


Looking at the OSM Wiki for Multilingual Names, I found out that in arabic countries, the following tags are recommended:

name=عربي for arabic name
name:ar=عربي for arabic name
name:fr=français for the french version

Following these recommendations, mappers will probably rather be using name:fr than name:en or int_name

So the Garmin maps will receive their POI names from the arabic name tag. Thus not displaying them correctly in Basecamp.

I’m a total newbie to topics like mkmap and tags and options, please excuse if I’m wrong with my guesswork.

Using iD, I checked e.g. Sidi Bou Said

it has (among others) the following tags:

thus perfectly following the recommendations in the OSM Wiki.

That’s a good catch Chris, I think Lambertus should add name:fr to the list?

The problem is that all characters are transliterated into ASCII in order to display it right on the older Garmin units as well (they cannot display arabic, not even lower case!). And I dont know if mkgmap is capable of detecting if the name tag is in Arabic to display it in Arabic because transliteration here makes no sense at all anyway, better a correct name on the map in Basecamp/Mapsource and ??? on the device than rubbish like Ql`@ ?L’Ndls on both screens.

These are limitation of mkgmap. You can use codepage 1252 or ASCI and get transliteration for Arabic, which usually isn’t readable or you can use UTF-8 for proper names but search functionality won’t work correctly.

Sounds to me like the best solution for the moment. :roll_eyes:

Thanks for spotting the problem and suggesting a solution. I added name:fr to the name-tag list and an update is running. Should be available by Friday.

Thanks a lot, Lambertus - I’ll then try again next weekend.

Hi Lambertus,

now looking excellent in Basecamp Win/Mac.
Haven’t tested it on one of my devices yet, but will do within the next days.

Thank you very much for your help !

Unfortunately adding name:fr is causing other unwanted effects in othr countries, see so please revert the change.

A workaround is to check in the style file in which countries the place name could be replaced with name:fr if exists

place=* & mkgmap:country ~ '(MAR|TN|DZA|ESH|MRT|LBY)' {name '${int_name}' | '${name:fr}' |  '${name:en}' |  '${name}' }

I’ve now added this rule to the style files to get the French names rendered in the following countries (MAR|TUN|DZA|ESH|MRT|LBY).
Lambertus, can you remove name:fr name-tag list?

name=* & mkgmap:country ~ '(MAR|TUN|DZA|ESH|MRT|LBY)' {name '${int_name}' | '${name:fr}' |  '${name:en}' |  '${name}' }

Thanks Minko, I’ll remove the name:fr from the list before the next update (scheduled to start on Monday).