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.


Topics - glendeni

Pages: [1] 2
1
Map Making Support / POI type affects GPS "Find"
« on: January 05, 2018, 11:59:33 AM »
I've noticed on my GPS64 load of my custom map that POIs with some types (eg: 0x5201, 0x6619) are found by a "FIND" of both "All POIs" & "Geographic Points (All Categories)" but other types (eg: 0x641c,0x6701) are found only in "Geographic Points (All Categories)" - not by "All POIs". (All types are displayed on the map.) Could not find anything in cGPSmapper User Manual addressing this. 

Anyone know what determines what Type is NOT found by  "All POIs" ??  My guess is that Garmin has some list of "known" POIs (eg those listed in cGPSmapper User Manual, but with others subsequently added by Garmin) and only those will be included in "All POIs" - but that's just a guess. (In my custom map I've purposely tried _not_ to use a "known" type since none of the Garmin descriptions match what the icon is supposed to represent - but I may now need to change that.)

2
I've been using version r2314 of mkgmap (which uses Java6) for my MP compiles.  But I'd been having some problems, so installed the latest mkgmap version, r3759 (which uses Java8), thinking there might be a bug in the older version which had been corrected.

I was surprised to note that img files produced from a contour-line MP were 20% smaller than their r2314-produced counterparts, but could see no difference between their IMG maps  when loaded to my GPS.  But then when I tried to install the EXE version into BaseCamp, BaseCamp rejected it and asked that it be "re-installed" - which I tried again but with the same failure.  Going back to r2314 solved that problem

I should note that I'd previously incorporated some r3759 compiles (for streams) without any difficulty. It was only when I tried using it for contour line files that the problem occurred. But since I can't have confidence in r3759, I've have gone back to using r2314 for all my MP compiles.

3
Map Making Support / Polygon renders differently on GPSMAP64 and etrex30
« on: January 18, 2017, 07:41:19 PM »
I've produced a map which renders differently on my GPSMAP64 and etrex30. Specifially, I've produced an .IMG file which when placed in the "Garmin" directory of the GPSMAP64 renders "correctly", with contour lines displaying above a polygon.  But when loaded onto the etrex30 the polygon is rendered _above_ the contour lines, so they cannot be seen.

That map was created by combining separate IMG files for the contours, polygon, and etc. I also used those to produce a Windows .EXE file which when in installed into the Windows registry displays correctly in BaseCamp.  But when BaseCamp then installs the file to the GPS, again on the etrex30 the polygon is rendered above the contour lines.

I couldn't find any reference in previous postings to such behavior.  Has anyone else seen disparities between the two platforms ?

4
Map Making Support / Loading via BaseCamp fails
« on: January 17, 2017, 11:43:05 AM »
After hearing from a user of my Garmin map that BaseCamp had failed to load it into her etrex, I tried the same using my Windows BaseCamp and got "There is a problem with your Big Sur Trailmap installation.  Re-install the product and try again."  Of course, re-installation gave the same result.  My map is complex, with cgsmapper compiles (of contours and streams), with mkgmap compiles (of trails, boundaries, and other data), and with TYP files - and it routable.  I use  NSI to produce an installation file which does install and display correctly in my BaseCamp (and is routable there).  Many years ago, when first creating the map, I was able to successfully install the map to my GPS using BaseCamp.  But since then my usual procedure has been to install the map by simply writing the corresponding IMG file to the GPS Garmin directory, not installing via MapSource (since updating MapSource is a slow procedure).

There have been considerable changes from the initial map (e.g. inclusion of a wildfire polygon) and I don't know at what point the BaseCamp problem developed.  The error message is obviously not helpful.  The only way I can think of trying to solve this is by successively removing elements from the map (e.g. first the wildfire polygon, then the trails, then the contours, ...) until it works. That would be very time consuming and I'm don't think I can devote that time.  Still, I want to make a quick attempt at finding a solution.  So my question is: is there some method (e.g. a software package) of testing the installation executable, one which would provide more useful error messages?

And if anyone has advice on how to best proceed in ferreting out the problem, I would love to hear it!

Jack

5
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

6
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

7
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

8
Map Making Support / packaging gmapi/gmap folder for Mac
« on: January 03, 2015, 09:40:54 AM »
I'm now creating "universal" Garmin "gmapi" map files which can be used to install maps on both Windows and Mac machines.  My current plan is to offer both a "registry" installation version of my maps for Windows users and the "gmapi" files for Mac users or others who might have a problem with the "registry" installation.   I'm going to assume that any gmapi users will have enough knowledge to do basic computer operations such as a "copy" (and possibly "unzip"), so will not need an installation script - but don't know what would be the most "convenient" form for them to use.

I've tested gmapi use on a Windows PC but am unsure how they should be used (and hence packaged) for a Mac.  Since I don't have one and can't test that, I'm looking for some guidance here.

"gmapi" creation produces a gmapi directory with a gmap subdirectory which contains the map files actually used.  On a Windows machine, the "gmap" subdirectory is utilized, not the "gmapi" one, being placed under an OS-dependent folder such as C:\ProgramData\Garmin\Maps.

Based on the thread http://forums.gpsfiledepot.com/index.php?topic=2383 I believe that for a Mac I should provide the "gmapi" directory (not its "gmap" subdirectory) as either a .zip or .tgz file.  Can someone who uses a Mac enlighten me on this?

Jack

9
Map Making Support / universal Garmin gmapi map creation on Linux box
« on: January 03, 2015, 09:25:26 AM »
I've now successfully created "universal" Garmin "gmapi" map files on a Linux box and wanted to document the procedure here for others as there were a few glitches I had to solve. Most people here use Windows based proceures,  so I wanted to document a successful Linux process.

Background: this will only work for .img files produced by the OSM mkgmap compiler, not for .img files produced by cgpsmapper (which I did test).  I'm assuming here that someone is already familiar with the mkgmap compiler and has already used it to create .img and .tdb files (and routing .mdx/mdr.img  files if desired).

() On Linux box, you can produce a "gmapi" directory containing a "gmap" subdirectory which contains map data usable with BaseCamp on Windows PC (7-64bit tested) and OS-X Mac (untested) by  using the OSM program gmapi-builder.py . A link to an older version with instructions is   http://wiki.openstreetmap.org/wiki/Gmapibuilder  - but there is a newer version can also utilize styling .TYP and/or routing .mdx/mdr.img files and it is hard to find so I've uploaded it as an attachment below.

() Put all the files in subdirectory, say "tiles", then run command
   
Code: [Select]
gmapi-builder.py -v -t tiles/MyMap.tdb -b tiles/MyMap.img -s tiles/STYLES.TYP -i tiles/MyMap.mdx -m tiles/MyMap_mdr.img tiles/*img       where "MyMap.img" is "background" map name or number
       and the last argument can be multiple, such that all needed .img files (i.e. basemap, routing, etc) are included
       Optional arguments -s/-i/-m are only needed as appropriate for processing .TYP and .mdx/mdr.img files
       and I've included optional "-v" flag for more verbose output

() This creates directory MyMap.gmapi which has a subdirectory MyMap.gmap.  The latter should be installed on PC under a folder which varies with the OS.  The following should work
         for Windows XP: "C:\Documents and Settings\All Users\Application Data" folder (untested)
         for Vista and Windows 7: "C:\ProgramData\Garmin\Maps" folder (tested)
         for a Mac - am unsure as to how the files should be provided, but I think one can create a .zip or .tgz file of the gmapi directory and a Mac can open those for automatic installation

() The script does give a worrisome "Unknown Block: ..." message.  This has also been reported by others.  But no one has yet reported finding any resulting problem (and neither can I). Note: one message which does indicate an error is "Missing part:  ... in IMG-file", which occurs when a .img file is not readable (likely not created by mkgmap)

() I've tested WITH a styling TYP file and WITH routing files and WITH contour+stream .img files overlaid on a background map.  Everything (including routing) worked for me on a Windows 7 64-bit BaseCamp.  So all seems good

Jack

10
Map Making Support / Registry problems with NEW nsis .nsi template ?
« on: January 02, 2015, 12:58:15 PM »
I'm looking for guidance on how to proceed after failing to resolve a problem encountered by a user of my maps.  Hopefully I'll get some wisdom from those better versed than I in the installation of a map into a PC for BaseCamp use.

The story so far:

() User with a new PC with Windows 7 64-bit first installed BaseCamp, then tried to install one of my maps.  He successfully followed the nsis installer procedure, with no apparent error, but the map did _not_ appear in BaseCamp.  It _did_ appear in the ControlPanel "Programs and Features" display.

() He was able to fix this by following the procedure described in thread http://forums.gpsfiledepot.com/index.php?topic=3794.0 - namely, downloading and installing the "MyTrails" map, then installing my map, then uninstalling the "MyTrails" map.

() That might seem to point to a problem created by use of a "older" installation script, as mentioned in that forum post. "Older" seems to mean prior to Dec 2011, namely the changes I found discussed in the Feb-Mar 2010 forum thread  http://forums.gpsfiledepot.com/index.php?topic=1022.0

() However, all my development work was done between Sept-Dec 2012.  As such, I used the then current NSIS version (2.46, currently still the latest v2) and the "new" installation script template available at that time.

() Comparing my current .nsi script to the current template .nsi file I can see no notable differences, only differences relevant to my specific maps.  (And there is NOT any reference to a Registry.nsh file anywhere, which was apparently one source of difficulty in the 2010 thread).  Looking at the "Write the MapSource configuration into the registry" section, the only difference is that in my version the following lines are used, not "commented-out" as in the template
Code: [Select]
WriteRegStr   HKLM "SOFTWARE\$OS_EXTRAGarmin\MapSource\Families\${MAP_SHORT_NAME}"   "IDX"   "$INSTDIR\${MAP_SHORT_NAME}.mdx"
 WriteRegStr   HKLM "SOFTWARE\$OS_EXTRAGarmin\MapSource\Families\${MAP_SHORT_NAME}"   "TYP"   "$INSTDIR\${MAP_TYPE}.typ"     ; only if using custom type

These lines were uncommented since I  do use TYP and MDX files.

() At the risk of introducing a red herring, I should mention that I'm creating the installation executable (and the .IMG files to be loaded into the GPS) and so running the NSIS creation script on a Linux box, not a Windows PC.  But prior to this there has been no reported problem.  (I myself also use a Windows 7 64-bit PC and have been able to install, uninstall, and re-install my map on my PC without difficulty - but have not tried a clean install of BaseCamp, since I have multiple installed maps which I would not want to recreate).  I run on a Linux box because I have a batch script which is run automatically each week to update the map with any current changes to the trail system - and has been doing so since Jan 2013.

() So next, I should ... ???

Jack

My current installation executable:
http://bigsurtrailmap.net/TRAILMAP/GARMIN/ROUTABLE/MEDIUM/BigSurTrailmapWithTopo_install.exe

I've added an attachment with my .nsi file

11
Map Making Support / TYP file for Topo24K ?
« on: August 13, 2013, 09:09:27 AM »
I'm trying to eliminate the green background (indicating Park/NationalForest/etc) from my Garmin Topo24K maps, so the contour lines will be more easily visible.  I don't need to be told that I'm in a Park/NF/etc when I hike - ALL the places I hike have a green background!  I know that TYP files can be used to alter the treatment of polygons, which I believe are used to generate the background, so I want to make those transparent.  I'm used to editing TYP files, as I've done that in creating my own (routable) maps.

But I can't see where any TYP file is being used with Topo24K.  30 minutes of googling has not producing anything useful.  So I'm hoping someone here has some info on how to do this.

A specific question: I can use GPSmapedit to determine the hextypes of the polygons on the maps.  Is it possible to simply create a TYP file with all those polygon types set to transparent and then load that onto my GPSMAP 62 (assuming I can figure out the family ID of the Topo24K files) ??

12
Map Making Support / Automation of routable maps
« on: January 27, 2013, 11:14:25 AM »
I want to note that I've found that it possible to automate the process of creating routable Garmin-format map files (both an .img file for direct GPS installation and a Windows-executable for MapSource installation) by using the OSM compiler.  And in particular it is possible to do this on a Linux box.  This may encourage others to do likewise.

Previously I'd been producing the Garmin-format files by having to manually run several different programs on a Windows box (namely cGPSmapper, GMapTool, MapSetToolkit, and NSIS) and since several of those are GUI based automation was not possible.  I actually got started using the OSM compiler because for some reason my latest .mp file produces a Windows "Access Violation" error with cGPSmapper (it was working fine until a month ago), but runs ok with the OSM compiler.  I then discovered that both the OSM compiler and NSIS will work on a Linux box, and with a little more (OK, actually a lot more) work I could automate the complete process.  Since I produce 9 different Garmin-format map files (I have variants which provide 3 different icon/line size options for the user, and "with topo" and "sans topo" versions), doing this manually was a pain in the butt so I found myself doing the updating only every 3-4 months.

For my "Big Sur Trail Map" (http://bigsurtrailmap.net) I use GPX data to create multiple map formats: an on-line browser-displayable map, a Google-Earth-format file for downloading, printable PDF maps, and the aforementioned Garmin-format files.  Now I simply have to make a change in the GPX line or point file and the result is propagated into all the maps (nightly for the on-line and Google-Earth maps, weekly for the PDF and Garmin maps).  Changes are needed surprisingly often, since I continue to find unofficial "use trails", the official trails get created and/or re-routed, etc..

13
Map Making Support / Making labels invisible
« on: August 06, 2012, 08:40:33 AM »
I've spent a frustrating day trying to make some icon labels invisible using a TYP file before finally stumbling on a solution, so am posting my result here so that others will hopefully not have to go through the same experience (googling "TYP hidden labels" did not produce anything helpful to me).

Why did it take so long?  I went through many, many tests, all needing to going through creation of a MapSource installtion, including

() using the "on line" TYP editor - after checking "extended labels", changing the icon and font color DID work, but changing the "Font Style" was NOT having any effect

() using TypWiz3
I input
  ExtendedLabels=Y
  FontStyle=NoLabel (invisible)
but later tried re-inputting the TYP file created and found that TypWix had substituted "Default" for its FontStyle without any notice to me!  It took quite awhile for me to discover that the value I thought I was specifying was not actually being used!
(I also tried variants such as just "Nolabel" with the same results.)

() altering the .mp file's  "Lblcoding" values

The solution?  Like the proverbial millions of monkeys typing to accidentally create a line of Shakespeare, I found that when using the on-line TYP editor if, with "extended labels" checked, I changed "Custom Colors" from its default "no custom colors" to "custom day color" then the text DID become invisible. (The custom day color actually specified could apparently have any value.)

14
Map Making Support / Abnormal termination of cpreview.
« on: August 03, 2012, 03:25:14 PM »
I'd previously reported getting "cpreview.exe has stopped executing" messages on my Windows 7 PC, with abnormal cpreview termination so, most notably, a _MDR.IMG file was not being created.  I finally tracked down the cause so am reporting it here in case anyone else encounters the same problem, which was certainly mysterious to me.

I'd been running MapSetToolKit to create MapSource installation files from 13 .IMG files in 3 different subdirectories.  After that process, IMG files with the same names appeared in the MapSource installation directory.  I assumed that they were simply copies of the original files (the file sizes were the same, to the precision reported by Windows Explorer) used in the MS installation process.  I now realize the abnormal terminations must have been on those runs when I had, for whatever reason, closed MapSetToolKit and since it does not remember the last parameters input to it, "for convenience" I was simply selected those files since they were all in a single directory.  But there must actually be some difference between those files and the original IMG files of the same name, because testing now shows that cpreview abnormal termination always occurs if I use those files but not if I use the original files.

FWIW I tried to look into this in more detail by using a script to run cpreview.exe and pipe stdout and stderr into files - but that gave no insight since cpreview indeed stops executing, as Windows 7 reports, so no stdout or stderr is generated. But at least I now know the reason for the problem.  For me it had been confusing since it was seemingly occurring with files which I had previously run without a problem.

15
Map Making Support / IMG efficiency question
« on: July 31, 2012, 03:50:58 PM »
I have 10 .img files containing topo data for different regions, 2 .img files containing steam data, and 1 .img file containing trail data.  I expect to be frequently updating the trail data whereas the topo and stream data will be static.  Currently I create an overall IMG file for MapSouce using all 13 files as input to MapsetToolkit but it would be more convenient to combine the static topo and stream data into a single .img file so that I only have to worry about two .img files when using MapsetToolkit.

I can combine the topo, for example, by generating a .mp file from each of the regional .img files, combining these into a single .mp file and generating a single .img topo file. I've already tried this - the compilation took 3 hours on my i5 processor but it did work.  But I've started wondering about the useage efficiency of using such a large single .img file instead of 10 smaller files.  Does anyone know whether using such a .img file will result in less efficient use either in MapSource or the GPS?

(As an alternative I've considered using the "Join" functionality of GmapTool to combine the 10 regional topo file, but I don't know exactly what that does.  Perhaps using GmapTool's "Join" would create a single .img file but within that file the 10 regional files would still be separate??)

Pages: [1] 2