Jump to content

Return the find count to cache logs?


Jeremy

Recommended Posts

Do you want the find count listed in the cache logs again?

 

In the new cache page design, caches will actually be generated only once per change to the cache page. That means that the find count will not be accurate, especially for caches that don't get much traffic. However, after each find, travel bug drop-off, or cache update, the stats will update.

 

If the vote is an overwhelming yes, I will re-add the find count, and add a note that explains that the finds are from a snapshot in time.

 

Jeremy Irish

Groundspeak - The Language of Location

Link to comment

When I first started, I thought the counts actually WERE static (duh...I'm not too technical). I was surprised when I returned to a page for a cache I already had done and saw my count had gone up there. I was actually a little disappointed at first.

 

Of course, I realize that Jeremy is NOT proposing that sort of a change. But it's worth considering implementing a feature that would tag your log with a number indicating what your count was when you found that particular cache.

 

Anyway, I'm so used to seeing the counts that putting any sort of count in is better than nothing... just MHO

Link to comment

Badger,

 

The reason that the find counts were removed is because each time you loaded a cache page, Jeremy's computer had to do a search for each cacher and his or her find counts. That not only slowed down his system, but it made it slower for you to view, as well.

 

Removing them and making the cache pages static greatly reduces the load on Jeremy's system. Now it does not have to check the database for find count data.

 

What I offered (and the idea isn't mine, I read it in another thread) is that the find counts be available, but become static, like the rest of the page.

 

Jamie

Link to comment

Don't let this conversation below the poll stray from the original question. Jeremy isn't asking if you want static count numbers on each log.

 

He wants a yes-or-no answer to whether or not you want find counts to be added to the logs with the knowledge that "the find count will not be accurate, especially for caches that don't get much traffic. However, after each find, travel bug drop-off, or cache update, the stats will update."

 

I don't want a bunch of people voting "yes" with the thoughts that he was talking about permanent static counts. icon_smile.gif

 

- Toe.

 

--==< Rubbertoe's Webcam, Photo Albums, and Homepage >==--

Link to comment

Don't let this conversation below the poll stray from the original question. Jeremy isn't asking if you want static count numbers on each log.

 

He wants a yes-or-no answer to whether or not you want find counts to be added to the logs with the knowledge that "the find count will not be accurate, especially for caches that don't get much traffic. However, after each find, travel bug drop-off, or cache update, the stats will update."

 

I don't want a bunch of people voting "yes" with the thoughts that he was talking about permanent static counts. icon_smile.gif

 

- Toe.

 

--==< Rubbertoe's Webcam, Photo Albums, and Homepage >==--

Link to comment

I voted yes, but its a weak yes. I can take it, or i can leave it.

 

But let me see if I have this all right - I believe that at the moment, what Jeremy is saying is that he would put the Cache found number back, and it would update to your current count each time an actual major change was made to that cache's page. (If your going to regenerate the page anyway, its not that much harder to get the current cache counts of everyone who has logged it.) And then the cache counts for EVERYONE who has logs on that page would be updated to their current count.

 

A truely STATIC count would be when someone actually logged the cache, their current found count would be logged, and it would never change for that praticular log on that page. This would more more of a "This is my #xxxx found cache." type of number.

 

Not knowing how all the is programmed, and not knowing the database used, I could not say what would be using more CPU, other then to say, the less things one has to seek and upadte in the database, the faster things run.

 

-Centaur

Link to comment

...it reinstated with a twist. I would like to see it static/realtime. For example, in the LOG record, store the found count for that user. And from the user profile, grab the total found and place them as a ratio. This should be be easy enuff to do since you are querying both records anyway, right?

 

icon_smile.gif

 

Bear & Ting

 

I thought I was a little off, then I looked at my GPS and discovered I accurate to 12 ft.

 

Geocachers don't NEED to ask for directions!

Link to comment

...it reinstated with a twist. I would like to see it static/realtime. For example, in the LOG record, store the found count for that user. And from the user profile, grab the total found and place them as a ratio. This should be be easy enuff to do since you are querying both records anyway, right?

 

icon_smile.gif

 

Bear & Ting

 

I thought I was a little off, then I looked at my GPS and discovered I accurate to 12 ft.

 

Geocachers don't NEED to ask for directions!

Link to comment

quote:
Originally posted by Rubbertoe:

Don't let this conversation below the poll stray from the original question.


Rubber is right. I commented because I think a compromise is acceptable.

 

I can see total find counts by clicking on the user's profile, but to have this info on the cache page real-time is a lot of processing power.

 

I figured that rather than have numbers that would often be inaccurate on the cache page (when accurate numbers are available with one click) a view of finds from a different perspective (that wouldn't require extra processing power) might be an option.

 

Jamie

Link to comment

The pages are now cached in XML into a file. Each time a significant change occurs, the XML is updated with the current information of the cache at that moment in time. The exception of the updates are when a particular cacher finds another cache.

 

I just currently choose not to list the number of caches found, because I don't have caches regenerate if the individual on a particular cache page logs a new find elsewhere.

 

So there is no overhead by re-adding that information. What I'm asking is if it is worthwhile to show that find count, even if it may be outdated.

 

Alternatives are not suggested. This is a yes or no question. Considerations may be made in the future, but they are not part of this poll.

 

Jeremy Irish

Groundspeak - The Language of Location

Link to comment

quote:
Originally posted by Jeremy Irish:

 

Alternatives are not suggested. This is a yes or no question. Considerations may be made in the future, but they are not part of this poll.

 

Jeremy Irish

Groundspeak - The Language of Location


 

Any variation which gives the approximate number of caches found is useful; this helps

1. Knowing if a cacher is a newbie

2. Spotting a cacher approaching celebration numbers (the UK thread regularly celebrates people hitting 100/200 etc)

 

Dave & Nicky

Link to comment

I, for one, do not miss the numbers.

 

For those that DO want the numbers, I don't think that the numbers being outdated by a few days will make a huge difference. Do you really have to know that the cacher who found your cache now has 105 finds instead of the 100 that show on the slightly outdated page?

 

However, the numbers MAY be important to the cacher who found the cache. I can see where it might be frustrating for some to see that "100" stay there when you know it should be "105"! Which will lead to another problem. I can forsee cachers adding notes to the cache just to *bump* the cache to regenerate, thereby cluttering the logs. Just a thought.

 

For me, leave them off. It solves a number of issues.

Link to comment

I voted no.

 

I took a page from BassoonPilots log entrys. I add the number find to the top of my log entry. If my typing a simple 3 digit number helps cut down on server load then it's a no-brainer.

 

If someone logs a no-find on one of caches I can always look up the number of finds they have.

 

One more thing. I have DSL at home and a T3 at work. I can get it as fast as a server can spit it out minus net-lag. I want faster servers.

 

Let it stand for a while and then ask the question again at a later date.

 

====================================

As always, the above statements are just MHO.

====================================

Link to comment

Since this is a yes or no question I said no.

 

I like Jamie Z's suggestion though. I think it'd be neater to know what number someone was up to when they found a particular cache than to know how many total they have had. We have the profile if we want that number.

 

If you light a man a fire, he will be warm for a day; if you light a man on fire, he will be warm for the rest of his life.

Link to comment

Based on the explanation here, I would rather see NO count than a "snapshot" count. If I want to know how many caches someone has found, it's easy to click on their profile.

 

I liked it better with the cache counts in real time, but if it helps speed up the site, having them removed is a good option.

Link to comment

Having a number-even if approximate- in the logs is helpful in the data when you're travelling. When you're caching locally, you probably know the working set of cachers and how much weight to give their comments. When you're out of town and working from paper or pda, you can't click on the profile link to see if the cacher that couldn't find it was perhaps just inexperienced with this kind of cache or if they're "old timers" that probably did due dilligence on the hunt. (And before you warm up the flame guns, I'm not saying that's a sole metric - I've had no-finds on 1/1's myself.)

 

Since the "freshness date" is at the bottom of the page, I'm perfectly happy with the count data being a little stale, but I'd like it to be there.

Link to comment

quote:
Originally posted by Rubbertoe:

Don't let this conversation below the poll stray from the original question. Jeremy isn't asking if you want static count numbers on each log.

 

He wants a yes-or-no answer to whether or not you want find counts to be added to the logs with the knowledge that "the find count will not be accurate, especially for caches that don't get much traffic. However, after each find, travel bug drop-off, or cache update, the stats will update."

 

I don't want a bunch of people voting "yes" with the thoughts that he was talking about permanent static counts. icon_smile.gif

 

- Toe.


 

YES SIR!

 

Dan Wilson - www.Buckscaching.co.uk

Link to comment

quote:
Originally posted by Rubbertoe:

Don't let this conversation below the poll stray from the original question. Jeremy isn't asking if you want static count numbers on each log.

 

He wants a yes-or-no answer to whether or not you want find counts to be added to the logs with the knowledge that "the find count will not be accurate, especially for caches that don't get much traffic. However, after each find, travel bug drop-off, or cache update, the stats will update."

 

I don't want a bunch of people voting "yes" with the thoughts that he was talking about permanent static counts. icon_smile.gif

 

- Toe.


 

YES SIR!

 

Dan Wilson - www.Buckscaching.co.uk

Link to comment

Someone wrote it would be okay to have an approx. number for the cache finds since it wouldn't be changing all the time. I just went to a cache that hadn't been logged for three weeks. I'm new and did around 40 caches last month. I think in active caching areas having counts serveral weeks old would no even be approx.

I vote no. I want speed and will look to get an actual count.

 

-Nurse Dave

 

cool_shades.gif ---I will stand out, I am a raven in the snow.

Link to comment

I'd really like to have some kind of indication on the cache page as to the experience level of the hiders who could and couldn't find it. A sporadically updating page (when a change is made) fits this bill well. And, as others have pointed out,

 

- if you really want to know exactly, you can click their link (I can't see why an exact count could be useful during the hunt);

 

- if the cache owner wants to update the counts on a cache that has low activity, they can make a tiny change to their page (like adding a space) and that would update the page; and

 

- this would still be a significantly lower impact on the servers than the system we had up until now.

 

"Why don't you just ask somebody?"

"No, no. I've got a map. Don't worry about that."

Link to comment

Quote:

[i'd really like to have some kind of indication on the cache page as to the experience level of the hiders who could and couldn't find it. A sporadically updating page (when a change is made) fits this bill well. And, as others have pointed out,

 

- if you really want to know exactly, you can click their link (I can't see why an exact count could be useful during the hunt);

 

- if the cache owner wants to update the counts on a cache that has low activity, they can make a tiny change to their page (like adding a space) and that would update the page; and

 

- this would still be a significantly lower impact on the servers than the system we had up until now.]

 

I agree.

Link to comment

Any data is (in my opinion) better than no data. Indicating the finder's current number of finds at time-of-the-find would be fine, perhaps even more indicative than a rolling ever-changing total.

 

You get to know the folks in your area better as well by seeing their totals, even if it's just their totals the day they found it.

Link to comment

I personally like to see the numbers. Since the change, I haven't seen one bit of speed increase so I don't see that as a reason for the change. I like to see how others in my area are progressing, are they inexperienced/experienced with regard to 'not found', etc.. I feel that it's just nice to know without having to go to another page to find out, TALK ABOUT SLOWING THINGS DOWN!!!

Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...