Home › Forums › Geocaching in Wisconsin › Tech Talk › Garmin Oregon – Remove found caches from GPX database?
This topic contains 31 replies, has 6 voices, and was last updated by gotta run 16 years, 1 month ago.
-
AuthorPosts
-
08/01/2009 at 3:17 am #1911299
@todd300 wrote:
[Just run a “My Finds” PQ if you want your finds updated. It can only be ran once a week though,
Oh yeah, that should work. Didn’t think about importing that into the unfound database.
So many workarounds….
On the Left Side of the Road...08/03/2009 at 12:52 pm #1911300@gotta run wrote:
@Team B Squared wrote:
If you want to see what caches you have found in your latest gpx download when you load it to a pre-existing database you would click on “Search” and then select “Filter” from the drop down. In the dialog that opens, just uncheck the check box next to “Unfound” and click “go” at the bottom. This will show you all of the caches that you have found in your database. To delete the caches you have found you would then right click and select “delete waypoint”. You would then select “All Waypoints in Filter” and click “ok”.
There may be a better way to do it, but this is how I do it and it isn’t too difficult to figure out.
Ok, still on this topic.
When you create a PQ, are you leaving caches that you have found in the PQ?
Our weekly PQ basically specifies “Caches within a 30 mile radius of our home coordinates that we do not own and have not found.”
Therefore, we do not receive “found” caches in the PQ.
Therefore, when we update the “Unfound caches” database in GSAK, it is not updating the caches in the existing database as found, because no new information comes through on those caches.
The only way I can see to let GSAK know what you have found is to load found caches in it, but loading ALL the caches in a 30-mile radius exceeds the number limit of the query.
Make sense?
To answer this question late, yes, I leave all the caches I have found in my pocket queries so that GSAK will be able to recognize which caches I have found and not found. If it was me I would leave your found caches in the PQ rather than download the “my finds” query to your database, since you are just adding another step to the process by having to download the “my finds” query.
It is very easy to query your database for caches that you haven’t found and don’t own when planning a trip. Before planning a trip in gsak I just filter out caches that we own and that I have already found. I then plan my trip using the caches that are left in that filter. If you don’t know how to do this I can outline it for you, just let me know.
As for the 30 mile radius exceeding 500 caches with your finds included, there are ways around that. I can type this method up if you are interested, just let me know. Of course I don’t really run into that problem up here in my neck of the woods. 😆
08/03/2009 at 1:21 pm #1911301@Team B Squared wrote:
It is very easy to query your database for caches that you haven’t found and don’t own when planning a trip. Before planning a trip in gsak I just filter out caches that we own and that I have already found. I then plan my trip using the caches that are left in that filter. If you don’t know how to do this I can outline it for you, just let me know.
Yeah, this I can do. Basically the difference is to filter it on the GSAK side rather than the PQ side. Makes sense.
@Team B Squared wrote:
As for the 30 mile radius exceeding 500 caches with your finds included, there are ways around that. I can type this method up if you are interested, just let me know.
Well, the only way I know is to set a few coordinates at the X mile mark from my home coordinates and then run smaller-radius searches from there. Then load the multiple PQs into one GSAK database. GSAK takes care of the overlap. If there’s an easier way than that, I’d love to hear it.
On the Left Side of the Road...08/03/2009 at 3:55 pm #1911302@gotta run wrote:
@sammyclaws wrote:
There is a way to use the file off your Oregon to update your GSAK database and mark the caches found.
Not that I’ve found. Oregon doesn’t make any changes to the GPX file and doesn’t seem to pass any “found” information back to GSAK either way, unless I am just missing it.
I’ll try to when I get home tonite to make sure, but I believe its GPS>Receive Waypoints – on that dialog box, I have mine set to ‘if matched update found status only’.
08/03/2009 at 4:20 pm #1911303@sammyclaws wrote:
I’ll try to when I get home tonite to make sure, but I believe its GPS>Receive Waypoints – on that dialog box, I have mine set to ‘if matched update found status only’.
Aha! There it is…”Just update finds.” It was greyed out behind the defaults.
Someone should write a book on this.
On the Left Side of the Road...08/03/2009 at 6:09 pm #1911304@gotta run wrote:
@Team B Squared wrote:
As for the 30 mile radius exceeding 500 caches with your finds included, there are ways around that. I can type this method up if you are interested, just let me know.
Well, the only way I know is to set a few coordinates at the X mile mark from my home coordinates and then run smaller-radius searches from there. Then load the multiple PQs into one GSAK database. GSAK takes care of the overlap. If there’s an easier way than that, I’d love to hear it.
You will probably need 2 pocket queries to get all the caches within a 30 mile radius. But what you do is take the pocket queries and set them up to filter by placed date (towards the bottom of the pocket query set up page). For the first one you would check the placed between and do something like Jan 1, 2000 for the start date and something like Aug 3, 2007 for the end date. The end date doesn’t really matter for what you are trying to do, as long as your pocket query doesn’t exceed 500 caches. Then set up another pocket query that is identical to the first, except your begin date for placed would be Aug 4, 2007 (if you used for Aug 3, 2007 for your end date in the first query) and then make your end date for the second query something far off into the future. This will give you all the caches within a 30 mile radius of your pocket query center.
Clear as mud? I do something similar to this to get all of the caches in the Upper Peninsula (3 pocket queries) and NE Wisconsin (5 pocket queries). I get these queries sent once per week and work off of that while planning a caching trip.
08/03/2009 at 6:21 pm #1911305Ah! That makes perfect sense because you know your “old” queries will never get any bigger unless someone messes with the placed dates. 😈
Thanks for the tip!
On the Left Side of the Road...08/03/2009 at 8:38 pm #1911306When I went to Green Bay last month, I ran 3 PQ’s for the Green Bay area.
1 PQ for traditionals only, 1 for multi’s and 1 for puzzles/unknowns. Yes, I know there are a few other icons such as your Letterbox hybrids, GR, but I’ll get to those eventually.
Anyways, running PQ’s for each type of cache seems to work with me in an area like Green Bay that is not as dense with caches as, say, West Bend, who claims to have 500 caches in a 7 mile radius.
I’ve seen in the ground speak forums that cachers would run PQ’s according to placed dates. I have not done that yet as I have no reason to, but I know I eventually will when I go to a dense cache area.
That’s why I like caching in the northwoods and the UP. I could run a PQ of a large radius and still be under 500 caches.
Good luck with your work, GR.
08/04/2009 at 2:07 pm #1911307@todd300 wrote:
When I went to Green Bay last month, I ran 3 PQ’s for the Green Bay area.
1 PQ for traditionals only, 1 for multi’s and 1 for puzzles/unknowns. Yes, I know there are a few other icons such as your Letterbox hybrids, GR, but I’ll get to those eventually.
Anyways, running PQ’s for each type of cache seems to work with me in an area like Green Bay that is not as dense with caches as, say, West Bend, who claims to have 500 caches in a 7 mile radius.
I’ve seen in the ground speak forums that cachers would run PQ’s according to placed dates. I have not done that yet as I have no reason to, but I know I eventually will when I go to a dense cache area.
That’s why I like caching in the northwoods and the UP. I could run a PQ of a large radius and still be under 500 caches.
Good luck with your work, GR.
You could probably get all of those caches with 2 queries including all of the cache types instead of three for specific cache types and then just filter them out (Traditional, Mystery, Multi, etc) in GSAK. Filtering is very easy in GSAK, if you need any help or hints feel free to ask.
08/13/2009 at 11:52 pm #1911308Hey B Squared, how do you clear ARCHIVED caches from your database using your method? Archived caches won’t show up in the PQ so how do you know to drop them? Are you filtering by “last GPX date” or something?
On the Left Side of the Road...08/14/2009 at 2:32 am #1911309On GSAK, go to search >> filter..then on the general tab, uncheck the archived box.
Let me know if that’s what you mean.
08/14/2009 at 2:58 am #1911310What I mean is that if you are building a database over time as B squared suggests, you will not know if an unfound cache in the database is archived unless you physically go out on each unfound cache and look on geocaching.com because PQs do not pull archived caches. So unless you are dumping and rebuilding your database with each query this is a problem, and part of the benefit of just updating the database versus rebuilding it is that you get a greater history of logs.
The only workaround to this I could see would be filtering any unfound remaining caches by GPX date. That is, if it is an unfound cache in your current working database and the record does not get updated with the new PQ, it would have an old date. Filter by dates, then take a look at any old dates to see why they were not updated.
On the Left Side of the Road...08/14/2009 at 3:00 am #1911311Far as I know, that workaround is the only thing I can think off. I never really paid attention to GPX dates and maybe I should. But so far, I have never run into a cache that turned out to be archived. Knock on wood. I’ll be sure to check closer next time.
08/14/2009 at 2:09 pm #1911312@gotta run wrote:
The only workaround to this I could see would be filtering any unfound remaining caches by GPX date. That is, if it is an unfound cache in your current working database and the record does not get updated with the new PQ, it would have an old date. Filter by dates, then take a look at any old dates to see why they were not updated.
I will sort the last GPX column to see if there is any caches that did not get updated with the last import. I have found two reasons so far why they do not get updated. Archived caches is the first one. Second, if your pulling the max number of caches in a query, as caches in the center increase, the once on the fringe will not be selected anymore. Not a huge deal for me since they are usually about 70 miles away, so I delete them too.
08/14/2009 at 2:12 pm #1911313Yeah, that’s what I thought. It makes sense and shouldn’t be too hard to do.
And besides, we have found many instances where archived caches are actually still there 😡 , so it’s helpful to have a record of that over time so that the geo-litter can be cleaned up.
On the Left Side of the Road... -
AuthorPosts
You must be logged in to reply to this topic.