Location data from Reverse (locationless) caches still included in some statistics [closed]

Question

When I first started using project-gc, I got a lot of fancy badges that I may not have deserved. In particular, I got diamond in both "Head in the ground" and "The long distance cacher" and platinum in "Head in the clouds". This, it seemed, was due to the stats calculator using data from the type "Reverse (Locationsless) cache". After a while, my stats dropped a few points, since the data from the reverse caches were now left out of the calculation of badges and maps. That is OK, since I have never physically been anywhere near the listed coordinate for those caches.

The places the location data from reverse caches was left out were:

• BadgeGen
• Finds
  • Most NSEW cache found
  • Highest and lowest elevations
• Maps

The places where it did appearently not get fixed:

• Elevation chart (finds) (lists 2 caches > 2500m - not listed on BadgeGen or any other place)
• Stats compare (premium feature) - (lists 13 countries where the count listed all other places is currently 10 (maps, badgegen))

This concludes the bug-report portion of this post. How to handle it is essentially a feature-request. Read on for proposed solutions.

I realize that because of the special nature that surrounds the Reverse caches and the fact that people who have found them are relatively rare makes them a low priority when implementing functionality on the website. I just thought that it would be a good idea to address the problem of the locationless caches by doing one of the following:

1: Eleminate all location-based data from locationsless caches

Eliminate them from any statistics calculation that involves anything that has to do with location since they are locationless. That is:

• Traveled distance (cache-to-cache distance)
• Distance from home
• All elevation-related
• Visited areas (counties/states/countries)

2: Use actually visited location

An alternative that will require more work: Everybody logging a reverse cache had to post a coordinate along with their log. The whole point of those were to locate some object described in general in the cache description and then post its coordinates along with photos of the object. If you have full access to the logs, the coordinates that the individual finder has been to will be there along with his or her log.

I realize that this will be more work, but it will be more representative of where the caches has actually physically been to. Consider it another feature-request (hence the tag) for a week with multiple thursdays in it :)

Answer 1

A very fine and long bug report, so I feel ashamed that my answer will be a lot shorter.

I am unsure what you related to with "Elevation chart", but if it's from Profile stats, I claim that locationless caches are excluded. Please give an example if that isn't the case. GC-code and a link.

We will most likely never exclude them from Stats compare or other parts of the site. They have been excluded from the Profile stats, but that doesn't not mean we exclude them elsewhere. The data is as it is, and every user has their own opinion of if they should be counted or not.

We have chosen your solution number 1, which is the logical way to go, since it's the only way that actually works. We believe we have done this for everything related to Profile stats which is our intention, not for the rest of the site.

One could also argue that if locationless are excluded, so should multi-caches be. Multi-caches has no range limit, they can for example be plotted in Portugal and have their hide in Australia.

To conclude, I do not see any actual bug being pointed out here, but design. Though your point about the elevation chart might be one, but I think you lack information there.

Comments

In relation to elevation data:

Yes, I'm talking about the bar chart in in "Profile stats".

The label on that bar is "<2500" which _does_ match my highest elevation found (2023 m - GC1EMEQ). The next category (bar) going down is "<2000" which should make the bar in question count caches with elevations in the inverval [2000;2500[ m. According to the "Highest and lowest elevations" table on the "Finds" page on "profile stats", the cache with the next highest elevation is on 1540 m (GC28EE6).

Since Groundspeak does not include elevation data (which I imagine from reading Q&A that you are painfully aware of), your assigned elevation data is all I have to go on. I may be blind, but so far the only tool that allows me to list my found caches based on their elevation is that on the "Profile Stats" -> "Highest and lowest elevations". That does make it kind of hard to "give an example if that isn't the case. GC-code and a link.", since I don't know what elevation project-gc assigns to individual caches.

The "Elevation chart" bar chart on the "Finds" page, however, lists _2_ caches that are "<2500m". I get that (GC1EMEQ) should be counted here with its 2023 m. Which is the other cache that the "<2500" bar on the "Elevation chart" includes? As mentioned in the paragraph above, I have no other mechanism with which to either find or eleminate other candidates.

I am not currently a paying member, so I cannot reproduce the "stats compare" table tool listing me as having found caches in 13 countries. The correct number is 10, which is also what the "Profile stats -> maps" and BadgeGen show. Can you confirm that bug?

I will readily grant you that choosing option 1 is fine, which is also why I suggested it. It just seemed that it has not been fully (correctly) implemented. I may be wrong here, but it seems to me that if the profile stats page is not even in consistency with itself, that's a bug report :)

---

Thank you. You nailing it down to that the problem was one of two caches helped a lot. It must admit that it was a bug with the elevation. GC8C6E was included. That "module" as we call it, excluded locationless from the tables, but not the chart. I missed that when I checked the code after reading your input the first time.

A fix for that has been applied in the development environment and will most likely go live in the weekend.

I can also confirm that stat compare will list you as having found 13 countries instead of 10. But this is by design and not a bug in our eyes. This could of course be argued, but our experience is that a lot want them to count, and we therefore use the data as it is.

---

Right. Thank you for the "elevation chart" fix. I will look forward to seeing it being in effect :)

Regarding the number of found countries issue: The "maps" tab of "profile stats" lists it as 10 countries. The BadgeGen tab does the same. How come that you count 3 extra countries in the stats compare list? Shouldn't project-gc agree with itself on how many countries I have found caches in and then go with that number ?

---

Profile stats is the exception, upon popular request. And at some point it will be configurable as well.

There is an option to exclude caches in a special bookmark list maintained by Moun10bike @Groundspeak. It mostly contain caches that are "like" locationless, but don't have that type. For example mystery caches plotted on the opposite side of the earth. This can be chosen by each user if it should be used or not. The default is to exclude them.

To be honest, most things with Project-GC is about prioritizing time and tasks. And I do think you are the first one to ask for locationless to be excluded in all location based data all over Project-GC. I am not saying you are wrong, definitely not. But it's also a rare case, mostly affecting quite oldschool geocachers, and most frequently from US I would assume.

---

Right. At this point, all I ask for is consistency.

I know that handling reverse caches is a special case that very few people care about at all, since (as you put it) only "quite oldschool geocachers" have found them - a phrase that I will consider a compliment :)

I frankly don't care whether the actual location of locationless caches is handled or ignored. It just seems entirely illogical that you apply one standard in one part of the page and another one entirely in another. The inconsistency is confusing at best, unfair at worst.

My plea is that you take a stand on how to handle this (which you already have), and then apply that policy across your site.

---

Look, I am sorry if i come across as ungrateful or steep. I am very grateful for the site and the time and effort that you put into it. I understand and respect the need to prioritize time and tasks, and I understand perfectly why handling this is not a priority.

I think that the relevant points of this thread have already been exchanged, and I therefore close it as solved. If anyone else thinks that this is an issue that needs fixing, they should raise the issue seperately.

Again: Thank you for your time and effort - not at least by reading and answering these threads :)

---

No worries. It is hard to "read feelings" in forums, definitely. And sometimes it is a burden to get feedback. I trust that most who "criticize" do it because they find most of the project useful and just wants to help make it better.