This object is in archive! 

Import of geocaches (gpx)

Peter Klein shared this problem 9 years ago
Solved

When impoting POIs from gpx file currently you have these options

Skip, Ignore, Ovewrite

  • Skip - do not import the new POI
  • Ignore - import new POI - results in two POI with the same name existing POI and the new POI
  • Overwrite - import new POI and delete the old one

I would like to add the option Merge. This would

  • import everything that is in 1:1 relation with this POI (name, atributes)
  • merge everything that is in 1:n relation with this POI (waypoints, logs). This would preserve manually entered waypoints and update original waypoints.
  • preserve note if there is a note for this POI in Locus before the import

Similar behaviour I expect whit direct update from geocaching.com.

Replies (5)

photo
2

Peter I'm sure this feature already eexists. Please check if you have enabled menu > settings > geocaching > keep data during import. This should do exactly what you want

photo
2

You are right it is working OK for import of POIs (geocaches).


Particularly for geocache there is also other way how to update the geocache - through the live API. I mean first to locate the cache by live map and downloading details and later to update the cache. It is also working OK.


What is not working, is the combination of these two methods. Problems are in both directions.


Import and later update.

The imported cache will be updated but logs and waypoints will result in duplicates. (Tested for logs. Waypoints I'll test tomorrow as I'm a Basic member at geocaching.com)


Locate a cache with live map and download details and later import the same cache from other source (gpx export from c:geo in my case).

This results with duplicate geocache. When touching such geocache in Locus a selection is provided with two caches with identical names. One without a date, one with a date (date of creation of the cache at geocaching.com). Locus think these are realy two different geocaches.

Tested with GC11X5R, gpx file attached.


My typical scenario is

- import large number of geocaches (from c:geo and perhaps geoget in the future)

- solve some final waypoints

- go hunting for geocaches

- sometimes it is interesting to update the cache when I've problem to find it

It would be nice to do the last point directly in Locus without duplicating the cache.

photo
2

I partially solved this issue.


When you locate a cache with live map and download it's details then it is stil temporary POI. It is necessary to copy this temporary POI to a folder. Then the import from external source is working OK (when importing to the same folder).


Logs

c:geo identifies logs with it's own IDs. I understand that import result in duplicate logs. I think c:geo should use original log IDs.


Waypoints

Waypoints are identified by coordinates.

Both c:geo and Locus are able to work very with precious waypoints (I think in 2.15 format).

Locus use Groundspeak Api that works with 2.6 numbers.

c:geo use the web geocaching.com and starts with degrees and minutes in 2.3 numbers. c:geo converts it for the export to format 2.15

When Locus imports such waypoints the result it they are sometimes duplicated, sometimes not.

E.g. these coordinates Locus consider to be equal

<wpt lat="48.442049999999995" lon="17.7736">

<wpt lat="48.44205" lon="17.7736">

while these Locus consider to be different

<wpt lat="48.44203333333333" lon="17.770216666666666">

<wpt lat="48.442033" lon="17.770217">


If Locus declare it is able to cooperate with c:geo, it would be nice to round coordinates to 2.6 format when importing from c:geo.

photo
2

Hmm when I firstly read your answers, I though it will be something like this (around export from c:geo)


When Locus checks waypoints for merging, there are two steps.

  1. Locus checks waypoints by it's code. If codes are same, waypoints are same.
  2. Locus checks waypoints by it's name and coordinates. To consider waypoints are same, names has to be same and distance between waypoints should be less then 1 cm. Anyway seems that different after c:geo conversion is more then 1 cm and this cause problems.

Seens that difference in 1E-6 should cause issue up to 11 cm, so I'll change this "check" feature to cover this difference also. Hope this helps.

photo
2

Thanks.

Replies have been locked on this page!