Keeping other database (GSAK, etc) updated

[+Hynr]

I find that when I hand-check the list of caches that are out-of-date, there is low rate (around 5-10%) which have other issues than being archived. The method we have is a band-aid and does not resolve the need as well as the requested change.

 

Perhaps a specific proposal might help in this thread.

 

I would propose that the PQ generater receive a bit of extra programming to treat archived caches as follows. Instead of including the cache information as normal, include only the following data items:

  <wpt>
<time>2002-06-01T00:00:00.etc (archive date)</time>
<name>GCxxxxx</name>
<sym>Geocache Found</sym>
<Groundspeak:cache id="nnnnn" available="False" archived="True" xmlns:Groundspeak=etc...>
  <Groundspeak:travelbugs />
</Groundspeak:cache>
 </wpt>

 

Note: no names, no descriptions, no coordinates, just the code and the status plus things that are relevant to person requesting the information.

 

The TB list might include the ones stranded in the dead cache. (Or this could be left out if it were to cause problems.)

 

I don't show logs in the example, but I would suggest that any final log by the owner or reviewer be included as this can prevent problems for others. The person who runs the PQ would still have own logs included and the correct found status delivered.

 

Note that this would actually serve the needs of the land manager better that what we have now because it does not deliver coordinates. If <wpt> xml is not legal without Lat= and Lon= then perhaps either of these could work:

 <wpt lat="" lon="">

or

 <wpt lat="90.000" lon="0.000">

The latter is the least desirable as it delivers bogus information, but could work because the north pole is not particularly receptive as a location of a physical cache and most users would probably not go there inadvertently. Forcing both lat and lon to be empty does make sense since the cache no longer has a physical location after it is removed.

 

Such a listing would only be delivered if the archive date is within the past 90 days and would not count against the user-specific limit (e.g. 100 (default), 500 (max) or whatever). I believe that this would meet everyone's needs quite well.

[robertlipe]

Note: no names, no descriptions, no coordinates, just the code and the status plus things that are relevant to person requesting the information.

The shootdown approach has a lot going for it. It's been proposed before many times , including on the first page of this very thread.

Forcing both lat and lon to be empty does make sense since the cache no longer has a physical location after it is removed.[/url]

But GPX is all about physical locations. You can argue with the GPX specs, but they insist on a physical location. Of course, any app that knows about the Groundspeak extensions could easily handle this. If you plop the GPX into something that doesn't know about the GS namespace, you'll get some points on the north pole or the Indian ocean or something else. That doesn't seem so bad.

 

This is totally not a technical problem. It's a matter of understanding that pulling a PQ the morning you hunt isn't always practical and that hunting archived caches is bad for cachers and bad for property managers. In the years this conversation has been going on, those seem to the the points that aren't registering.

[CoyoteRed]

I'd like to point out that the "shoot down method," as Robert calls it, will get the archived caches properly designated sooner than present best workaround.

 

When anyone does not clear the database every time and it takes longer than a single day to get a complete working dataset, then the delay in determining the possible archived cache, because it was not included in the last query, becomes the cycle time. If it takes you a week to pull a complete dataset for your stomping grounds, then the filter would be "those caches not included in GPS files in the last 7 days." Caches archived 6 days ago would not show up even though you've pulled queries in which those would have normally been included.

[+eagsc7]

I find that when I hand-check the list of caches that are out-of-date, there is low rate (around 5-10%) which have other issues than being archived. The method we have is a band-aid and does not resolve the need as well as the requested change.

 

Perhaps a specific proposal might help in this thread.

 

I would propose that the PQ generater receive a bit of extra programming to treat archived caches as follows. Instead of including the cache information as normal, include only the following data items:

  <wpt>
<time>2002-06-01T00:00:00.etc (archive date)</time>
<name>GCxxxxx</name>
<sym>Geocache Found</sym>
<Groundspeak:cache id="nnnnn" available="False" archived="True" xmlns:Groundspeak=etc...>
  <Groundspeak:travelbugs />
</Groundspeak:cache>
 </wpt>

 

Note: no names, no descriptions, no coordinates, just the code and the status plus things that are relevant to person requesting the information.

 

The TB list might include the ones stranded in the dead cache. (Or this could be left out if it were to cause problems.)

 

I don't show logs in the example, but I would suggest that any final log by the owner or reviewer be included as this can prevent problems for others. The person who runs the PQ would still have own logs included and the correct found status delivered.

 

Note that this would actually serve the needs of the land manager better that what we have now because it does not deliver coordinates. If <wpt> xml is not legal without Lat= and Lon= then perhaps either of these could work:

 <wpt lat="" lon="">

or

 <wpt lat="90.000" lon="0.000">

The latter is the least desirable as it delivers bogus information, but could work because the north pole is not particularly receptive as a location of a physical cache and most users would probably not go there inadvertently. Forcing both lat and lon to be empty does make sense since the cache no longer has a physical location after it is removed.

 

Such a listing would only be delivered if the archive date is within the past 90 days and would not count against the user-specific limit (e.g. 100 (default), 500 (max) or whatever). I believe that this would meet everyone's needs quite well.

 

If you did move the waypoints 'outside' of the state in which the cache was in though, the state name could change. This comes into issue when someone lives near a border of a state and pulls PQs from both sides of the line and sorts the data from each state in its own DB. (making it easier to search) Then you have the issue of people going out and searching for a cache that the DB says is there, but was already archived... Thus the reason for the thread. Why don't we just try this:

 

  <wpt>
<name>GCxxxxx</name>
<sym>Geocache</sym>
<Groundspeak:cache id="nnnnn" available="False" archived="True">
 </wpt>

 

Strangely, thats all that'd be needed. If there was Already information on the cache in the DB, then it'd just update the Avaliable and Archived fields. If the cache was NOT already in the DB, then thats all the info you'd get. Or in other words you get the GC Code, Its Cache ID # and that its Archived. Nothing else.

 

The Steaks