Messages

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

Just realized I'd forgotten one important thing I don't understand, which might be a difference between Windows and a Mac. 

On a Windows PC if I supply a zipped gmapi directory, then double clicking exposes the gmapi directory inside and I must further extract the gmap directory it contains.  IE on Windows one really needs the gmap directory, not the gmapi one.  So if I was supplying a file only for Windows, I'd want to zip the gmap directory not the gmapi one to make things easiest

But if I understand correctly, the Mac needs the gmapi one, so for it I must zip the gmapi one, not the gmap directory.

Jack

PS: does MapManager require any input or instructions - or are things completely automatic at that point?

Thanks.  I gather that in _both_ cases "click" should be "double-click".

Jack

So if I supply a gmapi folder as a .zip file, then would the following instructions work:

"click on the downloaded "Univeral Garmin File", a .zip format file, to extract the gmapi folder it contains, then click on that to run the MapManager (which should automatically appear if BaseCamp is installed)"

Jack

Boyd

No, I'd not seen that thread (it comes up as number 11 on a search on "nsis" and I'd not looked into it).  Thanks - as you say, that gives a lot of information (and answers some questions I'd had in my initial post).

I _have_ been able to create "gmapi" files on my Linux box and now plan to provide them to my users in addition to, not replacing, the current Windows registry installation executable.  My idea is that they will be an "alternate" source for Mac users or others who are unable or don't want to use the Windows registry installation.  My expectation is that they will know basic computer procedures (file move/copy and possibly "unzip") and be able to follow some basic instructions I provide, so an installation script will not be needed. I've described the above in a new post so as not to distract from this thread, which I expect will be discussion of the current Windows registry installation script and whether it is causing problems.

Jack

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

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 Expand

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

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 Expand


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

Boyd

Thanks for those details.  My work was all done Sept-Dec 2012, after the forum discussions I found in Feb-Mar 2010 and using the "new" .nsi template.  So I'm going to begin a new thread on the Map Making Support forum to see what others with more knowledge than I might think about this.

Jack

I just noticed this thread after hearing that a new install of BaseCamp on a Windows 7 machine did not seem to recognize the installation of the map I provide, even though it works for me in my BaseCamp on a Windows 7 machine.  The installation program I'm using is nsis-2.46 - is that an "older" installer referenced?  Do you have a link describing this problem and how a newer installer might be used?

Jack

Ok, will try elsewhere

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) ??

I did not know it was possible to create a MapSource file using cpreview so had been using a GUI program.  But bottom line for me is that I cannot use cGPSmapper since it is broken for my .mp file, as described in my original post.

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..