Track recording never uses SRTM data?
I downloaded the SRTM data for an area and did the following settings:
- Map - objcets & style > Dynamic altitude: enabled
- GPS and location > Altitude correction > Settings > Altitude offset: disabled
- GPS and location > Altitude correction > Settings > Pressure sensor: disabled
- GPS and location > Altitude correction > Settings > Elevation data: enabled (Optimize GPS altitude)
The SRTM height is shown as expected at the map center. HOWEVER, track recording seems to always use GPS altitude. I can verify by looking at the recorded track data that min and max altitude correspond to the GPS altitude, not the SRTM data.
==> Why isn`t Tracking using the SRTM data?
==> Another question: the Altitude correction > Settings > Optimize GPS altitude: The comment there is saying "Use offline elevation data (I assume this means SRTM data?) to *optimize* GPS altitude values". What does *optimize* mean? Why isn`t it using the SRTM elevation data as is? Same thing if I enable Pressure sensor: it doesn`t seem to use the Barometer altitude directly?
==> Third question: I created a Dashboard and want to display the altitude..One of the options is "Track Record - Altitude (All)". I tried it, but the altitude shown didn`t make much sense to me. What does "Altitude All" mean?
The same question
Hi,
optimization by SRTM files
this should help. Otherwise I`ll improve manual
http://docs.locusmap.eu/doku.php/manu...
question is, why use directly computed altitudes? It doesn`t make sense. If you want to use only computed altitudes, just "Fill altitude" after you stop track record.
dashboard
"Track Record - Altitude (All)" - mean sum of downhill and uphill elevation. So "Elevation" should be probably better here. If you want to see current "Altitude", it`s at top in section "GPS"
Hi,
optimization by SRTM files
this should help. Otherwise I`ll improve manual
http://docs.locusmap.eu/doku.php/manu...
question is, why use directly computed altitudes? It doesn`t make sense. If you want to use only computed altitudes, just "Fill altitude" after you stop track record.
dashboard
"Track Record - Altitude (All)" - mean sum of downhill and uphill elevation. So "Elevation" should be probably better here. If you want to see current "Altitude", it`s at top in section "GPS"
Thank you for quick response!
Ok - so by reading the referenced manual I understand better how the altitude "optimization" works. So, the SRTM data is not more accurate than "average GPS". Interesting though is that the SRTM altitude is right on spot for two locations for which I know the exact altitude.
Dashboard -.yes I know of the GPS Altitude. But I thought that was the un-optiized GPS altitude, but I now understand that this is the "optmized" GPS altitude.
Since you are using the term "Elevation Uphill/Downhill" in the Track Information sheet, maybe Elevation should be used here too to be consistent. Also, I am thinking Elevation makes more sense than Altitude in this context. And maybe "Uphill/Downhill Total" makes more sense than "All".
Thank you once again, Menion!!
Thank you for quick response!
Ok - so by reading the referenced manual I understand better how the altitude "optimization" works. So, the SRTM data is not more accurate than "average GPS". Interesting though is that the SRTM altitude is right on spot for two locations for which I know the exact altitude.
Dashboard -.yes I know of the GPS Altitude. But I thought that was the un-optiized GPS altitude, but I now understand that this is the "optmized" GPS altitude.
Since you are using the term "Elevation Uphill/Downhill" in the Track Information sheet, maybe Elevation should be used here too to be consistent. Also, I am thinking Elevation makes more sense than Altitude in this context. And maybe "Uphill/Downhill Total" makes more sense than "All".
Thank you once again, Menion!!
It also of course depend on source of your SRTM files.
If you use these, that you may download directly over locus, then these files has 3`` precision. This should mean almost 100m on equator, much less (around 60m) in our cca 50° latitude. So imagine that HGT file contain altitude values in 60x60m grid and you`re somewhere in the middle, so it`s more then 30m to closest interpolated! (so also not 100% precise) value. On a flat surface, no problem. In a wild, big problem (similar as with device GPS btw :) ).
So I think that this mechanism should result in quite usable values, because it tries to combine SRTM and measured values.
And un-optimized altitudes aren`t available anywhere. All altitude values you may see or display are values that go through all possible optimizations - altitude offset, pressure sensor, elevation files, filter ... uff and final value :)
It also of course depend on source of your SRTM files.
If you use these, that you may download directly over locus, then these files has 3`` precision. This should mean almost 100m on equator, much less (around 60m) in our cca 50° latitude. So imagine that HGT file contain altitude values in 60x60m grid and you`re somewhere in the middle, so it`s more then 30m to closest interpolated! (so also not 100% precise) value. On a flat surface, no problem. In a wild, big problem (similar as with device GPS btw :) ).
So I think that this mechanism should result in quite usable values, because it tries to combine SRTM and measured values.
And un-optimized altitudes aren`t available anywhere. All altitude values you may see or display are values that go through all possible optimizations - altitude offset, pressure sensor, elevation files, filter ... uff and final value :)
Thank you for spending time on explaining this for me/us. Very useful information/education! Thank you!!
Thank you for spending time on explaining this for me/us. Very useful information/education! Thank you!!
sure, you`re welcome :)
sure, you`re welcome :)
Replies have been locked on this page!