After solving previous issues, I am moving along with my map making adventure and have discovered a new issue I cant seem to resolve.
When I export my *.mp map to *.img format with GPSMapEdit/cgpsmapper the resulting map suffers loss of detail that is unacceptable.
In this linked screen capture (https://dl.dropboxusercontent.com/u/44223181/Map%20Issues/MP%20to%20IMG%20Detail%20Lost.png), you can see the original mp map detail compared to the exported map after installation into MapSource.
Map Levels are:
Level0= 24 Zoom0=0
Level1= 23 Zoom1=1
Level2= 21 Zoom2=2
Level3= 18 Zoom3=3
All Polylines exist on Level0 and are extended up to Level2
Map Header:
Quote
; Generated by GPSMapEdit 2.0.77.1
[IMG ID]
CodePage=1252
LblCoding=9
ID=17791779
Name=SW Trails 130808
Preprocess=N
TreSize=250
TreMargin=0.00000
RgnLimit=1000
Transparent=Y
POIIndex=Y
POINumberFirst=Y
POIZipFirst=Y
Levels=4
Level0=24
Level1=23
Level2=21
Level3=18
Zoom0=0
Zoom1=1
Zoom2=2
Zoom3=3
[END-IMG ID]
I have been experimenting with various TRE/RGN values, turning cgpsmapper preprocessing on/off, and have been unsuccesful in maintaining map detail in the final IMG.
I must be overlooking something very simple....
Any thoughts, please?
Have you noticed "overzoom" message under Mapsource scale? This means that map precision is too low for that scale.
You can use "SimplifyLevel" in header, values in range 2 - 3 can help a bit.
Quote from: popej on August 08, 2013, 09:19:49 AM
Have you noticed "overzoom" message under Mapsource scale? This means that map precision is too low for that scale.
How do I increase map precision for those lower scales?
Edit:
I see CNNANT and GPSFD 24k AZ Topo show overzoom below 500 ft, Garmin 24K Topo below 200 ft, and Garmin 100k Topo below 800 ft.
Is 200 ft the best detail we can currently achieve?
Quote from: popej on August 08, 2013, 09:19:49 AM
You can use "SimplifyLevel" in header, values in range 2 - 3 can help a bit.
I am not familiar with this setting.....
If you use most detailed level defined as "level0=24", then you have coordinates saved as 24-bit integers, which gives resolution about 2.4m. This is the best that cGPSmapper can do. And with 24-bits you get good view up to zoom 70m/200ft.
SimplifyLevel, cGPSmapper manual, page 12:
QuoteSimplifyLevel=n
Simplify level for Douglas-Peucker simplification algorithm. The higher value, the less simplification is done. It is important to note, that with high value, gridding (limitation coming from the format) might be visible.
Default = 1
Valid range is from 0.1 up to 10
Thank you popej. I added 'SimplifyLevel=0.1" to the header myself, recompiled, and see no change. Do header items have to be in specific order?
Quote
[IMG ID]
CodePage=1252
LblCoding=9
ID=17791779
Name=SW Trails 130808
Preprocess=N
TreSize=250
TreMargin=0.00000
RgnLimit=1000
SimplifyLevel=0.1
Transparent=Y
POIIndex=Y
POINumberFirst=Y
POIZipFirst=Y
Levels=4
Level0=24
Level1=23
Level2=21
Level3=18
Zoom0=0
Zoom1=1
Zoom2=2
Zoom3=3
[END-IMG ID]
Edit: I read it backward, using higher number now....
Low value = horribly simplified map!
Even using maximum value of 10, the only change I see is that my map is now only visible below 1 mile zoom level, with identical detail.
Simplification is about a number of points in a line. Bigger values means more points remain from original drawing. Nothing changes in levels or visibility.
Quote from: popej on August 08, 2013, 03:32:19 PM
Simplification is about a number of points in a line. Bigger values means more points remain from original drawing. Nothing changes in levels or visibility.
With SimplifyLevel=0.1 my map looked like a preschool art project.
With SimplifyLevel=10 my map looked the same as before I added any value to my header.
Page 12 of cgpsmapper manual states (as you quoted) valid range is from 0.1 up to 10, and Default = 1.
Is it possible the cgpsmapper manual has a typo, and the maximum level is actually 1.0, with a range from 0.1-1.0?
This would suggest that this value decides the percentage of points retained during simplification, where 0.1 = ten percent, 0.5 = fifty percent, and 1.0 = one hundred percent (or NO simplification), which would explain why I see no change between using no value (default = 1) and using value=10.
I have solved the issue with loosing visibility above 1 mile zoom.
My workflow is this:
1. create/edit map in GPSMapEdit
2. save as *.mp
3. export as *.img
4. install *.img into MapSource with MSTK
5. open MapSource to inspect map
6. uninstall map from MapSource with MSTK
I repeat this process each time I want to change a value or edit a specific map detail so I can see how that change will appear in MapSource/BaseCamp (I use MapSource because it loads faster than BaseCamp, and I am impatient).
I have discovered (at least on my Win8 64-bit PC) that each time I make changes and reload a map into MapSource using the same map ID, the changes are not displayed, and only the original map installed with the specific mapID will be displayed, even after uninstalling any previous versions of the map and deleting all associated files.
If I want to see changes each time, I have to install the map with a new mapID every time.
Have any other users experienced this issue, and if so, how can I force MapSource to clear it's cache?
Quote from: babj615 on August 08, 2013, 04:25:41 PM
I have discovered (at least on my Win8 64-bit PC) that each time I make changes and reload a map into MapSource using the same map ID, the changes are not displayed, and only the original map installed with the specific mapID will be displayed, even after uninstalling any previous versions of the map and deleting all associated files.
You know that MS/BC cache graphics and that Control-G flushes the MS/BC graphics cache?
I know that with Win7 if I rebuild a mapset the first time it loads it shows the old graphics, but after I Control-G things look new. Have you been doing this, and it's not working? Of course, if you create a new mapset, it would always show up.
Quote from: Seldom on August 08, 2013, 06:24:54 PM
Quote from: babj615 on August 08, 2013, 04:25:41 PM
I have discovered (at least on my Win8 64-bit PC) that each time I make changes and reload a map into MapSource using the same map ID, the changes are not displayed, and only the original map installed with the specific mapID will be displayed, even after uninstalling any previous versions of the map and deleting all associated files.
You know that MS/BC cache graphics and that Control-G flushes the MS/BC graphics cache?
I know that with Win7 if I rebuild a mapset the first time it loads it shows the old graphics, but after I Control-G things look new. Have you been doing this, and it's not working? Of course, if you create a new mapset, it would always show up.
No, I was not doing this. Now that you mention it, I remember doing this once a long time ago, and had forgotten completely about that function.
I knew there had to be a simple solution, there usually is.
Thanks for the heads up, Seldom! :)
Quote from: babj615 on August 08, 2013, 03:55:42 PMIs it possible the cgpsmapper manual has a typo, and the maximum level is actually 1.0, with a range from 0.1-1.0?
This would suggest that this value decides the percentage of points retained during simplification, where 0.1 = ten percent, 0.5 = fifty percent, and 1.0 = one hundred percent (or NO simplification), which would explain why I see no change between using no value (default = 1) and using value=10.
I'm using value 2 and it gives different results than default. Simplification doesn't count percents. When a sequence of points lies on a nearly straight line, simplification removes intermediate points. Parameter decide how far from straight line points are removed. See description of algorithm:
http://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm
Somewhere there is a setting that causes the data to generalize when imported. Make sure that is off.
Quote from: popej on August 09, 2013, 01:46:57 AM
Quote from: babj615 on August 08, 2013, 03:55:42 PMIs it possible the cgpsmapper manual has a typo, and the maximum level is actually 1.0, with a range from 0.1-1.0?
This would suggest that this value decides the percentage of points retained during simplification, where 0.1 = ten percent, 0.5 = fifty percent, and 1.0 = one hundred percent (or NO simplification), which would explain why I see no change between using no value (default = 1) and using value=10.
I'm using value 2 and it gives different results than default. Simplification doesn't count percents. When a sequence of points lies on a nearly straight line, simplification removes intermediate points. Parameter decide how far from straight line points are removed. See description of algorithm:
http://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm
I had looked at that page yesterday, and the example they give simply shows every other point being removed. I did not see anything in the Wikipedia article that equates to the cgpsmapper 0.1-10 scale.
Quote from: Red90 on August 09, 2013, 06:00:33 AM
Somewhere there is a setting that causes the data to generalize when imported. Make sure that is off.
Oh yes,
Tools > Options > Edit > Snap to grid is disabled!
Quote from: babj615 on August 09, 2013, 08:08:48 AM
I had looked at that page yesterday, and the example they give simply shows every other point being removed. I did not see anything in the Wikipedia article that equates to the cgpsmapper 0.1-10 scale.
See in "Pseudocode" section, there is used "epsilon" constant. My guess is that for cgpsmapper could be dependency like epsilon = 2.4m/value.
It is when you convert a track to a polyline, there is a checkbox for generalize.
Has anybody solved the problem with "loss of detail" after compiling by cgpsmapper?
I am asking, because I am facing the same problem with isobaths in waterways maps (web: waterways.cz).
I thought, I solved the problem by using level0=26 instead of level0=24. The picture has been very nice in Mapsource, but the polygons and polylines haven't been visible (under certain zoom) in marine plotters. So, this solution is unusable.
AFAIK cgpsmapper only supports to 24-bit. My guess would be because Garmin devices only support coordinates to 24 bit. Perhaps Garmin's newer devices support closer coordinates.
See popej's Aug 8, 2013 11:41AM post.
The 'accuracy' of most publically available source data would not even support 24-bit coordinates. Some calculations I did years ago indicated 23-bit is about equal to a scale of 1:20,000. Most (likely none) consumer grade GPSr units used on the 'fly' would be accurate to 2.4m (7.9m) anyway.
I read the post from Popej and it is obvious not only from this post, that Popej knows about creating of maps much more than me. But ...
What does exactly mean "cgpsmapper only supports to 24-bit"? When I use level0=26, the is no error at the compilation and I can read in the log, that all object were succesfully imported into layer 0. And, as I wrote, the result in Mapsource is better than by using 24 bit (you can see isobaths in the same place with 24 bit and 26 bit in attachments).
Of course, the discussion about this is useless, because the map with 26 bit is not visible under ceartain zoom. Discussion is, how prevent cgpsmapper from distortion the lines.
SimplifyLevel doesn't help, because input data are correct and therefore I use Preprocess=N. Even when I used Preprocess=Y and SimplifyLevel=3, the picture was the same - distorted.
May be there is no way (see discusssion at page tech.dir.groups.yahoo.com/neo/groups/map_authors/conversations/topics/2495).
I understand that the precisison 2.4m is enough for GPS unit, but I don't think, that inaccuracy GPS unit is reason for making inaccurate maps.
Quote from: zhrd on September 08, 2013, 07:37:56 AMWhat does exactly mean "cgpsmapper only supports to 24-bit"?
It means that internal representation of coordinates is 24-bit integer. This is what we know about img format and what is written in cgpsmapper manual.
But you are right, cgpsmapper accept level0=26 and creates map, which probably uses better resolution. I don't know how compatible is that kind of map with Garmin devices. I have checked that simple, non-routable map can be displayed in Mapsource and BaseCamp.
I wrote about the 24 bit limits in this old thread. My solution was to use a raster-based (.kmz) map which does not seem to have this limit. Of course, the size of such a map is limited and marine devices don't support them at all. http://forums.gpsfiledepot.com/index.php/topic,1335.msg8387.html#msg8387