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.

+1 vote
622 views
I've got finds near sea level in Massachusetts and Maine that are suddenly going nuts, gaining thousands of meters of elevation. I also used to have a find that registered -1m but no longer. Is there some sort of recalculation or in progress, or a change in where the data is sourced from?
in Miscellaneous by 99celing (770 points)

2 Answers

+4 votes
 
Best answer
There is an update ongoing. We are switching source to a service that have merged several data-sets and tries to use the best one for each area.

We try to regularly monitor it to see if any updated data is really crazy. If you have any specific gc-codes for us to look into we will. For example if something had changed thousands of meters, it's obviously wrong.

Update: I can see that GCMVJ4 is at 5000 meters height in our data, while the API says less than 40 meters. I do not have a god explanation right now, but this is worrying.

Update 2: I have temporary disabled updating our elevation data. It will still happen for new geocaches and geocaches changing location though. I just need to think this through. I have raised an issue with the service we are using, and I will also think of how we can counter this ourselves.
by magma1447 (Admin) (243k points)
selected by 99celing
Yes, GCMVJ4 is one. GCX7ED is the other one I noticed. Thanks for looking into it so quickly!
This is a combination of feedback to you, and others, and also a bit of note to self. More notes might follow.

We have this far updated over 0.5 million geocaches. Our of those, ~250 have changed more than 100 meters. When removing those that are hidden at latitude,longitude = 0,0 there are only 204 left that has changed more than 100 meters.

With our old data-set we had quite crappy data in the sea. For example 0,0 had 0 meters elevation. So that's an improvement, besides the fact that the geocaches likely aren't actually hidden there.

At a fast glance it looks like almost 41 of these 204 also might be geocaches in the sea, which should then be considered an improvement (technically).

So there are ~160 of them left for us to manually review, to see what's happening here. I'll probably save that for tomorrow though.

I am afraid most issues will be in large cities with sky scrapers. That this is some radar shadowing effect, from scanning elevation using radar technology.

PS! For fun I have hand picked two random locations. The first one wasn't super clear, but might be worse now than before. The second is an improvement.
33.084683,-114.143383  1010.00 => 1144
1155 meters quite nearby according to Wikipedia.
We have now made some changes. We look at two services and the difference in the elevation data and try to automatically figure out if the data is reasonable or not.

To illustrate the issues I received this map from the guy behind the service we use.
https://user-images.githubusercontent.com/10361305/92341394-6a628180-f072-11ea-88a7-f37357c28592.png

The more red, the higher the elevation. It can clearly be seen that there are some artefacts that doesn't belong around the coast in this example. It's some form of issue when they (yet another project) are merging two data-sets. One data-set that's good on land, and another that's good on water.

We have updated the elevation data of those geocaches that we could easily find straight away, and now we are restarting our process from scratch. 6.8 million geocaches to go through agian :)
0 votes
There recently was a similar question regarding altitudes :
https://project-gc.com/qa/?qa=25136/low-altitude-cacher-badge-bug-or-feature

To summarize a bit : the elevation data is fetched from an external source and may indeed change. I'm not sure how much control Project-GC itself has over this.
by AxelFox (3.8k points)
...