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”.
**

**Another problem is that the Garmin Edge 800 sometimes stalls with “Route calculation error” when computing the route using the “bicycle routing” maps when the routing works for the “generic routing” maps. I’m guessing that the reason is because avoiding the “highway=primary” routes (in my location) cause the route not to be computable.
**

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

1. Whats the difference between the two map types?
2. Is there anywhere I can get the current two style-files used for the different types?

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?

Another issue: when using Basecamp with either the Motorcycling or Dirt Biking activity preference, I’m getting routed onto hiking trails that are coded in the OSM data as footways. For example, routing from Carse Rd, Huntington, VT to East Rd, Waitsfield, VT should involve going out Main Rd. to VT-17; instead, I’m Basecamp suggests that I continue on Carse Rd., continue on the Beane Trail (a footway), turn onto the Long Trail (footway) and then to VT-17. I’m sure it would be an interesting motorcycle ride, but it seems ill-advised. My motorcycling profile has the “narrow trails” avoidance set; my dirt-biking profile does not. Also interesting is that with the ATV profile or the bicycle profile, I get routed the correct way, as I do with the automotive profile. The hiking profile also sends me up the hiking trail, which would seem to be the correct behavior.

Unfortunately it is a known issue that the routing in Basecamp (as well as the latest GPS units) is not quite compatible with OSM / mkgmap generated maps anymore. You have to play with other settings like avoid carpool lanes (by default turned on in the bicycle mode) or other vehicle modes to make it work. AFAIK “Narrow trails avoidance” does not work with OSM / mkgmap generated maps.

There could be routing problems when crossing map tile borders and having interstate highways avoidance selected. Those tile borders are hardly visible in Basecamp (small line accross the road) but are visible in Mapsource.

I havent followed the latest mkgmap developments so I’m not sure if this issue have been tackled?

I would say when someone wants to do Alpine hiking better use more specialized maps.
Rendering it with another layout would be an option but unfortunately Garmin’s default trail symbols are very limited without a typ file.

Just a reminder that due to works on the power lines, the custom map server will be offline from today until Monday.

Thanks for the reminder!

I agree with this. But nevertheless there are people in the alps who are very careless.
The basic problem is: What is a highway?? If you look to this picture
http://wiki.openstreetmap.org/w/images/9/98/SAC_SCALE_T6.jpg
is this a highway?? It is from the definition page of sac_scale=difficult_alpine_hiking.

A solution could be to tag such a way not with ( highway=path & sac_scale=difficult_alpine_highway) but only with sac_scale=difficult_alpine_highway ,that means: delete the key highway=path. But this is in contradiction to the definition page of sac_scale, which states that sac_scale goes together with highway=path or highway=footway. To my opinion, there should be defined, that sac_scale=difficult_alpine_hiking is no highway and should be used only without the highway tag.

I understand what Opasto is saying. I suggest rendering/routing this type of highways on garmin.openstreetmap.nl in a different style/way and if this is not possible just skip these in the map by changing scripts. Nobody wants the occasional hiker to enter these kind of paths just because he/she was unaware of the difficulty of the path. I’m glad I live in the Netherlands which is as flat as a pancake