Request for mechanism for quick determination of status

[+Hynr]

It is clear that over the years one particular request comes up again and again: let us obtain data about archived caches; the answer is always the same, but the need persists. It is clear from past threads that this information will not be included in gpx files for fear that novices will end up with the coordinates of archived caches in their GPSrs.

 

I would like to propose an alternative that will meet the needs of many cachers (not all), especially those premium members who consume a lot of PQ-generated data.

 

The mechanism I am proposing involves a binary file which at each bit in the file signals the archive status. The location of the bit corresponds to the Cache record number; the bit set to 1 would signal that the cache has been archived. A bit set to 0 would indicate that the cache has archive status = true in the database. The file would need a small internal header (of size Y bits) to hold a long-integer that indicates the last relevant bit in the file. Thus, for example, to identify whether cache # 987654 is archived or not, one would poll bit number Y+987654 - the bit would be 1 if the cache is archived, 0 if not. I reference “bits” rather than “bytes” solely to keep the file size (relatively) small even into the future; clearly the programmers would weigh the pros and cons of this technical issue.

 

Note that for the current geocaching database (currently ~1 million are active and ~700k are archived) this file would be just over 200k in size - roughly the size of one moderate-sized jpg (8 times larger if it is done with bytes instead of bits). The time-stamp on the file would signal its last creation date (so users would only need to pull the file if a new one has been created). Even creating such a file once per hour would be adequate for most of us.

 

I would couple this to request a small app that could be provided as java script on a page or as an app for a mobile device; perhaps also as a stand-alone program to run on a PC. The application would cache the file on the user's device and pull a new copy only if a newer file is anticipated by the app. It would accept as input both GC codes (they start with "GC") or cache number (which start with a numeral) and simply return whether that item is archived and the time of the last creation of the status file. Obviously third-party application providers would include tools to make use of this.

[+Harry Dolphin]

It is clear that over the years one particular request comes up again and again: let us obtain data about archived caches; the answer is always the same, but the need persists.

 

I can see that a desire exists. I cannot see that a need exists. (Except for TPTB, and they know how to do it.) Of the 815 caches that I've found that have since been archived, the vast majority were archived for valid reasons: They are missing! (I'd guess that there might actually be ten of them still out there.) So, please elucidate: What is this 'need' that persists????

[AZcachemeister]

As a GSAK user, I just click the status update button to see if a cache has been archived.

Before I became a GSAK user, I visited the cache page to check status. (Admittedly, the archival rate was a bit lower in those days...)

[+Chrysalides]

As a GSAK user, I just click the status update button to see if a cache has been archived.

I've always wondered how that works (but never motivated enough to run WireShark to find out). Seems it might be a borderline (or flat out) TOU violation to me.

[Great Birds]

As a GSAK user, I just click the status update button to see if a cache has been archived.

I've always wondered how that works (but never motivated enough to run WireShark to find out). Seems it might be a borderline (or flat out) TOU violation to me.

 

Clyde is careful about TOU violations in GSAK. This feature is not available in macros because it could cause disruption to the web site. On an individual cache basis it is no different than loading the cache page.

[+Hynr]

It is clear that over the years one particular request comes up again and again: let us obtain data about archived caches; the answer is always the same, but the need persists.

I can see that a desire exists. I cannot see that a need exists. (Except for TPTB, and they know how to do it.) Of the 815 caches that I've found that have since been archived, the vast majority were archived for valid reasons: They are missing! (I'd guess that there might actually be ten of them still out there.) So, please elucidate: What is this 'need' that persists????

If your point is that "need" is not the correct word, then you are absolutely right: none of us NEED to go geocaching; none of us NEED to pay our premium membership fees, etc. But as "need" goes, geocaching.com is a business that has clients and a revenue stream and to this company the clients "desires" should equate to "needs".

 

The rest of what you wrote does not seem to relate to what this thread is about as this has nothing to do with reasons for archiving of caches.

[CoyoteRed]

I can see that a desire exists. I cannot see that a need exists. (Except for TPTB, and they know how to do it.) Of the 815 caches that I've found that have since been archived, the vast majority were archived for valid reasons: They are missing! (I'd guess that there might actually be ten of them still out there.) So, please elucidate: What is this 'need' that persists????

The needs exists if one wants to reduce the server load.

 

Folks who keep a running OLDB are forced to pull full datasets in order to find out which caches are still valid. All caches that have not changed in the last 7 days is wasted as it provides no useful additional information.

 

The one thing that keeps the "Changed in Last 7 Days" is the lack of letting folks the change to archived status. The data sent is only partial due to this one thing.

 

There are all kinds of schemes that have been offered in order to provide useful archived information without providing undesired results. All have, apparently, fallen on deaf ears. My only assumption is Groundspeak really isn't concerned about server load, even when they do other things claiming they are.

[Great Birds]

My only assumption is Groundspeak really isn't concerned about server load, even when they do other things claiming they are.

 

In my observation, Groundspeak's concerns are numerous. They must distribute customer created data to other customers. Because they have no propritary ownership of the original information, they need to distribute it at the lowest possible price. At the same time they must restrict access to the information to hold costs down and to prevent others from copying their database for redistribution, even at some expense.

 

Why restrict access?

 

For example, if I know that I will be caching where cell service is spotty, I'll create a HTML list of full cache descriptions and all the caches I may want. The files are stored on my phone and I use the phone browser to look up cache info. Anyone can easily create a HTML copy of the GC data for caches anywhere and put it on a public server to give away to non-premium members. If a pirate database were easy to keep current with GC data, then it would be a substitute for people willing to be free riders. Groundspeak's few advantages as a distributor of information is the completeness of the data and they do need to protect that.

 

We are their customers and they must provide services that will keep us happy. At the same time, if they don't protect their competitive advantages and free riders take them out of business, we all will be very unhappy. So it is a balance they must find between revenue and satisfaction. By keeping costs down, Groundspeak makes it easy not to free ride. the $30 per year is a pittance compared to other caching expenses and the enjoyment I get from caching. I gladly pay it to be part of this community.

 

I think of it as the security at a store. Walmart, Best Buy and Frys have attendants at the exit doors to reduce shrinkage. Do I like having to prove my purchases? No! Does it matter much to me? Not really. I still will shop at those stores. I don't like having to enter my zip code when I use my credit card to buy gas either, but the benefits of prevention from loss from credit card are more important. Restricting theft through minor inconvenience is a benefit to all shoppers and we have a choice to shop elsewhere. All stores have security and the costs are reflected in their prices. The expenses to prevent theft are a part of life.

 

Yes I would like to have access to a "Changes in the last 7 days" PQ, but if Groundspeak feels it needs to restrict that information, it isn't going to happen and I will have settle with working from slightly stale data or interact with GC in the way the site has set up to provide the most current information. But I will also keep asking Groundspeak to serve me the way I want them to.

[+CCrew]

.

 

I think of it as the security at a store. Walmart, Best Buy and Frys have attendants at the exit doors to reduce shrinkage. Do I like having to prove my purchases? No! Does it matter much to me? Not really. I still will shop at those stores. I don't like having to enter my zip code when I use my credit card to buy gas either, but the benefits of prevention from loss from credit card are more important. Restricting theft through minor inconvenience is a benefit to all shoppers and we have a choice to shop elsewhere. All stores have security and the costs are reflected in their prices. The expenses to prevent theft are a part of life.

Actually, if you research it you're not required to submit to any of the above. So pretty bad examples.

[+Hynr]

Yes I would like to have access to a "Changes in the last 7 days" PQ, but if Groundspeak feels it needs to restrict that information, it isn't going to happen ...

You're not making sense to me. That feature has existed for as long as I have run PQs (since 2003).

[+Chrysalides]

Yes I would like to have access to a "Changes in the last 7 days" PQ, but if Groundspeak feels it needs to restrict that information, it isn't going to happen ...

You're not making sense to me. That feature has existed for as long as I have run PQs (since 2003).

From the topic in this thread, I'd guess he means for archived caches to be included when "Changed in the last 7 days" is selected.