Most visited cache?

[Trekkin and Birdin]

Is there some way to find out what cache has had the most visitors? Not necessarily just in WI, but anywhere?

[zuma]

Check out http://www.itsnotaboutthenumbers.com/meta.php

These would be the most visited by INATN users, but should give you an idea.

zuma

[Team Black-Cat]

@Trekkin’ and Birdin’ wrote:

Is there some way to find out what cache has had the most visitors? Not necessarily just in WI, but anywhere?

Strange you should ask that. GetMeOutdoors and I were discussing how to do exactly that just the other day. I’ve figured out how to get the info out of GSAK, but the ended up with more questions than answers. The oldest caches will generally have the most visitors. The newest caches will have the highest overall find rate. Longest average log length seems to be a good indicator of a “good” cache. (If that’s what you’re actually looking for)
If I come up with anything interesting, I’ll post it here in a few days.
I didn’t realize that INATN had that info already. Even if it’s only based on data submitted via users found.gsk files, it should be pretty accurate.

[GetMeOutdoors]

Yeah, INATN is where I originally started looking too, but I wasn’t happy with the results. Most of them are archived after all. You get alot of virtuals too that way. Most caches have a high find rate in their infancy but then trail off. Older caches have more finds, like que232 said. I guess one good indicator is the most sustainable hit rate. But how do you measure that? We need a stats guy! 😉

What I was looking for was twofold 1) find a place to stash trackables that are headed somewhere specific so cachers passing through could pick them up easily and 2) to learn from other successful caches when designing my own.

It’s too bad there’s not a PQ feature that would measure some of this stuff.

Keep crunchin those numbers I guess.
🙂

[Team Deejay]

The reality is that PQs are not useful for this sort of thing. They only contain the last 4 logs (plus any of your own.) You could, in theory, write a program to view each cache page and record the number of logs, but this would take a while to run and would have to be timed to avoid triggering the circuit breakers on GC.com. Also, note that there is a difference between number of logs versus number of finds. Finds would be much more difficult to extract, as the current log counters don’t seem reliable. I would suggest that the top ten list would be heavy on virtuals in Las Vegas and Washington DC, but that is just a guess on my part.

[-cheeto-]

The reality is that PQs are not useful for this sort of thing.

It seems PQ’s are limited. How does that get fixed? Perhaps request what things you’d like to see improved on the GC.com forums and maybe they might agree and implement some of your ideas….

I always love it when computer system users complain about how the system doesnt do this or that or the other and then probably never take the time to request an enhancement via provided means.

If you are a paying subscriber and would like to see something get better, voice it on the Geocaching website forum thread. I for one want to see continued enhancements for the money I pay to support the site.

The PQ seems to be an area that could use lots of enhancing, mainly because the PQ seems to be the answer to many “can I do this” type questions about the site because they don’t offer the functionality elsewhere. It’s also an area that customers actually PAY to use.

Can you tell I work in software development for a living?

[Team Black-Cat]

You get alot of virtuals too that way.

Those can be filtered out.
Sustained hit rate. Ok. New caches don’t count. Filter ’em. Getting closer.

You could, in theory, write a program to view each cache page and record the number of logs

Or a macro to DL every log. Already doing that, but it’s not practical for the reasons you mentioned.

The PQ seems to be an area that could use lots of enhancing, mainly because the PQ seems to be the answer to many “can I do this” type questions about the site because they don’t offer the functionality elsewhere. It’s also an area that customers actually PAY to use.

PQs are probably the most valuable feature for premium members. I find them a bit limiting, but most cachers probably aren’t data freaks like I am. GC has to draw a line somewhere on how much data a single user can grab, so I can’t complain. All cache logs would be a nice option…

[Team Deejay]

@-cheeto- wrote:

The reality is that PQs are not useful for this sort of thing.

It seems PQ’s are limited. How does that get fixed? Perhaps request what things you’d like to see improved on the GC.com forums and maybe they might agree and implement some of your ideas….

I always love it when computer system users complain about how the system doesnt do this or that or the other and then probably never take the time to request an enhancement via provided means.

If you are a paying subscriber and would like to see something get better, voice it on the Geocaching website forum thread. I for one want to see continued enhancements for the money I pay to support the site.

The PQ seems to be an area that could use lots of enhancing, mainly because the PQ seems to be the answer to many “can I do this” type questions about the site because they don’t offer the functionality elsewhere. It’s also an area that customers actually PAY to use.

Can you tell I work in software development for a living?

It would be simple enough to add some metadata to the pocket queries, such as number of finds, date last found, average words per log, etc. This would take a change to the GPX file standard utilized by Groundspeak and others. Its a pretty basic XML extension and could be changed easily enough. The problem is a) very few people care, b) even fewer would ask for it, and c) they have bigger fish to fry, such as expanding server banks, upgrading hardware, fixing bugs, etc. Something that only 1% of the people would care about isn’t going to make it onto the priority list. Now, if you offered money to fund the development…

[Author]

Posts