Use offline altitude for SRTM data from track recording

Thomas K. shared this idea 5 years ago
Completed

After recording a track, I can fill the altitude. Therefore I select to use offline data (SRTM) from HGT-files. The result is almost perfect. It would be very nice, if Locus would use those altitude-values from the HGT-files *while* recording the track and for the appropriate fields of dashboard (e.g. altitude, inclination (german: "Steigung"))


I know the option "elevation data" of the "Altitude manager", but there is noted: "Result of this optimization, aren't altitudes equal to altitudes from HGT files, just an filtered and little bit optimized measured values" But altitudes equals to altitudes from HGT files is that, what I really want, and what would an almost perfect altitude (only for ground actitivities of course).


My use case: While biking through the forrest, I would like to see the current (almost real) inclination and - that is more important for me - the difference in altitude (dashboard: "Uphill"), that I have driven up to now, and the altitude graph (of a track). Using HGT this seems to be possible from my point of view, with GeoID (and some filter) it is not impossible at all, but the values are not so accurate, especially in the forrest (with out without leafes) the GPS values are very inaccurate in my case.

Comments (33)

photo
1

It is already there in Non-GPS-mode. If I use androids Non-GPS-Location-Mode (WLAN, GSM, ...?), the height for the dashboard and tracking is used from the HGT files is it not?

photo
1

I just want to post an idea for better height from gps, but that is an really better idea. (I have never thought about.) Please implement it, before the trees getting leaves, after that the gps height is totally unusefull for me. Thank you very much. Best regards, Emi.

photo
3

I also think that this may be useful.


Currently in altitude manager is checkbox "Optimize GPS altitude" as you (Thomas) wrote in first post. It should be possible extend this to some chooser, where will be options

  • no improvements
  • optimize (as current solution)
  • replace GPS altitude with computed

Something like this?

photo
1

@Menion: If you mean with "computed" the values from the HGT files, then that would be really great! Thank you very much!

photo
2

Yes, I mean values from HGT.


And please don't thank me. I just discuss about it to make it more clear to me and others. I'm not saying I'll do it now. Anyway I agree it's useful feature, not so complicated to create. Votes will show if there is more people interested in this ...

photo
1

@Menion: I thank you for beeing open for ideas and discussing them. Of course I understand that you cannot realize any ideas or wishes, I have. ;)

photo
1

This is exactly what I wanted too!

http://forum.locusmap.eu/index.php?topic=3735.0

photo
1

Thomas, may I contact you? I am interested in what you write above about the dashboard, uphill etc. and I have not really figured out what you do there.

I would also like to display graphic uphill/downhill information when navigating trails offroad...

email, phone, messaging??

regards, volker

photo
1

Volker, of course you can, but I do not want to post my private mail address here, so please use xzli0b1@crapmail.org in the next three days to send me a mail (de|en).

photo
1

super, check your mailbox :-)

photo
3

IDEA Subject: Automatically apply .HGT altitude data to recorded tracks when saving

My idea/wish is simpler than the original (that collects the votes): it is merely a setting in options for this:


It would be great to have an option to set that altitude data could be saved into the track automatically from the .HGT files right when saving the track after the recording finishes.

Now it is only possible to later open the saved track and select the “Fill altitude” command.

Why?

Isn’t SRTM .HGT data always (much) more accurate?

Or at least could we say that in most cases it is more accurate compared to GPS data?


In this case the user should have an option to set that Locus would use that .HGT data all the time for every recorded track automatically, when saving.

photo
1
photo
1

No news, sorry.

photo
1

Menion, thank you for answering. Curious ... it is complicated to implement or lack of votes?

photo
1

Simple question, complicated answer. This one belongs definitely between easier tasks. Implementation of such features usually depend on many factors, but to be true, mainly on:

- my personal opinion on it's importance

- free time and feeling that I've for a longer period did nothing useful for community

- number of votes of course


Currently I do not think that importance is so high here, my bad feeling about lack of work for community, I've satisfied with new slope shading (which had twice more votes - and was 10 times harder to implement) and free time is currently spend on offline address search and some tasks around. Anyway I count with this feature.

photo
1

Yes, I imagine it must not be easy to decide which idea to give priority. Furthermore when each user considers his idea as the "most important".

Impossible to satisfy everyone ...

We will be waiting :).

Greetings.

photo
photo
2

IDEA: Fill elevation automatically – i.e. use data from HGT files automatically when saving tracks


It would be good to have an option in Settings for using elevation data from HGT files when saving tracks – or even constantly during track recording for more precise measurements.


Regardless of this, i.e. whether this will be implemented or not, it would be great if Locus would display on the statistics screens if the displayed elevation data is based on recorded GPS sensor data or on HGT file data.


This would draw the user’s attention to either manually choose to “fill altitude” (just like how it works now) or not to do that again and again because he might not recall whether he filled altitude from the HGT data already or not.

photo
1

Supplement, new info:


I’ve started to use my new phone, which has a Pressure sensor in it.

With it, altitude values are very-very precise. I would say, almost unreal if I compare to my previous saved tracks’ altitude charts (without srtm elevation data applied). With a pressure sensor you get extremely precise data and a very smooth graph curve.

Even more precise than applying .HGT data to the saved track.

This is new for me.


I don’t know how many percent of current phones have pressure sensor built-in, but I would guess that way more than half of them DOESN’T have, so let me again tell that the GPS data for elevation is EXTREMELY CRAPPY. It’s surreal that how inaccurate it is even with filtering. It’s totally crap.

Hence, I really don’t understand why isn’t that is an automatic process to apply .hgt data if it is present on the device.

Of course, this should be an option to choose via settings, because (in my short experience) altitude data corrected by the pressure sensor beats the accuracy even of the 30m SRTM.

photo
1

In such a case, pressure based altitude is extremely crappy for long term instability and needed corrections for the deviation wrt the standard atmosphere.

photo
1

To my knowledge the pressure-based altitude is continuously calibrated from the GPS. This works well, because the recalibration evens out the GPS altitude errors. It works statistically.

photo
1

Yes, I suppose so. My previous posts were based on incorrect outdated knowledge that such a callibration was one-time event. So the continuos recallibration works about the same as I was suggesting.

photo
photo
1

Hi Arpad. What model phone?

photo
1

Xiaomi Mi 4

photo
photo
1

In addition, if applied directly (either at the end or while recording is in progress), three taps for each track recorded are avoided :) (Option, More, Fill altitude).

Greetings.

photo
1

Hi guys,

what about implementing this feature to next version? :)


I'll need small help anyway.

As I think about it, we have three options:

  1. Fill elevation values when saving track to database
  2. Fill elevation values to every point that is recorded, so just for points in recorded track
  3. Fill elevation values for every received GPS point, so overwrite GPS values


First options does not make sense mainly as someone wrote before - during recording will be used GPS values and computed values will be used just before save. So for whole recording, you will see values you don't care,

Second option looks interesting. On dashboard, charts etc. all values will be already computed from computed HGT values.

Third option is even more aggressive. In this case, no filtering will be used in "Altitude manager" and all elevation values in whole Locus will be based on HGT files. Here should be conflict with pressure sensor.

So, I have own favorite choice, but I would like to hear some opinions from you, who are able to imagine all these options. Thanks!

photo
1

Hi menion,


I am glad to hear. :) :)


I agree, that first option makes no sense. I think, I would be happy with the second or the third option, but I am not sure, which I would prefer. Whereelse are elevation values used beyond recording?


Thanks!

photo
1

Hello Thomas,

good question. I'm checking a code and seems that it is only in "export" (to files) or in "display" (like in top panel, satellite/compass screen, detail of point, etc.).

So major difference between second and third option looks for me like > "can you imagine that you will wants to have sometimes computed elevation and sometimes not (defined in a every recording profile)" or this all should be "set once and forget I ever saw this setting" (defined globally in altitude manager)?


Global option will be little bit more complication on UI, because it should probably be a) current system like various filters, pressure sensors, etc. or b) "automatic usage of computed elevations".

photo
photo
1

I wanted/asked only the option #1 :)

And when it will be realesed I can use automatic export of track finally :)

So after stop recordig > autmatic fill elevation >automatic export ( to Velohero or gpx for me) - now I have to do the two steps by clicking - becouse I dont want to export tracks with elevation from GPS

And I do "fill elevation" for all my records becouse elvation data from GPS are useless.


#2 and #3 can be useful - but not for me I guess - real-time corected altitude data are not intersting for me for hiking and biking. I need uphill and downhill corected elevation data over HGT files before recording for planning/create the track and after finish the track (recording) for statistics.

photo
1

Option #3 in conjunction with Sonny's high quality HGT/ SRTM files could be excellent improvement for phones that don't have inbuilt barometer (most phones?). Display of gradient on dashboard may finally be useful instead of erratic values.

photo
1

#2 respects the track option settings (how often to record), i.e. consumes less energy, typically, right ?


The "fill altitude" function is still needed, BTW. You may change the hgt files for better ones, you may want to correct older tracks etc. etc.

Automation is great, patronizing / castrating users is not :-)

photo
1

I vote for 4, store both data gps and strm altitude. The user can choose which one to display or display both. Locus in all statistics data related to altitude can let the user choose for gps or strm data (positive and negative gain etc).

How can you manage the recording if there are not/incomplete strm data for the portion of map of that track? Just curious.

photo
2

First, thanks Menion for considering any advancement on this topic.


It isn’t totally clear for me what others talking about, I mean, I don’t fully understand how they mean, why is a particular working mechanic good or not good for them…


Based on what Menion outlined, from the 3 possibilities, either 2) or 3) makes more sense compared to option 1).

I’m not sure whether 2) or 3) is the better…


However, I’d like to stress that, in my very short test I’ve found that pressure sensor data is extremely accurate, so most probably it wouldn’t make sense to overwrite the elevation data gained from the pressure sensor.


It makes perfect sense not making it a user choice whether to overwrite GPS elevation data, because it is crap.

So overwriting GPS elevation data with the .hgt data is always a gain in accuracy – it should happen always, automatically.


However, this is not the case with elevation data gained from the pressure sensor.

So I think there should be a choice in the settings whether to overwrite elevation data gained from the pressure sensor; or not to overwrite it.

In my opinion, this is the main question.


As to whether option 2) or 3) would be better, I can’t take a stand.

In any case, make sure to always overwrite GPS elevation data, and either do not overwrite pressure sensor data or make it a user choice.


See my attached images to see the difference in accuracy.

I’ve taken the exact same route twice.

I’ve made a copy of both track – the images showing ‘copy’ in them are the ones where I’ve “filled elevation” from the downloaded 30m SRTM data, i.e. the .HGT file on my device for this region is more precise than the one Locus would download when requested. The 1”, 30m resolution SRTM data is the most accurate what is available.


The “06:56:59” images are about the track recording where my device and Locus have used pressure sensor data.

The “15:57:27” images are about the track recording where I’ve disabled the pressure sensor.

As you can see on the images, the elevation data from the GPS and without .HGT correction (“fill altitude”) is crap; it is extremely bad, it might be considered as an approximate at best.

What you can get with “fill altitude” is fairly good, quite good, I would say.

However, I’ve got the most accurate result with pressure sensor ON, without .hgt correction.

(To help you to assess the accuracy of the track records based on the Statistics that Locus displays, I tell you that the route I’ve taken is totally non-horizontal, i.e. it constantly inclines then declines, with stairs in the middle, with just a few meters of ALMOST horizontal sections. As you can see, again, the track record gained with the pressure sensor turned ON is the most accurate in this regard, too.)


Speed data

I have to add that speed data received from the GPS sensor is equally crap, quite inaccurate – it can only be used to count an average from it, at best.

It would be better if Locus would calculate the speed solely from the track points, I assume.


As a final note, I would add that pressure sensor data can be precise, but its extreme accuracy might be assured by the following setting:

Settings\GPS and location\Altitude manager\Pressure: Automatic calibration according to GPS.

I assume that this setting assures there wouldn’t be measurement inaccuracy caused by change in weather conditions.

photo
1

For devices using pressure sensor, there should be possible

1/ to use pressure based altitude as it has the best local and short term accuracy

2/ as pressure based altitude has the worst long term accuracy, compared to SRTM and GPS, there can be implemented automatic continuous recallibration of the barometer by either SRTM/HGT or GPS values. The calibration would be set to converge to zero filtered difference of pressure based and the other values.

photo
1

Doesn’t the “Settings\GPS and location\Altitude manager\Pressure: Automatic calibration according to GPS” do exactly what you describe?

See the end of my post above.

photo
1

Yes, you are right, but only if it is working continuously, not one-time.

I was not aware it is implemented. Was not it only manually until recently ?

BTW,barometers are very far from being extremely accurate. As accuracy requires both random and bias errors to be low. Extreme accuracy extremely low. But barometers do not have extreme precision nor resolution and have at least 2 sources of systematic bias errors, like trand of pressure and deviations in pressure gradient.

photo
1

I’m not that proficient in measurement as you. You’re probably right – I can’t comment or add anything to your arguments.

I imagine that the quite good accuracy can be reached by the


  • quite bigger sensitivity and responsiveness of the pressure sensor as opposed to the quite crappy altitude values reported by the GPS,

complemented with


  • the continuous, on-going re-calibration of the pressure sensor/elevation data by the GPS/SRTM values.

photo
1

Yes, thats is fine. But there should be ".... by the GPS/SRTM values, for the quite crappy pressure altimeter long-term stability. " :-) You know, measuring by the same metre.

As you would not probably consider as very accurate the computer clocks, giving time with ms accuracy due frequent synchronizing with NTP servers or even GPS time unit.

photo
photo
1

Good afternoon,


so first version, what about ... first version in "Altitude manager"


29f4890dba02be4b13b7c0f37043dc03


And options ...


36f5b775fa33811a6e626b593f2fdc8c

photo
1

Crisp and clear - I trust you'll add the "i" button for those who did not follow this forum track :-)

photo
1

Looks good to me. Thank you!

photo
2

Great.

This way it’s up to the user to decide what he prefers.

He can replace GPS data on a device without pressure sensor; or leave SRTM data unused on a device with pressure sensor turned on.

Nice.


Can you elaborate on “Optimize GPS values”?

What does that do and how?


What would happen if I choose this setting and

a) turn the pressure sensor ON?


b) turn the pressure sensor OFF?

photo
3

I've optimized whole workflow little bit, so precise explanations in order, how steps are performed:

1. Elevation offset

- no comment, it just offset GPS elevation based on parameters

2. SRTM data!

- optimize mode: Locus compute difference between GPS altitude and elevation from SRTM file for last 120 seconds. Computed difference is then used to optimize GPS altitude. So if new difference (GPS altitude vs elevation from SRTM) is different, value is reduced little bit to better match computed difference from previous 120 seconds

- replace mode: GPS value is completely replaced by SRTM elevation

3. Pressure sensor

- best used with "automatic calibration". For calibration will be used altitude from previous steps or SRTM data if they were not used previously. So if pressure sensor will be enabled, previous "SRTM data" step won't have big influence. Which is logical I believe.


4. Filter

- basic filter that just optimize values based on previous values

photo
1

+1.

photo
1

Just stumbled into this interesting thread. Just one remark: New GPS chips as used in modern phones are a lot more accurate than what we were used to. They use GPS, Glonass, Beidou, and possibly more systems (Japan, India). Mine gets a GPS position fix inside a closed room with windows typically in 4 s. Horizontal error is often something like 2 m. Even if you double that for the vertical error, it is still fairly precise, sufficiently precise for almost all typical GPS purposes.


The justification for fixing up the altitude data is shrinking year after year.


Sure, Locus Map is doing an excellent job there, quite useful today, but in a few years that function may become underused.

photo
1

But in case of bad satellite visibility and bad DOP the chip cannot help. IT may help in case of averaging of the static position, but that is increasing precission, not necessery the accuracy. And it may not help in the dynamic scenario like the bike track recording. The major problem is not accuracy itself, but the error time fluctuations.


Aside of that, indoor locasion has often mixed location providers. I have often very precise indoor location even if GPS is OFF.

photo
1

Yep this is THE point. Problem with measured elevation are in inconsistent error value. Once you get +5 metres, a while later -5 metres compare to real value. That cause major issues. Same with repeat measure of same elevation in different date & time.

Using of SRTM values may greatly improve consistency of recorded points even with same systematic error. I believe that this consistency is for common usage a lot more important that "correct" real value.

photo
photo
1

Can we conclude that using the built-in pressure sensor greatly improves the accuracy and also the consistency?

At least if it is constantly re-calibrated?


Can we say that using it is always a very good idea, and improves the overall accuracy of measurement on a per use basis and also across several distinct measures?


Between the following three options regarding elevation:

•GPS data

•SRTM data overwrites GPS data

•Pressure sensor data

Can we say that the best option is the pressure sensor data?

photo
1

I guess even a proponent of pressure based altitude can see major pros and cons of it in Locus usage context.

A1a+b> It somewhat improves accuracy, but not consistency, see also A2.

A2> It could be, it the recalibration is implemented as by continuous progressive way, based on long time constant of differential altitude filter. I do not have handy a device with pressure sensor to test it. The recalibration must not corrupt the smooth altitude recording.

A3>if the point altitude accuracy is the primary priority.

photo
2

Don't overestimate the accuracy of the SRTM data set. It has only one altitude point every 90 (or 30) meters. In any rough terrain or between buildings it is bound to be inaccurate.

photo
1

Hi Libor,


Thanks for your answer.


Re: A3> if the point altitude accuracy is the primary priority.

What else priority could you think of that makes sense?

photo
2

@Hans-Georg: I do not overestimate SRTM accuracy at all, not even of 30m grid, or even better ones as used for recent Alps Openandromaps. I am aware of most of its artefacts, as I have mentioned it more times on various places, as e.g. Glosssary page on my GitHub depository.

@Arpad: Stability and reproducibility. Whatever artefacts SRTM has, it provides for the same points always the same altitude, no matter what happens. The elevation track profiles have minimum noise as the altitude is interpolated .

Pressure based altimeter has to deal with tradeoff to face strong enough GPS filtering to get good absolute calibration, and OTOH not to use too strong filtering to adapt dynamic changes. E.g. a fast altitude change by 200 m during bike downhill ride in cold or hot day can without fast recalibration give 10 m altitude error. To be honest, I am not aware, if pressure sensors have temperature correction a/o how reliable it is.

IMHO, in Locus context, the most important is the shape of altitude profile, minimal noise and resonable elevation statistics. If you climbed 10m along 100 m path on tilted plane (SRTM) or more exact little waved one (pressure) is not that important.

Another question I cannot comment is resolution and precision of the sensor.

An important factor for Menion may be the unified approach.

photo
1

Yes, when consistency between tracks is important, then nothing beats SRTM data.


Whether the smoothing, i.e. the loss of finer detail in the altitudes, is desired or not is an open question. Some users may want it. When I hike along steep and rough paths in the mountains, I may want to know whether I hiked up for 15 m, then down for 15 m. Using only SRTM data would suppress much of this information.


But if the user has the choice of using SRTM data or not, then offering it cannot hurt. The remaining question is, how many users download SRTM data, how many users understand this problem, and therefore how many users make the correct decision. I suspect that only a small fraction of all Locus Map users go into this.


There is even a contrarian effect. When new users check out an app and see too many settings that are unintelligible to them, they might be turned off and use another, simpler app. These are difficult questions and difficult optimizations.


I personally like as much as possible automatic functionality. To put it simply, I don't like settings. What Locus Map could do is check the accuracy of the GPS altitude data and determine a good strategy from that. It could check the repeatability in places that are visited repeatedly or the altitude variation when the device stays in the same place for some time. I'm not sure whether such things are feasible though. They would need more thought.

photo
1

It is not about just inter-track consistency. SRTM is a static model of terrain with static artefacts. GPS or pressure based altitude provide dynamic artefacts.

It is needed to say that all 3 ways have strengths and weaknesses at different aspects.

With long term filtering of static-like position is GPS altitude superior, eliminating short time DOP noise and long term ionospheric noise. But for not static-like measurement +/- 15 m is easily hidden in the shorttime noise.

The reasonable approach is implemented in BRouter , filtering out minor artefacts and real terrain fluctations from SRTM DATA by an altitude hysteresis filter. It is used for route evaluation and for final elevation of ascend statistics. It could be used for GPS altitude as well.

I agree the SRTM data logistics can be improved.

About automation, it is usually challenging to implement a model persuading enough people, that is is better than manual settings. As no model pleases all and a bad one even less.

photo
1

@Libor Poutnik Striz

Re: tilted plane (SRTM)


What does ‘tilted plane’ mean?


I’m curious about the details of the SRTM data structure. For a particular tile/area (30*30 meters or 90*90 meters), does the whole surface have the same (averaged) altitude value?

So essentially it represents a flat and horizontal surface of a 30*30 meters or 90*90 meters tile?

I.e. if one happens to move along the edge of such SRTM tiles on a very steep terrain, then the elevation values in the elevation profile will jump up and down like crazy? From one track point to the next (maybe just 1 meter apart), the elevation value could jump up 20 meters? And then back down 20 meters for the next track point if I happen to move just along the edge of two SRTM tiles on a steep terrain?


Or the SRTM tiles are tilted and while their surface is flat, they can be non-horizontal?

So even if one happens to move just along the edges of SRTM tiles, the elevation profile wouldn’t be any more zig-zagged than if going in any normal, casual manner?

photo
2

Each grid square is represented by a single value of average altitude.( Otherwise they could make finer grids).

Values of 4 adjacent grid "pixels" are taken as altitudes of their centres.

Altitudes for any position between them

Is calculated by bilinear interpolation.

Imagine it yourself as if you took a sheet of paper and attached all 4 corners at 4, generally different heights.

Whatever direction you go-between those 4 corners, the altitude changes linearly.

photo
1

For your (and my) curiosity: apparently it is not the case that SRTM based elevation profile is more consistent on the same path in practice.

Theoretically, yes – if you’ve taken EXACTLY the same path as before.

In reality? It’s less accurate than pressure based elevation, see my inserted screenshots of Locus tracks’ graphs.

I’ve run four different times on the exact same route in the forest. The path is approx. 3 meters wide. Obviously there were slight differences between my paths, depending on whether I’ve moved along on the left or right side at particular places along the route.

But look and see: the elevation profile determined by the pressure sensor (first 4 pics) for these 4 screenshots is more consistent than of that calculated by the SRTM data (second 4 images).

Very interesting, isn’t it?

Pressure sensor based elevation profiles of the same track:

c65c278e92a5e96e8a44de4e09bb6de5

5538169aaa81eb892a083a11cec57fd2

cb432295130fed1159e4fc4d0a298d2d

dc455f5f7d28c9390c26bd5735f01415

SRTM based elevation profiles ("Fill elevation") of the same track:

dc711b6292428875f8240f071c82be43

3666ee254d7bc3c0436f7e616dbc237d

20ce131ee407051652c3a6341af509d4

90c35eca4a2f427faae0dd5ab9a70603

Ps.: For Menion: Is there a thread (help ticket) about calculating speed and maximum speed plus displaying chart of speed calculated by Locus itself as opposed to just displaying the inaccurate values reported by the GPS? Also, the maximum speed data is obviously not real - it is too high and only possible because of the jumps caused by inaccurate positions reported by the GPS. Where can I file this inquiry?

photo
1

Re SRTM tiles

Libor, thanks for your efforts for explaining it, but I still don’t understand it.

If the SRTM tile has the same value (1 value), then two track points (separated by the edge of two adjacent SRTM tiles) can have quite different elevation values, let’s say one of them is 30 meters higher than the other, even if there are only a few centimeters between them (if one track point resides in one SRTM tile and the other is on the adjacent tile with a quite different value).

Or if the tile is tilted, then firstly, the tile has to have at least for values, one value for each of the four corners; and secondly, there are infinite elevation values within one SRTM tile along any line across the tile.

photo
2

Then read it once more.

Or imagine this more simple case.

Left 90m grid tile has elevation 100

Right one has 118

Centr of left one has 100

5 m on the right 101

25 on the right 105

45m on the right, at the edge, 109

50m on the right 115m

Etc.

Regarding SRTM consistency, it provides the same altitude for the same Gps location.

I agree, but since beginning, that pressure altimeter is superior for the altitude profile itself. but is not superior in all altitude aspects.

It has temperature bias, that is removed only at price of Gps altitude notice Or více versa.

photo
2

Good evening guys,

I'm little bit lost in longer discussion. But just for your information > Locus interpolate elevation values from SRTM files with BiCubic interpolation, not BiLinear, so it is interpolated from 16 surroundings points.

And please ... no gaps. All interpolated values are fluent, there are no jumps on border of rectangles.

photo
1

So even better. I like bicubic.

It reminds me 3 kinds of bicubic spline interpolation of Avisynth video resampling.

photo
photo
1

For me this new feature is a great improvement.

I have a question about SRTM mode.

What happens when SRTM mode is applied to points registered with bad accuracy of gps position?

I think we have a bad altitude value.

Why locus don't consider for the altitude calculation only points with good accuracy?

Good accuracy can be 20 m for hgt "1 and 50 for hgt "3.

photo
1

if GPS position is bad, GPS altitude is worse, so it still makes sense. With 10% slope it would make 2 or 5 m., without correction easily 40-100 m.

photo
2

What I tried to explain is that there is not usefull to calculate altitude for points with bad gps position accuracy.

When locus calculates altitude it can ignore points with bad accuracy or apply an altitude as average from previous and next point with good accuracy.


Example:

point A good accuracy apply SRTM

point B bad accuracy ignore the point from altitude statistics or apply an average value from A and C

point C good accuracy apply SRTM.


I know we can limit the recorded points in recording profile with "required accuracy" parameters but this can be a fine tuning option when you want all points recorded also when the accuracy is bad but you want a precise altitude statistics.

photo
1

IMHO, if a point has significantly worse accuracy than others, it should be removed completely.

If not, then you have to work with what you have.

photo
2

I know what you mean but sometimes you are in situations where you want to record a point also if it has bad accuracy.

If you are at the feet of a steep mountain, canyon, in a deep forest etc a lot of points will have bad accuracy but you want to keep your not so good track points recorded because you can lose 1h of track. You can also manage bad point at home with your PC to have a better track, but with no point you have nothing to adjust.

What is true IMHO is that a bad point recorded for example in a canyon can put you at the top instead of the bottom, so my suggestion is to ignore that point in altitude calculation but keep it for the track creation.

photo
1

It is not easy to automatically detect the special case scenarios. IMHO it should be based on the user decision, if SRTM is to be used as altitude replacement or not.


Or doing so as post-processing on demand.


Eventually with pattern recognition, but I doubt Menion would be a fan of it.

photo