Altitude (from GPS) optimizations

[Menion]

I'm opening discussion on topic - altitude in Locus

I'll  ... from conversation that I had with Christian over email (and also with other people here on forum)
"I noticed that the alitude difference of gpx tracks i downloaded (and checked) miscalculated in Locus (track details and diagram also). As attachement a track i want to use it for the alp cross. It has 76,38km and 802m ascendency shown in different software programs (approximately). Locus shows 387m ascendency :-( "

Altitude from GPS is generally a problem, there's no doubt about it. Question is, what's the best way, how to handle it

current solution
Current solution is quite simple, it's based only on a small small filter (set in settings), that optimize altitude a little bit before storing to database!
Altitude results (uphill, downhill, ...) are computed as a sum of altitude change on distance. So change from -2% to +2% are considered as a "flat", others are uphill, downhill

place for improvements
no filter may help to get better values to altitude. It may reduce some huge noises, but ... so question is what we should do with this, to get as good as possible results.

- possibility is to keep current system, but create better filtering method. Some more logical system, that will filter and compute better values

- locus fully support SRTM files, so it's quite easy to compute altitude values during a track record and substitude GPS altitude values, by this computed. Here is question - precision of this method. I did not test it ...

- other possibility or combination?

- you may be also fully satisfied with current system. This is also option

[jusc]

A combination of GPS and calibrated pressure sensor perhaps?

(With the Galaxy Note the display should be always on :cry: )

[tommi]

Hi Menion,
just a few thoughts from my experiences with altitude measurement:
1) With GPS based altitude I had to use strong filter to get useful results. With weaker filter settings I got much higher result for altitude
2) With pressure based altitude measurement I have to use the strong filter again for the same reason as in 1)
2a) I'd like to see automatic pressor sensor calibration before start of track recording based on SRTM for current location
2b) Can I use the altitude based on pressure sensor values also on the fly (i.e. without a track?)
3) I think the -2..+2% aren't necessary if the filter is "strong enough"
4) For track *planning* (add route and measure) I'd like to see an option to calculate the altitude profile based  on e.g. SRTM values along the track. Altitude only for the points on the route isn't sufficient as you would need to define points on all the local minima/maxima (valleys, hills) on the tour which are not always easily visible.
5) Don't know how the current filter really works. Is it a FIR, an IIR filter? Or something proprietary? This not to ridicule you but out of interest as you write "create better filtering method"

As I wrote in the beginning, just a few thoughts, nothing really serious.

[Menion]

@jusc:
I'm sure we all now know, that pressure sensor is is on modern Samsung devices useless. Unfortunately. Also calibration have to be improved. I have already here a topic from one user viewtopic.php?f=10&t=728&p=19237#p19237 so I'm more then sure, improvements are needed. Anyway this will not solve problems, because I think that pressure sensors is not solution on this problem that all may use (limited number of device has pressure sensor btw.)

@tommi:
after quick learn lesson about filters, I discovered that I use very simple IIR filter. Something like

Code Select Expand

Y(i) (final) = Y(i) (measured) * X1 + Y(i-1) * (1 - X1)
Anyway I agree that SRTM data should be probably best way to achieve some usable results. Better filter is probably not a solution right? I'm not much skilled with all these data processing, so some expert advices are of course welcome

[Maksym]

Now I am using pressure sensor and compare height with SRTM data (pressure sensor calibrate using METAR). Sometimes difference is about 2 meters, sometimes more than 10 meters. So SRTM data not very precise. But GPS height, especially in the town or forest,  is very inaccurate, all the time jumps up/down. Btw using SRTM data is good idea (when you can't use preassure sensor, of course). Better GPS filter not a solution, right - you'll get slowly change height and wrong height (GPS height sometimes is very inaccurate).

[tommi]

Better filter could only give better result if we have a noisy altitude signal over time and you use a low pass filter to filter away the noise. Problem with GPS altitude data is that you cannot rely on it having only some noise. Sometimes it has really jumps in it and filtering these away would mean to filter away other meaningful changes in the signal.
So I agree that we cannot easily get a perfectly filtered result.
Results with pressure sensor are a bit better but as you say only few devices have such a sensor and additionally I even there saw jumps in the data which I have  no explanation for.
Unfortunately there are also errors in SRTM data...

[jusc]

@jusc:
I'm sure we all now know, that pressure sensor is is on modern Samsung devices useless. Unfortunately. Also calibration have to be improved. I have already here a topic from one user viewtopic.php?f=10&t=728&p=19237#p19237 so I'm more then sure, improvements are needed. Anyway this will not solve problems, because I think that pressure sensors is not solution on this problem that all may use (limited number of device has pressure sensor btw.)

yes I know. But I support still the idea to use the pressure sensor too, because other special GPS devices like Garmins 62 or Compes Sportiva use it too to improve the altitude data. For me personally it´s annoying that the Note 2 doesn´t use the sensor while the display is off. But on the other side Tommi has shown, that it works correctly with a S3. So not all Samsung devices are failing. And which releated the problem "limited number of devices use a pressure sensor", so I would answer: Locus offers ANT support, but how much devices support ANT?
And Maksym is right, SRTM or GPS data are failing p. e. with trees (forests). I often wondered about altitude data in my tracks of plan areas, there I suddenly should have climbed 30 meters.
So in my eyes a combination of GPS and/ or SRTM and pressure sensor could be a way to improve the altitude data. For those the correct altitude is important, they would buy a phone with pressure sensor, I think.

[Maksym]

I think menion think what to do with users who can't use pressure sensor. That users who can use it still will use pressure sensor. Nobody will disable pressure sensor altitude :-). I hope even add some methods to automatic calibration. But that users who can't use pressure sensor want to have precise altitude too. This topic is also about how to do it.

[Christian]

Hi guys,
i'm the one who started the discussion via email with Menion. Thanx to Menion for the support (even during weekend) and the thread here. Sorry for the delay. I was biking the last days in the spring.
I'm not the specialist in programming or GPS related stuff. I'm just a user who want to use the nice app for mountainbiking (planning tours in / over) alps.
So i understand that :
: GPS ist not precise in recording heights,
: Filters can work, mostly not
: pressure sensor as well,
: different devices from different manufacturer computing ascendency in different ways.

For me a "fix point" in this universe could be solution. Means calibrated values from satellites in SRTM Files.
If i record a track in traditional way - like possible in Locus just now - i will get values with "noises", means wrong data due to influences from the environment during recording. This is what we have now. In some cases the accumulated values of ascendency differ up to 30% from other recordings. (Not unimportant when you are in the alps! Thats why i started the discussion)
May be there is a solution if i had the possibility to compare the recorded values with values of SRTM files. Better Locus should compare this for me.

possibility 1:
point A: recorded height in traditional way: 5m
point B: recorded height in traditional way: 25m
point C: recorded height in traditional way: 7m

point A: height value from SRTM file: 5m
point B: height value from SRTM file: 8m
point C: height value from SRTM file: 6m

Locus can straighten the values.


possibility 2:
give users a choice to use values from SRTM files for their recordings (before or after record) or use the values from their device.


English is not my native language. So if there are any blurs don't hesitate to ask :-)

Christian

[tramp20]

Hi,
I would prefer a combination of GPS and SRTM heights.

[Maksym]

After track recording you now can write height data from SRTM in Locus! Open Track information window, click on down-right button with two cogwheels and choose "Set height".
I agree to use combination of GPS and SRTM but also don't forget about most precise method - pressure sensor. On that devices that can use it (Sony for example).

[tommi]

After track recording you now can write height data from SRTM in Locus! Open Track information window, click on down-right button with two cogwheels and choose "Set height".
I agree to use combination of GPS and SRTM but also don't forget about most precise method - pressure sensor. On that devices that can use it (Sony for example).

I also would prefer a combination (to be discussed average of raw values from each available source, average of filtered values from each available source, ...) [source = GPS, SRTM, pressure]

I think it would help a lot to find the best method if we could produce tracks containing data with all three sources. It should be possible then to do an offline investigation (e.g. with a spreadsheet) what the best method would be.

[Christian]

After track recording you now can write height data from SRTM in Locus! Open Track information window, click on down-right button with two cogwheels and choose "Set height".
I agree to use combination of GPS and SRTM but also don't forget about most precise method - pressure sensor. On that devices that can use it (Sony for example).

Ahhh, thanx for the information. I tried this some times before but the values are not changing until the window with track details is closed and re-opened...
So i checked my favourite track with the values from SRTM files and the ascendency are quite right. That means ...Locus is computing the uphill and downhill and flat area in the right way but with wrong data. I'm right?

@tommi: "average" is always ...un-exactly.

edith says: using my old but reliable HD2 sensor data are not available. So i would prefer a final solution without pressure sensor data.

[Christian]

No, i'm wrong. All tracks updated with SRTM files has distances in flat area = 0 m.

So i guess its easy to calibrate the algorithm within Locus with support of SRTM values...

[tommi]

@tommi: "average" is always ...un-exactly.

Average is one possible attempt to make better data out of bad data. Of course it won't lead to exact data out of bad data.

But the available sources are all bad:
GPS: inaccurate, jitters
pressure: more accurate, less jitters but needs calibration, has shift over time due to weather, not available on all phones
SRTM: It is misbelief to think it is correct. Only one km from my home, I know an area where it is definitely wrong: An area with a change from free field to forest and additionally the forest is on a not steep slope. SRTM more or less ignores that and tells the area of field and forest is flat.