At least here in Vermont, our unpaved roads vary from good, well-maintained gravel (on which a race-replica sportbike is a completely reasonable ride) to old right-of-ways that have not been maintained for vehicular travel in decades. I’ve been tagging unpaved “roads” that I wouldn’t want to drive in a normal-clearance, two-wheel-drive sedan as highway=track and using the smoothness tag to distinguish between “a little rugged”—the type of roads where the locals will drive two-wheel drive sedans, albeit with the occasional scrape of an oil pan on a rock—and places that present an interesting challenge on a dual-sport motorcycle (or from those that might challenge a good rider on a dirt bike).
So my two cents is that it’s important to have a distinction between “unpaved road” and “track”. It’s not an easy problem to solve, particularly since the areas with the most questionable roads also tend to have low population densities and the most questionable data (to the point where I’ve learned that a “major road” showing up on a Garmin CNNA map, unless it’s a state highway, usually means “road indicated in Navteq data without further information” and probably translates to “woods road that may or may not be passable,” while a minor road may well be a well-maintained gravel road), but I think it’s one worth doing our best to solve.
And yes, all of the above can change with weather—there are plenty of roads in this state that are passable by passenger car for all but two or three weeks of the year, and for those few weeks, you may or may not get through even with AWD and reasonably high ground clearance. I still think that it’s important for the data to reflect the overall picture, not necessarily the “mud season” situation.
I’ve been experimenting with the new style the past few days and noticed that while the default style displays the names associated with polygons like parks and building, the new style does not. Could someone tell me how to enable that in the style file? I’ve tried quite a few things without any luck, including starting over with a copy of the style without any of my modifications. I was going to try to see if a map generated online works correctly, but there is a 2 day wait in the queue.
Aside from that, tweaks I’ve made to the style for personal use on my small cycling Garmin unit:
changed the building polygon type to 0x3600 for better contrast
changed the path type color to red using TYPWiz
increased the height of the “unpaved” type 0x10002 from 7 to 11 so it is more visible when applied to unclassified roads
The appearance of labels are controlled in the TYP file. For some polygon types I have set them to invisible.
With the typwiz or typviewer editor you have to edit the TYP file and set the labels to default, no label (invisible), small or large font.
In the style files you can check which OSM key/value is rendered with which Garmin type: https://code.google.com/p/mkgmap-style-sheets/source/browse/#svn%2Ftrunk%2Fstyles%2Fworld
Maybe the handling of the downloads can be improved. I wanted to get the Moscow area but I don’t wait the scheduled 2.4 days. So I went for complete Russia. Now it would be a good idea to cancel the first request. (Maybe showing the estimated time in advance would reduce custom area requests a lot…)
At the moment, osm_generic_gmapsupp.zip for complete russia seems to be broken. It is only 174 bytes large. I don’t see any method to force a recalculation.
Any way to get an auto-email when a country file is recalculated with new data?
I have limited knowledge on the map generation process (maybe Lambertus can comment on this after his holidays) but you can do a few things. For a small area like Moscow you can download the img tiles directly (click on the files that you see in the left panel) and compile a map with Javawa’s OSM Combiner.
I see not only the gmapsupp.img is broken for Russia, but also the Mapsource installer (probably many things went wrong during the latest map generation). You can also use OSM Combiner to install it on your pc and/or create a gmapsupp.img for the GPS with the osm_generic_new_tiles.zip file.
At present there is a problem with “Istambul tile”, both selecting it during a custom map generation or downloading Turkey ready map as whole.
If you select the Istambul containing tile and generate a custom map you obtain a map containing the “Friburg” tile
I’m seeing a small problem. In the Zuiderpark, Den Haag there is an athletics track. It is properly mapped as “leisure=track”. But because of the “track” the outline of the track shows in BaseCamp as a “path”.
The problem is should it be tagged as a way (the track itself) or the whole sports area (where the track(s) is/are located).
In the wiki this is unclear. If you look in the right tabel it recommends not to use it on the area:
Used on these elements:
should not be used on nodes
may be used on ways
should not be used on areas
may be used on relations
So therefore the mapping on OSM is wrong, one should map the actual race track with leisure=track (which is represented as path in Basecamp) and not on the whole sports area.
Reading the wiki again, I am not sure how to solve this. All situations are different.
The “Areas?” paragraph states that the handling of areas is a bit unclear at the moment.
In Rijswijk there is a cycling track. That is definitely not properly mapped (highway=cycleway). But when it would be mapped with “leisure=track” (as it should be, I think) you want the track to show as a real path. But athletics track are commonly mapped as areas.
And leisure=track is also used for horse racing. Duindigt is also mapped as an area. But maybe other horse racing tracks are mapped different.
I use a Nüvi 55 with primarily maps from Denmark. I have the latest revision of the Denmark map… 09-09-2014
There is an error:
For example, my journey takes me though a roundabout. It is a straight forward roundabout with 4 exists, 3 o’clock , 6 o’clock , 9 o’clock 12 o’clock , where I am entering the roundabout at 6 o’clock and should exit the it at 9 o’clock to reach my destination.
The voice prompt navigates me though the roundabout correctly… “take exit number three, bla bla bla”…
The small icon to the top left of the navigational window on my Garmin, indicating the specific roundabout with the exit to take, incorrectly indicates that I should exit the roundabout at 6 o’clock.
I find this to be the matter with all roundabouts… the icon to the top left on the navigational window displaying an exit later that the actual exit that I need to take.
Thank you for the welcome. I have disabled all other maps on my device… for example “city navigator europe nt lifetime” that came with the GPS.
(I have tried the downloadable *.img file that I copied directly onto my device and *.exe file for installing the map to BaseCamp, where I then uploaded the map to my device via BaseCamp. The result is the same)
Regards,
Johan
P.S. I’m worried that it actually might be a firmware bug… just like you mentioned.
Yes, I expect that it will work correctly with all of Garmin’s maps. But can you try a different kind of map? You can try our own NZOGPS map and put your unit into demo mode (i.e. turn off the receiver). You can position your pointer somewhere in NZ and route to another location on the map.
What I suspect is that your GPS can’t handle roundabouts in maps other than Garmin’s.
OSM maps are produced by a compiler called mkgmap. By trying another kind of map I want to eliminate this, as other free maps are generally produced with cgpsmapper. The output should be pretty much the same, but this is just what we are trying to prove.
Ok, I managed to download the NZ map… but first I had to register.
I selected two waypoints in Christchurch…
S43.55101° E172.54557°
and
S43.55205° E172.54589°
(there is a roundabout between the two points)
I did a simulation of the route and no problem whatsoever. Both the voice prompt and the icon indicating the exit in the roundabout (top left of navigation screen) is correct.
On the face of it your Nuvi seems to have a problem with roundabouts compiled with mkgmap, but cgpsmapper created maps and Garmin’s own (naturally) are ok. 1 attempt is not proof, of course, but I think there is a lead that can be followed - but not here. This forum is for tweaking the appearance/functionality of the maps produced by Lambertus.
