Changing the default style must be discussed on the mkgmap dev list: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2012q3/014883.html
I don’t know the current tagging rules very good so I cannot say if it is a good solution to remove the tourism tag. I fear it’s not because “do not tag for renderers”…
WanMil
I agree with Wanmil that is an mkgmap style issue which should not be repaired on OSM.
Concerning the wrong assignments of city/region/countries, we have to wait until “the boss” is back from holidays but it has his attention 
Hi Lambertus,
I got a problem with the map of syria with the names.
The osm datas are containing arabic names
The datas i download on openstreetmap.nl are in english
I need the arabic names
Is there a possibility to get them ?
I tried to generate my own map with osm tools, mkgmap, etc, i got the arabic names but no index of the cities for exemple
I really need your help on this.
Thanks in advance.
Perhaps the data for Prinsengracht were entered or altered by a Spanish tourist who was unfamilar with Amsterdam 
The maps contain many similar errors, e.g. a village shown to be in Belgium whereas it is in the Netherlands. Anyway, the maps are free and still very useful if users find ways to circumvent the errors.
Carnut, you are right: http://www.openstreetmap.org/browse/node/1864177616/history 
This is a mappers error, because AFAIK there is no district in Amsterdam with Spanish name.
I also removed nonsense names of suburbs/hamlets (gehucht) like Jordaan and Dam plaza because they are obviously added for “mapping for the renderer”
This is only one part of the explanation, more important is why the streetnames are not assigned to the administrative boundaries here (and almost anywhere else, not only in Amsterdam) and only assigned to the nearest place node (like the Barrio Judio, Jordaan or in the Openfietsmap, to the cycling nodes (I misuse a place name poi for them)). This is I think caused by some misconfiguration in Lambertus scripts but I cant investigate it since I dont have the exact scripts and files he is using (have to wait until he is back from holidays).
Re. the strange names in the Garmin maps. I’ll try to add all relevant information here for debugging:
The Mkgmap settings used for initial rendering of each individual OSM source file:
$command = "ulimit -t 900 && java -Xmx1792M -ea -jar $mkgmap";
$command.= " --family-id=$family_id";
$command.= " --product-id=$product_id";
$command.= " --draw-priority=20";
$command.= " --description='$description'";
$command.= " --series-name='$description'";
$command.= " --style-file='$style_dir'";
$command.= " --style='$style'";
$command.= " --reduce-point-density=4";
$command.= " --reduce-point-density-polygon=8";
$command.= " --make-opposite-cycleways";
$command.= " --link-pois-to-ways";
$command.= " --precomp-sea='/home/lambertus/garmin/utils/sea'";
$command.= " --bounds='/home/lambertus/garmin/utils/bounds.zip'";
$command.= " --location-autofill=bounds,is_in,nearest";
$command.= " --latin1"; // implies code-page=1252
$command.= " --ignore-maxspeeds";
$command.= " --remove-short-arcs";
$command.= " --min-size-polygon=10";
$command.= " --merge-lines";
$command.= " --add-pois-to-areas";
$command.= " --preserve-element-order";
$command.= " --route";
$command.= " --name-tag-list=name:en,int_name,name:zh_py,name:engels,name";
$command.= " --input-file=$file";
The final map combine Mkgmap settings:
$command = "java -Xmx6144M -jar $utils_dir/mkgmap-performance-r2269.jar";
$command .= " --index";
$command .= " --overview-mapname=$overview_name";
$command .= " --family-name='$description'";
$command .= " --family-id=$family_id";
$command .= " --series-name='$description'";
$command .= " --latin1";
$command .= " --description='$description'";
$command .= " --product-id=$product_id";
$command .= " --tdbfile";
$command .= " --nsis";
$command .= " --copyright-message=$copyright";
$command .= " --gmapsupp *324*.img $typMkgmap";
And English or international 
Yes, that is a specific choice I made because it is the most commonly understood language.
Yes, but from someone else or by doing it yourself.
Maybe because the Garmin firmware indexing doesn’t work in Arabic? It’s just a guess from my part but it would not amaze me. Another option is that you need to add the ‘index’ parameter to the Mkgmap commandline.
Please use the very latest r2328. It contains a fix when using location-autofill=bounds together with add-pois-to-areas.
I can reproduce the Prinsengracht problem with this old bounds file. There are two possible problems with the old bounds zip file.
Failed to read boundary file bounds_1850000_750000.bnd Unsupported file format
I am not sure what has changed in the bounds file format but I am also not sure which mkgmap release was used to create the world_20120221.zip.
Anyhow using the latest bounds_20120708.zip the problem disappears.
WanMil
Thanks WanMil for confirming that the bounds file is probably too old, I’ve also upgraded to the latest Mkgmap and run an update now.
Hello,
I like your tool and the style of the resulting maps. But I wanted to have a very large map.
This resulted in a server error with the message: “The requested URL’s length exceeds the capacity limit for this server.”
Also I know that this would be not so good for your server. Is it possible e.g. to download a map with europe. I think this would reduce CPU load for you, and it would be possible to get large maps.
loewe-xy
I’m very well aware that everyone has his own way of working, but mine can be an answer on your question. Most likely it is not the best way, but by posting it I want to learn something.
The conclusion is for at least me is that I have within a mum of time what I want and without huge CPU effort on the server side (just downloading).
Regards
Searching for “Prinsengracht” shows some improvements, although there are still some weird results.
Here is a comparison between the search results of the Generic map and the OFM Benelux.
What I would expect is streetname,place,province,country (like in the OFM BNL) but the generic map shows streetname,nearest place poi,place,country
Sometimes the local place poi is an obvious mapping error like “Leidseplein” (some tourist was mapping for the renderer and put a suburb poi on this square).
There are very strange results like Enkhuizen in Edam-Volendan (spelling error and wrong assignment, Enkhuizen is not in Edam-VolendaM!)
Also Meppel is not even close to Grafschaft Bentheim, which lies in Germany!
I dont know where those errors come from, I have to wait for the results of the OFM Lite to see if the results are different (could be caused by the styles file)
Maybe the bounds file is broken, too (for the OFM Benelux i have used an older bounds file from 22/01/2012)
Yes, this bounds file is too old. You should see some errors in the mkgmap logfile.
WanMil
I havent noticed any errors.
The results still look good (see the screenshot, the right box with OFM Benelux is made with the older bounds file. I still have to test the latest one to see if the results are different)
Btw here are the locator settings in my Openfietsmap Benelux styles
# first set the country code
mkgmap:country!=* & mkgmap:admin_level2=* { set mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:country!=* & addr:country=* { set mkgmap:country='${addr:country}' }
mkgmap:country!=* & is_in:country=* { set mkgmap:country='${is_in:country}' }
mkgmap:country=DEU & mkgmap:region!=* & mkgmap:admin_level3=* { set mkgmap:region='${mkgmap:admin_level3}' }
mkgmap:country=LUX & mkgmap:region!=* & mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' }
mkgmap:country=BEL & mkgmap:region!=* & mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' }
mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' }
mkgmap:region!=* & mkgmap:admin_level5=* { set mkgmap:region='${mkgmap:admin_level5}' }
mkgmap:region!=* & mkgmap:admin_level6=* { set mkgmap:region='${mkgmap:admin_level6}' }
mkgmap:region!=* & is_in:county=* { set mkgmap:region='${is_in:county}' }
# Germany = DEU cities
mkgmap:country=DEU & mkgmap:admin_level4=Hamburg {set mkgmap:city='${mkgmap:admin_level4}' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8|subst:Gemeinde |subst:Stadt }' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=DEU & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=NLD & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=BEL & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=AUT & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8|subst:Gemeinde }' }
mkgmap:country=CZE & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=CZE & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=DNK & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=DNK & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=FIN & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=FIN & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=FRA & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=FRA & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=ISL & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=ITA & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=NOR & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=POL & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=POL & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=PRT & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=PRT & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=SVN & mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:country=ESP & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=SWE & mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:country=SWE & mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' }
mkgmap:country=CHE & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
# common rules for all the rest of countries
mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' }
mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' }
mkgmap:city!=* & is_in:city=* { set mkgmap:city='${is_in:city}' }
mkgmap:city!=* & addr:city=* { set mkgmap:city='${addr:city}' }
mkgmap:postal_code!=* & mkgmap:postcode=* { set mkgmap:postal_code='${mkgmap:postcode}' }
mkgmap:postal_code!=* & addr:postcode=* { set mkgmap:postal_code='${addr:postcode}' }
mkgmap:street!=* & addr:street=* { set mkgmap:street='${addr:street}' }
mkgmap:street!=* & addr:housename=* { set mkgmap:street='${addr:housename}' }
mkgmap:housenumber!=* & addr:housenumber=* { set mkgmap:housenumber='${addr:housenumber}' }
mkgmap:phone!=* & phone=* { set mkgmap:phone='${phone}' }
mkgmap:is_in!=* & is_in=* { set mkgmap:is_in='${is_in}' }
Unfortunately, the street search of the OFM Lite version is also messed up: 
I have no idea what the cause is, because the styles should be ok (style file is the same as my map).
Next thing to test is to generate my maps with the latest bounds file although I doubt that this is the cause.
Another question for Lambertus, regarding those parameters:
$command.= " --style-file=‘$style_dir’“;
$command.= " --style=‘$style’”;
I dont use the first line, just --style-file=%style% with %style% the directory to my style files.
What does the first line mean? What kind of styles are in that style_dir? Maybe another set of locator files that is messing up the index?
Edit:
I generated one tile of my Openfietsmap Benelux with the latest bounds_20120708.zip and I couldnt reproduce those errors.
It finds Prinsengracht, Enkhuizen, Noord-Holland, NLD (as expected) and not Prinsengracht, Enkhuizen (or 30),Edam-Volendan,NLD
So the fault could be in the styles files. Lambertus, can you mail me a copy of the exact contents of your $style_dir?
Finally, I think i have found the index bug 
In your first step, I missed the index parameter.
This one is crucial. It reads the location from the style file parameters and puts the info in the img tiles.
In the second step another index is created, but it misses some location info that lacks in the individual tiles.
Maybe Wanmil can confirm this, because it is just a wild guess. I can partly reproduce the error when I first make an img tile without the --index (Prinsengracht,30,ABC) and then compile a new map with the --index parameter.
Good day Lambertus
I’ve used you nifty site many times to generate custom maps to send directly to my 60CSx. Now I’m trying desperately to use Base Camp on Mac OSX (ML). First I downloaded the “osm_generic_macosx.zip” file and Mac seems to extract it, but I can’t figure out or seem to Google what to do from there? There doesn’t seem to be any install file or anything I can import to Base Camp on Mac… (I could be missing something obvious I’m very new to Mac) Thanks a lot for the great site
Did you try double clicking the extracted file?
On a Mac things are simplier than you think…
Thanks for your great maps. I really enjoy them.
I have one little idea:
I often use a custom selection of tiles. It would be nice to do the tile selection by loading a tiles.txt file from a previous download to get the same selection as before.
