Map deselect doesn't work

I want to use two maps of the same region on a Garmin Etrex Vista Hcx. One is purely OSM and the other is enhanced with non free information.

While I have managed to create a gmapsupp.img containing both maps (+styles +type-files) and I can select/deselect them in the Vista, I always find parts of the deselected map on the display. They seem to be all at places, where the selected map is empty. (And no, none of the Maps is transparent)

It looks as if “deselection” were a misnomer and should be called “draw it first”. Is this a known problem?

Weide

Are you sure you are de-selecting the entire product, and not just a few tiles? L’Allemand’s email on this thread
http://forum.openstreetmap.org/viewtopic.php?id=4806
describes how to show or hide entire map products.

If that doesn’t work, please provide more info on the two maps are using, and, if you know, what compiler was used to create them.

Yes, I’ve tried both.

It doesn’t make a visible difference, as each of both maps has only one tile. The selection/deselecting of tiles also selects/deselects the product und the other way round and the result on the map is the same.

1.: Downloaded a region with JOSM and stored it as “frei2.osm”

2.: Edited with JOSM and stored the result as “unfrei2.osm”

3.: Edited a type file (from http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map))
using http://ati.land.cz/gps/typdecomp/editor.cgi such that the product-id is 45 and the
family-id is 4. Stored as mytyp454.TYP

4.: Same for mytyp465.TYP with product-id 46 and family-id 5

5.: Edited a style file (from http://wiki.openstreetmap.org/wiki/DE:All_in_one_Garmin_Map))
to contain different display levels for railways and display of beaches). stored as
mystyles/mystyle/* (Yes, I use Linux)

6.: mkgmap --style-file=mystyles --style=mystyle --description=“OSM” --country-name=germany --country-abbr=DE --family-id=4 --product-id=45 --series-name=‘XXX’ --family-name=OSM --area-name=DE --latin1 --lower-case --mapname=63240002 --draw-priority=20 --add-pois-to-areas --road-name-pois --net --route --gmapsupp frei2.osm mytyp454.TYP

7.: mv gmapsupp.img gmapsupp2.img
(this is just a renaming)

8.: mkgmap --style-file=mystyles --style=mystyle --description=“UNF” --country-name=germany --country-abbr=DE --family-id=5 --product-id=46 --series-name=‘XXX’ --family-name=UNF --area-name=DE --latin1 --lower-case --mapname=6324003 --draw-priority=10 --add-pois-to-areas --road-name-pois --net --route --gmapsupp unfrei2.osm mytyp465.TYP

9.: mv gmapsupp.img gmapsupp3.img

10.: gmt -jo gmapsupp.img gmapsupp2.img gmapsupp3.img
(gmt is the command line version of GMapTool for Linux)

11.: cp gmapsupp.img /media/disk/Garmin/gmapsupp.img
(Thats copying to the garmin)

I’m afraid I’m ignorant in both Linux and style files, and my overlaid maps consist of 1 commercial Garmin product, 1 cgpsmapper compiled product, and 1 OSM product compiled from Polish format. I’ve never tried to overlay two OSM maps, and I’ve never tried to incorporate copyrighted data in my maps.

Have you tried your maps without the style files?

When I try it without styles and TYP-files, the problem is still there. It much less visible, as the beach became completely invisible. But an administrative border and a POI of “frei.osm” are still visible, when “frei” is switched off. (If I switch off both of the maps, nothing is visible; switching on the “unfrei” again, makes the administrative border and the POI of “frei” appear again.)

I’ve noticed, that an area of wood behaves correctly while an area of beach does not. Perhaps the problems are connected to the fact, that it’s a north sea island and the water background is missing and so not redrawn.

I’ll try now to reduce the example.

Solved!

It’s rather simple: storing in JOSM does not store the state that was achieved by editing, but stores the “change operation set” to be sent to the OSM-Server and mkgmap cannot handle all that kind of data correctly. The solution was to copy everything into a new layer, store that one and use the resulting file. Well, at least first tests suggest, that mkgmap can handle that kind of data…

Thanks
Weide