Feature Request: Search for Favorite Points

[GoogleCodeExporter]

What steps will reproduce the problem?
[Please include the relevant parts of your command line, if applicable.
Don't send your password though!]
1.
2.
3.

What is the expected output? What do you see instead?
[If possible, include the last ~10--20 lines of verbose output.]

What version of the product are you using? On what operating system?
[Did you check you're using the latest version?]

Please provide any additional information below.

Original issue reported on code.google.com by Christia...@gmail.com on 23 Mar 2012 at 8:31

[GoogleCodeExporter]

Sorry for this, I hit enter and there it was...

Feature Request: Search for Favorite Points:

How about filtering Caches with min (/max) number of Fav Points?

Original comment by Christia...@gmail.com on 23 Mar 2012 at 8:33

[GoogleCodeExporter]

You read the recent blog post on Latitude? ;)

The idea isn't new, I've discussed it with Thomas several months ago.
Actually, fav count parsing has been introduced in svn r977 on Sep 8, 2011 :)

There's a serious problem: GeoToad is running out of letters.
"-f" currently is occupied by "fun factor" limits, and I have no idea how many 
people are still using it - it made sense when it was invented, but hard to 
maintain (in particular, in non-English speaking regions). It's something that 
has been in GeoToad for so long that I won't throw it out very quickly.
(What about "-g" for "good"? A lower limit should be enough, right?)

And there's another issue which I consider serious: 
Absolute fav counts don't tell you much about a cache - it's rather the ratio 
of points to (paying) visitors that would classify a cache as "must do". 
Otherwise, new but good caches would be under-represented. 
But there's another flaw closely related: 
Very old caches would have seen a lot of visitors but only a few would give fav 
points retrospectively, for several years - so even the "divide fav count by 
visitors" approach would be wrong. 
Also, PMO caches would have a higher ratio because non-payers can't give points 
- at the same "quality level".

To summarize, fav counts, absolute or relative, are prone to distortion from 
several sources. I'd like to leave this issue open for discussion - adding just 
another filter isn't too hard once we have fixed the details.

Original comment by Steve8x8 on 25 Mar 2012 at 2:58

• Changed state: Accepted

[GoogleCodeExporter]

Shouldn't this be an "enhancement", not a "defect"?

Original comment by Steve8x8 on 25 Mar 2012 at 7:12

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I've got a first attempt at "fav factors" _output_ ready. (No filtering yet, 
stay tuned.)

Currently, only the html and text output templates are listing the "fun 
factor", so I will add the "fav factor" to them. For GPX output, I will (some 
day) work on issue 174 and include that information into a "fake" log entry 
(like GSAK does).

The approach at the moment is to ignore the cache's pre-fav (i.e. Feb 1, 2011) 
history completely (which is unfair to older caches which have seen the 
majority of visitors before 2011 and probably will never catch up with newer 
ones).

The formula I've chosen is 
 5 + ln (favpoints / totalfounds)
of course properly clipped to the 0.0 .. 5.0 range.
This will map the "super duper gets points from everyone" cache to 5.0, and the 
average "gets its 1 of 10 share" cache to about 2.5, so is doesn't look 
completely bad.

GC19NBJ, as an example (Bonaire is my favorite testing country, with only 14 
caches), with 12 fav points out of 79 "found it" (almost one third of them by 
basic members) ends up with a fav factor of 3.1 - the fun factor is 1.75 and 
perhaps wrong because of different log languages.

I'll upload to my branch when I've done some more testing.

Original comment by Steve8x8 on 28 Mar 2012 at 9:03

[GoogleCodeExporter]

Working on it in branch

Original comment by Steve8x8 on 2 May 2012 at 1:23

• Changed state: Started

[GoogleCodeExporter]

I've been using this patch for a while now, and found it to work, somehow.
It's far from perfect, mostly because of the late invention of the feature, so 
old caches don't get proper points.
During a cache's lifetime, the lion's share of the "found it" entries happens 
shortly (first year) after publication.
On the other hand, the "fun factor" calculations are language dependent and 
need some training. Anyone come up with training files in Dutch, or Norwegian? 
:) I found that fun factors may be terribly misleading...

The only thing we know for sure: a cache which has a fav factor of 0.0 after 
one year is... perhaps not a big surprise. One would miss a lot of fun if using 
it as a selection criterion.

Should this feature be merged into trunk? What do you think? (And should it 
replace the fun factor selection in the text user interface?)

Original comment by Steve8x8 on 4 Sep 2012 at 11:50

[GoogleCodeExporter]

With the exception of integrating it into the TUI (replacing "fun factor"), 
this feature has been in "stable" starting with 3.16.4 three months ago.
Both "fun" and "fav" factors have their weak points, but I'm very hesitant to 
throw the "fun" code out. I'd love some feedback: Please send me an e-mail
- whether you use "fun" or/and "fav" filtering
- whether you still prefer "fun" over "fav", and possibly wrote your own filter 
rules
- even if you don't care at all (for example because English isn't the language 
of logs in your area)

Original comment by Steve8x8 on 18 Apr 2013 at 1:36

• Changed state: InfoNeeded

[GoogleCodeExporter]

Thanks to your copious feedback, I have become aware that there's public demand 
for having fav factors in the TUI as well. (The command line options will still 
be -g and -G.)
If you depend on fun factors (because you've invested your last two 
years'vacations in tuning the rules), you may still have them via the -f/-F 
option.
This has been in the branch for a long time, and will be rolled out with the 
upcoming stable release from trunk (in a couple of weeks, I guess).

Original comment by Steve8x8 on 3 Jun 2013 at 12:27

• Changed state: FixAvail

[GoogleCodeExporter]

This has been rolled out in both devel and stable 3.16.8 now. Closing.

Original comment by Steve8x8 on 27 Jun 2013 at 9:22

• Changed state: Fixed