> Well, I had assumed that you somehow identified AZ teams to build your team
> stats. However, on further inspection, it appears that you are using cache
> stats to build your team stats, and that the number of non-AZ teams logging
> into AZ caches would be in the noise; comparatively. If this is what you
> have done, a similar logic could be used to identify the percentage of
> non-AZ teams in any one cache. Teams with a high percentage of out-of-state
> finds, could be considered non-AZ, and even if they weren't, they would
> appear to travel a lot. So, caches recording a high percentage of log-ins
> from non-AZ/traveling cachers would be good candidates for "travelers" or
> bugs.
I had thought about that already, but there is a a certain amount of noise
to those figures due to people moving in and out of state or people from
other countries that might only have 4 caches in their entire country to
find and they can come to AZ for a day and find enough to "move" them to
our state :)
Like team tj, he found around 100 caches before leaving arizona so he
would have to find 101 cache outside of arizona before he was considered a
non-arizona team. Then with the fact that I would had to calculate the
totals for all the teams then compare the resulting caclulations with the
caches to see what caches had the most. It's a very nasty query on the
database because of having to total all those up and dump them somewhere.
I think that I would rather stick to stats that I can say are 100%
accurate given the data. (can't help what people log or don't log)
We are, or course always looking for new actual data we can add to the
database. If anything ever comes up that tells us where a person is at.
We will add all sorts of stats about locational info.
Brian Cluff
Team Snaptek
(text/plain)