"Update caches"-bug of unfound caches

[Sonny]

After the import of a .gpx file of Caches a friend sent me, I've to use "Update caches" to replace his found status on these Caches with mine.

This is working fine for Caches he didn't visited yet but I already found => yellow found smiley is set

But it isn't working for Caches he found, but I didn't visit yet. Usually the yellow found smiley of his .gpx should change into the "unfound" Cachetype icon. But it stays a yellow smiley.

You can test this yourself by importing the attached .gpx-file of a "found" Cache and click onto "Update caches"

[Menion]

Hi Sonny,
currently, app preserve "Found" status during update in case, "Geocaching > Keep own data" during import is enabled.

You may look on it also from the second side. In case, you really found a cache by the app, such update may lose your "Found" status.

Is this really a common problem that needs a solution or it happens just once per century?

[Sonny]

Hi Menion,

I already tried to switch off the setting "Keep own data" during import as well as later on "Update Cache". But also in this case the Cache status stays "Found" by mistake. Am I doing something wrong? I also deleted all field notes before within Geocaching settings.

Well this case always takes effect if a friend plans a joint Cache tour, sends me a GPX of planed Caches, and if there are some Caches he already found which I didn't. Then for me it looks like I found thoses caches too because I see a Found-smiley on the map by mistake.

I thought, Locus is updating the Cache status by connecting to Groundspeak via "Live Api"? So there should be no problem to get the correct found/unfound status from Groundspeaks' database.

You're right that "Update caches" should not overwrite a manual entered Offline-"Found" within Locus (field note). But a Cache which have been imported by a .gpx is not a manually entered Foundlog. Hence "Update caches" should sync the Caches with Groundspeaks database.

Maybe Locus could check the existance of a field note of this Cache before setting Status from Found to Unfound in these cases?

But ok, if this is too complicated to implement - it's not the most important Geocaching problem to solve and we can still arrange with these "pseudo-found" smileys due to the import of a foreign gpx-file ;-)

[Menion]

Hi,

firstly sorry. I've checked my code again and the "Found" status is preserved no matter what settings you have set. I wrote this part of the code in 2016. Why does it work like this? Nobody knows now .

the app does not communicate with Groundspeak servers during import. Better, Locus Map does not download any cache data directly.

I still see here the only solution: manually define that for this particular import, existing status should not be preserved. Uff ...

[Sonny]

the app does not communicate with Groundspeak servers during import. Better, Locus Map does not download any cache data directly.

There's no need to communicate with Groundspeak servers DURING IMPORT of a .gpx file. Just after a user wants to update a Cache's status/Listing/Logs by clicking onto "Update caches"

To be honest: I never understood what the setting "Geocaching > Keep own data during import" is exactely for. I'm sure there are good reasons for this setting, maybe they could be explained in more detail within the manual e.g. what data of a Cache exactly is being saved from overwriting.

One example could be the follwong case: I import a .gpx of a friend which contains Usernotes regarding the solution of these Mystery caches. I want to keep these Notes also after clicking onto ""Update caches" although I don't have any Usernotes on this Cache at Groundspeak's Cache site"

[Menion]

"Keep old data" keeps waypoints, logs, "is computed" state, notes, GC votes, images.

As I wrote, Locus Map currently does not download any data from the geocaching.com server related to a single cache, so it is a little more complicated task. This may change in future because G4L is not so actively developed as I would like, but for now, I do not see a simple solution, sorry.