[Resolved] GC7MHH8 question from MAN-LIFT

GC7MHH8_14-challenge-where-the-lamb-the-lure-hat"
According to "Project GC" Checker, the challenge is not met.
That cant be true,
because I like was in the salt mine on 31.08.2016 and visited the EC, sh. Investment:
https://www.geocaching.com/geocache/GC38TF7_kristallgrotte-merkers-teufe-800-meter.

greeting
Manfred

The elevation data in the checkers is always measured from the surface of the earth

Please read from Frequently Asked Questions the following

I found a cache with a faulty elevation
Sadly there are a lot of geocaches with these issues. The elevation data does not come from Geocaching.com since it doesn't have that data. We have therefore built our own SRTM-service for the purpose, it serves both SRTM1 and SRTM3. As a fallback for the areas these doesn't cover, we fallback to OpenElevation (OpenStreetMap) and the Google Elevation API.

If you find that a value in Project-GC isn't correct. Please read below how our elevation data works, and also check other services like for example Geonames SRTM3. If you find out that other services has about the same fault tolerance, then there is nothing to do.

We do not do manual changes in the data. But if you find an entry that seems to be off by a lot more than in other services, feel free to report it so that we can investigate.


How is the elevation data calculated?
In November 2017 we rewrote the workflow for elevation from scratch. This will simplify it compared to before.

When a new geocache is either added to our database or the coordinates are updated on an existing one we will add an "elevation job" into a queue. Until this job is executed the elevation will be null and should be considered unknown. Under normal circumstances the job shall be executed within a minute.

The elevation job will then firstly look at our local SRTM1 and SRTM3 data. This data is created by NASA and covers most of the earth. The data is created by measuring the earth using satellites. SRTM1 has a higher resolution, but that data only exists around USA. SRTM3 exists for most other parts of the world, except closer to the poles.

The SRTM1 data has ONE measure point per 30x30 meters, and the SRTM3 data has ONE measure point per 90x90 meters. What this means, is that there is no measurement for every coordinate, and therefore not for every geocache location. So what we do is that we interpolate between the 4 closests values to get a weighted average for the geocache location. In an area which is very hilly, like mountains, this will give a quite big unreliability factor and almost always a too low value. There is however no better way to do this, since the measurements just doesn't exist. Well, except manually adding data for all the geocaches, which we do not do.

Other services - like, for example, Geonames - might have slightly different approaches to how they calculate the data, therefore we will have smaller differences. But they do have similar solutions.

If the coordinates are not covered by the SRTM data we will temporarily fallback to using OpenStreetMap's OpenElevation API. We have found the data in this API to be extremely unreliable, therefore we will only use it as temporary data. Immediately after adding the data from the OpenElevation API we will add a new elevation job into our queues. This time it's flagged to use the Google elevation API.

The Google elevation API has API limits that we have to respect, therefore there might be another few minutes of delay before we actually fetch this data. We are trying to bulk multiple locations together to help us with the rate limits. Meanwhile we are relying on the temporary OpenElevation data added before.

Before using SRTM as our primary source we used AsterGDEM which is created by radar measurements. This data has measure points for every 30x30 meters in a larger area of the earth, which in one way makes it better. But, AsterGDEM is however also known for being affected by radar shadows, which makes the data quite useless for some areas. While it's often more exact, it's usually a lot more wrong once it is wrong. We have found out that switching to SRTM has given us more precise data.

Thanks