Worldwide routable Garmin maps: Missing/incorrect feature requests

This is strange, both OSM tags tourism=caravan_site and tourism=camp_site gets the same Garmin rendering poi [0x2b03 resolution 24], see https://github.com/ligfietser/mkgmap-style-sheets/blob/master/styles/generic%20new/points
Are you sure you look at the Generic New maps? Can you send me a link of the OSM.org map of a campsite you don’t see on your device?

I’m investigating this issue further…
poi 0x2b03 is rendered as campground on the map, but is not found with search menu on my Garmin Oregon.
poi 0x2b05 that I use on my openfietsmap is also rendered as campground, can be found with the search menu. On my Openfietsmap I use 2b05 for camp_site and 2b03 for caravan_site. I think this a Garmin device bug rather than a mkgmap index problem because Basecamp and Mapsource can find those pois.

I have dropped this issue on the mgkmap-dev list, http://gis.19327.n5.nabble.com/index-problem-camp-site-td5844807.html
It should be an easy fix to switch for the 0x2b05 poi.
On the Garmin new Style maps I can change this myself so in the next update it will be fixed, thanks FactualOrc for reporting!

I did some further testing with several devices

0x2b03 (camp and caravan site default style) renders on Dakota, Oregon 600 as tent symbol, but is not findable (only under all POIs -if you know the name). On a Nuvi 310 it renders as tent and findable under lodging. Monterra renders it as caravan and finds it under lodging/campgrounds

I adapted the default style and made a test map without typ file
https://drive.google.com/file/d/0B5LoKTN293hkYWhQMXRYd0NXSmc/view?usp=sharing
0x02b05 tourism=caravan_site
0x4800 tourism=camp_site

0x2b05 = renders on Dakota, Oregon 600 as tent symbol, and is findable under lodging/campgrounds. On the Nuvi and older Etrex it renders as “bed” (lodging) and findable under lodging. Monterra renders it as tent and finds it under lodging/campgrounds
0x4800 = renders on Dakota, Oregon 600 as tent symbol, and is findable under lodging/campgrounds. On the Nuvi / older Etrex it renders as tent, but pois are not findable at all. Monterra renders it as tent, cannot find it at all.

Please test it for other units.

Hi Ligfietser,

I am happy to report that the img file that you provided in your google drive does actually have working campsite poi’s on my 64s! If you could render a map from this osm http://planet.openstreetmap.ie/ using the same settings I would be greatly appreciative.

Thank you very much,
FactualOrc

Orc, seems like your 64s behaves the same as my Oregon 600 so I’m glad to hear it works as expected.
I’m sorry but I’m not rendering a map from planet.openstreetmap.ie This is an extract of the same planet osm that Lambertus uses on garmin.openstreetmap, so be patient until the next map updates.

Not quite sure if I have to post it here ?

I’ve downloaded Routable Bicycle (Openfietsmap Light) Ontario version 10-09-2015

In Openstreetmap I see parking spaces written as:
Amenity = parking
parking=surface
surface-=asphalt

After installing I see (for example: Hamilton (ON) - King William Street only car towing truck as pictogram.
Here a screenshot: https://onedrive.live.com/redir?resid=49D9B9E5AE291F75%213135
What goes wrong ?

groen_duiven

Typ file seems missing.
Maybe try a fresh download, if it still missing, you could post the download link here.

After downloading new map of Ontario (version 16-09-2015) problem solved.

In the version of 10-09-2015 were more strange things. In parks there were many watertaps instead of benches.

groen_duiven

Thats because I have to use other Garmin types to make some cycling features findable. I use parking for bicycle parking, normal car parks I have to shift to another garmin type, like towing truck :wink:
If the map does not have the original typ file, those “hacks” become visible. Maybe by some compiling error on the server of the map generation the typ file was lost?

Hi folks,

I downloaded the Lambertus osm_generic_new_gmapsupp.zip North America/Oregon Generic Routable (new style) and installed it on my Garmin GPSMap62st.

Looks really good, but I’ve noticed a couple potentially-missing items:

From https://www.openstreetmap.org/#map=19/44.06379/-121.35297

leisure=playground [point]

From https://www.openstreetmap.org/#map=16/44.2548/-121.1544

lines associated with aeroway [ways], though the labels appear

Ideas? Thanks!

Not all features found in OSM are being compiled into the Garmin maps. You would not be able to discern much on the map, if they were all there. I’m sure playgrounds are not included. After all, the Garmin maps are mainly intended for navigation.

The runways, however, should be visible, since their labels show up. I wonder whether that is a colour problem.

@beej71:
Leisure=playground is a feature that IS included, have a look at the polygon style
https://github.com/ligfietser/mkgmap-style-sheets/blob/master/styles/generic%20new/polygons

The problem with your shape is that you are using the highways also for the borders of the leisure=playground shape.
I don’t think this is common practice on OSM and should be avoided, at least it will lead to rendering issues on the Garmin maps. It will draw the ways first and then the processing stops, it does not expect that those ways double as line for other shapes as well. Only in certain features (plazas, parking lots etc) ways are rendered as polygon shapes too.

About the runway line type, I use type 0x27, which is visible in Basecamp.
https://github.com/ligfietser/mkgmap-style-sheets/blob/master/styles/generic%20new/lines

Maybe this line type is invisible on the GPS (I havent specified a shape for it in the TYP file), I will have a look on this issue on my Oregon.
If you want to experiment it yourself, I can recommend the TYP file editor Typviewer.

Oops, the shape I meant was referring to leisure=park which is rendered fine, my mistake.

You mean this feature https://www.openstreetmap.org/node/3728637353

It should be rendered with leisure=playground [0x2c06 resolution 24] but I made point 0x2c06 invisible because it is also used for labels of leisure=park, garden etc otherwise it would clutter the map. If you give this feature a name the label would show up.

Cool. Thanks for the info! I’ll try to learn more about this to see if I can troubleshoot it myself, as well.

Cheers,
-Beej

Beej,
On my Oregon the type 0x27 (runways) were invisible too. Strange, because 0x27 was the default Garmin typ for runways.
Apparently something has happened in the firmware and those lines are not rendered anymore without a typ file?
Anyway, I added this type to the TYP file so next time it will be rendered on the device.
You can download the improved file here:
https://github.com/ligfietser/mkgmap-style-sheets/blob/master/typ/osm%20generic%20new/2000.typ (view raw to download it)

Thanks for reporting this!

Feature request …
We plot a lot of GPS tracks over here in the jungles of Thailand … To aid differentiating those that genuinely dead end, against those that just might have stopped for another reason (jungle canopy/cloud cover on traced tracks, etc), …when physically verified, we tag the last node as noexit=yes
Is there any way a small “no-through road” icon (similar to that used on road signs) can be added into the mkgmap latest style to pick up on this noexit tag, and have it display on the units at higher zoom levels ?

You mean a sign like this one?

The only problem I can see is that there is no universal sign that is used and understood everywhere. I wonder whether we could give it the name “Road ends” such, that it only shows when the cursor hovers above it. That way people can find out what it means, but the maps won’t be cluttered with redundant labels.

Only a name would be very difficult to find. I can make a small icon like this, but we unfortunately cannot control the zoom levels anymore in Basecamp and the newer devices (only in Mapsource), so it might clutter the map at lower zoom levels. Only if i make it very tiny it will be acceptable?*

*) I’m afraid it will clutter the map in areas like here: http://overpass-turbo.eu/s/et1

This doesn’t look good… :frowning: