Keeping Database Current

[+marshajean]

I am wondering what the best way is to keep one's database current. I maintain my "Home" database on GSAK. When I solve a puzzle I enter the corrected coordinates and before I head out caching I run a pocket query to find the closest 1000 caches that I have not found and are available and add those to the database. I flag my unsolved puzzles so I can filter them out before downloading them to my GPS.

 

My problem occurs when a cache that is currently in my database becomes disabled or archived. More than once I have driven out to an area and unsuccessfully searched for a cache only to find when I come hope to log my DNF that the cache has been archived. Once a month or so I do try to look through the caches on Geocaching.com and compare them with my database to catch these unavailable caches, but that is very time consuming and, of course, I miss several in the meantime. I don't want to start a new database each time I run a pocket query because my solved puzzles have the corrected coordinates on them and my unsolved puzzles have the user flag on them. Again, very time consuming to update that every time I run a pocket query.

 

Does anyone have any suggestions for me? Thanks.

[+Bear and Ragged]

Use filter and columns.

 

Use a filter to find the latest GPX files

Or use the column to set 'Last GPX' date -click will place the newest first, click again oldest fist.

 

Check the date, any that are older then your last run PQ are likely to be archived.

(Archived caches do not get updated)

 

There is a macro which will sort out the caches that are older than your chosen date, usually a week old, as regular PQ's are run weekly.

Edited September 5, 2011 by Bear and Ragged

[+eusty]

Have you tried GSAK v8?

 

It's in beta at the moment, but uses the Groundspeak API so it can update the status of caches/logs etc even download new ones without having to run a PQ...very handy

 

[+NYPaddleCacher]

I am wondering what the best way is to keep one's database current. I maintain my "Home" database on GSAK. When I solve a puzzle I enter the corrected coordinates and before I head out caching I run a pocket query to find the closest 1000 caches that I have not found and are available and add those to the database. I flag my unsolved puzzles so I can filter them out before downloading them to my GPS.

 

My problem occurs when a cache that is currently in my database becomes disabled or archived. More than once I have driven out to an area and unsuccessfully searched for a cache only to find when I come hope to log my DNF that the cache has been archived. Once a month or so I do try to look through the caches on Geocaching.com and compare them with my database to catch these unavailable caches, but that is very time consuming and, of course, I miss several in the meantime. I don't want to start a new database each time I run a pocket query because my solved puzzles have the corrected coordinates on them and my unsolved puzzles have the user flag on them. Again, very time consuming to update that every time I run a pocket query.

 

Does anyone have any suggestions for me? Thanks.

 

This is probably more of a GSAK forum question but here's what I do.

 

For caches in my local area (basically a 50 mile radius) I use a PQ which includes all cache types except mystery caches and another which only contains mystery caches. I have a GSAK database called "NotYetFound" that I use to read in the PQ which contains all caches that I have not yet found within 50 miles (excludes mystery caches) and set the "clear database before loading" flag for this database. Then I load a "Puzzles" database with the mystery cache PQ and *don't* set the clear database before loading flag on that DB. As I solve puzzles and change the coordinates using the "corrected coordinates" form I'll also enter the actual coordinates in the personal notes section on the cache page. I also include the corrected coordinates indicator column and sort the GSAK db by that field. I have a third database I use for download to my GPS. When I'm ready to update the waypoints in my GPS I'll clear the "Download" db, copy all the waypoints from the NotYetFound DB, and the first "N" waypoints in the puzzles DB (those that I have solved) into the Download DB.

I might have to highlight mystery caches I might look for before going out to make sure they're still active but that doesn't take long. Once I find a puzzle cache I just removed it from the puzzles DB.

 

Of course, what works for me might not work for you as the number of caches in my area and how often I go geocaching may be much different than for others.

[+ChileHead]

I never understood the need to keep an offline database. When I load up my GPS, it's always with a set of fresh GPX files, no more than a day or two old. I don't have a huge backlog of unsolved puzzles, so I don't bother to keep those solutions in a database of any sort. I suppose if you have hundreds of solved puzzles there are some advantages to doing so.

[+Bear and Ragged]

And.

Setting a filter, in the Where tab, if you put

"not(cachetype='U' and not(hascorrected))"

-remove the quotes- only solved puzzles will be sent to the GPS

[+LaxRef93]

I don't really see the need in keeping an offline database either. I have 2 main databases... My Finds, and one for Home. I always delete/replace the Home database each time I do a PQ, because I will always want the freshest logs and non-archived caches.

[+Team Batpony]

OK, I have a question... How do I send my database from GSAK 7 to the new GSAK 8??? Wait, never mind, I'll just clear it and rebuild it from new GPX's.

[+Bear and Ragged]

Be aware. GSAK 8 will be a chargeable update, once it comes out of Beta.

[+eusty]

OK, I have a question... How do I send my database from GSAK 7 to the new GSAK 8??? Wait, never mind, I'll just clear it and rebuild it from new GPX's.

 

Backup (in 7)>Restore (in 8)!!

 

It is chargeable once its out of beta, but it's worth it I think. If not just restore your db in V7.

 

[+Markwell]

Edited September 5, 2011 by Markwell

[+Bear and Ragged]

 

Which will remove any solved puzzles, with corrected coordinates, in the database...

[AZcachemeister]

I use the 'Last GPX' column to reveal the 'stragglers', and then the Waypoint > Status check function to confirm they are indeed Archived. Sometimes I use the split screen to actually look at the cache page live, and see what happened.

Before uploading/creating files for mapping, I use a saved filter that screens-out disabled caches.

[+StarBrand]

The good folks up at HQ have graciously decided to keep a master database up to date for all of us. I'd keep just the puzzle caches in GSAK and get the others fresh as needed.

[AZcachemeister]

The good folks up at HQ have graciously decided to keep a master database up to date for all of us. I'd keep just the puzzle caches in GSAK and get the others fresh as needed.

 

Mostly works also, but there are too many cases where the owner only posts a note about corrected co-ordinates, or a finder mentions corrected co-ordinates, or a finder just mentions the cache was xxx feet off the listed co-ordinates.

 

Yes, a diligent owner would fix the listing, but some just don't.

 

Once that log with the vital info scrolls down far enough, it won't show up in your PQ any longer...all you see are the logs thanking so-and-so for the helpful info you can't see.

[+pppingme]

And.

Setting a filter, in the Where tab, if you put

"not(cachetype='U' and not(hascorrected))"

-remove the quotes- only solved puzzles will be sent to the GPS

You are making the assumption that a solved puzzle will always have corrected coord's.

 

Thats not the case. Some have good starting coordinates, but require you to be onsite to figure them out.

[+Bear and Ragged]

I don't want to start a new database each time I run a pocket query

because my solved puzzles have the corrected coordinates on them

and my unsolved puzzles have the user flag on them.

 

And.

Setting a filter, in the Where tab, if you put

"not(cachetype='U' and not(hascorrected))"

-remove the quotes- only solved puzzles will be sent to the GPS

You are making the assumption that a solved puzzle will always have corrected coord's.

 

Thats not the case. Some have good starting coordinates, but require you to be onsite to figure them out.

 

Not that a solved Puzzle will ALWAYS have correct coordinates.

But if I -and the OP- have worked on the 'solve at home puzzles' they will have corrected coordinates.

 

If I only want quick and easy caches loaded in the GPS, I don't want Puzzles, Multi's, caches over D3/T3 loading. But will accept Puzzle caches that have been solved.

 

I often do multi caches 'in passing' one part at a time, and have a list of them that now have the coordinates, as corrected coordinates, ready to go and find the final.

 

Everyone plays it their own way!

[+marshajean]

Thanks for all the great suggestions. I've got some ideas now as to how I can solve my problem.

[+The Jester]

And.

Setting a filter, in the Where tab, if you put

"not(cachetype='U' and not(hascorrected))"

-remove the quotes- only solved puzzles will be sent to the GPS

You are making the assumption that a solved puzzle will always have corrected coord's.

 

Thats not the case. Some have good starting coordinates, but require you to be onsite to figure them out.

"In field" puzzles have the starting co-ords saved as Corrected Co-ords in my database, so any puzzle without CC's are not exported to my GPSr.

 

My work flow for radius based PQ's (i.e.. the closest 500 to home) is to set the user flag when importing the PQ (clearing flags before hand). Sorted on distance, I check farthest out cache with a flag (F8 - filter on User Flag set), then I can sort on all caches within that distance that the User Flag is NOT set, and update them as needed. All of this is done with a macro or two - the distance is stored so other macro's can use it - such as the export macro for GPSr, MS S&T, and CacheMate (which also filters out unsolved puzzles, boat caches, night caches and those on Vashon Island as that is ferry ride/special trip - all these are "flagged" in one of the User Data fields). With GSAK8 and the API I don't have to manually check each cache anymore, but can update logs, cache data, and/or status of the all caches in a filter.

[+GeePa]

And.

Setting a filter, in the Where tab, if you put

"not(cachetype='U' and not(hascorrected))"

-remove the quotes- only solved puzzles will be sent to the GPS

You are making the assumption that a solved puzzle will always have corrected coord's.

 

Thats not the case. Some have good starting coordinates, but require you to be onsite to figure them out.

For those puzzles I go ahead and make corrected coordinates in GSAK that are the same as the original coordinates. That way I can still filter on unknown caches with corrected coordinates and get the field solvable ones as well as the ones I have solved at home.

[+benh57]

GSAK v8. None of the 'workarounds' above are necessary anymore.

[+NYPaddleCacher]

And.

Setting a filter, in the Where tab, if you put

"not(cachetype='U' and not(hascorrected))"

-remove the quotes- only solved puzzles will be sent to the GPS

You are making the assumption that a solved puzzle will always have corrected coord's.

 

Thats not the case. Some have good starting coordinates, but require you to be onsite to figure them out.

 

I flag those in GSAK by changing the icon from the Mystery icon (just a blue question mark) to the "other" icon (a blue question mark in a white box) and send all caches with the "other" icon to my GPS when I download the database.

[+NYPaddleCacher]

GSAK v8. None of the 'workarounds' above are necessary anymore.

 

I haven't looked at v8 yet. Do most/all of the macros work with v8?

[+Bear and Ragged]

GSAK v8. None of the 'workarounds' above are necessary anymore.

 

I haven't looked at v8 yet. Do most/all of the macros work with v8?

Yes.

 

Be aware, it WILL be a chargeable update, once it's out of Beta.

[+TomToad]

 

Which will remove any solved puzzles, with corrected coordinates, in the database...

Actually, it depends on how you enter the corrected coordinates. If you just edit the listing with the new coordinates, then it will be deleted, but if you right-click the listing, then click on Corrected Coordinates and enter them there, it will not be erased with the rest of the database. I use that function all the time.

 

Note that if you erase the waypoints from the Database menu instead, that will erase the corrected coordinates.

 

Edit to add: Glonch'sPride recently had a GSAK101 event here in Central Florida. He has a .pdf of his presentation here.

Edited September 6, 2011 by TomToad

[+The Jester]

GSAK v8. None of the 'workarounds' above are necessary anymore.

Different "workarounds" are needed. GASK8 does a lot, but not everything. There are limits to the API (number of calls per day/minute, distance, etc.).

[+yawppy]

Have you tried GSAK v8?

 

It's in beta at the moment, but uses the Groundspeak API so it can update the status of caches/logs etc even download new ones without having to run a PQ...very handy

A BIG HUGE THANK-YOU I just sort of stumbled across this the other day, and D/L'd V.8.91 Beta...but it really is a great upgrade, love the way in connects to GS API, simply awesome, again TY!

 

OK, I have a question... How do I send my database from GSAK 7 to the new GSAK 8??? Wait, never mind, I'll just clear it and rebuild it from new GPX's.

 

I just posted the very same query in the GSAK forums, "Noob" questions, basically got the answer was to save from V.7 and restore in V.8, but the admin explains it quite well here

 

Here is the actual reply: 5) You can transfer everything easily: open Version 7, go to File>Backup, choose All Databases and All Settings (this includes your macros). Save the file somewhere on your PC. Now close V7 and open V8, go to File>Restore. Select all databases and all settings. Your V7 data and settings will now be imported into V8.

 

K well GSAK is full circle , can not see how it can get any better, simply awesome!

Edited September 6, 2011 by yawppy

[+Don_J]

 

Which will remove any solved puzzles, with corrected coordinates, in the database...

Actually, it depends on how you enter the corrected coordinates. If you just edit the listing with the new coordinates, then it will be deleted, but if you right-click the listing, then click on Corrected Coordinates and enter them there, it will not be erased with the rest of the database. I use that function all the time.

 

Note that if you erase the waypoints from the Database menu instead, that will erase the corrected coordinates.

 

Edit to add: Glonch'sPride recently had a GSAK101 event here in Central Florida. He has a .pdf of his presentation here.

 

I had never heard this before, so I did a little experiment in V8..0.0.111. As expected, the database was cleared, regardless of corrected coordinates.

[+TomToad]

 

I had never heard this before, so I did a little experiment in V8..0.0.111. As expected, the database was cleared, regardless of corrected coordinates.

 

Just tried it myself with 8.0.0.91 beta. Corrected coordinates were still preserved. Did you clear it by checking the "Clear Database before loading" option on the "load GPX/LOC File" dialog, or did you do it from the "Database/Remove waypoints" option in the menu. The first will preserve the corrected coordinates, the second will not.

[+Don_J]

 

I had never heard this before, so I did a little experiment in V8..0.0.111. As expected, the database was cleared, regardless of corrected coordinates.

 

Just tried it myself with 8.0.0.91 beta. Corrected coordinates were still preserved. Did you clear it by checking the "Clear Database before loading" option on the "load GPX/LOC File" dialog, or did you do it from the "Database/Remove waypoints" option in the menu. The first will preserve the corrected coordinates, the second will not.

 

1. Created new database.

2. Copied my meager solved puzzle cache database over. Each cache has corrected coordinates. Note: proper corrected coordinates, not edited coordinates.

3. Downloaded local traditional cache GPX file.

4. Loaded GPX with with the "Load GPX/LOC/ZIP" dialogue and the "Clear database before loading" checked.

5. I was left with a database that contained my new traditional only. The original database was gone.

 

I'm not sure why you get something different, but I would hate to see someone lose their puzzle solutions over this.

 

I have been lurking on the GSAK forums for years. It's clear to me that the reason for using the corrected coordinate feature is that it locks the field so when you update the listing by loading a new GPX file, the coordinates are preserved, while the other fields are open to be updated.

 

For some reason, to me "Clear database before loading", means that when the load begins, it will be an empty database and there will be nothing left to preserve.

Edited September 7, 2011 by Don_J

[jholly]

 

I had never heard this before, so I did a little experiment in V8..0.0.111. As expected, the database was cleared, regardless of corrected coordinates.

 

Just tried it myself with 8.0.0.91 beta. Corrected coordinates were still preserved. Did you clear it by checking the "Clear Database before loading" option on the "load GPX/LOC File" dialog, or did you do it from the "Database/Remove waypoints" option in the menu. The first will preserve the corrected coordinates, the second will not.

 

1. Created new database.

2. Copied my meager solved puzzle cache database over. Each cache has corrected coordinates. Note: proper corrected coordinates, not edited coordinates.

3. Downloaded local traditional cache GPX file.

4. Loaded GPX with with the "Load GPX/LOC/ZIP" dialogue and the "Clear database before loading" checked.

5. I was left with a database that contained my new traditional only. The original database was gone.

 

I'm not sure why you get something different, but I would hate to see someone lose their puzzle solutions over this.

 

I have been lurking on the GSAK forums for years. It's clear to me that the reason for using the corrected coordinate feature is that it locks the field so when you update the listing by loading a new GPX file, the coordinates are preserved, while the other fields are open to be updated.

 

For some reason, to me "Clear database before loading", means that when the load begins, it will be an empty database and there will be nothing left to preserve.

 

From the V8 help file ...

Clear Database Before Loading (File>Load GPX/LOC)

 

Click this check box if you want GSAK to clear the database before loading the GPX/LOC file.

 

This is almost the same as taking the option "Database=>Delete all waypoints" before loading the GPX file, but there is one subtle yet very important difference. This option does not delete all your corrected coordinates, where as "delete all waypoints" does.

 

If your seeing something different a bug report over on GSAK boards would be the thing to do.

Edited September 7, 2011 by jholly

[+The Jester]

 

I had never heard this before, so I did a little experiment in V8..0.0.111. As expected, the database was cleared, regardless of corrected coordinates.

 

Just tried it myself with 8.0.0.91 beta. Corrected coordinates were still preserved. Did you clear it by checking the "Clear Database before loading" option on the "load GPX/LOC File" dialog, or did you do it from the "Database/Remove waypoints" option in the menu. The first will preserve the corrected coordinates, the second will not.

 

1. Created new database.

2. Copied my meager solved puzzle cache database over. Each cache has corrected coordinates. Note: proper corrected coordinates, not edited coordinates.

3. Downloaded local traditional cache GPX file.

4. Loaded GPX with with the "Load GPX/LOC/ZIP" dialogue and the "Clear database before loading" checked.

5. I was left with a database that contained my new traditional only. The original database was gone.

 

I'm not sure why you get something different, but I would hate to see someone lose their puzzle solutions over this.

 

I have been lurking on the GSAK forums for years. It's clear to me that the reason for using the corrected coordinate feature is that it locks the field so when you update the listing by loading a new GPX file, the coordinates are preserved, while the other fields are open to be updated.

 

For some reason, to me "Clear database before loading", means that when the load begins, it will be an empty database and there will be nothing left to preserve.

You would not have lost the CC's IF your GPX file had contained the caches that had the CC's. In other words, all the local traditionals did not include the puzzle caches that you had CC's to, if any of the CC's had a cache loaded that matched you would see them. A better test would be to create the DB you did, then load a PQ of the puzzle caches in the area.

[+fizzymagic]

I'm not sure why you get something different, but I would hate to see someone lose their puzzle solutions over this.

 

What you have experienced here is not a bug, but rather a design flaw in GSAK. The original design to integrate corrected coordinates was done the wrong way, and there are all sorts of results, among which is the effect you have seen.

 

I have a solution that works for me. I keep all my corrected coordinates in an external file, and I have written a macro that reads the external file and automatically corrects the coordinates in a database. This solution corrects several of the defects in the design; if you create a new DB and populate it with a GPX file, then run this macro, the proper caches in the new database are corrected. You don't have to copy them one-by-one from another database to transfer the corrected coords.

 

I am working on a similar solution to the problem of notes. I lost a whole bunch of important notes before I realized that the design of cache notes is flawed.

 

Particularly annoying about these design flaws is that they discourage proper use of PQs. In order to keep archived caches out the the database, one should clear the DB and then load the new PQs. But if you do that, the corrected coords and cache notes disappear.

[+Dgwphotos]

Something I've noticed about the GSAK API is that there is no option to exclude Ignore listed caches, other than using pocket queries.

[+TomToad]

 

I had never heard this before, so I did a little experiment in V8..0.0.111. As expected, the database was cleared, regardless of corrected coordinates.

 

Just tried it myself with 8.0.0.91 beta. Corrected coordinates were still preserved. Did you clear it by checking the "Clear Database before loading" option on the "load GPX/LOC File" dialog, or did you do it from the "Database/Remove waypoints" option in the menu. The first will preserve the corrected coordinates, the second will not.

 

1. Created new database.

2. Copied my meager solved puzzle cache database over. Each cache has corrected coordinates. Note: proper corrected coordinates, not edited coordinates.

3. Downloaded local traditional cache GPX file.

4. Loaded GPX with with the "Load GPX/LOC/ZIP" dialogue and the "Clear database before loading" checked.

5. I was left with a database that contained my new traditional only. The original database was gone.

 

Makes sense, since your PQ only has traditional caches. Corrected coordinates are not caches. They are only waypoints associated with a cache. If the puzzle cache is not in the new PQ, the CC wont show up since the cache that it is associated with is no longer there. Try redoing the PQ, but add the puzzle caches to it. The corrected coordinates will show up.

 

For some reason, to me "Clear database before loading", means that when the load begins, it will be an empty database and there will be nothing left to preserve.

 

I think that was just a bad choice of words for the function. Probably would have been better as "Clear waypoints before loading" as that is exactly what it does.

[+Don_J]

 

I had never heard this before, so I did a little experiment in V8..0.0.111. As expected, the database was cleared, regardless of corrected coordinates.

 

Just tried it myself with 8.0.0.91 beta. Corrected coordinates were still preserved. Did you clear it by checking the "Clear Database before loading" option on the "load GPX/LOC File" dialog, or did you do it from the "Database/Remove waypoints" option in the menu. The first will preserve the corrected coordinates, the second will not.

 

1. Created new database.

2. Copied my meager solved puzzle cache database over. Each cache has corrected coordinates. Note: proper corrected coordinates, not edited coordinates.

3. Downloaded local traditional cache GPX file.

4. Loaded GPX with with the "Load GPX/LOC/ZIP" dialogue and the "Clear database before loading" checked.

5. I was left with a database that contained my new traditional only. The original database was gone.

 

Makes sense, since your PQ only has traditional caches. Corrected coordinates are not caches. They are only waypoints associated with a cache. If the puzzle cache is not in the new PQ, the CC wont show up since the cache that it is associated with is no longer there. Try redoing the PQ, but add the puzzle caches to it. The corrected coordinates will show up.

 

For some reason, to me "Clear database before loading", means that when the load begins, it will be an empty database and there will be nothing left to preserve.

 

I think that was just a bad choice of words for the function. Probably would have been better as "Clear waypoints before loading" as that is exactly what it does.

 

I retested it with matching waypoints and it did preserve the corrected coordinates, yet it deleted my notes. I think that this is way too risky. Accidentally load the wrong GPX file and you end up wiping out a lot of work.

 

I never use the clear database option. My method for getting rid of archived caches is to load my PQs with the clear then set user flag option. I then filter on "user flag not set" and then delete the whole filtered set.

Edited September 8, 2011 by Don_J

[+GeoBlank]

I used to love GSAK and had a set of PQs to get all of washington "offline". Too limitted and too much work (even though I had some killer scripts and scehduled batch jobs). Smart phones makes life grand and targetted PQs when I know I will be going someplace where caching is on the front of my lobe.

 

Would be very nice still if GC.com supported state by state or some sort of pre-built (rest based) links to GPX files. That way all of the work people to with PQs or gsak would be much simpler and less load on GC.com in the long run.

[+Frank Broughton]

The good folks up at HQ have graciously decided to keep a master database up to date for all of us. I'd keep just the puzzle caches in GSAK and get the others fresh as needed.

 

Oh how we forget about the week end woes..... having a offline accurate db takes care of the gc glitch!

[+Frank Broughton]

GSAK v8. None of the 'workarounds' above are necessary anymore.

 

Indeed. Clyde is one hard working class act. I am looking forward to giving him more $$ for version 8. Just hope GC gives us decent numbers in the api limits once it is all settled.

[+Frank Broughton]

GSAK v8. None of the 'workarounds' above are necessary anymore.

 

I haven't looked at v8 yet. Do most/all of the macros work with v8?

 

Yes! Plus many are no longer needed.

[+Frank Broughton]

GSAK v8. None of the 'workarounds' above are necessary anymore.

Different "workarounds" are needed. GASK8 does a lot, but not everything. There are limits to the API (number of calls per day/minute, distance, etc.).

 

I hate the distance ones with get caches!

[+Frank Broughton]

dup...

Edited September 9, 2011 by Frank Broughton