Here is what these lines look on the Zumo 660:
Ok, so I’m moving this here.
I meant 0x2b06.
I see what you mean: the shelters show up when searching for Lodging. If we use any other type they won’t be searchable at all. I can’t see a suitable Garmin searchable category.
Off to bed now…
Progress report:
1: Shelter rendered as camping : needs a typ entry
2: Garmin type 0x07 needs splitting into several line types: Minko volunteered for this one
3: Railways not showing at lower zoom: fixed, needs typ entries
4: Bridges & tunnels not shown: needs typ entries
5: Ghosting effect when zooming in on latest MS: I think this is an MS bug, but need more info for possible workaround
6: Remove admin boundaries: fixed, but may have to put state boundaries back in. Need info on which levels should be shown.
7: Gas stations tagged as polygons missing: On hold. Can’t see a fix without a change in mkgmap
8: Communication towers clutter the map; water tower not rendered: fixed, needs typ entry
Minko: over to you! You can grab the modified style files here: http://code.google.com/p/mkgmap-style-sheets/source/browse/trunk/styles/world
When you are done please put the typ file into typ/world.
Thanks Peter, I will give it a try sooner or later 
About #6:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative
Admin level 4 is used for States (USA) Provinces (NL) or Federal States (DEU).
We can use the mkgmap locator rules to implement it for certain countries where we want the States borders on the map.
mkgmap:country=USA & boundary=administrative & admin_level=4 [0x1d resolution 19]
mkgmap:country=DEU & boundary=administrative & admin_level=4 [0x1d resolution 19]
In the NL’s Province borders are also fetched under admin level 4, but they may clutter the map.
Maybe you can decide if Australia needs their State borders (map is quite empty there anyway ;-))
BTW: country abbrev’s can be found in the locatorconfig table:
http://www.mkgmap.org.uk/svn/wsvn/mkgmap/resources/LocatorConfig.xml
Hiking in Switzerland, where this tag is often used, I discovered that:
tourism:information
information:guidepost
is rendered as toilets (both in MapSource and on my GPSMap 60CSX) … inappropriate unless the user is a dog 
FWIW this tag is rendered correctly (again both in MapSource and on my GPSr) in the Kowoma leisure map of Switzerland, so there is no fundamental problem.
Thanks for pointing this out. This is a curly one.
First, the fact that this is a guidepost is actually ignored. The tags for guideposts are tourism=information and information=guidepost. Perhaps you can see where this is leading to:
tourism=information is a tourist info office. This is mapped to Garmin code 0x2f0c. If you right-click on the toilet icon on the map and select Properties you will get:
Category: “Auto services”, Subcategory: “Rest Area/Tourist Info”
Unfortunately, in their infinite wisdom Garmin have decided to render this with the toilet symbol. We need to fix this with a more appropriate icon.
Toilets proper (amenity=toilets) is rendered with a different code, no problem here.
Looking at the presets in JOSM there are two other points where toilets can be found:
highway=services and highway=rest_area, both with toilets=yes. The latter is currently not rendered at all and with the former the toilets are ignored.
We are hitting a fundamental problem here: in OSM objects can have more than one tag (like a tourist info can also have toilets), but at present we have to map that to one single object in the map.
Solution:
typ file entry for tourist info with a round blue i
filter out guideposts, as I don’t think they should show on a routable map (clutter)
Created issue 9.
I need a list of poi codes that are likely to be searchable by most GPS. Working on the above issue I’ve come unstuck, as toilets and tourist info are searchable in MS, but not on my Zumo. The cgpsmapper manual wasn’t useful…
I think you can find more info on that in the mkgmap archives. I think Charlie Ferrero has done some research, maybe you can find more on his website: http://www.cferrero.net/maps/mkgmap_tiddlywiki.html
Whether a feature is searchable or not also depends on the GPS model. Also the display varies, sometimes you get a toilet symbol, sometimes a ? sometimes an i for tourist info. By using a default typ file we can eliminate those Garmin issues.
Edit:
Maybe this can help you further http://www.cferrero.net/maps/downloads/garmin_feature_list.xls
Thanks for the link to that spreadsheet.
Issue 9 is fixed. No more guide posts. Toilets and tourist offices are now searchable, at least in MS and on my Zumo.
I had to create a typ file for that. Minko, before you start on your typ file please grab mine from the svn repository.
Cheers,
Peter.
Issue 1 fixed.
Issues 3 & 6-9 are also fixed. There is only one important fix left, issue 2: splitting some minor ways that all get rendered as alley. We have made significant progress on that one, too, but my Zumo doesn’t show all of those lines. We may end up leaving it at that… Let’s see what other tricks Minko comes up with.
Lambertus, you may want to have a go at testing some of what we have done so far, just so that there are no hidden show-stoppers.
The mapnik typ in its current form will not be totally compatible with the new definitions, but the default typ is almost required now.
Cheers,
Peter.
Thanks Peter!
I will setup another map tile generation toolchain. This will take a while before you will see a first result though…
I’m a bit overloaded with stuff right now. Lots of changes, things to check and decisions to be taken. Only a few hours per day to work with. So I cannot provide a target date to release the first version.
Please don’t hurry, we still have to work out the last issues and in the mean time I can adjust the Mapnik.typ file to match with the modified style files.
I copied the mapnik typ file and also the openfietsmap lite styles and typ to the trunk. I named the typ file 20011.typ but maybe ofm_lite.typ is better since people will probably change the Family ID’s to install more copies. The name openfietsmap_lite.typ is definitely too long for Mapsource and will cause crashes.
I have created a test map with the new styles and default typ file. In this map the sea is now rendered and the background is solid white.
Buildings are only rendered in the highest detail level so they won’t clutter the map. Some lines still needs some finetuning (footpaths, track roads).
The map can be downloaded here: http://code.google.com/p/mkgmap-style-sheets/downloads/list
Licensing: I didn’t give much thought to this and it’s not important to me, but when I set up this little project on google code I was told to choose a licence. I chose ODBL, but on reflection this is not really sensible. What licence should this stuff be under? mkgmap itself uses GPL version 2.
Licenses don’t have my interest, but I think the one thing you should ask yourself is: what do you want to accomplish with a license?
Do you want to enforce a license if someone just grabs the stylesheets and does whatever they want to do with it?
If you don’t mind, just release it as public domain.
If you want to have your name preserved in the files take a very light license like MIT or BSD
If you want to enforce any party that uses the stylesheets to open their version of the stylesheet too, then use GPL for Mkgmap compatibility
Don’t know much about licenses too but GPL sounds good.
I have finetuned the paths, pedestrian roads and tracks too and updated the test map
Here is a screenshot:
http://www.openstreetmap.org/?lat=52.3734&lon=4.5381&zoom=14&layers=M
GPL it is then. The map looks good. Are we all go then?
I will first need to test it an older Etrex to see if there are still issues. Maybe others can test it as well.
Here is a screnshot on a nüvi:
Edit: gmapsupp.img added in the download section for testing
http://code.google.com/p/mkgmap-style-sheets/downloads/list
Looks good on my Zumo, except the long shield at the tunnel that I pointed out before. I think if you want the tunnel name displayed you should have a separate label for it. I suspect that the name is in the ref tag, but I haven’t checked it out.