Loading Very Slowly?

[+Cheminer Will]

I have had as many as 20K geocaches loaded on my GPSMAP 66 in one ggz file, loaded using the GSAK Garmin Export macro.  All seemed fine with that.  Today I loaded 3 differently named ggz files to the 66 using that GSAK macro.  Ended up with 3 ggz files as expected.  One file with 22K caches, the other two files had just under 1K each. But the first time powering up after loading them the 66 took 5 to 10 minutes to slowly progress past green progress bar "loading waypoints, routes and tracks" screen.  Subsequent power on and off cycles were normal, taking only seconds to power up past that screen.  Is that normal?  If I load multiple ggz files is it going to take a long time to load them the first power on cycle?

Edited March 23, 2019 by Cheminer Will

[+Mineral2]

When using multiple GGZ files, be sure that there is no overlap in caches. Because the index database is provided in the GGZ file, a single cache having two index values can cause some issues with performance. With GPX files, this isn't an issue as only one index gets created in the internal database as the device reads the files upon startup. Do any of your GGZ files have any overlap? Is it possible to export everything you want to a single GGZ file?

[+Cheminer Will]

Yes I am sure there is some minor overlap as I was not watching for that.  And yes, I could easily combine the 3 GSAK databases for export from one common GSAK Db to have only one ggz file.  I'll try that next time.  Thanks.

[+Mineral2]

I'm not familiar with GSAK (mac user here!), but does it allow you to organize caches into folders, both manually and automatically using filters? A single database might be more efficient than separate databases for different collections of caches.

I use iCaching, and as far as I know, there's no way to have multiple databases. So my database contains 80,000 caches split mostly between the greater northwest and a corridor on the east coast between pennsylvania and Charlotte North Carolina where our families are. 

I found out the hard way that overlapping GGZ files causes performance issues. My weekly maintenance and update is a 120 mile radius around my home coordinates. But when I travel out of the area, say to Bosie or Seattle, the easiest way to export is just to filter for the entire state - either Washington or Idaho as needed. (Unfortunately, iCaching does not have the ability to filter/export around a radius other than your home coordinates. You can change your home coordinates, but then the distance for every cache has to be recalculated. There's also no mass map selection/select map area.). So when I had my 120 mile radius home location exported along with my entire Idaho collection, the GPS crashed. So now, when travelling, I'll export each state separately, or together as a giant file.

[+Cheminer Will]

I feel GSAK is very robust and usually whatever it is I am trying to do there is a way to do it either within GSAK or with a macro.  In this case it is very easy for me to send the caches in those 3 GSAK databases over to a single temporary Db for exporting as a ggz file.  Normally I only have one large GSAK Db that covers the southern 2/3 of our state.  Only when I am moving around out of that area do I need to add caches from one of my other GSAK databases and it is easy to do within GSAK and then export one ggz file.

[+Cheminer Will]

On 3/23/2019 at 3:54 PM, Mineral2 said:

I found out the hard way that overlapping GGZ files causes performance issues.

 

Since your suggestion I have been making sure that I use only one GGZ file at a time and the slow loading issue has been gone.  But:

 Yesterday I loaded the whole GSAK database of 20K+ caches as a GGZ file using the GSAK Garmin export macro as I normally do.  However, I forgot, when experimenting with proximity last week,  I had previously checked the "proximity" box in that macro.  After loading the GGZ file, I then followed the new instructions at GPSrChive to get alerting proximity caches on to the 66.  So I ended up with two very large, (both over 20,000K) proximity files on the 66. When I started the 66 the first time after this, it took 25 minutes to load!  So it seems likely that it happens not only with GGZ files.

Edited April 7, 2019 by Cheminer Will

[+Atlas Cached]

What was the file size of the 20K+ proximity *.gpi file?

[+Cheminer Will]

37 minutes ago, Atlas Cached said:

What was the file size of the 20K+ proximity *.gpi file?

 

Both of the two proximity files were just over 2Mb.

 

Something is confusing me though.  I thought I ended up with both of the proximity files because I loaded the proximity alert file using the instructions at GPSrChive and I had previously loaded the GGZ file using the GSAK Garmin Export macro with the proximity box checked.  But, I deleted the files on the 66 and just reloaded the GGZ file from GSAK, making sure the proximity box was unchecked as in the attached screenshot.  I still get not only the GGZ file on my SD card as I want, but I still also get a 2Mb proximity*.gpi file on my 66 internal memory POI folder.  The date time stamp of that matches all the other .gpi files in that directory so it is being put there with all the other, much smaller, .gpi files, (virtual, trailhead, final, parking, etc. 10 - 120 kb files).  That date time stamp is 2 minutes earlier than the GGZ file but I guess is probably being loaded in the same step, using the GSAK Garmin Export macro.  Probably loads the .gpi files first, then the GGZ file after which takes about 2 more minutes to transfer.

 

Why is there a 2Mb proximity file?  That seems to match in size what I get with the GPSrChive proximity alert file, so I think loading the GGZ file from GSAK creates the proximity file with an entry for all of the 22K+ caches.  But I don't see that I have that selected to happen anywhere in GSAK so not sure what to think or how to avoid that large POI file.  

 

I suppose I could just delete that proximity.gpi file before I load the proximity alert file so that they are not both on the 66 when I boot up the first time. That might tell me if the 25 minute boot time on first load/indexing is due to there being two, 2Mb proximity files.  But that does not solve the question of why the first 2Mb file is being created with the GGZ load.

 

[+Atlas Cached]

 

GSAK is sending child waypoints as POI.

[+Cheminer Will]

2 hours ago, Atlas Cached said:

 

GSAK is sending child waypoints as POI.

 

Yes you are likely correct that the proximity file contains the child waypoints, but I thought maybe those were in one of the smaller .gpi files like maybe 47Kb Reference Point.gpi file.  Seems odd that the GSAK macro would put a few hundred child waypoints in a Proximinty.gpi file that just happens to be approx. the same 2,000 Kb size as the proximity alert file with 22K caches that is sent using the GPSrChive instructions.  Which, as I am about to post in that thread, I can not get to work yet. 

 

In any case the first boot after loading the GGZ alone which puts the GGZ and the 2Mb proximity.gpi file on the 66 is very fast.  If I do not load the GGZ file, but load the GC Proximity POI.gpi file following the GPSrChive instructions, the first boot up is also very fast.  If I load both the GC Proximity POI file and the GGZ file with its corresponding proximity.gpi file, then the first boot with both of those proximity files is 20 minutes or so rather than seconds.  So with both of those files on the 66, some sort of comparison/indexing must be going on during that initial boot up that slows things down.  Subsequent boot ups are normal and fast.  This is not a huge deal, just need to plan to wait a while after loading both of the files.  Although I do not yet really have any reason to load the GC Proximity.gpi file as I can not get those proximity alerts to work!

Edited April 7, 2019 by Cheminer Will