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] 4
31
Troubles & Questions / Video attachments: wrong file extension
« on: March 29, 2017, 11:28:35 »
I want to inform you about a small bug: Video attachments (at least on my phone, see Screenshot of Mediainfo) are saved by locus in a MPEG-4 file container (ususal file.extension: .mp4).
But Locus by mistake uses a wrong extension .avi, which denotes a completely different container format (AVI).

So please use extension ".mp4" for video-files, thanks.

32
Grundsätzlich: Ich weiß, dass die Bestimmung der richtigen Seehöhe eines Punktes selbst bei guten GPS-Empfangsbedingungen nicht immer genau und zuverlässig ist. Ganz zu schweigen wenn man sich innerhalb von Schluchten, dichten Wäldern oder am Rand von Felsmauern bewegt.
Gleiches gilt selbst bei Verwendung von sehr genauen .HGT-Dateien. Da deren Genauigkeit das eine ist, aber die Genauigkeit der per GPS ermittelten GPS-Position auch eine wesentliche Rolle spielt: Wenn man z.b, unterhalb einer hohen Felswand geht und die (horizontale) GPS-Position nur 15m falsch ist, wird selbst bei genauestem .hgt-DAten eine falsche Höhe von z.B. 50m oder mehr angezeigt. Diese kann wiederum von Sekunde zu Sekunde stark hin- und herschwanken allein wegen der Ungenauigkeit der Positionsermittlung des aktuellen Standortes mittels GPS.

Noch viel komplexer als die Ermittlung des Höhenwertes eines einzelen Punktes ist die Berechung von summierten Höhenwerten, sprich wieviele Höhenmeter habe ich während meiner Wanderung in Summe bewältigt.

Hier gibt es selbst bei besten Empfangsbedinungen je nach Methode der Filterung/Nachbearbeitung eines Tracks GEWALTIGE Unterschiede, was dazu führt das sich viele Leute immer über völlig unrealistische Höhensummen wundern, die ihnen das GPS anzeigt.

Ich habe z.B. einen längeren Spaziergang bei guten Empfangsbedingungen in eher flachen Gelände gemacht. Track habe ich mit Locus, nur GPS-keine SRTM Daten, aufgezeichnet. Alle Sekunde ein Trackpunkt, mittlere Filterung.

- Am Schluss zeigte mir Locus in den Trackeigenschaften einen Höhensumme von +484 m an - völlig unrealistisch.

- Ich habe dann den selben Track mit den Höhenwerten meines LIDAR-Hgt von Österreich füllen lassen. Ergebnis: Höhensumme nur mehr: +163 m: viel besser! Trotzdem bleibt noch die oben erklärte Ungenauigkeit aufgrund der schwankenden horizontalen GPS-Position (eine in wirklichkeit gerade Strecke ist nach der TRackaufezeichnung immer leicht zick-zack förmig. Das führt dazu das die summierten Höhen immer größer sind als in der Realität.

- Ich habe deswegen den Zick-zack-Track noch vereinfacht (hatte danach nur mehr ca. 20% der ursprünglichen Trackpunkte
dies führte dazu, das auch die Anzahl der fehlerhaften Höhenpunkte abseits der wirklichen Strecke deutlich reduziert wurde. Höhensumme nun: +110 m was sehr gut der Relität entspricht.

Wie man sieht gibts hier selbst bei sehr guten Empfangsbedingungen haarsträubende Unterschiede. Der Laie der sich über die Hintergründe nicht bewusst ist, sagt er hat heute eine Wanderung mit fast 500 Höhenmetern gemacht, obwohl es in wirklichkeit nur knapp über 100 Höhenmeter waren.

Das war ein Einschub um zu zeigen wie extrem schwierig es für Geräte, Software und Benutzer ist für einen Track einigermaßen sinnvolle Höhensummen zu erhalten. Wer nur GPS zur Verfügung hat und keine LIDAR-Höhendaten hat, ist wirklich arm dran wenn sie nicht einen sehr starken Höhenfilter verwenden und am besten Trackpunktaufzeichnung nur alle 10 Sekunden oder so.
Selbst bei Verwendung von genauen SRTM-Dateien bedarf es noch der Einstellung von schlauen Trackaufzeichnunsintervallen und Filterungen.

Du hast aber recht: Wenn man ein Gerät mit Luftdrucksensor hat kann man Höhenmessungen+Summen davon am zuverlässigesten messen. Der Drucksensor erzeugt keine sprunghaften Höhenunterschiede, selbst wenn der horizontale GPS-Empfang zick-zack Sprünge macht.
Und die größte Unsicherheit bei Geräten mit Drucksensor: Der sich bei Wetterumschwung ändernde (Meeres)luftdruck wird durch die schlaue automatische Kalibrierung von Locus mit Hilfe von .hgt-Daten kontinuierlich angeglichen.

Also: Pressure sensor in den Einstellungen aktivieren, und "Automatic calibration".
Einzig offener Punkt: ob man bei "SRTM  Data" in der Praxis besser "optimize GPS values" (GPS wird hauptsächlich verwendet) oder doch "Replace GPS values" (nur .SRTM-Files werden verwendet) bzw. ob diese Einstellung überhaupt für die automatische Kalibrierung verwendet wird müsste man ausprobieren.

33
gibts schon seit einigen Monate da, viel Spaß!
http://data.opendataportal.at/dataset/dtm-spain

34
Hallo, ich versuche es so "kurz"  ;) und verständlich wie möglich zu erklären:

Für jene Gebiete wo es bereits meine LIDAR-DTMs gibt, z.b. für Österreich http://data.opendataportal.at/dataset/dtm-austria , lädst du dir jeweils die 1"-DTM runter. Hier findest du übrigens auch einen Link zum Kartenvergleich meiner LIDAR-Daten zu denen der SRTM-Kacheln: http://goo.gl/DM2YxD

Das 1" ist das genaueste DTM, es gäbe auch noch die 3" die aber ungenauer sind. Mit den 20m und 50m-DTMs kann Locus sowieso nicht umgehen.

Du entpackst alle Dateien und schiebst die .hgt Dateien rüber in den data/srtm-Ordner von Locus. Dort liegen ev. schon Dateien mit dem gleichen Kachelnamen drin, die überschreibst du einfach, denn dabei handelt es sich vermutlich um die "alten" wesentlich ungenaueren SRTM-Höhendaten.

Sodala, da war's schon. Ab nun nimmt Locus zur dynamischen Anzeige der Höhe deiner aktuellen Position ("Dynamic Elevation", zur Berechung von Höhenunterschieden eines Tracks, zum Erzeugung der Kartenschattierungen ("Map shading") dieso genauen Höhenkacheln her.

Diese Höhendaten sind so gut wie immer genauer und zuverlässiger als die Höhenbestimmung per GPS oder auch per Barometer (dieser folgt zwar Höhenänderungen sehr genau, muss aber manchmal nachkalibriert werden, da sich der örtliche Luftdruck ändern kann).
In den Locus-Einstellungen (Menü > Settings > GPS > Altitude manager > "SRTM DATA" kannst du einstellen:
"Optimimize GPS values" (gerade in Zusammenspiel mit einem Barometer sicher eine interessante Sache) oder gleich "Replace GPS values", dann werden ausschließlich diese Höhenkacheln zu Höhenberechnung herangezogen.

Etwas anderes ist die Lage für Länder, wo es solche LIDAR-basierten DTMs noch nicht gibt, sonder nur die SRTM-Kacheln. Diese können zuverlässiger sein als GPS-Höhenempfang, aber auch ungenauer sein, da die SRTM-Kacheln stellenweise Abweichungen von 50m,100m oder mehr haben können, z.B. im alpinen Gelände, in Schluchten etc.
Speziell in gebirgenen Regionen und/oder dicht bewaldeten Flächen würde ich hier zuerst auf barometrische Höhenmessung zurückgreifen falls im Gerät vorhanden.

Zu deinen Zusatzfragen:

- Es kann immer nur eine gleichbenannte Kachel geben und diese erwartet Locus im data/srtm ordner.
Dabei sollte es sich hier immer um die genauest möglichen Kacheln eines Landes handeln (1"-Lidar besser als 3"-Lidar besser als 1"-SRTM besser als 3"-SRTM)
- Wenn du einen Track z.B. für eine Navigation im Vorhinein erzeugst, dann basiert das Höhendiagramm definitiv auf den Höhenkacheln.
Wie dies aber bei der Aufzeichnung eines Tracks ist während du unterwegs bist, weiß ich nicht. Entweder es werden auch hier standardmäßig nur die Höhenkacheln genommen oder aber jene Höhe die Locus live ermittelt anhand der obigen einstelllungen bei (Menü > Settings > GPS > Altitude manager > SRTM).

Müsstest du menion dazu fragen, oder jemand anders der das weiß.

36
Troubles & Questions / Re: option to dim/darken the map layer?
« on: January 26, 2017, 11:20:49 »
Original:


black background, opacity of map: 30%


You can see that the waypoints in the map are not very easy to recognize, the contrast will be even worse if you're out under sunlight. Now if we could quickly dim the map (by using a slider or a button to apply a predefined opacity value), you can see how easy the waypoints now could be seen.

I simulated the dimmed screenshot by choosing "Blank maps > Dark variant" as basemap, the original street map as Overlay and set it's opacity to 30%. Much to complicated for the average user, to many clicks for just to dim the current map.
But if you would really implement such a feature that's would be the method to implent the dimming   :D

37
Troubles & Questions / option to dim/darken the map layer?
« on: January 25, 2017, 15:34:31 »
Hello,
on some maps it is very difficult so recognize point icons. They are very good "camouflaged" within the layout consisting of streets, paths, landmarks etc of the map. So is there an option within Locus quickly to dim/darken the map by a fixed value (e.g. 50%) or by the use of a slider but not darken the point icons?
So the point icons would be better contrast the the map's layer.

38
Hi, I'm using the GSAK-database addon for Locus. It's a pity that it seems to be that its delelopment was stopped.

I noticed the following little bug. When opening a cache from a GSAK-databse using this addon in Locus and looking at the Logs tab of the Cache:
Each logtype has its correct icon left of the logtext. But NOT "Archive" logs. When loading the same cache online with Geocaching4Locus addon, then this "Archive" log has the correct icon.

Would it be posssible for Locus to recognize even  this maybe "malformed" Archive logs of GSAK-addon and put an icon next to the log and below in the Quickinfo-window of a cache?

39
Troubles & Questions / Sunrise/Sunset Values for Dashboard?
« on: September 15, 2016, 22:02:53 »
Hello,
Sometimes I want to know what time the Sunrise is when hiking outdoors. I know, I can use the Weather-function of Locus. But just if an Internet connection is available which is not always true outdoors.

The only offline sunset-info in Locus I found, is the "Sunrise/Sunset"-entry in the large, top text field. But I have to switch to this entry first cause usually I'm displaying other stuff there. And not the (for me prefered) time OF sunrise (e.g. 19:24h) is displayed, but the time TO (e.g. 1:58h) sunrise, which is changing every minute. 

Wouldn't it be possible to provide both, a sunrise- and sunset- item for the use within dashboard? That would be an ideal, offline solution!

40
I want to clearly identify the Navigation route an the map, therefor I can adjust Settings > Navigation > Style on map.

But this Style right now is just used for Navigation mode "Navifation". Not for "Guidance (commands)" and "Guidance (no commands)". Please use the line style also for these 2 Guide Modes.

41
First of all:
- Just download the 1"-sec versions of the DTMs (or if you have little available memory on your phone: 3"-sec).
Not the 20m and 50m-versions, Locus can not use them.

- Yes, copy the .hgt-files into data/srtm folder of Locus.

- If there are already equal named files in this directory, just overwrite them (they have been automatically downloaded by Locus before and are based on less accurate SRTM-data)

You don't have to copy each .hgt-file of a country, just for the areas you are interested in.
Each elevation file (.hgt) represends exactly 1° x 1°, which could automatically derived from the filename. The filename specifies the southwest corner, e.g. "N47E014.hgt" represends an area from N47° to N48° latitude and E14° to E15° longitude.

- If you copied them I recommend to start Locus and once execute
Menu > Settings > Miscellaneous > Clear temporary data > (check all points)
to make sure, no old cached elevation or shading remain.

42
If the country's Lidar-elevation data is Opendata, then maybe. But those of Switzerland, France are not available free. And for Italy (exempt South Tyrol) I'm unsure about the situation. And if Opendata - where to find LiDAR sources of the whole country.

43
Maps / LiDAR- Digital Terrain Models (DTM) of European countries
« on: September 11, 2016, 21:17:19 »
Dear Locus map creators and users!

I want to tell you, that I've created several Digital Terrain Models (DTMs), which are based on precise Opendata LiDAR-elevation data of the country's Geographical Institutes. Right now these are:
The improvements in accuracy, quality and fine details of my model's elevations compared to those of the popular SRTM-datasets are enormous. Especially in mountainous terrain. Take a look at the following Map comparisons: Maps based on LiDAR-DTMs to maps based on SRTM-DTMs: https://bit.ly/dtm-map-comparisions

You can use these new DTMs to create improved, more accurate contour lines in maps. Or you can copy the files for the area of your interest into the correct folder of Locus to improve dynamic elavation values and the shading of the maps in these areas.

I spent many, many Hundreds of hours during my leisure time to search for new Opendata source files, get in contact with national public authorities. To download those giant amounts of source data. To search for errors, plug gaps within the data, compile, resample it and create files in useful formats. To finally provide them to you, FOR FREE.

It would make me very happy, if you honor this work by supporting me with a Donation. I’ve created a DONATIONLINK via PAYPAL:
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=E6GG3NPU88ZQE&source=url

THANK YOU VERY MUCH, Sonny.

44
I just controlled bicubic interpolation using Global mapper. Same result here, also Global mappers maximum is even 1213 m for the 1206 peak. And funny detail: The 1213m maximum is at a position, where in the .hgt file the edge of the peak-pixel is about 50 meters away :o

I also looked at the result using bilinear interrpolation: Using this method, each map-pixel is <=1206 m

Just for interest: Is there a reason why bicubic is better for elevation files than bilinear?

Bicubic:
Original:
Bilinear:

45
I'm using Global Mapper for the creation of the .hgt files. i can define any raster width i like. For my test-hgt for example I used 2200x2200 values which equals about 50m x 35m. (By the way: Does a .hgt file for use in Locus have to be same amount of rows and colums? Or is it possible e.g. to create files 1600 x 2200 - which equals about 50m x 50m - which suits much better to the original 10x10 m elevation files, which are free available for Austria.

Global Mapper has several options to resample the elevation values of the new, wider raster. One is: take the maximum elevation within a box of e.g 5x5 elevation pixel of the source file. So I can make sure that each maxiumum elevation of a peak is still in the new .hgt file for Locus.

But I have to see if this is really the best method now I know that Locus is adding some meters in altitude in the center. I have to take care the resampling method of Global Mapper as well as these of Locus to get optimum offline elevation files. Some tests following  ;)

Pages: 1 2 [3] 4