Use offline altitude for SRTM data from track recording

No news, sorry.

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

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.

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.

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

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.

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.

Xiaomi Mi 4

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

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.

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.

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.

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.

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.

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.

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.

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.

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?

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

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.

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.

@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?

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.

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:

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

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?

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.

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.

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.

So even better. I like bicubic.

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

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.

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.

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.

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.

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.