The new generic style has a built in typ file. I’ve requested a new download but it takes some time before those maps are generated.
Edit: please try this link, I can see the peaks, lakes and track road. So maybe your version was somehow incomplete, see one page back:
Thank you again! Just loaded this version and those mountain peaks showed up normally. Looks like I’ll just need to re-download and update my map.
Ligfietser: I’ve now built and downloaded a new set in new style. All the mountain peaks are now in. But a further issue noted. Any reason why Iron Cove (S33.86169 E151.15547) and the next bay to its West are not coloured blue as for the rest of Sydney Harbour? A bug? I don’t see the same problem in the old style download.
For bays in Sydney not showing, see this thread: http://forum.openstreetmap.org/viewtopic.php?id=22143
Its a problem with the tagging/mapping.
Thanks. But doesn’t really say how to fix it.
That’s not been resolved yet, I just noticed and reported a few days ago. I’m happy to make edits to fix, but I’ve not got a lot of OSM experience so I don’t want to make big changes without a consensus from more experienced mappers.
Thanks for this great service! I am currently trying this out for the first time, but it already looks very promising 
I did run into the issue where a mail server with sender verification will block the e-mail from this service, due to the sender address not accepting e-mail. The e-mail envelop sender is ‘www-data@osm2.pleiades.uni-wuppertal.de’, As there is no MX address for osm2.pleiades.uni-wuppertal.de, it will connect to the A address (132.195.124.248) to try and deliver e-mail, but this IP address doesn’t respond to connections from port 25.
This can be solved by either making sure that the server does accept e-mail for the specific address, or altering the source address to some existing e-mail address (could very well be a no-reply@ address which does get accepted, but redirected to /dev/null).
For me, I solved this by switching to an e-mail account that does no sender verification (gmail), but as this could also be an issue for future users, I figured I’d report it
Keep up the good work!
natural=bay wasn’t covered in the new styles. Normally it should be rendered blue if a natural=coastline is present, otherwise it was empty.
I added natural=bay to the new styles as well as the openfietsmap style, thanks for reporting!
Thanks for this report, my current ‘solution’ to the email verification problem is described here. We need to change the email server/handling in the near future and your comment will be considered.
Hi!
I think i have found the cause why many adresses in Austria are not found. I can reproduce that each street which has an sharp s “ß” in the name (this is the case for nearly every second street because of “xxxx Straße” in the name).
The street itself is found with converted the “ß” to “ss” which is correct, but then no housenumbers are found any more. (tested with the latest new style)
This is a great service! What I did for a recent group trip is created a map file and then distributed it to the group members.
What I am interested in being able to do is generate data/files/whatever that are useable in other programs. Like smartphone apps such as “Galileo Offline Maps” http://galileo-app.com/)).
This app uses .sqlitedb/.mbtiles format.
Is there an way to convert data provided by your service into this format?
I don’t think so, and I think you should use the OSM XML exports directly instead of a Garmin files as intermediate step if you know how to create the proper inserts/updates for the SQLlite DB and mbttiles.
The routing (on the Garmin Edge 800) turns out to problematic where I live (northern New Jersey, USA) mostly due to how local roads are classified in OSM.
The routing puts me on a major road (typed as “highway=secondary”) largely unsuitable for bicycle riding that is typed as “highway=primary” and avoids less major roads people regularly ride on.
The “bad” road typed as “highway=secondary” roads is mistyped in my opinion.
The problem is that the routing either avoids “highway=primary” roads (suitable for bicycling) or also includes “highway=trunk” and “highway=motorway” roads (unsuitable for bicycling).
**That is, in my location, “highway=primary” roads need to be included in “lower class” roads (with “highway=secondary”.
**
I have an idea that this problem depends on where (the country) the routing is being done and the differences in how people type/classify roads. The problem is also related to the fact that the Garmin Edge 800 (and, presumably, other devices) don’t provide enough control over the routing parameters.
I’m guessing that the maps provided “http://garmin.openstreetmap.nl/” convert the OSM tags to Garmin tags in such a way as to coerce “reasonable” routing. It’s possible that tags other than “highway=*” are use to figure-out what Garmin tags should be used.
Interestingly, using the Goolge Maps routing for bicycles produces fairly reasonable routes as does the routing performed by the Apple iOS app “Pocket Earth”, which uses “cloudmade.com” as the routing engine/provider.
Hello ,
There are two map types available for download at garmin.openstreetmap.nl.
For many months now I have moved to the new style.
However I am realizing sometimes garmin routing refuses to use the much shorter unclassified road and instead takes
the very longer tertiary road. (osrm does the right thing)
My queries are
Thanks for the great work.
Carl
Hi,
Can you post a position link so that we could check if there is a data error in OSM.
Last time I had this kind of error (OSRM was able to route, but Garmin was not), was caused by a little Z-shape in the road.
Chris
On http://map.project-osrm.org/ routing works fine
routing from mpabana road to bombo road as on http://www.openstreetmap.org/#map=18/0.32269/32.57284
does not work with nuvi 2515 unless i just step onto that unclassified , then it realises …
thanks.
-Carl
Hi,
I see no error in OSM data at this place, and routing is ok in Basecamp with my selfmade map. (Didn’t ckecked Lambertus’ map yet).
Edit: OSM generic routable is also ok in basecamp:
Chris
Even generic routable using new style ?
In the swiss community, see
http://forum.openstreetmap.org/viewtopic.php?id=22383
I started a discussion on the use of paths with the tag sac_scale=difficult_alpine_hiking. To my opinion the use of such a path by “normal” people without “Mature alpine experience” and without “Familiarity with the handling of technical alpine equipment” could bring them into danger of life.
Now I found, that such paths in Lambertus maps are also handled like normal paths. My proposal: Let such paths away in the maps or show them with another layout.
I’m having trouble with routing in Basecamp after downloading a chunk of the 20130829 map. For example, between N44 20.444 W72 38.644 and N44 20.454 W72 38.669 on South Bear Swamp Road in Middlesex, VT, USA, Basecamp acts like the road is non-contiguous and attempting to route from the south to the north results in a U-turn, heading back south, and then looping in from the north. I don’t see a break in the data via openstreetmap.org. I’m having similar issues on Bushey Road between N44 20.477 W72 37.735 and N44 20.355 W72 37.793 (OSM link) as well as on Molly Supple Hill Rd (just east of Bushey Rd) and French Rd (which intersects Molly Supple).
Is this a glitch in the OSM → Garmin map generation process or is it a Basecamp error?