Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Sonny

Pages: [1] 2 3 ... 7
1
Troubles & Questions / Re: Incorrect altitude data
« on: June 07, 2021, 15:19:54 »
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. 

2
Troubles & Questions / Re: Incorrect altitude data
« on: June 07, 2021, 10:12:17 »
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.

3
Maps / Re: What DEM (elevation) formats are supported in Locus?
« on: May 23, 2021, 14:57:59 »
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.

4
Troubles & Questions / Re: Export/Import of computed Geocaches
« on: May 07, 2021, 21:04:32 »
Thank you menion, this feature is working now!  :)

5
Troubles & Questions / Re: Export/Import of computed Geocaches
« on: May 05, 2021, 09:24:22 »
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]
<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


6
Thanks, this is working now  :)

7
Troubles & Questions / Re: "Update caches"-bug of unfound caches
« on: April 29, 2021, 09:26:24 »
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. ;D

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"

8
Troubles & Questions / Re: "Update caches"-bug of unfound caches
« on: April 28, 2021, 21:12:16 »
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 ;-)

9
Troubles & Questions / "Update caches"-bug of unfound caches
« on: April 26, 2021, 13:47:55 »
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"

10
Troubles & Questions / Re: Export/Import of computed Geocaches
« on: April 24, 2021, 12:04:55 »
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]
<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]
<locus:OriginalCoordinates lat="48.123456" lon="14.123456" />


11
Troubles & Questions / Export/Import of computed Geocaches
« on: April 24, 2021, 09:47:28 »
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.

12
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.

13
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.

14
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.   

15
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

Pages: [1] 2 3 ... 7