I guess that depends on whether your 64s completely ignores these POIs or just doesn’t display them. Can you find them by searching for the name? If so, you may want to experiment with modifying the TYP file.
Failing that, you could compile your own map. It’s not that hard if it is an area not too big: you need a copy of mkgmap, download the config files from the SVN server and make up a suitable batch file. You then download OSM data and drop that on the batch file. Once your map gets over a certain size (I don’t know what the limit is) then you need to split the data into tiles. I have never attempted that.
Another option is to download just the missing POIs from the Overpass web site. After transforming into a compatible format you can load them as custom POIs using Garmin POILoader. This is probably easier than the other options.
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!
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
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.
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.
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.
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
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?
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.
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.
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.
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.
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)
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 ?
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?*