Worldwide routable Garmin maps: URL REMOVED

Beddhist · 2013-08-09 03:32:56

Sorry to report: the latest Thailand set (new style) in the South shows more tile boundaries on the selection screen than there actually are. E.g. there is a small rectangle around Kuala Lumpur, but this is actually part of a much larger tile.

Regards,
Peter.

Last edited by Beddhist (2013-08-09 03:57:28)

Lambertus · 2013-08-09 11:04:39

I can't reproduce that problem. In the old generic map there is indeed a small rectangle around Kuala Lumpur, but when I select the new generic map there is no small rectangle, only the big tile that covers almost all of Malaysia... maybe it helps when you force a refresh (ctrl-F5) or empty your browser cache?

Beddhist · 2013-08-09 11:12:09

It's not doing it for me any more, either. Perhaps it happens if I change the map style before the page has completely loaded? In any case, it looks all good now and in any case, the downloaded map is good.

Regards,
Peter.

Ciprol · 2013-08-12 04:34:52

Quick question. Any reason why some of the landscape features from OSM aren't included in these Garmin compatible maps? An example being Frenchmans Cap, a peak in Tasmania, Australia <http://osm.org/go/uC~eDi9n?m=> along with other hiking essential land features? Would be good if they could. Thanks.

ligfietser · 2013-08-12 08:25:19

Frenchmans Cap is tagged as natural=peak, so it should appear on the map. Try zooming in closer because it is only rendered at the highest zoomlevels.
Of course you could question if this (and other elements) shouldnt be rendered earlier but this is very region/purpose specific.
See also this topic http://forum.openstreetmap.org/viewtopic.php?id=21779 and maybe contact Brett (Ent) who is working on a better Tasmanian hiking OSM Garmin map.

Ciprol · 2013-08-12 09:04:13

Thanks Ligfietser. Yes, I understand that Brett (Ent) is working on a dedicated TAS hiking Garmin map, but I use a generic download from the site to cover a larger area than just Tasmania. That aside, what's interesting is, Frenchmans Cap is definitely not showing in BaseCamp on the Mac, even at max magnification. Frenchmans Cap Track is showing but no peak. What's interesting is, the various peaks around the Overland Track are showing normally, but very few peaks outside of that area eg. Mount King William III and Algonkian Mountain peaks are showing, but not the rest. Given the geology of Tasmania, it's as if the map generation engine only selected certain peaks from the OSM database for display and somehow a large chunk of SW Tasmania (south of Lyall Hwy) got abbreviated. BTW, no peak either on the map as read on a Garmin Oregon 650 with latest firmware (2.90).

Last edited by Ciprol (2013-08-12 09:10:42)

ligfietser · 2013-08-12 09:46:56

Thats odd, if I look at http://osm.pleiades.uni-wuppertal.de/ga … 240691.img with gpsmapedit, I can see the poi.
Maybe it is covered somehow with another feature (a routing node), it appears as blue dot while other peaks have another symbol.
So maybe it's a mkgmap problem, have to investigate it further.

ligfietser · 2013-08-12 10:46:42

I've downloaded the map (without typ file), it should be visible in Basecamp from 3km zoom at the highest detail level:

without typ file

with typ file

Did you use generic map with or without mapnik typ file or the new generic styles map?

Ciprol · 2013-08-12 10:51:48

Thanks again Ligfietser! I have further looked around on my copy of OSM download from 21 Jul 2013 (in New format - Mac OS X). Again, the various peaks I checked in the state of New South Wales are all properly displayed, but not so to a large area of S/W Tasmania. Hope this information helps with your investigation.

Ciprol · 2013-08-12 10:57:19

ligfietser wrote:

I've downloaded the map (without typ file), it should be visible in Basecamp from 3km zoom at the highest detail level:
Did you use generic map with or without mapnik typ file or the new generic styles map?

I downloaded the new generic style, without typ file. At maximum maginfication, max detail, ticks on Labels and Overlays in BaseCamp, no Frenchmans Cap nor surrounding peaks nor lakes, just the track on display.

ligfietser · 2013-08-12 11:07:30

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:

Lambertus wrote:

Notice: The weekly update is delayed a few days because of broken daily diffs.

Ciprol · 2013-08-13 04:36:24

ligfietser wrote:

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.

Ciprol · 2013-08-14 12:35:39

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.

Vclaw · 2013-08-14 14:08:07

For bays in Sydney not showing, see this thread: http://forum.openstreetmap.org/viewtopic.php?id=22143
Its a problem with the tagging/mapping.

Ciprol · 2013-08-15 03:24:55

Thanks. But doesn't really say how to fix it.

DaveWaterworth · 2013-08-15 04:50:09

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.

Learloj · 2013-08-15 07:58:00

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!

ligfietser · 2013-08-15 08:56:20

Ciprol wrote:

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.

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!

Lambertus · 2013-08-16 10:14:51

Learloj wrote:

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!

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.

mapper_07 · 2013-08-20 07:07:06

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)

Last edited by mapper_07 (2013-08-20 07:11:17)

dpawlyk · 2013-08-20 21:07:17

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?

Lambertus · 2013-08-21 11:00:00

dpawlyk wrote:

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.

dpawlyk · 2013-08-26 14:40:29

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.

Last edited by dpawlyk (2013-08-26 22:50:58)

Alienx · 2013-08-29 11:45:06

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

chris66 · 2013-08-30 10:27:40

Hi,

refuses to use the much shorter unclassified road

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

Announcement

#1951 2013-08-09 03:32:56

Re: Worldwide routable Garmin maps: URL REMOVED

#1952 2013-08-09 11:04:39

Re: Worldwide routable Garmin maps: URL REMOVED

#1953 2013-08-09 11:12:09

Re: Worldwide routable Garmin maps: URL REMOVED

#1954 2013-08-12 04:34:52

Re: Worldwide routable Garmin maps: URL REMOVED

#1955 2013-08-12 08:25:19

Re: Worldwide routable Garmin maps: URL REMOVED

#1956 2013-08-12 09:04:13

Re: Worldwide routable Garmin maps: URL REMOVED

#1957 2013-08-12 09:46:56

Re: Worldwide routable Garmin maps: URL REMOVED

#1958 2013-08-12 10:46:42

Re: Worldwide routable Garmin maps: URL REMOVED

#1959 2013-08-12 10:51:48

Re: Worldwide routable Garmin maps: URL REMOVED

#1960 2013-08-12 10:57:19

Re: Worldwide routable Garmin maps: URL REMOVED

#1961 2013-08-12 11:07:30

Re: Worldwide routable Garmin maps: URL REMOVED

#1962 2013-08-13 04:36:24

Re: Worldwide routable Garmin maps: URL REMOVED

#1963 2013-08-14 12:35:39

Re: Worldwide routable Garmin maps: URL REMOVED

#1964 2013-08-14 14:08:07

Re: Worldwide routable Garmin maps: URL REMOVED

#1965 2013-08-15 03:24:55

Re: Worldwide routable Garmin maps: URL REMOVED

#1966 2013-08-15 04:50:09

Re: Worldwide routable Garmin maps: URL REMOVED

#1967 2013-08-15 07:58:00

Re: Worldwide routable Garmin maps: URL REMOVED

#1968 2013-08-15 08:56:20

Re: Worldwide routable Garmin maps: URL REMOVED

#1969 2013-08-16 10:14:51

Re: Worldwide routable Garmin maps: URL REMOVED

#1970 2013-08-20 07:07:06

Re: Worldwide routable Garmin maps: URL REMOVED

#1971 2013-08-20 21:07:17

Re: Worldwide routable Garmin maps: URL REMOVED

#1972 2013-08-21 11:00:00

Re: Worldwide routable Garmin maps: URL REMOVED

#1973 2013-08-26 14:40:29

Re: Worldwide routable Garmin maps: URL REMOVED

#1974 2013-08-29 11:45:06

Re: Worldwide routable Garmin maps: URL REMOVED

#1975 2013-08-30 10:27:40

Re: Worldwide routable Garmin maps: URL REMOVED

Board footer