GPSFileDepot.com
 

News:

Welcome to GPSFileDepot!

Main Menu

Adding a single polygon

Started by glendeni, November 04, 2016, 02:18:51 PM

Previous topic - Next topic

glendeni

I provide trail maps for Big Sur hikers (http://bigsurtrailmap.net), since many printed maps have errors and most don't include "unofficial" trails known to local hikers.  Besides on-line and printable maps, I provide a routable Garmin map for GPS users.

I originally setup the Garmin map in 2012 and created scripts such that later trail changes were automatically replicated in an weekly-updated Garmin map - so much of that 2012 knowledge is now lost to my aging (71yo) memory.  But a recent wildfire (you may have heard about it, the most costly one in US history so far) has greatly impacted many trails - so displaying the burnt area has become important. I've now done that for the on-line and printable maps but am having difficulty doing so for the Garmin map.

I am trying to add a single polygon of the burnt area as _simply_ as possible since it will only be temporary, likely removed in about 2 years when the land has recovered somewhat and trail crews (almost all volunteer - I'm also a trailworker) have had a chance to do some work.  I've _almost_ got this to work, but my current knowledge seems insufficient despite trying to refresh it via on-line searchs. A particular problem is being unable to find any manual giving the MP format specifications, since website cgpsmapper.com is no longer on-line.

By "almost" working I mean that I have created a new TYP file and IMG file (compiled from a MP file using OSM mkgmap) which I can display in GPSMapEdit with a pink polygon displayed below the existing trails+contour+stream lines and camp+poi icons.  But two problems are:
(1) the polygon is only displayed at "Level 0", not at higher levels and I would like it displayed to level 2
(2) when the IMG file is transferred to my GPSMAP64 the polygon does not appear at _any_ zoom level.

Things which may be applicable:
() the TYP polygon is created with _no_ draw order
   (but trying a draw order of 9 gave no change)
() the "polygon" MP file contains:
     [IMG ID]
     CodePage=1252
     ID=...
     Name=SoberanesWildfire
     Preprocess=F
     TreSize=396
     TreMargin=0.00000
     RgnLimit=1024
     Transparent=Y
     Copyright=
     Levels=5
     Level0=24
     Level1=21
     Level2=18
     Level3=17
     Level4=16
     Zoom0=0
     Zoom1=1
     Zoom2=2
     Zoom3=3
     Zoom4=4
     [END-IMG ID]
     [POLYGON]
     Type=0x71
     EndLevel=2
     Data0=(36.501664,-121.896562),...
     [END]
() a "polygon" IMG is created from the "polygon" MP file using mkgmap with "--transparent"
() the "trailmap" IMG is created by adding the "polygon" IMG to the other (trail,contour,stream) IMG files in a mkgmap run

Any insight would be appreciated.  I assume something needs to be changed in my "polygon" MP file but my testing some alternative MP versions has not produced anything better.

Jack

popej

I think you got multiple problems.

First is that not all polygon types are usable. I don't think type 0x71 is visible in Garmin devices. You should try other value, for example 0x10f00. And you can try TypViewr:
https://sites.google.com/site/sherco40/

This program allows for editing TYP file and as a bonus it shows a list of standard Garmin types for all objects.

Next is that polygon without draw order in TYP file won't be displayed at all. If you don't see it with draw order 9, then it is because of first problem.

Next is that transparent map is not for polygons. I even don't remember what happens to polygons on transparent map (maybe they cover objects form non-transparent map?). Usually you do it the other way around - non-transparent map with polygons and transparent map with tracks, contours or other lines.

Just a thought: if you want a polygons on transparent map, then maybe create graphics for them as semi-transparent pattern?

eaparks

#2
popej, Maybe there is something I'm missing in your comment, "Next is that transparent map is not for polygons. I even don't remember what happens to polygons on transparent map (maybe they cover objects form non-transparent map?). Usually you do it the other way around - non-transparent map with polygons and transparent map with tracks, contours or other lines." because I'm using multiple polygons in a transparent map.  I did have to change the draw orders to make it all play together properly.

The image below is a screenshot from Mapsource of a Garmin custom vector transparent map that has 3 polygons in this particular area and 2 of the 3 are over-layed on top of the first polygon.  The lowest (1st polygon) is the green dashed lines that is a planted timber stand, the 2nd polygon at the top that is green is a food plot and this polygon is over-layed on the timber stand, and the 3rd polygon, blue area/lines, is a flooded area, and is over-layed on the timber stand.  The dashed Blue line is a polyline (stream) over-layed on the polygon and the solid Blue line is a polyline (trail) that was there before the area was flooded.  This entire map is transparent where I can enable both this map and Garmin's U.S. Topo Map and view the topo lines through all of the polygons, even the polygons over-layed on 1 another. 

I did have to do a little experimenting to see what polygons would work together to give this desired look and in setting the draw orders for everything to display properly.

The polygons I'm using are: Forest ox50 - Draw order of 2; Wetland/Swamp ox51 - Draw order of 3; and Orchard/plantation ox4e - Draw order of 4, with draw orders set and polygons customized in my .typ file.  Everything else has a Draw order of 1 or it's default draw order.

I am using the old free version of cgpsmapper from several years ago and gpsmapedit and a custom .typ file using Typviewer.


popej

Usually you use transparent map to merge data from 2 maps. For example you can use non-transparent road map and transparent overlay with contours line. This works correctly, but if you add polygons to transparent map, then results can be weird.

Here 2 merged maps as displayed by BaseCamp, rectangle areas are form transparent overlay:


And here the same file displayed in nuvi:

glendeni

Thanks to popej I got things "work" - but I use quotes because it has one significant problem.

I changed to use Type=0x07 in the polygon MP and TYP files. In the latter I also changed the draw order to 1.  And in the mkgmap compile run for the polygon IMG I removed the "--transparent" option.

I now get the desired behavior at the higher zoom (lower levels), i.e. trail, contour, and stream lines are all displayed atop a pink background inside the burn polygon area and atop a white background outside that area.

BUT: I have the map setup so when I zoom out the trail lines should remain visible but the contour and stream lines should disappear.  That does still occur.  And _within_ the lat/lon rectangle region surrounding the polygon min/max all is well, i.e. trails are displayed atop a pink background inside the polygon and atop a solid white background outside it.  But _outside_ that rectangle, trail lines are displayed atop an ugly hatched background pattern.

I don't understand where the hatched background comes from and hope someone knows what can be done to make it white.

Jack

popej

Do you test your map in GPS or Mapsource?
What you see outside of you map area could be a basemap in GPS or other active map. I guess white background is non-trnasparent cover area of img with polygons. What is outside should be other map.

glendeni

#6
Testing was done on GPS - it's tedious and time consuming but the only way to be sure of what will happen when the map is actually used on a GPS.

I don't think it's the basemap since (1) the basemap appears outside my map's border and is not hatched (2) the hatched area is new, appearing only after the addition of the polygon.  My belief is that there are "background" map problems generated by the polygon creation process.

Spending another two days on this, I did achieve partial success, producing two "almost correct" versions.  One displays the pink polygon below the trail+contour+stream lines at the lowest levels, i.e. those at which the contour+stream lines appear - but if I zoom out to the level when only the trails should appear then the polygon disappears (note: for this version no hatched area ever appears).  But since displaying the wildfire area at higher levels is important for planning purposes, I found this unacceptable.

The second result displays as above at lower zoom levels but also displays the pink polygon at the higher zoom levels, below the trails.  It's drawback is that hatched area appears outside the map's domain, obscuring the basemap below, and is ugly. But it is the best I can do and is useable.  I console myself with the fact that in 2 years I should be able to remove the wildfire polygon and get back to a non-ugly map.

Achieving the latter required a kludge, by adding 4 infinitesimally small polygons to the polygon .mp file, one polygon at each corner of the outer map region as set by all the non-polygon .mp files. (Prior to the kludge, with just the wildfire polygon, the hatched area appeared outside the rectangular region bounded the wildfire polygon, so trail lines were being displayed atop hatched area which was not acceptable - with the addition of the 4 polygons, the hatched area has been pushed further out, beyond the overall map area, and so is acceptable.)

Since it seemed like I was "close" to a non-ugly solution, i.e. having no hatching ever displayed (just as prior the polygon addition), I tried many, many different slight changes (feeling like the proverbial monkey typing for an infinite time to accidentally produce a Shakespeare masterpiece) - but to no avail.

To document this for any cognoscenti who might later be interested, historically I've been creating an Garmin IMG file by creating a trail .mp file and compiling it with mkgmap, then doing a subsequent mkgmap run which combines that img file with img files previously created for the contours and streams, to produce the final IMG.  And it worked well - no hatched area ever appeared.  For the wildfire, I created a separate .mp file which I compiled separately, then included that with the contour and stream img files for the final IMG.  My guess is that the hatched area is some "background" map problem - either
(a) one is being generated, or
(b) one is required but is _not_ being generated. 

So I've tried variants such as
(1) adding "--transparent" to the polygon compile (which caused the pink polygon to overlay and blot out the contour+stream lines),
(2) moving the polygon .mp commands into the trail or stream .mp files (the latter produced the first "almost correct" version described above)
(3) changing the "DrawPriority" of the polygon .img file to be lower than that of the other .img files (which I was surprised to find did not change the displayed map),
(4) combining _all_ the .mp commands into a single .mp file (but the compiler rejected it as being too large),
(5) using cgpsmapper instead of mkgmap to produce the polygon .img file, with several variants ala the above, e.g. different transparencies (but results were the same),
(6) altering the specified .mp file "Level"s, etc.

Bottom line is that I've exhausted my knowledge and am ready to call this a dead end.

One final thing which might be informative.  Starting with the cursor in the middle of the map, with no hash area appearing, moving the mouse horizontally causes the hashed area to appear with the boundary being at the lat/lon of the map perimeter (which is the same as the rectangle defined by the 4 corner polygons). Continuing to move the mouse outward, the hatched area grows and eventually fills the display until suddenly the basemap appears in the entire display.  So there is a sudden jump between the hash area filling the display and the basemap filling the display.  This seems to occur when the _entire_ display region is outside my map's domain - if just a small part of the display area extends into my map's region, then the entire display is hashed. (Very different from prior to adding the polygon, when there was no obvious boundary or transition between my map and the background map.)

Jack

Below is a screen shot for just a single pink wildfire polygon, showing hatching outside the rectangle around that polygon - adding 4 polygons at the map domain corners pushed the hatching outward

popej

This hatched area looks like some kind of "outside-map" indications. Could you post a sample of your map?

I assume that you design this map to be used as an overlay. I don't know if there is good solution for polygons.

glendeni

Actually no - it completely hides the basemap below.  In any case, thanks for all your help.  I would not have been able to get the useable version I now have without it.  Jack

Boyd

I had a similar problem that confused me for awhile. Finally I realized I'd used the polygon type that is reserved for defining the coverage area of the map. Sorry, my Windows machine is not accessible anymore, but there are two polygons that have a specific meaning. One of them is reserved for a background object and the other is reserved for the map coverage area. These should not be used for any other purpose.

I don't know if that could be your issue, but it will cause something very similar to happen.

glendeni

Thanks for info.  My polygon uses Type=0x07 which Garmin uses for "Airport" (but there are no airports in my map's domain).  Jack

Boyd

That shouldn't be a problem in and of itself, unless perhaps there are some polygons in your map you aren't aware of? I've been making some very complex maps that use literally every available polygon type (there are about 80 IIRC), and you can re-purpose any of them except the two I mentioned above.

But I don't make transparent maps, never found much appeal to them personally.

glendeni

Just for clarification, this is NOT a transparent map.  (I actually do produce a transparent map which displays only trails and is intended for use with some other map which displays contours, etc - but that is a separate map, and I am not attempting to add a polygon to it.)

Jack