Installer script... again

[-Oz-]

It hadn't occurred to me about people who want to install these on a different drive.  That definitely isn't possible with the new Garmin way.

As far as I can tell we will still need two files, a mac .gmapi and a windows .exe that is actually the contents of gmapi.  The .tgz is not any smaller than the .exe file because nsis compresses it.  With the new setup file I even force a better compression.

So the question is: is it worth it to start using the new script or just use the old 32-bit version which solves the basecamp issues 64bit users were having.

As far as I can tell:
PROS:
* Uses Garmin's new format
* Less messing with the registry
* Appears to have no family id conflicts (untested)
* Easy setup script

CONS:
* Doesn't work with nRoute or old MapSource
* Doesn't allow you to install to a different drive
* Solves no real problem (since 64 bit issue is solved with the old install script which I still had)

However perhaps at some point Garmin will stop supporting the registry method.

[maps4gps]

For my mapsets in the 100-200Mb range the .tgz is about 1 Mb smaller for somereason.
For CA & TX there is a 2 MB difference.

It would be very, very nice to only have to upload one version of a mapset.  It was very time consuming to upload 2 versions of 38 mapsets in May/June, especially when there is only about 1 MAC download per 8 PC downloads. 

[maps4gps]

When I first started making MAC versions, Indrid point out that the then current Mapconverter did not work and I should use the previous version.  Making a .tgz file is an option in that version.
I had DOS programs which handled .tgz and .tar files.  However, Microsoft decided that supporting older 8-bit programs in Windows 7 was not useful to most users and require purchasing a 'higher' level of Windows 7 which opens a XP window to run those programs. 

[Boyd]

Garmin hasn't updated Mapconverter for a long time. It doesn't make .tgz files anymore, but it works fine on the Mac. The only issue that I recall is that the GPSFileDepot uploader won't accept .gmapi files, only .tgz and .dmg files.

I just did some Googling, and it turns out that making a .tgz file on Windows with 7-zip is trivially simple - who knew?  Assuming you have a folder named MyMap.gmapi that was created by Mapconverter, right-click, choose 7-zip > add to archive. In 7-zip, choose Tar in the Archive Format dropdown and hit OK. This creates a file named MyMap.gmapi.tar.

Now right-click the MyMap.gmapi.tar file and choose 7-zip > add to archive again. Choose GZip from the Archive Format dropdown this time. The default filename will be MyMap.gmapi.tar.zip, so just change this to MyMap.tgz and hit OK. This creates a .tgz file that works as expected on the Mac (I just tried it). I assume that you already have 7-zip? If not: http://www.7-zip.org/

I think the new .gmap format addresses a couple issues that we see in the forums all the time. It may be true that a small number of people want to store their maps in a special place, but it seems to just confuse most people. Since they choose a location for the map, they assume that they need to "open" the .img files in that folder. When that doesn't work, their next stop is usually the tutorial for adding .img files to MapsetToolkit and now they're really lost. We see posts about this every couple days. For most users, I think it would be better not to give them a choice of where to store the maps and just use Garmin's default location. If they want the maps somewhere else, let them ask that question in the forums.

Another issue that I have seen (less frequently though) is that people sometimes just delete the .img files if they want to remove the maps. With the registry based maps, this confuses mapsource and it gives you a message about improperly installed maps and then quits. With the .gmap format, the user can just delete the folder and the maps will be gone.

I think trouble-shooting would also be easier with .gmap. If a user doesn't see the map in Mapsource, the first question would be to ask him to look in the Maps folder to see if it was properly installed.

But regardless, I can see the value to both types of maps. I am going to publish my next map in this .gmap format myself and see how it goes. I really appreciate the work Oz has done here in creating the installer, since that would have taken a LOT of trial and error for me. 

[maps4gps]

I hear you and OZ on the new method and agree that the benifits outway staying with the older method.

Also some users cause problems by moving a mapset after it was installed - they may get the idea of being able to put a mapset anywhere when they see that option during install and do not realize the registry also needs to be changed.

[-Oz-]

I've updated a lot of my maps to the old installer script so they won't have the 64 bit issue.  My Florida Topo is using the new gmap install process so we'll see if I get any complaints.  I'm going to add some IF statements and then release the scripts on the actual website. I want to make it so if NSIS doesn't see the left side graphic or icons it won't "break".

[Seldom]

Just tried the installer and it worked fine for me, uninstalled my old FL Topo and everything.
System is Win7-64 w/ 16GB RAM.  Is the new script ready for distribution?  If not, when can we expect it?  And will it support address search (Find Places in MapSource)?

[Boyd]

And will one format be able to be used on both the PC and MAC?

Just realized that it should be very easy to create a universal download package. I believe it will only require one small change to Oz's script... don't have time to look now but will try to get to it tonight.

Instead of embedding the .gmapi file in the NISIS script, it would need to be accessed as an external file. So the universal download would be a zipped folder named for your map, such as MissouriTopo.zip. Inside the folder would be the .gmapi file, named MacInstall.gmapi and the NISIS script file named WinInstall.exe.

A Mac user would doubleclick MacInstall.gmapi which automatically launches Garmin Mapmanager and installs the map. A Windows user would double-click WinInstall.exe which would run the NSIS script, read the map from MacInstall.gmapi and install.

Thoughts?

[jbensman]

I can understand using this process for most maps on this site.  However, from my understanding of what would be required, there is no way I would use it for any of my maps-particularly My Trails.  If you make the mapset once, no big deal, but if it is a mapset that is regulalry updated, it makes things way to hard.  While I update the installer for my trails about once a month, I update it several times a week on my computer.  So first I would have to create the imgs, use mapsettoolkit, use mapconverter, uninstal the first version, create the installer, uninstall the gmapi version, then reinstall the imgs.  To be able to constantly update My Trails, it has to be imgs.  If there was a way to directly create gmapi files, that would be one thing.  But I need to have my maps as imgs on my system. 

[Boyd]

I don't see why this changes anything. You need to have a "classic" map installed on your own computer anyway (using Mapsettoolkit). So you would keep that as your working copy and make all your updates there. Then when you are ready to upload, you'd make the .gmapi version. And I don't think that really involves any extra work as long as you're making a Mac version, since you need to run Mapconverter for that anyway.

And the payoff would be you only need to do one upload because it would work on both platforms, so you cut your upload time in half and Oz only needs to store half as much data on his servers.

[jbensman]

Will this installer automaticy uninstall the older version of My Trails already installed?

So I would just keep doing things the same way on my computer with the img files.  When I am ready to make an updated installer, I would run the macconverter and the new install script?  That's all I would have to do?  If so, that does not sound bad.  I thought I would have to uninstall and reinstall the img version.

[Boyd]

Oz added an uninstaller for previous versions (read back a bit in this thread). I think the only issue is that the .gmapi version is going to have the same FID as your working version. So it would be best not to install both on the same computer or you would need to change the FID of your working copy to avoid a conflict (I assume there would be a conflict but haven't actually tested that myself).

[maps4gps]

That would be great to be uploading the .img files only once.

[Seldom]

Is this installer script available for download (with instructions)?  I'd like to try it out on my routable maps.  Address search gets lost when I use OZ's old NSIS script.

Also, do I describe the workflow correctly below?

Compile the IMG files with cgpsmapper and install the map on my PC.
Run MapConverter to create a MAC compatible file.
Run an NSIS on the MAC compatible file to create a combined file.
Test the installer (this should uninstall the original IMG based map).

Why would I want to have both versions of the map installed on my machine at the same time?  Therefore, why would I need to change the FID on the original IMG based map?

[Boyd]

I believe Oz's most recent update is attached to his post here: http://forums.gpsfiledepot.com/index.php/topic,2383.msg13980.html#msg13980

I think your workflow is correct, however we need to tweak the one thing I mentioned above for this to be a "universal" solution. Oz's NSIS script embeds the .gmapi file in the installer but it needs to be an external file for Mac users to access it. I will try to look at this soon.

The only thing about the workflow you describe is that it would remove your original source .img files from your computer when you test the script. Is that what you want? For me, I want to keep all the source files in the original .img formate, so I can continue to update my map one tile at a time.

Therefore, I would not install the .gmap version on my work computer. I would create the Mac version and Windows installer, then test actually installing the map on another Windows machine so that my original files are not affected.

If I wanted to do it all on the same machine, I would first change the FID of my source version to something else, then install the .gmap version.