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

Thank you for the answer. But how do I find out which cache gave us this badge? I've looked at the PGC page Top elevation caches (lowest) but I don't find a match there (our Ruby badge states that we have found one at -38 meters, but we have not logged any of the caches listed for -38 meters).

---

On the Finds tab of your Profile Stats there's normally a section for Highest and lowest elevation. It would be visible there, but it seems that you have disabled that part of the stats so it doesn't show right now.

---

I have now checked that part of our statistics and it lists GCG3W3 Pure Pearl at -38 meters. So far, so good but some questions still remain:
* Pure Pearl is a virtual cache on the bridge over the Bosporus, not under the water, so a minus elevation doesn't seem right.
* Or, if it still shall be considered to be on -38, why isn't it listed on the PGC page Top elevation caches (lowest)?

---

If the cache is on a bridge over the Bosporus, the cache is effectively in the middle of the water. Elevation is not something that comes from Geocaching HQ, so we can't know if the cache is on the ground, in a tower or in a cave. Thus, all caches are assumed to be at ground level (which is true in the vast majority of cases). In the case of a cache which is in the sea like this one, "ground level" means the ocean floor. The fact that there is a bridge here is not relevant since the elevation services that are available are not exact enough to detect that. The given elevation for a point is in fact the mean elevation for an area that's something like 100 meters square. There's a lot more information about this in the FAQ, if you want the nitty-gritty details.

As for the other question: it is listed there, at place #2 (https://project-gc.com/Statistics/TopElevationlowest?country=Turkey&submit=Filter)

---

Ok, I see the problem - fair enough (good explanation, no more details needed)! But this is obviously a new way to look at it, since we didn't get credit for this low find until the other day (we logged the cache in 2014).

As for the other question: my mistake.

---

It's actually not a new way to look at it. We have always used water depth for geocaches in the water. However the data is (hopefully) becoming better now. The approach is the same though.

---

... or maybe that you now include virtual caches?

---

There is no change regarding Virtuals. They are included in all places I can think of, and has always been.

---

Since the "new" altitude in GC-Project goes around, many Caches I know of in the Netherlands (and elsewhere) have moved "deeper" .

Looking at the above conversation I assume that all cache types with an other final coordinate than their listing coordinate are affected by this. Thus: Mysteries, Letterboxes, WIGs, Multis etc.
The obvious ones are those with their listing coordinates somewhere in/on a river, lake or estuary. In all other cases the effects are more hidden, or correct by geographical luck.

The question remains if current use of this particular coordinate information for the Elevation Statistics is correct or disturbing? The results, as noted by others as well, are far off.

---

It's our opinion that it's correct that a geocache plotted in the water should have a negative elevation (generally), regardless of where the final is. This has always been the design, we are just trying to improve the elevation data itself. The problem before is that most geocaches in the water have had an elevation of zero.

---

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.