Messages

Bitte keine Google-Drive Links posten, diese können sich ändern, ich erhalte auch jetzt schon zuviele Anfragen, die bei Google Drive ins Leere laufen aufgrund von falschen Links die irgendwer ohne Zustimmung gepostet hat.

Solange das opendata.at Portal noch aufgrund von Umzug offline ist, könnt ihr mich gerne per PM um bestimmte DTMs bitten. Wenn es Neuigkeiten dazu gibt, erfährt ihr das auf meinem Twitter-Kanal.

Weitere Fragen bitte direkt im Thread https://forum.locusmap.eu/index.php?topic=5363.0 posten, danke

data.opendataportal.at is going to be transfered to a new operator, run by a governmental department. After necessary adaptions the site is going to be online again.

The downloadlinks itself are still active, but I don't want to post them in public, cause they could be outdated in the future. So neanwhile you can send me a PM with your DTM of interest and I'll send you the download links.

Btw: If there are news, I'll post it on my twitter channel

Just for info, there's also thread regarding this idea at:
https://help.locusmap.eu/topic/26813-custom-sub-directory-datageocaching

Very strange the fact that LoMaps ignores the new elavation file if creating hillshades, maybe a caching problem?

About the files: Yes, 1" files (an elevation sample ca. each 25m) has a 3 times higher resolution than 3" files (an elevation sample ca. each 75m). And since there are 3x3 1"-samples in the same area of one 3"-sample the resulting filesizes are 9 times larger. 

Download version "DTM Germany 1" v1 by Sonny" from https://data.opendataportal.at/dataset/dtm-germany (you can just download the files of the area of your interest, e.g. N51E011.zip )

LIDAR elevation files for the area of Sachsen-Anhalt have been added some months ago, probabaly that's the reason why LoMaps still using older (=SRTM) elevation sources for this region.

As far as I know, Locus just supports the fileformat of SRTM data (.hgt) right now, so you probably have to convert your .geotiffs.

There's a thread in th Helpdesk https://help.locusmap.eu/topic/please_support_geotiff_format
to add GeoTIFF support for maps, the same would apply to elevation data.

Thank you menion, this feature is working now! 

There a some small things to improve:

1)
Since you choose the GSAK-notation, maybe also keep its CamelCased-tags, since otherwise this could be a potential problem if importing into other software:

Code Select Expand

<gsak:LatBeforeCorrect>47.123456</gsak:LatBeforeCorrect>
      <gsak:LonBeforeCorrect>13.123456</gsak:LonBeforeCorrect>

2)
<gsak:lonbeforecorrect> is filled with Latitude instead of Longitude value by mistake

3)
A new (unnecessary) "Final" Additional waypoint is created during export

Thanks, this is working now 

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.