If you leave me the choice I’d say it’s a data problem 
I tried again, and it turns out that when using a street name shown on the OpenStreetMap the search does work for some streets. On the other hand, it doesn’t find certain streets which can hardly be called alleys. Petuelring in Munich is one of those. I did check the spelling, of course, and this street IS shown on the map.
Isn’t that odd …
… the same issue exists for Netherlands and Belgium maps.
Some streets can be searched and found, some streets - which ARE shown on the map - are not found.
Just as well I haven’t dumped my Tomtom yet 
Well, in the end: after downloading the new version the problem is solved indeed. Routing along Motieweg in Open Fietsmap works again.
Thanks again.
Just discovered that for some larger cities the map data includes multiple entries. For example, Amsterdam has 4, among which “Amsterdam, NLD” (A) and “Amsterdam, Amsterdam” (B). A search for “Prinsengracht” using (A) fails, whereas the same search using (B) resulted in a hit.
The solution could be not to specify a city when doing an address search - this works as long as the name of the destination street is not too common.
@Carnut: I get strange results when searching for Prinsengracht, too (tested in Mapsource):
Prinsengracht, Barrio Judio, Amsterdam, NLD
Prinsengracht, Ciudad de los Museos, Amsterdam, ABC
The Openfietsmap Lite shows other errors:
Prinsengracht, Jordaan, Amsterdam, NLD
Why the Jordaan? Why the Spanish names?
This has something to do with the wrong assignment of streetnames to districts, provinces and countries.
Lambertus, what are your mkgmap settings?
I use
bounds: bounds
location-autofill: bounds,is-in,nearest
bounds file is from http://www.navmaps.eu/wanmil/ (The one I use in my OFM is from 22/01/2012, maybe later versions has some errors/holes?)
I suspect the map chooses too often the nearest district instead of the admin. country boundaries, maybe because they are broken in Wanmil’s latest database?
And why does it choose the Spanish names instead of the Dutch in the General map?
As a very grateful user of the maps provided by Lambertus, I loaded the UK map on my Garmin for our holiday in Scotland. As always excellent data, and those little things that were missing, well, we can live with those.
However, this time, when driving past Loch Ness, I suddenly realised it didnt show on my Garmin (you understand I was more looking for Nessie through the carwindow :D).
Back home I checked the map in Mapsource and Basecamp, and found this famous Loch doesnt show there either. It is in Openstreetmap, and shows on the website, but it seems there is something fishy with the data. I download the UK fresh, and loaded this new version in Mapsource, but with the same result.
I am not proficient enough to understand why it doesnt show. In the past I have seen this when a waterbody wasn’t ‘closed’, but that doesnt seem to be the case here. The only difference between Loch Ness and Loch Lochy (that does show correctly) is that the object Loch Ness shares nodes with other objects around it (e.g. wood, forest). Not sure if that is the cause of this error.
Appreciate if somebody can shed some light on this.
tks,
Piet.
Hi ligfietser,
you can debug which bounds values are assigned to the given streets. Add the line
uk.me.parabola.mkgmap.reader.osm.LocationHook.results.level=FINE
to your logging.properties file. Read http://wiki.openstreetmap.org/wiki/Mkgmap/dev#Enabling_Debugging how to enable logging. The logfile contains one line for each OSM element (Node/Way, osm id, and the value for each admin level 11-1). So when you know the osm id of the wrong Prinsengracht you can check the logfile if the bounds values are assigned correctly.
I propose to compile only the tile containing the Prinsengracht because the logfile will become quite big
The latest boundaries are from July 8th so the redaction bot was not started yet.
If you cannot solve the problem yourself please give me exact details about the data and the mkgmap parameters you use. I can then have a look on it.
WanMil
Thanks Wanmil, since it is not just a single street but seems very widespread all over the world, I have to know which mkgmap settings Lambertus is using.
About the issue from PJS, this seems also related to mkgmap and the splitter. I notice it happens with big polygons (lakes, forests) when they are located in different tiles.
Somehow the polygons are broken and so the lakes are dry or forests not green. Making the overlap higher (5000 or even 10000) can solve the problem, but this is a workaround. Is it possible to fix this in mkgmap or the splitter?
It sounds like two separate problems:
Wrong assignments of city/region/country to some streets
=> Use the mkgmap logger to track down the problem.
Some big polygons that overlap the tile bbox are not rendered.
=> In case the big polygon is a single polygon and not a multipolygon it should be rendered. Please post some details so I can have a look on it.
In case it is a multipolygon it is very difficult to fix. In this case the splitter would require a mulitpolygon handling which requires an additional pass and makes splitter much slower. There have been several discussions on the dev list without any good idea how to fix this…
Ok, I’ve had a look at Loch Ness myself. It is a single polygon so it should be rendered. Can you please give me the splitter areas.list file so that i can try to reproduce the problem? Thanks
I’ve checked Loch Ness. The reason that it does not appear in the map is located in the default style file. The relevant tags of Loch Ness are:
name=Loch Ness
natural=water
tourism=attraction
This matches the rule in the default style polygons file
tourism=* & area!=no & waterway!=* [0x13 resolution 24]
The rule for natural=water is contained in the waters style which is included by the default style. AFAIK included styles are processed after the style itself so the tourism rule matches first and the natural=water rule is not used for Loch Ness.
WanMil
Thanks for the speedy replies, however not sure what the solution is.
Can the processing be changed so the natural=water will be processed, or should we just remove the tourism tag from Loch Ness. Its first and foremost a body of water, and there are more lochs that would qualify as an attraction, which arent tagged as such.
Piet
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