Welcome, Guest. Please login or register.

Login with username, password and session length
Forums Search:  


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - glendeni

Pages: 1 [2] 3 4 ... 6
16
Map Making Support / Re: MP format Zoom# parameter
« on: November 11, 2016, 10:42:19 AM »
Since I've been running a bazillion variant runs lately, so now have a relatively quick testing process, I decided to run a test of the "Zoom#=" parameter.  My test run compiles two different .mp file using mkgmap to create two separate .IMG files, then again uses mkgmap to combines those files into a gmapsupp file.  The first file always had Levels=5 with "Zoom0=0 ... Zoom4=4".  The second file always had Levels=4  with 2 cases (A) "Zoom0=0 ... Zoom3=3" and (B) "Zoom0=1 ... Zoom3=4".  I could not see any difference whatsoever between the two cases with differing Zoom# parameters.

Jack

17
Map Making Support / MP format Zoom# parameter
« on: November 08, 2016, 12:23:27 PM »
I noticed that some of my .mp files have
  Levels=4
  ...
  Zoom0=1
  Zoom1=2
  Zoom2=3
  Zoom3=4
whereas some others have
  Levels=5
  ...
  Zoom0=0
  Zoom1=1
  Zoom2=2
  Zoom3=3
  Zoom4=4
The history of those is lost to me so I was trying to understand what the "Zoom#="
parameter does.

Reading the cgpsmapper manual, "Level#=" and the difference between "Hardware" and "Map" zoom levels are thoroughly explained. But all I can find for "Zoom#=" is "Refer to Section 4.4" - yet that section discusses "Level#=" but nowhere mentions "Zoom#="!  There is a later use of
  Zoom0=0
  Zoom1=1
  ..
  Zoom4=4
in an example - but that it all I can find!

I'm surprised that this seems an omission from the otherwise remarkably detailed descriptions in the manual.  Does anyone know what "Zoom#=" is supposed to do? Might this be an obsoleted parameter?

Jack

18
Map Making Support / cGpsMapper Manual
« on: November 07, 2016, 01:42:38 PM »
The cGpsMapper manual is an invaluable resource for those constructing or editing .mp ("Polish format") mapping files but the links I found all pointed to the cgpsmapper.com server which seems no longer available.   Finally I found an archived version which greatly helped me, so for others having problems accessing the manual a "wayback machine" link is

https://web.archive.org/web/20160729043418/http://cgpsmapper.com/manual.htm

Jack

19
Map Making Support / Re: Adding a single polygon
« on: November 07, 2016, 10:30:54 AM »
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

20
Map Making Support / Re: Adding a single polygon
« on: November 07, 2016, 10:12:06 AM »
Thanks for info.  My polygon uses Type=0x07 which Garmin uses for "Airport" (but there are no airports in my map's domain).  Jack

21
Map Making Support / Re: Adding a single polygon
« on: November 07, 2016, 09:20:23 AM »
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

22
Map Making Support / Re: Adding a single polygon
« on: November 07, 2016, 12:17:11 AM »
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

23
Map Making Support / Re: Adding a single polygon
« on: November 05, 2016, 12:02:29 PM »
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

24
Map Making Support / Adding a single polygon
« on: November 04, 2016, 01:18:51 PM »
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

25
Map Making Support / Re: packaging gmapi/gmap folder for Mac
« on: January 11, 2015, 10:12:24 AM »
Currently my users have the choice of downloading either a PC executable or a gmap format file.  FWIW, last week (excluding bots and multiple downloads from the same IP) there were 3 PC executable downloads and 7 gmap downloads (Apple Safari browser downloads accounted for 5 of the latter).  I've put instructions for the gmap install for both PC and Mac on the download webpage - so far no one has asked for any more help on my forum.

Jack

PS:  the ratio of executable vs gmap downloads is likely skewed in favor  of the latter since I announced the new gmap on my home page, so Mac users likely have taken advantage of that new availability

26
Map Making Support / Re: packaging gmapi/gmap folder for Mac
« on: January 04, 2015, 04:13:48 AM »
I found a link where a "gmap" file (folder) is input to Garmin MapManager on a Mac - so apparently that software knows how to utilize both gmapi and gmap folders.
  http://www.openfietsmap.nl/installation

For giggles, I decided to see what would happen if I placed a "gmapi" folder on the Garmin/Maps directory on my Windows PC.  It was not recognized by MapSource - so the "gmap" folder must be placed there.

Jack

27
Map Making Support / Re: packaging gmapi/gmap folder for Mac
« on: January 03, 2015, 04:13:14 PM »
That triggers a memory, that I have set up my Windows display to show the "extension" - but since I do see the full filename I tend to forget that other Windows users will only see a partial name. 

28
Map Making Support / Re: packaging gmapi/gmap folder for Mac
« on: January 03, 2015, 02:36:08 PM »
Thanks for that enlightenment.  One problem I think I have is that as a Linux person I think of the file "name" as including a "zip" tail ala  myfile.zip whereas sometimes Windows omits that  tail in reporting a filename - and I don't know how a Mac reports such filenames.

After looking at some "gmapi" files I found online, they appear to be zip files created from a gmapi directory which has a gmap subdirectory. - a file I would give a filename  like "MyMap.gmapi.zip"   So "unzipping" file "MyMap.gmapi.zip" produces a "MyMap.gmapi" directory with a "MyMap.gmap" subdirectory.

But from what you say, I should be able to create a "MyMap.gmap.zip" file which will unzip to create a "MyMap.gmap" directory with subfiles.  I will try that until my Mac users report that does not work for them.  I have no difficulty creating instructions which will work for such a file on a Windows machine but won't be able to test the instructions I supply for a Mac user.

Jack

29
Map Making Support / Re: packaging gmapi/gmap folder for Mac
« on: January 03, 2015, 01:42:24 PM »
OK, thanks for the info.  I was going to try installing Garmin MapConverter on my PC so I could look at the structure of the file it was creating - but that fails to install for me!  Think I will just have to make my best guess of what the structure of the gmapi file should be and let my users let me know if that works or not.

Jack

30
Map Making Support / Re: packaging gmapi/gmap folder for Mac
« on: January 03, 2015, 12:56:42 PM »
Yet again - I now get the feeling that for a Mac I should be zipping the "gmap" directory but then _naming_ it with a "gmapi"  as a tail on the filename ala "BigSurTrailmap.gmapi" where that is a zip file of the gmap directory.

I am getting myself confused!  (Partly because in the python-script I run to create the gmap files, those are created in a BigSurTrailmap.gmap directory which is below a BigSurTrailmap.gmapi directory - so using that last name as a zip file name would require some fancy footwork to avoid a name conflict.) 

I am used to a zip file always having a .zip tail in the filename but this would be a case where that is not so (but now that I think of it, a GoogleEarth kmz file is really just a zip file - so that would be another example.)

Jack

Pages: 1 [2] 3 4 ... 6