Return to Project-GC

Welcome to Project-GC Q&A. Ask questions and get answers from other Project-GC users.

If you get a good answer, click the checkbox on the left to select it as the best answer.

Upvote answers or questions that have helped you.

If you don't get clear answers, edit your question to make it clearer.

0 votes
836 views
For my BadgeGen Head-in-the-clouds award, I have found a cache at 1668m above sea level. The highest badge I've gotten is just 1484m though. Is there a way for me to manually adjust this number so that it is correct? The difference is almost 200m, which is quite a lot, and it's also the difference between silver and gold, so I find it significant.

Thanks!
in Bug reports by thomasnb2 (120 points)

2 Answers

+3 votes

From the FAQ:

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 Groundspeak since they don't have that data. We have therefore build 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 several over services, for example: Geonames, Google and MapQuest.

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, feel free to report it so that we can investigate.

How is the elevation data calculated?

This is actually quite advanced, but we will try to simplify it a bit.

First off, we use different data sets for different areas on the earth. For most of the planet we are using data from the SRTM1 and SRTM3 databases created by Nasa. Nasa has created this data by measuring the height using satellites. SRTM1 has a higher resolution, but that data only exists around USA. SRTM3 exists for 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 fail 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.

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 also known for being affected by radar shadows, which makes the data quite useless for some areas. We have found out that switching to SRTM has giving us more precise data.

For those areas where there is no SRTM1 or SRTM3 data we are falling back to other services which relies on other data.

 

by magma1447 (Admin) (243k points)
0 votes
There could be many reasons for this. Did you achieved that find only recently? One could be that the Project-GC database has not yet synced properly (this might take a few days). Or that the cache is at a location with rapid change in altitude and the two different map databases have the location at a slightly different height. Which cache is it for? Anyway, for me the Head-in-the-Clouds award has always been accurate.
by swirlynail (3.0k points)
This is for the cache "Snota (1668moh)" (GC4KZYV)
I found it back in August, so it was not recently. There are indeed rapid changes in altitude, so that might be what's causing it..
...