I just downloaded the new look Thailand map. Looks good to me here. The typ definitely works. Thanks for all your hard work you continue to put into this.
As far as I am concerned this is the most useful OSM web site there is.
Now we can continue to fine tune the style.
Q: do we need POIs for areas? Every island gets a POI and there are lakes where the POI is way outside the water due to the crescent shape.
Another project I want to tackle at some point is a routable map optimised for motorcycles. As we all know, the maps canāt distinguish between cars and bikes. There are many places where bikes can go, but not cars and vice versa.
Yes we need them but not in all cases. This has to be finetuned. In mkgmap you can exclude it with something like place=* & mkgmap:area2poi!=true [0xā¦ resolution ā¦]
Any idea why this island is not rendered: N14.02267 E99.52300
It seems mapped correctly (I donāt know for sure, itās a multi-polygon), but in the img file there is a river polygon exactly covering it. I guess thatās an mkgmap bug?
Peter, it isnt rendered because of the wrong OSM tags. The inner polygon shouldnt tagged with riverbank but without any tags.
If a polygon tagged with riverbank means inside it will contain water (riverbanks are the outlines of the river), so mgkmap thinks it is a river instead of an island. http://www.openstreetmap.org/browse/relation/2067334 All inner islands are tagged the wrong way, and those riverbank tags should be removed.
The correct way to tag a river like this, is to put a tag waterway=riverbank on the relation itself (with type=multipolygon), and no tags on inner and outer ways.
Very large map requests (>2 GB) are becoming more and more common which requires up to 7 GB of ram to preform the necessary computations. Unfortunately the custom map server only had 4 GB ram thus forcing it to use the swap file on many occasions which dramatically reduces the performance. The map request queue grew to more then 200 on several occasions in the past few weeks and the server sometimes struggled to respond to all the people who tried to download their maps (connection timeouts).
So therefore I express many thanks to the technician @ Wuppertal university for searching, finding and installing 4GB extra memory into the custom map server. I hope it will considerably boost the production capacity of custom maps.
Onwards!
PS. Map requests larger then 4 GB are now rejected to further smooth the custom map production. I donāt think Garmin GPS devices are capable of handling such large maps anyway.
Thanks Popej, sometimes itās just that simple (on FAT32 files != >4GB).
Some further technical ramblings:
Besides the memory upgrade to prevent swapping (and allow some caching) I also started moving data around on the custom map server to include more harddisks in the map generation & serving. A single harddisk has a hard time to provide&store data for 3 map generation processes and 16 Apache download instances :P. I/O wait frequently consumed three of the four available CPU cores and on average used about 1.5 cores, but by moving the source tiles to another disk this reduces the load on the harddisk considerably thus increasing map production throughput. The reason is simple: more spindels (harddisks) means there are more I/O operations available. I wish I knew there were unused disks in that server earlier
Anyway, it seems there is again a little headroom for more users (or more maps)!
I use both Garmin CN Europe 2013.1 and OSM by Lambertus. To display on Win 7 PC I have Mapsource 6.13.7 and 6.16.3. It is know that Mapsource 6.16.3 tends to distort maps especially as one moves further north whereas 6.13.7 makes a good shot at a better presentation. I was somewhat surprised, therefore, to see that the Garmin map seems to have exagerated E-W whereas the OSM map has reduced E-W in 6.16.3. This distortion occurs at all magnifications/scalings. See my snapshots in link which should show what I am trying to describe. Point I am trying to make is why do the Garmin and OSM versions not show the same distortion in Mapsource 6.16.3? http://www.flickr.com/photos/40470386@N08/sets/72157632776262325/
Mapsource 6.16 compute compression factor for longitude according to medium latitude of a whole map. For small maps, like a single country, map looks much better then for CNE Europe, which include Reunion Island on Southern Hemisphere.
Just a remark on the statement that it would be useless to offer downloads bigger than what can be loaded on a gps device.
I donāt think the size of what fits on a gps should be your point of view.
Maybe some, or even a lot of people put the downloaded stuff directly on a gps.
But what makes more sense I think, is to install the downloads first in Mapsource (Basecamp).
In Mapsource you plan routes. At the gps you navigate. Thatās different things.
To give a real-life example: suppose you are a dutch speedskater, ride very nice routes on a Mountainbike as well, the bike that you also take to the big skating event at the Weissensee in Austria.
For the route by car to the Weissensee you want a special one to avoid all the queues around Munich and therefore you use the GR map in Mapsource from the Netherlands, completely to the far end of Austria. To be able to make this route, this GR map must be 1 map, not split in several ones, because otherwise the routing doesnāt work and also you would miss the necessary overview.
For ATB-routes in the Netherlands, in the Sauerland and Teutoburger Wald in Germany where also is being cycled a lot, and at the Weissensee in Austra, the Open Fietsmap Light is used.
Again: in Mapsource you want 1 map, not having to have all the trouble of getting installed it several times with different names and having to switch map all the time if you are planning in another country.
With the cycling club, in summer a trip has been made to the Stelvio mountain in Italy and Alpe dāHuez in France. Not very handy to have to arrange a separate map for those purposes.
For navigating on the gps, finally, you want another style than in Mapsource, since navigating routes is a completely other thing than planning routes.
So for maps on the gps, you first change typ files, then you extract an area from the Mapsource maps and send that to the gps (maps GR and OFMLight combined since an Edge 705 can only have 1 img file GMAPSUPP).
For other purposes, another map can be sent to the gps, other area e.g.
Basis is always the 2 maps in Mapsource, the GR and the OFMLight.
Of course this is just 1 example, my point is you canāt predict the usage of the maps.
Donāt limit this on forehand because of what fits on a gps device. The useful size is completely independent from what fitās on the gps.
Not everyone only is using these maps in the local area.
P.s.
Of course if you need to restrict the size because otherwise things fall over, there is a good reason. Which however, has disadvantages in usage.
In the last downloads for me, the Windows installer was missing. So to install the maps in Mapsource still, I used MapsetToolkit. This makes things less simple to use of course.
Thanks For your feedback GRi, I agree that for certain uses a large map would be preferable. I wonder, though, how many people really need such large maps.
On a technical note: the most memory is used by the gmapsupp.img step which I could bypass when the user selects more then 4Gb tiles. However, the Windows installer is also limited in size because of the NSIS installer (2Gb).
Is it an idea to let us make a choice in what we would like to get: If I get an installer I donāt need the gmapsupp.img at all.
I only dowload the installer file, leave all the rest on ther server, untouched. A bit pity you generated them.
Maybe those who order an imgsupp donāt need the installers?
Also people on Windows donāt need the other executables, exactly as Apple people wonāt need a windows installer?
The nsis limit can also solved by making an installer which dont include the tiles (like an install.exe that I use for my Europe or Germany map).
Of course this will ask for the user some extra efforts to unzip things first but if you want something extra you have to work for it. This also makes it not neccesary to include an extra set with the tiles only, and maybe even a Mac/Gmap format isnāt needed anymore because with Javawaās Mapconverter this zip file can be easily installed for the Mac or as gmap. So then we have only one gmapsupp.img set (< 4 gb) and one zip file containing the tiles with a windows installer. See for example my Germany mapset: http://www.openfietsmap.nl/downloads/germany
We could also think for asking a small donation first for very big mapsets larger then 2 Gb (5 euro minimum or so). That will exclude all people who are just downloading everything just for fun and so limit the server load.
