Lack of contrast varies from unit to unit. In the typ file those roads are not defined, so it makes use of the internal Garmin rendering type (which makes it a Garmin problem). The only thing that you could do is adjusting the TYP file with a typ file editor and give it your own colours.
The forests are polygon type 0x15, residental roads poly lines 0x06. A good editor is TYP viewer, https://sites.google.com/site/sherco40/home
The map (generic routable, new style) of Belgium had a large void area (i.e. no map data) in the west of Belgium. I downloaded it on friday.
This is probably caused by an old version in the history cache of Basecamp. Try ctrl-G (2x) to clear it?
Hi, I have accidentally found there are some areas with the same .img number but different name (and different real place) in the map generated yesterday. I have found these:
63242597, named ID-Denpasar (western coast of Australia + lot of water) and ID-Banjarmasin (northern Java and southern Borneo)
63242700, named VN-Ho Chi Minh City (south-east Vietnam + Malaysia) and PH-Taguig (small area in Phillippines south-east of Manila)
63242866, named TR-Istanbul (Istanbul + Black sea north to Istanbul) and IT-Busto Arsizio (west to Milan)
As I know close to nothing about the map creation, maybe this is not the right place to report it - sorry then.
Yes it is the right place to report those issues, thanks David.
I hope Lambertus can have a look at this?
That is very strange. Does this relate to the generic map or one of the other two maps?
As far as those tiles are concerned, only the generic. If you download Indonesia, one tile will be missing.
Perhaps filling up the sea tiles will solve this issue? Now only the generic map does not have a complete coverage of sea tiles.
The past three weeks two custom map generation servers have been added together with a lot of software development and encountering some interesting bugs. So, after last night, the queues are finally empty again. Many thanks to those who made this possible. Onwards!
Turkey map selection:
When selecting Turkey is leaves out the Istanbul tile. When manually selecting tiles it leaves this tile out as well in the final installation. It has been this way for at least a month I believe. I use my maps in Mapsource / 276C.
I believe it is map tile TR-Istanbul, 63242890.img
KP
I’ve also received several emails by different users about this problem and been looking at this problem for a while, but didn’t spot the cause earlier. Now I think I found it and implemented a fix.
When Splitter is called to subsplit a tile but cannot find a good solution it will produce only one result (instead of the two it is ordered to produce). This is spotted by the build-script which then simply re-renders the original tile without further subsplitting. However the sub-split attempt leaves two ‘orphaned’ files behind which aren’t cleaned-up though cause double use of a tile number later on, e.g. tile number 63242074 is defined twice as US-Long Beach and US-Los Angeles. The same happens with Istanbul and other places as described by DavidOb a few posts above. I thought that this problem had been fixed with an earlier update, but clearly it didn’t.
The problem should be fixed by removing the subsplit files which are not going to be rendered. When the Openfietsmap_lite render process is finished a new map update will be started. I hope that solves this issue.
Many thanks for the reports!
150 people downloading countries from the same server while an update process is running: Madness. Both harddisks are fully occupied 
To make it worse, the OFM mirror server from NLUUG seems down for some time so people have to use the Wuppertal server too 
Good to have a fall-back server then, even if it’s not the fastest 
Anyway, I’m in the process of moving the render chain to the new server: It has much more ram, cpu-cores and disk space and so is able to do much more in parallel. That’ll free one harddisk in the osm server allowing me to use it for sharing country maps. This means there will be twice the I/O bandwidth available for country (and OFM) downloaders. But several other things need to be in place before this happens.
For those familiar with Linux, I’ve rarely seen a quad-core server having more then 100% I/O-wait, the last few hours it was at 400%. All four cores are 100% waiting for the disks to return the requested data that is needed to do any useful work. In other words: all cores were starved of data and could do nothing but wait almost 100% of the time.
A first attempt failed due to only one of the two orphaned files being cleaned-up. With a second attempt both files are cleaned-up and the problem is solved starting map version: 13-08-2014
I downloaded and installed an .img file of Canada on my Garmin. The map is present on the gps and I enabled it. When I zoom on an area, I only see some part of the map but not the full map. If I change the zoom level I will see more or less part with sometimes previously visible area which will disappear and others which will appear. The data seem to be present but not visible everywhere, since I can simulate a trip from one point to another even in invisible area. In the part where no information is displayed I can only see the path of the planned trip.
I checked the map using BaseCamp and I can see all the data without trouble.
I also tried to install an .img file from “www.osmmaps.com” and I have the same problem. I tried to reset the gps but it doesn’t change anything.
Do you have any idea of where the problem could come from?
Hard to say…Maybe you have duplicate maptiles installed try javawa device manager, www.javawa.nl/jdm_en.html to check for map errors. Or maybe your sd card can be faulty, did you try another sd card?
I tried javawa and there is no map error.
The map is saved directly on the internal gps memory and I tried an old map from US (bought from Garmin) and everything is fine. Only osm maps have the problem.
Can you give the location (permalink from osm.org) so I can check if I can reproduce it?
Which map did you exactly download (generic, generic new style?)
Which link do you want?
I downloaded one .img file of a generic new style map covering Canada obtained from garmin.openstreetmap.nl (the download link was (now it’s dead): http://sfs4.pleiades.uni-wuppertal.de/garmin/generic_new/10-08-2014/d557bd19d7e55b5315d96518900c3d4f).
I also tried an .img file obtained from www.osmmaps.com (Canada map).
Both maps behave in the same way (but the displayed area are different (I mean the visible or invisible area are different)).
Do you see this happening everywhere in Canada, or at particular spots?
If it is everywhere, maybe your device cannot cope with mkgmap generated maps.
If you see this only at some places, maybe there is a feature on OSM that is messing up the rendering on other devices too.
So if you can send a link (something like http://www.openstreetmap.org/#map=14/49.2560/-123.1131)) of an area that disappears I can check this on my device.
Just “Canada” is way too big, sorry.