+Tecks Posted July 15, 2009 Share Posted July 15, 2009 I was trying to find a way to get only changed/updated caches in Pocket Query within specified time-frame. There is the "updated in the last 7 days", but because also a log means a change, the result is always too large for this to be usefule. I think many people run several querys just to keep their GSAK updated (whether this is good idea or not is not the issue here). By offering us a way to get either only changed caches (published, disabled, archived, coord update) or let's say the updated in the old way within 1 day would probably ease the load on PQ-servers? Also people could then use easily GSAK's great "Get data via e-mail"-feature. I tried to search the forums about this, but came up empty. Opinions, comments? Link to comment
CoyoteRed Posted July 15, 2009 Share Posted July 15, 2009 What are you trying to do? I find the "updated in the last 7 days" a potentially very useful option. I say "potentially" because it doesn't include archival data which makes it less than useful. Why is it you're only wanting the cache data changes and not the logs? Link to comment
+gse1986 Posted July 15, 2009 Share Posted July 15, 2009 What are you trying to do? I find the "updated in the last 7 days" a potentially very useful option. I say "potentially" because it doesn't include archival data which makes it less than useful. Why is it you're only wanting the cache data changes and not the logs? I think what the OP means is that the "changed" flag shouldn't be triggered by someone finding the cache, but rather just if the description (useful for puzzle caches), coords, or status (archived, enabled, disabled etc) changes. That way if you're maintaining an offline DB you're only downloading useful data. Personally I think it's a great idea, will see what GS think Link to comment
+Tecks Posted July 15, 2009 Author Share Posted July 15, 2009 I find the "updated in the last 7 days" a potentially very useful option. I say "potentially" because it doesn't include archival data which makes it less than useful. Why is it you're only wanting the cache data changes and not the logs? Actually it's fine to get the logs also, but like gse1986 said, I would just like to download data which has changed since I last got the PQ. I understand making custom data for everyone could be difficult, but just a way to get changes since "last X days" would be great. Because the current setting makes cache updated even when someone logs a find, it makes almost every cache in the query "updated", causing a big set of caches. Link to comment
CoyoteRed Posted July 15, 2009 Share Posted July 15, 2009 That kind of interesting in that you're saying that just about every cache is updated. I maintain an OLDB and because of the way the PQ system is set up I pull full datasets. When I update the OLDB, GSAK reports only about a quarter to a third of caches are updated. Here's my last update numbers: Waypoints in file(s) loaded 9185 New waypoints added to GSAK 42 Existing Waypoints updated in GSAK 2457 Waypoints already up to date in GSAK 6683 Notice that of the 9185 caches imported 6683 were already up to date. This was for a two week period! The total database size is only 6038, so you see there was a lot of redundancy. The problem with keeping an OLDB is knowing which cache to purge due to archiving. If you're only getting the caches that update you're not getting those updated caches that are archived which makes the database assume there was no update. This has been a problem since the beginning. Link to comment
+Tecks Posted July 15, 2009 Author Share Posted July 15, 2009 Notice that of the 9185 caches imported 6683 were already up to date. This was for a two week period! The total database size is only 6038, so you see there was a lot of redundancy. The problem with keeping an OLDB is knowing which cache to purge due to archiving. If you're only getting the caches that update you're not getting those updated caches that are archived which makes the database assume there was no update. This has been a problem since the beginning. Yep, and if I understand things correctly, all that redundancy could be removed by having a "updated only" PQ which would also give archived caches for GSAK to mark/remove? Link to comment
+Isonzo Karst Posted July 15, 2009 Share Posted July 15, 2009 also give archived caches for GSAK to mark/remove? This is now a horse of a different color. You're asking for archival to be added as part of "updated". It is not now; it seems unlikely that it will be in the future. Currently, archived caches are NOT returned in PQs, except the My Finds PQ, and from Bookmarked lists. Link to comment
CoyoteRed Posted July 15, 2009 Share Posted July 15, 2009 Yep, and if I understand things correctly, all that redundancy could be removed by having a "updated only" PQ which would also give archived caches for GSAK to mark/remove? The issue is getting the archived cache data. TPTB have long said they don't want to send out archived caches--though they do in certain situations. However, they don't have to send out the cache data, only some sort of identifier of which caches have been archived. I've provided several different schemes that would facilitate OLDBs while keeping all the data fresh and greatly reducing the server loads--all with no feedback from TPTB. Link to comment
+Tecks Posted July 15, 2009 Author Share Posted July 15, 2009 Yep, and if I understand things correctly, all that redundancy could be removed by having a "updated only" PQ which would also give archived caches for GSAK to mark/remove? ... I've provided several different schemes that would facilitate OLDBs while keeping all the data fresh and greatly reducing the server loads--all with no feedback from TPTB. What a shame. If we could at least have "updated in the last 1 day", it would probably be much more useful in this sense than the current 7 days. Link to comment
+novw.nl Posted September 10, 2009 Share Posted September 10, 2009 (edited) I came here looking for an answer on the first posters question We are heading out on vacation, and do not have mobile internet in Florida. So I downloaded part of the available caches through PQ's: 16 times 490 caches to be precise. Updating their status (available, unavailable, archived, ...) is going to take 4 days (5 PQ's per day with 16 PQ's...), so by the time I get aware of unavailable it might take 4 days. And I have already filtered out 75% of Florida caches, so I can not go below 16 PQ's (traditionals, small/reg/large, T and D under 2.5, available) So I am "forced" to run 16 PQ's that are heavy on the servers, just to get a hold of unavailability? Hm. I agree with the idea: if there was an option to just get a hold of the available/unavailabe/archived flags, it would greatly reduce pressure on the servers. Edited September 10, 2009 by novw Link to comment
+beejay&esskay Posted September 10, 2009 Share Posted September 10, 2009 So I am "forced" to run 16 PQ's that are heavy on the servers, just to get a hold of unavailability? Hm. I agree with the idea: if there was an option to just get a hold of the available/unavailabe/archived flags, it would greatly reduce pressure on the servers. While true, we've been here before. Since that would facilitate the maintenance of OLDBs, TPTB would rather have that load on their servers. Link to comment
+novw.nl Posted September 10, 2009 Share Posted September 10, 2009 please explain OLDB, I am assuming TPTB is shorthand for Groundspeak ? Link to comment
+beejay&esskay Posted September 10, 2009 Share Posted September 10, 2009 please explain OLDB, I am assuming TPTB is shorthand for Groundspeak ? Sorry. OLDB=Offline data base, like those maintained by GSAK. (Oops, Geocaching Swiss Army Knife.) Link to comment
+novw.nl Posted September 10, 2009 Share Posted September 10, 2009 Thx ! (euhm: thanks) Link to comment
Recommended Posts