Thanks for the compliments. No idea why the streetnames aren’t searchable in the Germany maps as every map is created with the same parameters. This points to some OpenStreetMap data problem or (dare I say it :p) user error…
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.
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?
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.
you can debug which bounds values are assigned to the given streets. Add the line
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.
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:
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.
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.
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”…
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
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";
- The Mkgmap-performance-r2269.jar is a symbolic link to the currently used Mkgmap version r2311.
- Bounds.zip is a symbolic link to world_20120221.zip from WanMil’s site. Perhaps the newer bounds_20120708.zip file should be used?
- The areas.list file is continuously being overwritten on each subsplit during initial rendering but the coordinates of each tile is kept up-to-date in an XML file.
- Central Amsterdam, Netherlands is located in this tile, the source OSM file is here.
- Tirana, Albania is located in this tile, the source OSM file is here.
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.