I thought I was beginning to understand this stuff, but now the mysteries are multiplying.
I backed up and created what I thought as a simple map, importing a shapefile of roads into GPSMapEdit. All the roads are imported as type 0x000a (unpaved) at level 0. I add another level (otherwise I get an error that about generating the preview). Here are the various settings:
(http://i.imgur.com/QuVbGwt.png)
(http://i.imgur.com/d66tzLm.png)
(http://i.imgur.com/I71gfes.png)
And here's what a small piece of the map looks like in GPSMapEdit
(http://i.imgur.com/VtDboBs.png)
Here's the corresponding region in MapSource - notice the extra straight lines. What are these? They appear to be some sort of simplification of the curves, but why are they there? They seem to relate to my zoom levels, but how?
(http://i.imgur.com/QbNY8vv.png)
And the final kicker - when I zoom out, I get this:
(http://i.imgur.com/3voBM9c.png)
I've tried this process numerous times, tweaking zooms, changing type, use of external .typ file, etc, and keep getting this nonsense. I've been careful to delete all my intermediate files (rename outputs) so I know I'm seeing the results of my new run. I suspect these are newbie errors that are familiar to the more practiced, but I'm baffled.
Not sure about that brown and blue houndstooth check in your bottom image, but try Transparent=S instead of Transparent=Y. I always used Transparent=S when I was doing overlay maps, and it covered up those generalized shapes.
Quote from: Seldom on April 29, 2013, 08:00:23 AM
Not sure about that brown and blue houndstooth check in your bottom image, but try Transparent=S instead of Transparent=Y. I always used Transparent=S when I was doing overlay maps, and it covered up those generalized shapes.
Transparent = S didn't make a difference.
I've been doing a lot more experimentation and the issue seems to be the complexity of the map. I can make a simple map of the same extent and not get the hounds tooth. I can take the data that I'm using for the example above and select a smaller region and get a good map. I've tried increasing the TRE_SIZE, nothing changes. I've tried adding layers with the details only on the 0 layer with just gross detail at the next layer - still get the hounds tooth. An obvious solution is to split the map into tiles, but it doesn't seem like an excessive amount of data when I look at some of the topo map tiles.
Update: I split the map in half and now it seems to work. For what it's worth, the map spanned 1° 40', split it spanned 1°. Not only did it solve the problem with the background, the extra lines disappeared, and the jaggies in lines also disappeared. Probably not a coincidence - the NM Topo mapset in the custom maps on this site also has tiles that are 1° wide.Update: Spoke too soon - when I zoomed in close enough on the 1° wide map, the hounds tooth appeared. Not sure if it was a factor the width or where I was looking in the map. I've now extracted a small region in the north west corner and get the hounds tooth at all zoom levels. Other problems that are showing up - one class of my polygons doesn't appear in MapSource, the class that does appear (and has the right color), but has no tooltip value, even though it's set in the .typ file. The roads are type 0x30, but appear in the color of type 0x03. I've checked the .mp file and the types are correct in the file.
I second Seldom opinion, the reason for double lines is using transparent 'Y' maps in Mapsource. Stright lines are from preview map, which is visible over areas without background objects.
Other effects are probably a result of processing details, of which we haven't any informations. Just an example - if you recompile your map, changing transparency from Y to S, you can still view old map in Mapsource, since Mapsouce can use data from cache.
Interesting...All my map tiles are 1 degree or smaller. If you've just discovered a new "feature" of cgpsmapper, hopefully someone with more understanding of the mechanics of the compiler, like popej, can address it here.
Quote from: popej on April 29, 2013, 09:12:04 AM
I second Seldom opinion, the reason for double lines is using transparent 'Y' maps in Mapsource. Stright lines are from preview map, which is visible over areas without background objects.
Other effects are probably a result of processing details, of which we haven't any informations. Just an example - if you recompile your map, changing transparency from Y to S, you can still view old map in Mapsource, since Mapsouce can use data from cache.
I've bee wondering if I've been seeing cache effects because sometimes I don't see changes I'd swear I made. Is there any way to force MapSource to clear the cache, or do I have to change the map name on each test? Is it enough to change the mapset name, or do I have to change the tile ID as well?
I don't think there is any problem with tile size, many maps use bigger tiles.
To clear cache in Mapsource or BaseCamp press Ctrl-G twice.
Quote from: popej on April 29, 2013, 10:12:51 AM
I don't think there is any problem with tile size, many maps use bigger tiles.
To clear cache in Mapsource or BaseCamp press Ctrl-G twice.
That's a huge help. Now I'm pretty confident that I'm seeing the map I just generated. From that, I now think my problem lies in my custom .typ file. If I build with no custom typ file, I get a sane background and only the items that coincide with standard Garmin types appear on the map. When I build with my custom .typ file, I don't see all the objects, although all are mapped to types. I'm using roads (polylines) with types 0x30, 0x31, 0x32, 0x33. I'm using polygons with types 0x5100 and 0x5200, in a type file designed using TypWiz. The houndstooth is a polygon fill "left-over" from a .typ file I started with, and is somehow being used to fill empty space. (It's code is 0x4b00). Once I deleted that entry, the houndstooth is now gone.
None of the roads are appearing on the map, perhaps these type codes aren't valid?
The polygons appear, but when I mouse over the polygons in MapSource, it says "Unknown area", even though the type is set to "Private Land" for the string.
The .typ file is attached.
Thanks for all the help.
Some roads aren't visible at all, some can be visible in GPS but not in Mapsource, some ranges of type values are simply wrong, even if cgpsmapper doesn't complain.
Your safe choice is to use types described in cgpsmapper manual. You can change their meaning with TYP definition but even then there are some peculiarities, like for example line 0x14 (railway) is not displayed at higher levels.
Quote from: popej on April 29, 2013, 11:52:33 AM
for example line 0x14 (railway) is not displayed at higher levels.
So MapSource/BaseCamp overrides EndLevel settings in GPSmapedit/cgpsmapper?
I'm getting pretty close. I renumbered my line types into the lower range, over-writing some standard values I didn't need. I had never gone through the end of the cgsmapper manual to find the Appendices with the type ranges. Seems 0x30 and above are not valid lines, so that's why they didn't appear. Now I've got my lines appearing, houndstooth is gone.
The lines show their types on mouse-over, but the polygons still don't. Any suggestions?
Also, the lines are jagged, whether I use bitmap lines or non-bitmap lines.
Here are the lines in GPSMapEdit:
(http://i.imgur.com/0iHMvQY.png)
and here are the same lines in MapSource:
(http://i.imgur.com/0737y28.png)
They're jagged like that even when I don't use the custom .typ file, but I know I've sen and made other maps with smoother lines. Might this have something to do with my zoom levels? Level zero was 24 bits. I changed it to 26, but that made no visual difference. (GPSMapEdit allows a setting of 26 bits, but the cgpsmapper manual stops at 24 bits).
Are they still jaggy when you zoom in close? It looks like you might be seeing multiple levels of objects superimposed. I've seen this before, but it's not common.
Quote from: Seldom on April 29, 2013, 01:10:28 PM
Are they still jaggy when you zoom in close? It looks like you might be seeing multiple levels of objects superimposed. I've seen this before, but it's not common.
I think the problem is the opposite of what you're suggesting. While zooming in closer and closer, I noticed that the MapSource scale said "overzoom". I then backed out until the "overzoom" message disappeared. That occurs when the scalebar is .7 miles. For the NM Topo Maps, overzoom occurs at 300 ft. Apparently my map is being written at too coarse a level. As noted above, I've set the zoom level 0 to 26 bits (in a text editor).
Could TreSize have anything to do with it? I set it to 1000, based on the cgpsmapper manual. RgnLimit is set to 1024 as the manual states.
Positions to the 24 bit level was as detailed as the Garmin GPSrs supported when the cgpsmapper software was created. Do the newer GPSrs support coordinate positions to the 26 bit level?
What bit level for coordinates means is 360 arc degrees divided by 2 raised to the bit level power, i.e. 360/2^24 or about 7.8 feet (2.4 meters) at the equator. Coordinates are snapped to' this valid coordinated grid. Positions at the 16 bit level will be 'snapped to' a valid coordinated on a grid with 2003.9 foot spacing (at the equator); hence, the very jagged/blocky lines you have observed.
POI's and points have 0xnnnn format, lines and areas have 0xnn format.
As the cgpsmapper manual states, some things just do not work as expected and you have to use 'trial and error' methods.
Some type codes seam to be 'fixed' in the GPSr units and will display as Garmin intends and ignore what is in a custom type file.
Worse still, some type codes will display differently on different Garmin models.
Cgpsmapper doesn't support level=26, should be maximum 24. Your map looks like much less then 24 and ovezoom scale depends on Level0 value.
@seldom: I think Mapsorce displays railways correctly but GPS doesn't show them above some scale, it could be like max 120m.
I originally had the map laid out at levels 24, 20, 18, 16. When it looked jaggy I tried upping the 24 to 26 (which GPSMapEdit seems willing to support, even if it's wrong). Didn't help. After your comment, I set the 0 level back to 24 and changed the others to 22, 20, and 16. The jaggies are pretty much gone.
The only remaining issue is the tool-tips on polygons. The mouse over text is "unknown area", not the string I entered in TypWiz. I'm using types 0x5100 and 0x5200. With the default types, these appear as wetlands and tundra, and tool tips work. With my custom .typ file, the polygons are painted, but no tool tips.
Here's what the .typ entries look like in text format (minus the bitmap)
[_polygon]
Type=0x5100
;421 DBlk:&4CF
String1=0x00,Private Land
String2=0x04,Private Land
;polygon type: 8
ExtendedLabels=N
Xpm="32 32 2 1"
"0 c #FF6F6F"
"1 c #000000"
....
[end]
[_polygon]
Type=0x5200
ExtendedLabels=N
String1=0x00,Camping
String2=0x04,Camping
Xpm="32 32 2 1"
"0 c #00FF40"
"1 c #000000"
...
[end]
Isn't it a label that you have defined in mp sources?
Quote from: popej on April 30, 2013, 02:02:13 AM
Isn't it a label that you have defined in mp sources?
As I understand it, labels are per-object, eg, some polygon is Yosemite National Park, a polygon of type 0x14. If there is no label, then the type name is displayed. This is how it works for the default Garmin types. Based on a suggestion by the author of TypWiz (who is really supportive, so make your donation if you're using the program!), I went ahead and loaded my map onto my GPS (map76csx) and indeed the type names appear when I mouse over them, as expected. Why this doesn't work in MapSource is a mystery, but then all kinds of MapSource behavior is a mystery. Garmin seems to make pretty decent hardware (it sure is popular enough), but their software design and implementation leave something to be desired, to put it charitably.
So, bottom line is that all the problems related to this mapset seem to be solved.
This "unknown area" is a mystery for me too, so I'm trying to imagine any possible reason for it. One is that you somehow put this text into source of your map.
Other possibility is to define polygon of selected type (for example 0x13), set no definition for this area in TYP file and no label in source. Is it possible, that you have this polygon?
General rule is, that if object has label, then it should be displayed. If there is no label, then definition in TYP file can be displayed. If this is missing too, then default type of object should be visible as label. And for area 0x50 this is "woods".