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â.
**
**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
- Whats the difference between the two map types?
- 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.