Under review

Read corrected coordinates from Cache notes

magma1447 11 months ago updated by GCDroid Support 11 months ago 5

At least Project-GC, Neongeo and C:geo parses the Personal cache note for coordinates. Since Neongeo and C:geo was ahead of Project-GC on this, Project-GC copied their behavior. If there are multiple coordinates, the first one is used. If there is also a "real" corrected coordinate, that one has precedence.

Under review

just don't really see use for it. neongeo is dead and cgeo has no access to api so they need to do their own thing.

given the fact that I can store corrected coords for ANY cachetype I don't see why I would try and parse the note.

it also makes it impossible to show the map fast and correctly since I clearly don't want to check for a stored note before hand.

so this get's a likely no from me


In this case it's irrelevant that C:geo doesn't use the API. It can both read and submit to the corrected field with it's web scraping.

Regarding the position on map, it could either be moved after actually opening the geocache, which would be better than today's behavior in my opinion. But you could also read all cache notes from a user on startup for example. However, there are a few users with very very many, which could cause issues.

I know myself and many other Project-GC users uses Final coordinates in the Cache note field instead of as Corrected. The reason is that Project-GC can retrieve all their Cache notes and therefore know about all those, but can't retrieve all of their corrected coordinates, since there isn't such API method. That would require fetching all geocaches with their api token, which would cause quote issues.

From a personal perspective, this is something that is troubling me quite often. But maybe it's just me, and then I need to learn to be better at updating the corrected-field. If there are no votes, then it's a 100% no, for sure. If it gets a few votes, maybe you will reconsider. :)


New API allows to get all caches with corrected coords via search. So this could be changed :-)

And yes, if many +1 votes I will think about a solution. It just needs to fit the concept of having a super fast live map...


That sounds great. I tried to find a way in the API documentation before answering here to see if there was a new solution. I didn't look at the Search function which I assume you refer to. I will look into that once I am done with rewriting the rest.

This may very well change my use case for the future, maybe. :)

despite the upvotes really not liking it... so many issues with parsing coords, so many things can go wrong.

not saying no but at least at the bottom of my list...