Re: Elevation data change?

I've had this cache on my signed-but-not-qualified list for a while:
https://project-gc.com/Challenges//93590

Today I noticed it's green. I ran it... and it lists a bunch of caches that were previously not below sea level. Has there been a change in the elevation data recently or something? I remember a while back there was an announcement, but I did not pass here when I signed it in July, and I had already found most of the caches listed in the output.

I confirm, e.g. my finds with a maximum height of -1 meter have also changed (there are more of them than before)

geoPetros (Slovakia)
info@geopetros.sk
Challenge Guidelines

Yes. I actually thought it made the last newsletter, but I see it didn't. It will make the next. Probably because it's still ongoing.

I checked about half of those in that checker's output. Our new data has them a bit low, but still within reasonable limits. At least GC7B9V8 already existed below zero before, but that one will actually change to +2m when the update is complete.

We have this far updated ~50% of all geocaches in the database. The process will go on for another ~3 months (due to rate-limits in the plan). Geocaches are primarily being updated in a geographical order. Based on latitude if I recall correcty. The process seems to be at latitude 41 now (everything below should be done already).

I'm assuming this elevation update also causes strange behaviour on checkers from time to time? If yes and this is known issue I do wish this had been shared via newsletter. If not, then perhaps it is something to investigate/analyse if the loads/updates could be implemented in a way that checkers are not impacted?

As during the spring I have now had few times cachers contacting me and asking why the checker is not working / has had its counts changing significantly back and forth / has shown false positive with hundreds of caches when in reality it should show less than twenty.

Last occurrence seems to have occurred on March 21 approximate 1800 EET, according to Finnish user/reviewer who reported seeing 208 hits on this
https://project-gc.com/Challenges/GCAVVKZ/94254
Whilst today it showed 15/20

And also non valid data was reported at the same time on this
https://project-gc.com/Challenges/GCAVVJ0/94269


Previous time concrete problems were reported was on 24.2. about problems related to same checkers (invalid "lowest/highest" recognised).

https://project-gc.com/Challenges/GC9ZRZF/73619

In addition to these I have had few less articulated queries indicating this has probably happened more times than just these



Edited 1 time(s). Last edit at 03/23/2026 03:07PM by sm07. (view changes)

sm07 Wrote:
-------------------------------------------------------
> I'm assuming this elevation update also causes
> strange behaviour on checkers from time to time?

I would say no. We are updating the elevation data for every geocache, slowly. The data (potentially) changes from one integer to another.

From the information provided I can't tell what the issue is, or if there is any.

Ok, I think I found the problem now that the users reported proble again to be reappearing after it again had worked properly for some days.

For reason or other the GetLowestCaches seems to be returning nil from time to time. This was the root cause for users seeing totally incorrect (too high) count reported by the checker as checker script (duh) incorrectly used user's found cache as the country's lowest cache when the method returned nil.
The script has now been fixed so that now it properly errors out if PGC method returns nil.

However I'm wondering why this method works properly from time to time and again why it doesn't. Ie why on some days the method returns those true values and on other days it returns nil for the same query? Does this perhaps have now something to do with the updates of elevations?

Most interestingly this error can be seen for many people that have visited at least few countries.

But interestingly enough, at the same time the method returns true value for someone that has only one country (Finland or Sweden) as query parameter.
---
(sm07)
WARNING: GetLowestCaches returned no data for 66 groups
Checking the lowest finds
Data unavailable for Czechia: cannot verify - skipping
Data unavailable for Denmark: cannot verify - skipping
...

(Anneli)
Fetching the lowest cache for 1 groups... 1s
Found the lowest cache for Sweden ... Till havs -93
Checking the lowest finds
Sweden: GC1KCDG,5 ≠ GC3R7DF,-93
Groups processed 1 of 1

sm07 Wrote:
-------------------------------------------------------
> Ok, I think I found the problem now that the users
> reported proble again to be reappearing after it
> again had worked properly for some days.

You are right, more or less (mostly more). Your analyzes made me understand the issue.

I am in a hurry so I'll write this fast. Hopefully it's understandable.
- Elevation ís not a part of geocache data from Geocaching.com.
- Elevation is retrieved from a third party.
- To get geocache data into the system as fast as possible elevation data is handled in a post-process.
- We have rate-limits when fetching elevation data. We can do X calls per day, but we can also do many at a time. Therefore they are queued and we fetch for a few hundred at a time.

The real bug here is that the GetLowestCaches() sorts null as lowest. So when we are missing elevation data you are getting weird results. This bug already existed and could happen, and probably happened fairly often. While refreshing all our elevation data the queue is now longer, so increased chance of awkward data.

I have fixed the code to exclude the null values, which should only affect new geocaches. While we are refreshing all elevation data that could be for a day or two. A more normal flow is maybe an hour or so.

Thanks for being persistent and realizing where the issue was!