Attributes to Include is Inaccurate

[+Wayfarer-MD]

Via actual testing of Pocket Query, I have found that when using the Attributes to Include the Total Records count can be grossly off.

Additionally, a small number of correct sites can be omitted, and a small number can be duplicated.

My testing

 

Baseline Setup

o A 10 mile radius around Postal Code 21757 (Keymar, MD)

o No restrictions were selected

o Attributes to Include: None selected

> This produced a Total Record count of 43.

> There were exactly 43 listings,and none were duplicated.

As far as I could tell. this was a completely correct listing.

 

Test Setup

This was the same as above, except that

o Attributes to Include: All 42 were selected

> This produced a Total Record count of 248 !!.

> There were only 46 listings - not 248!.

...However, there were 8 duplicates, netting 38 unique ones. The bottom listing on a page was often duplicated at the top of the nest page.

> This also left 5 missing!! There were, in fact, 5 listings in the Baseline results that were not in the Test Results.

...The fact that five were missing bothers me the most. It happens that each had no attributes listed on the web cache page.

 

If anyone is interested, I have saved the detailed results.

Wayfarer-MD

[+gpsfun]

I would send the detailed information to bugs at geocaching dot com

[+Markwell]

I think the problem with your statement about the five missing is that the selection process worked exactly right, but five of the caches may not have had ANY attributes. That's a very distinct possibility.

 

But what I think is happening (and could be backed up by my test results as well is that the system is counting each iteration of the cache being included in its total results, while still only producing the correct results.

 

Example:

In a particular area let's say there's 10 caches.

7 of the 10 caches have the "Less-than-one-hour" attribute

5 of the 10 caches have the "Handicapped" attribute

4 of the 10 caches have the "Thorny Plants" attribute

1 of the 10 caches has no attributes whatsoever

 

My guess is that the system is going through and flagging the results with each attribute pass, so it would show 16 caches in the results (7+5+4=16), but only display 9 of the 10 caches, as only 9 of the 10 have any attributes. Even if I selected ALL attributes, I still wouldn't get that 1 cache out of the 10 since there aren't any attributes.

 

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

What bothers me is that no where is it indicated on these attributes that it's an "OR" statement. I had fully expected this to be an AND statement, where if I selected "Less-than-one-hour" and also selected "handicapped" I could get a list of caches that my wheelchair-bound friend could find in less than an hour. Now I find that this type of search may pull results for a cache that's on top of a 20 foot flagpole in the middle of a parking lot - hardly handicapped, but able to be done in less than an hour.

 

Of course, if the attributes were included in the results of the GPX file, I could filter it further in GSAK, but...

[+Kabuthunk]

Y'know, I don't think the pocket query attribute thing has ever quite worked correctly... but mainly when trying to find things listed as "NOT X attribute". For example, for winter I've been wanting to just download caches that either say either 'winter friendly', or not specify... so the logical thing would be to get a PQ of all caches that don't have a 'not winter friendly' attribute.

 

Yeah... more duplicates than I can count, and if I remember correctly, it gave me some ridiculously low number (like 40 or so) caches within 500km's (or whatever the max distance is).

 

Now I get a seperate PQ of caches that ARE 'winter friendly' (which DOES work, peculiarily enough), and upload those to the GPS with a different icon. Sure, the 'winter friendly' caches are now listed twice (one with a regular icon from the normal PQ, one with the modified icon for winter), but I know which ones I'll more likely tackle in winter. Unfortunately, I can't tell apart the 'not winter accessible' and 'not specified'.

Edited September 4, 2007 by Kabuthunk

[+Jhwk]

Venn diagrams. I haven't seen one of those in years...

[+Wayfarer-MD]

Markwell,

I really like your Venn diagram, it helps to make the analysis quite clear.

I believe it correctly describes the situation, as it fits all the facts that I know of.

Summarizing,

.o For a site to be selected it must have at least one of the selected attributes.

.o If a site has no attributes, then it can't be selected

.o If a site is selected, all of its matching attributes are summed into the Total Record count.

=> This is opposite of what one would like: A count of the selected sites.

 

As a consequence,

.o It would behoove a site owner to select as many applicable attributes as is applicable

.o (The owner should NOT select the Needs Maintenance attribute unless it really does.)

One fix:

.o Add one attribute to Attributes to Include: "No Attributes Claimed"

 

Wayfarer-MD

[+Wayfarer-MD]

I would send the detailed information to bugs at geocaching dot com

Thanks for the email. I'll write it up, including Markwell's analysis, and send it in.

Wayfarer-MD

[+Markwell]

Already submitted.

[+Markwell]

One fix:

.o Add one attribute to Attributes to Include: "No Attributes Claimed"

I agree with everything except that last one. If you really want to capture all of the caches regardless of attributes, don't select any.

[+TrailGators]

I think the problem with your statement about the five missing is that the selection process worked exactly right, but five of the caches may not have had ANY attributes. That's a very distinct possibility.

 

But what I think is happening (and could be backed up by my test results as well is that the system is counting each iteration of the cache being included in its total results, while still only producing the correct results.

 

Example:

In a particular area let's say there's 10 caches.

7 of the 10 caches have the "Less-than-one-hour" attribute

5 of the 10 caches have the "Handicapped" attribute

4 of the 10 caches have the "Thorny Plants" attribute

1 of the 10 caches has no attributes whatsoever

 

My guess is that the system is going through and flagging the results with each attribute pass, so it would show 16 caches in the results (7+5+4=16), but only display 9 of the 10 caches, as only 9 of the 10 have any attributes. Even if I selected ALL attributes, I still wouldn't get that 1 cache out of the 10 since there aren't any attributes.

 

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

What bothers me is that no where is it indicated on these attributes that it's an "OR" statement. I had fully expected this to be an AND statement, where if I selected "Less-than-one-hour" and also selected "handicapped" I could get a list of caches that my wheelchair-bound friend could find in less than an hour. Now I find that this type of search may pull results for a cache that's on top of a 20 foot flagpole in the middle of a parking lot - hardly handicapped, but able to be done in less than an hour.

 

Of course, if the attributes were included in the results of the GPX file, I could filter it further in GSAK, but...

That's a great chart Markwell! I'm a big fan of Venn Diagrams!

[+Wayfarer-MD]

One fix:

.o Add one attribute to Attributes to Include: "No Attributes Claimed"

I agree with everything except that last one. If you really want to capture all of the caches regardless of attributes, don't select any.

Of course, but that was not quite what I was attempting to accomplish:

I wanted to exclude sites having certain attributes(e.g. rock climbing, scuba, ticks), but not to exclude those sites that do not claim any attributes at all.

I now think that None Claimed does not have much merit, and that my objective cannot be met using Attributes to Include (let me know if you think otherwise).

Perhaps, I need to explore Attributes to Exclude (although some say this is buggy).

[+Markwell]

If you think the Attributes to Include is buggy, just wait...

[+Wayfarer-MD]

If you think the Attributes to Include is buggy, just wait...

[/quotee

Just what I need in my life: Another challenge

[+Harry Dolphin]

And sometimes, mapping programs vary as to where the center point is. Some of them are wonky.

If I go to 'Zip Code', the center is 4.7 miles north (in an entirely diffrent zip code!) Other mapping programs will put me three miles north (in a condo development, by the mall. Still in the wrong zip code.)

Might be a difulgaty in mapping programs?