Low Altitude Cacher badge - bug or feature?

Question

The other day we had the Gold badge for Low Altitude Cacher - now suddenly we have the Ruby badge. What happened? (No, as far as we know we have not logged any low altitude caches in the meantime).

Answer 1

We are fetching elevation information from external services. This is likely due to a change there.

Comments

I agree with the opinion that " it's correct that a geocache plotted in the water should have a negative elevation" but only for those caches that have a physical position there.

Accepting the "listed" position of any Cache for Elevation Statistics purposes , without checking if this is the physical location, severely reduces its value.
May well be that it never showed up to the extent it does now, due to having "0" elevation for many "on water" coordinates, but does not make it correct.

For instance:
GC7ZVK0 is shown in my Statistics as at @ - 6 meters but is situated in the town of Dirksland, next to the main entrance to a house located @ 0 meters. The originial location of this Mystery is about 1500 meters to the SW, still on the Island of Goeree-Overflakkee. This area of the Netherlands is most definitely at sea level and not 6 meters below it...

---

@WeinWalker So what solution do you suggest? Base the elevation statistics on Traditionals only?

---

From professional experience I know that Statistics are only as good as the Data that is behind it... For predictions one can use more fuzzy data, but true statistics can only be based on true values.

I presume that GC-Project does not receive the Final "corrected" Coordinates from GeoCaching.com, otherwise this anomaly would not have occurred.

So since you ask for my straight forward suggestion: "The Elevation Statistics should be based on valid complete data for coordinates. Meaning: Traditionals, EarthCaches, Virtuals, All Event Types and WebCam Caches."

Having given this considerable thoughts, this problem is just "a can of worms" compared to "the Pandora's Box" thinking about all other statistics using the horizontal coordinates in similar fashion. The corrected coordinates of a Multi might be in another county or even country.
But since the truths should be out there, yes same rules should apply there to do it correct.

Taken all this into account, there obviously is no easy way out.

---

As you say, it's "a can of worms". Geocaching dot com also has statistics, they also base it on the data that exists. In cases of plotted isn't equal to final, they use the plotted as well. This has also been the approach by FindStatGen which our Profile stats was inspired by 10 years back. It's the only viable solution.

We don't have the final location for every single geocache. And if we did, and used it, our statistics could in some cases be used to figure out where the final was, which would be bad.

Of the cache types you list, they are more likely to be where they are plotted, but far from always. Some of them can have multiple waypoints, and in several cases you don't even have to visit the plotted coordinates themselves actually.

There are too many corner cases to treat this in a accurate way. It's our believe that one just have to understand what data the statistics are based on, and read and interpret them based on that. There will without a doubt always be anomalies.

The easiest approach is to just use the plotted coordinates. And it probably isn't significantly worse than any more complex solution, which doesn't require manual handling of every single geocache.

---

I still use FindStatGen on my GSAK database. This by the way uses the Corrected coordinates since they are locally stored in your off-line Finds Database.

I rest this case for now since it apparently can not get any better soon.