Display problem with Mapsource 6.16.1

ligfietser · 2010-05-29T08:57:47.000Z

You could try to empty the cache history of mapsource (press ctrl-G twice). Sometimes the display gets mixed up and cleaning the cache will restore it.

Seldom · 2010-05-29T12:33:59.000Z

I already mentioned the ctrl-G fix in my post above. The other question is: is there any other fix for the smeary display for non-transparent maps compiled with mkgmap, or is the cache flush the only option?

Beddhist · 2010-05-30T05:41:31.000Z

Thanks for your comments. I used to run 6.15.11, I think, whatever the latest version before 6.16.1 was. This worked fine for me.

I have tried Ctrl-G, but it only toggles “Basic Map Only” display. In OSM maps the basic map shows nothing at all, so yes, I can zoom without problems, but it’s not useful. As soon as I press Ctrl-G again it switches back to normal mode and the screen corruption occurs again.

I’m going to try this out on another PC with a fresh MS install and I’ll report back. And don’t expect any amazing discoveries.

Cheers,
Peter.

Beddhist · 2010-05-30T11:39:25.000Z

I just tested it on our second PC. Same problem on MS 6.16.1, no problem on 6.15.11. Looks like Garmin have changed something in the latest MS which makes mkgmap compiled maps kind of incompatible. I guess I have to downgrade MS.

Cheers,
Peter.

ligfietser · 2010-05-30T11:46:55.000Z

@beddhist: What kind of maps are you using? With my maps (compiled with mkgmap rev 1647) and Mapsource 6.16.1 (on a Windows Vista pc) I don’t see any problems with rendering.
@seldom I’m sorry, I didnt notice you mentioned it already

Beddhist · 2010-05-30T11:55:37.000Z

I have two OSM maps, one downloaded from http://garmin.na1400.info/routable.php, the other was compiled for me by somebody else, so I don’t know which version(s) of mkgmap have been used. I’m on XP SP3.

Cheers,
Peter.

Gollem · 2010-05-30T13:27:45.000Z

I have the same “problem” there is a shadow around roads and borders, when you move the cart a little the shadow is gone.
I have this only with osm maps.

Win XP SP3, mapsource 6.16.1
But I had this also on my netbook with previous version, 6.14. I think.

Seldom · 2010-05-30T16:42:36.000Z

ligfietser:

@beddhist: What kind of maps are you using? With my maps (compiled with mkgmap rev 1647) and Mapsource 6.16.1 (on a Windows Vista pc) I don’t see any problems with rendering.
@seldom I’m sorry, I didnt notice you mentioned it already

No big deal about control-G.
I’m running Win7-64bit. MapSource 6.16.1 NVidia GeForce GT220 1024MB Video RAM.

Samples of the MapSource rendering follow. Rendering is same in BaseCamp.

Blurry OSM Image.

1275237039.jpg1024×606 129 KB

Clean OSM Image after Control-G.

1275236951.jpg1024×606 105 KB

Transparent or Non-transparent images generated with cgpsmapper don’t render this way. See below:

1275241908.jpg1024×606 132 KB

This cgpsmapper generated image cleanly at all zoom levels. The image was of a non-transparent map. Transparent maps are identical. Note the difference in background color.

Seldom · 2010-06-13T15:28:10.000Z

I suspect this may have to do with the Map Selection Area Polygon (0x004a) and/or the Map Coverage Polygon (0x004b). The OSM samples above were compiled as non-transparent maps, but the gray background is the same color as the NoMap color in MapSource 6.16.1. So it looks like 6.16.1 may be treating the OSM maps as if they had no background. The light beige in the lower right of the following image is the standard background color.

Also note the yellow map selection polygon highlight is offset from the actual map bounds. This is a routable map, so the actual limits of the map selected are the bottom of the horizontal contours and the right side of the vertical contours, but the gray background aligns with the map selection area. The selection polygon offset has no effect on the routing.

Beddhist · 2010-06-14T09:24:02.000Z

I posted this on the mkgmap developers mailing list and got this reply:

Peter Hendricks wrote:

Hi,

Sorry if this has been discussed before, but I did search the list and
couldn’t find any reference.

I’m using maps from OSM, downloaded from here:
http://garmin.na1400.info/routable.php

Ever since I upgraded Mapsource to the latest I’m getting the screen
corrupted when zooming in. Details are currently discussed here:
http://forum.openstreetmap.org/viewtopic.php?pid=83694#p83694

I would have thought that the developers would be aware of this problem,
but can’t find any reference to it.

Cheers,
Peter.

I also have MapSource 6.16.1 and I don’t get this problem, so it’s not
universal. When I have been messing around with self-generated maps
in the past, I have seen this problem occur (with older versions of
Mapsource) but that was due to the bounding box of my data not being
converted to Garmin coordinates properly so the map “border” was
offset from the actual map data.

– Charlie

Is the problem with how the tiles are split, then?

Seldom · 2010-06-14T10:04:54.000Z

I’m running both MapSource 6.16.1 and 6.13.7 on my machine. The blurry image cacheing isn’t visible in 6.13.7 but the tile boundaries are displaced.

The samples I show above are from my own maps, which are generated in MP format, but I see the same results when I download map samples from http://garmin.na1400.info/routable.php.

The maps aren’t split, but since the tiles are routable they are aligned. Since they are in MP format I don’t use a “style” file.

It would be helpful if “Charlie” could advise how to control “data being converted to Garmin coordinates properly.” The only thing I can imagine is that the “level” of the bounding box is set to too low a precision. I imagine it would be controlled by the --tdbfile switch, but I don’t see any options listed for it.

If I recall correctly, the older versions of cgpsmapper used to generate similar offsets between the selection boundaries and the actual map tiles. Recent versions don’t do that.

Lambertus · 2010-06-14T10:09:03.000Z

I wonder if that’s really the problem. I’m using Splitter (the ‘official’ tool) and this version has been used for many updates now. I’m also updating Mkgmap on a regular basis, but the current version r1648 has been used for the last two or three updates. The Mkgmap version that is used to combine the tiles on the server is r1568, I could update that but I don’t think it will solve anything as it only generates the gmapsupp, NSIS installer script and an overview file (which doesn’t seem to be the problem here).

Seldom · 2010-06-14T10:49:13.000Z

Lambertus, which “that” is really the problem?

Also, I’m leery of mkgmap updates. While I always check updates for improvements, any version I’ve used since 1173 has resulted in the behavior shown below:

N Main St in the image above is the same N Main St shown on route 12 in my post of June 13 above, but it is truncated. This problem goes away if I make the TDB file with r1173, even if the IMG file was generated with a more recent release of mkgmap. The image below was compiled with mkgmap r1173. The seam between the two map tiles can be seen by the breaks in the roads. However, connections across the roads do route.

Lambertus · 2010-06-14T11:27:16.000Z

Seldom:

Lambertus, which “that” is really the problem?

I referred to this:

Beddhist:

Is the problem with how the tiles are split, then?

I.e. I don’t think it’s because of some splitting error.

Also, I’m leery of mkgmap updates. While I always check updates for improvements, any version I’ve used since 1173 has resulted in the behavior shown below:

http://imghst.gpsfiledepot.com/1270466342.jpg

N Main St in the image above is the same N Main St shown on route 12 in my post of June 13 above, but it is truncated. This problem goes away if I make the TDB file with r1173, even if the IMG file was generated with a more recent release of mkgmap.

Yes, I know there’s always a risk in using new versions (the ‘if it ain’t broken, don’t fix it’ meme), but there’s always a big group that want’s to benefit from new developments.

Anyway thanks for sharing your experiences. So moving back to r1173 for the final step of combining the maps could fix some strange behavior, but then this should be reported back to the Mkgmap development community as well…

Edit: in response to your edit: so the only change between the two images is an older Mkgmap version? Then it’s certainly not a splitting error unless the old Mkgmap version ignores the information that splitter adds to the osm data?

csdf · 2010-06-14T15:18:24.000Z

Seldom:

I’m running both MapSource 6.16.1 and 6.13.7 on my machine. The blurry image cacheing isn’t visible in 6.13.7 but the tile boundaries are displaced.

The samples I show above are from my own maps, which are generated in MP format, but I see the same results when I download map samples from http://garmin.na1400.info/routable.php.

The maps aren’t split, but since the tiles are routable they are aligned. Since they are in MP format I don’t use a “style” file.

It would be helpful if “Charlie” could advise how to control “data being converted to Garmin coordinates properly.” The only thing I can imagine is that the “level” of the bounding box is set to too low a precision. I imagine it would be controlled by the --tdbfile switch, but I don’t see any options listed for it.

If I recall correctly, the older versions of cgpsmapper used to generate similar offsets between the selection boundaries and the actual map tiles. Recent versions don’t do that.

Hi, “Charlie” here. The problem I was having was of my own making as I wrote a small programme to generate OSM XML data and I wasn’t setting the bounding boxes to be in round numbers of Garmin coordinates. This caused Mapsource to exhibit the same symptoms as have been reported above. I’ve no idea if the cause is the same. My suspicion at the time was that the problem related to the overview map (mkgmap doesn’t create this properly whereas, afaik, cgpsmapper does).

Seldom · 2010-06-14T17:19:47.000Z

Thanks, Charlie and Lambertus.

Lambertus, the only difference between the two images in my 10:49 post is that the lower one, which renders correctly, was done with r1173, which is the last mkgmap that I have found that fully supports my Polish format files. The image above was generated with r1625. I realize most of the effort in mkgmap is directed to supporting OSM, but I think that improved MapSource rendering is a concern we have in common.

Charlie, thanks for the tip. I’ll see if I can get GPSMapedit to modify the basemap.IMG files so they align correctly. And another question, right now I’m working in MP format because my data sources are USGS 10 meter DEMs and the US NHD data set. Is there a way to incorporate this data into OSM for compilation?

extremecarver · 2010-06-14T19:42:32.000Z

The problem ist, that you mess around with --transparent or 0x4b inside the typfile. Don’t do it and you’re fine. If you set 0x4b in Typfile, then you cannot use --transparent (there is no 0x4b polygon included). If you do this, then the error above occurs, which is simply stupidity.

Seldom · 2010-06-15T00:26:05.000Z

extremecarver, we’re talking about several rendering problems here, and one of them, blurry image cacheing, applies to maps downloaded from http://garmin.na1400.info/routable.php as well as my own maps. Regarding Typ files, I don’t use any, and the maps I’m compiling are not transparent. My maps are compiled from MP, not OSM.

csdf · 2010-06-15T06:40:54.000Z

Seldom:

Charlie, thanks for the tip. I’ll see if I can get GPSMapedit to modify the basemap.IMG files so they align correctly. And another question, right now I’m working in MP format because my data sources are USGS 10 meter DEMs and the US NHD data set. Is there a way to incorporate this data into OSM for compilation?

Maybe this? http://www.mail-archive.com/talk@openstreetmap.org/msg05500.html

extremecarver · 2010-06-15T06:56:04.000Z

Well, then your map has brocken background polygon. The same problem happens, if you compile from osm and use --transparent, or put transparent 0x4b into the Typfile. Therefore clearly something is broken in your mp file. I also had many contourline maps, that I converted from .img to mp with gpsmapedit (to delete problematic lines), and then recompiled with mkgmap. And it does not matter which version of mkgmap. They don’t shown any probs in Mapsource 6.16 or Basecamp 3 even though compiled from mp.