Mafketel, sounds like this is caused by a missing typ file, there were some errors in the map generation a few weeks ago (see http://forum.openstreetmap.org/viewtopic.php?id=2625&p=87)).
Could you please try the latest version?
That removed the hatching for the Islands and made the map more readable with basecamp.
This map is installing on my gps as we speak… but this always takes a long time with my mac… And if I don’t install them and just copy the gmap image from the website every time I open basecamp it will load the map from gps and I have two identical maps as a choice in basecamp (one from gps and one already on pc).
By the time I was done checking and changing Crete I could also check my gps where the old town and the lake are both rendered correctly now.
Crete is a different matter though. I already noticed that the hatching was much bigger then the Island, partly 10km GISCO buffer zone and the other side is Crete/south aegean periphery.
I Assume this is a data problem at osm and I am willing to change it except I have no idea what is wrong 
scratch that I think I know what is the problem and I hope I fixed it.
… I assume it is the multipolygon Κρήτη (Crete) 453129 and then in particularly the fact it was tagged place=island , which I just removed.
So that should be ok in the next rendering
Correct, the tag place=island is rendering the whole boundary as island. I’d better make this polygon invisible instead of rendering it as land (hatched pattern if you dont use a typ file), because I fear more mistakes are made with this tag.
Provinces mixed up in Thailand:
Search for the city of Suphan Buri, located at N14.46762 E100.11834. In Mapsource and the GPS all places in Suphan Buri province that I have seen so far are shown as located in the neighbouring province:
Suphan Buri
Phra Nakhon Si Ayutthaya Province, THA
Suphan Buri is capital of the province with the same name.
I notice something strange as I point my mouse at the provincial boundaries. W of Node: 2902644726 it shows both province names, E of this only one. At this point the boundary for a national park splits off. I don’t understand enough about relations to troubleshoot this, so I would be glad if somebody could take a look. I don’t even know whether this is related or not.
Info about the node:
Node: 2902644726
Data Set: 63db73
Edited at: 2014-06-06T10:13:24Z
Edited by: Paul_012 (100662)
Version: 1
In changeset: 22771905
Coordinates: 14.8350687, 99.3081859
Coordinates (projected): 1.105493668599175E7, 1670199.6986975581
Part of:
Way: 286584848
Way: 286584849
Way: 141066689
I don’t even know whether this is a Garmin map problem or a problem with the data.
I think rendering place=island as land is correct, just need to fix the mistake in the data 
And i think it was the only one in the area I looked at.
@Beddhist sounds like a data problem, make a map note if you don’t know how to fix it
Peter, could be a broken boundary problem in OSM, maybe it is fixed in the next update because it was edited recently: http://www.openstreetmap.org/relation/1908824 (seems not broken now)
Thanks for noticing it Mafketel, because I now see that this place=island polygon is causing more issues, like covering too many details (like covering other landuse types) so I have to made it invisible in the TYP file anyway. Now it will only render the island names. Land area is already rendered by the coastline tags so there is no need to do this with a place=island tag.
You know better then me
After downloading the rest of some maps (5-7-2014)
I also just noticed that in basecamp and gps the buildings on the airports are almost invisible against the background of the tarmac of an airport.
e.g. schiphol but also newark and boston have this issue.
Maybe I should stop looking at recent tracks
I notice that the front page of the garmin.openstreetmap.nl site shows a map based on 2014-07-07 data. Is it no longer on a weekly update cycle, or did this week’s update just fail to happen as planned?
2014-07-07 is the date at which the map update is started and it takes a few days to complete. So it is simply too early to wonder whether the approx. weekly update cycle is not executed as it normally would
My request is number #1631 in the queue, 6.8 days to wait… too late I’m afraid 
I miss predefined groups of countries in the listboxes: I need (north of)Germany+Denmark+(south of)Sweden. Would it be possible to add very common combinations like Germany+Austria+Switzerland or Germany+Sweden+Denmark to the list of predefined maps? Country queries are much faster, but I have an old Garmin etrex and cannot combine maps manually.
Just install all those countries on your computer and use Basecamp’s Mapinstall or Mapsource to send a selection of map tiles to your GPS.
Thanks, in the new map update just out it is OK now.
Regards,
Peter.
Just a quick heads-up:
The custom map queues have been really long the past few weeks (up to 1700 requests waiting), but I’m happy to announce that later this weekend I hope to be able to add a second custom map server which adds 2x the cpu power but unfortunately only supports 1/3rd of the disk space which is limiting. Anyway it looks like a nice addition.
It looks like only the mail daemon needs configuring…
Thank you again for providing this invaluable service. It keeps getting better all the time.
Regards,
Peter.
Lambertus, if you are short of disk space, does a mirror server like the NLUUG server for the Openfietsmap help?
They asked me if we need more disk space.
The new server is live. At first all new custom requests will be routed to the new server and the original custom server is enabled again when it has caught up.
I’m aware of one last problem on the new server: fancy directory listing isn’t working yet.
Edit: fixed. Needed to change AllowOverrides None → all
This is difficult. As it stands now, disk space alone has little value to this service, especially the custom maps need disk space AND cpu power. The country maps could be hosted offsite but there is no need for that at this moment.
How often are the predefined maps updated?