Messages

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"

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 ;-)

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"

There's no GPX-standard, cause Groundspeaks' .gpx files always just contains the Header-coordinates or the corrected-Coordinates in its <wpt>-Tags. Groundspeak delivers both coordinates just via API (="Update caches" in Locus)

So you can define an additional tag on your own. GSAK for example (which Locus is able to import in a correct way) notes the Original coordinates following way:

Code Select Expand

<gsak:wptExtension xmlns:gsak="http://www.gsak.net/xmlv1/6">
      <gsak:LatBeforeCorrect>48.123456</gsak:LatBeforeCorrect>
      <gsak:LonBeforeCorrect>14.123456</gsak:LonBeforeCorrect>
</gsak:wptExtension>

So Locus could for example create an additional:

Code Select Expand

<locus:OriginalCoordinates lat="48.123456" lon="14.123456" />

[export]

There's a problem if I export a Cache with computed coordinates (=a cache with Orignal + Corrected Coordinates, marked with red star on Cacheicon in the map. see Screenshots "map with" + "detail with").
After re-importing such a Geocache, Locus doesn't treat it as "computed" anymore and also lost its Original Coordinates (see Screenshots "map without" + "detail without").

This would be important: for example a friend sends me an exported .gpx-file of a planed joint Cache-trip. I import his .gpx file and want to see on the map if he solved some of the "Mystery"-Caches already at home (="computed"), or if this are just the Cache's Headercoordinates and we have to solve them in the field.

Please export Original+Corrected Coordinates (+ "computed" flag if necessary) into the .gpx-file so that Locus is able to read both coordinates after a re-import.

I see.

But please make Locus import this kind of "Pseudo-geocache" waypoints at least as "standard" (non-geocaching) waypoint. Cause Locus' standard waypoints can be filtered by distance/Date/Icon (=Icon of the folder).

The Waypoint within the .gpx file is conform to the GPX-standard, so it is a regular waypoint with name, description, coordinates. The only problem is that Locus' filter function runs crazy (even if I'm just using non-geocache filter parameter which are availabe for standard waypoints too like distance or icon) perhaps because Locus imported it as "Geocache" instead of a standard waypoint.

Hi Menion, the .gpx is attached in the post above

I  think a solution could be that Locus treats every "Geocache" within a .gpx of (for Locus) unknown type or unusual GPX-formating into an own pseudo-cachetype "Other". Icon of this Pseudo-caches could be e.g. a questionmark.

So all filter methods (distance, cachetype) could still be applied to them.

[Non-Geocaching locations]

I'm managing my Geocaches with GSAK and exporting Geocaches to import them into Locus.
I'm using GSAK also to store waypoints of Non-Geocaching locations, therefor I'm labeling this waypoints with GSAK's pseudo-Cachetype "Other".

I can import these "Other" waypoints into Locus like any Geocache, they are named correctly, and drawn in the map with the default icon of Locus' point folder. (import attached .gpx file of a test waypoint into a folder which already contains other standard waypoints or Caches)

But there's one problem: I cannot filter them. An applied filter always returns 0 results (see Screenshots).

Please make these pseudo-Geocaches filterable and within the filter-dialogue give them the point folders' default icon.   

[Austria]

There's a new version (v2) of DTM Austria, my oldest DTM. Therefor I downloaded the latest LiDAR source data of Austria's federal states.

Additionally I created 2 models with finer resolutions (10m and 0.5"). These fine gridded models will kept limited to Austria.

https://data.opendataportal.at/dataset/dtm-austria

[Poland]

By the way: There's one European country left which offers precise 1m-OpenData Lidar source data: Poland.

But it's not possible to download the enourmous data for the whole country due to the limitations in the download methods. I already contacted the Polish office (GUGiK), but they seem not willing to improve their download methods nor offering an alternativem less dense gridded DTM (e.g. 10m) for the whole country which would result in an ideal file size to download.

If somebody of you is interested in a Lidar-DTM of Poland, you could contact them too, to make them understand the request for a countrywide download of their elevtion data.

Info site is:
http://www.gugik.gov.pl/pzgik/zamow-dane/numeryczny-model-terenu

[Germany]

I created new DTM of the whole of Germany. Not each federal state is offering OpenData elevation data yet. Please open the image "_Sources.png" in the download package to check the type of Sourcedata for each region.

https://data.opendataportal.at/dataset/dtm-germany

Furthermore I created a new DTM of Slovakia, please check:

https://data.opendataportal.at/dataset/dtm-slovakia

[Swiss DTMs]

I created a new Version of Swiss DTMs, with great improvements in large parts of the country:
https://data.opendataportal.at/dataset/dtm-switzerland

They are based on new high-quality OpenData sources of Swisstopo.

By the way: I created a Twitter account to post news and answer questions. If you want me to follow:
https://twitter.com/SonnyLidarDTMs

I'm not sure if there are Opendata LiDAR sources avalable for these coutries yet. If you know some, please post the links where to get them.

[DTM of Iceland]

I created a new DTM of Iceland

https://data.opendataportal.at/dataset/dtm-iceland

Have fun!

Since some weeks LiDAR source data of the whole territory of France in its finest resolution is available as OpenData. So during the last weeks I created enhanced DTMs of France:
https://data.opendataportal.at/dataset/dtm-france

Additionally Wallonia (Souther Belgium) also provides their LiDAR sources in its finest resolution as OpenData. So I created enhanced DTMs for Belgium too, now the whole country is complete in highest resolution:
https://data.opendataportal.at/dataset/dtm-belgium

Have fun, Sonny.