This object is in archive!
Incorrect altitude in Alp tour
Answered
Allached is a file in witch I report a tour in the Alps. I discovered a significant difference between the realistic change of altitude and those witch are recorded in the "Statistic". Comparable differences I saw also in many other routes. Could you provide me with informations how I could get more acurate statisic datas?
Files:
LOCUS_Altitude.docx
The same question
Thanks for the quick answer. I will choose the upmost heavy filter and check during a tour tomorrow. Regards Hans
Thanks for the quick answer. I will choose the upmost heavy filter and check during a tour tomorrow. Regards Hans
Hello Hans!
First of all, please upload your track .gpx as well, so that we are able to duplicate this case within Locus.
Your differences to the theoretical values are quite enormous, especially as you wroite in your .docx that your tour always leads upwards and there are hardly any canyons you pass.
But Locus has some clever methods that you can solve your problems. The first one @Falco already told: Settings > GPS & sensors > Altitude manager > Heavy filter
But there's even a better method in Countries where 1"-LIDAR-elevatiotion files are available, in yourt case "DTM Germany_Bayern, 1" which you can download here: http://data.opendataportal.at/dataset/dtm-germany
Install it like explained here: http://forum.locusmap.eu/index.php?topic=5363.0
To make Locus use these elevation files you have to: Settings > GPS & sensors > Altitude manager > SRTM data > "Replace GPS values"
Now Locus saves the track using just the LIDAR-elevation files, and not the jumpy GPS-values.
You even can correct a track with jumpy GPS-values afterwards (like in your case): Open the track > tab "Information" > on the right bottom click on the "^"-icon > More > "Update elevation"
Now the elevation of each trackpoint is replaced with the LIDAR-elevation at this position.
Hello Hans!
First of all, please upload your track .gpx as well, so that we are able to duplicate this case within Locus.
Your differences to the theoretical values are quite enormous, especially as you wroite in your .docx that your tour always leads upwards and there are hardly any canyons you pass.
But Locus has some clever methods that you can solve your problems. The first one @Falco already told: Settings > GPS & sensors > Altitude manager > Heavy filter
But there's even a better method in Countries where 1"-LIDAR-elevatiotion files are available, in yourt case "DTM Germany_Bayern, 1" which you can download here: http://data.opendataportal.at/dataset/dtm-germany
Install it like explained here: http://forum.locusmap.eu/index.php?topic=5363.0
To make Locus use these elevation files you have to: Settings > GPS & sensors > Altitude manager > SRTM data > "Replace GPS values"
Now Locus saves the track using just the LIDAR-elevation files, and not the jumpy GPS-values.
You even can correct a track with jumpy GPS-values afterwards (like in your case): Open the track > tab "Information" > on the right bottom click on the "^"-icon > More > "Update elevation"
Now the elevation of each trackpoint is replaced with the LIDAR-elevation at this position.
Thanks again for the answer. I did the recalculation as you mentioned. The result was not too bad. Remember: The change of altitude acording the topografic map was: 1.199m + 20 m guessed up and downs = 1.219 m. The recalculated result: 1.240. With a diff. of 21 m (1.7%) is good to live. Attached "Schneck".
Today I did an other tour. I set "heavy filter". The result: Up: 1.043 m: down -706 m. The topografic data: 1.036m. In the route is no up and down. So the statistic for "Up" is very good for down very poor. See attached "Kleiner Seekopf"
Tomorrow I try the setting: "Replace GPS values"
Regards and "Happy New Year".
Hans
Thanks again for the answer. I did the recalculation as you mentioned. The result was not too bad. Remember: The change of altitude acording the topografic map was: 1.199m + 20 m guessed up and downs = 1.219 m. The recalculated result: 1.240. With a diff. of 21 m (1.7%) is good to live. Attached "Schneck".
Today I did an other tour. I set "heavy filter". The result: Up: 1.043 m: down -706 m. The topografic data: 1.036m. In the route is no up and down. So the statistic for "Up" is very good for down very poor. See attached "Kleiner Seekopf"
Tomorrow I try the setting: "Replace GPS values"
Regards and "Happy New Year".
Hans
I thought the phone gps would be more capable. But you did proof the oppiside. I guess you need to stick with SRTM data as suggested.
Your topographic map is probably made based on same data and the SRTM aligned result maybe even more true then your map.
But keep in mind that SRTM data will fail if you are close to the montains edge and your GPS signal errors tell that you are 20m off the edge down the montain. A tour near the cliff could produce a lot of errors with SRTM.
@Sonny thank you for your work. I guess you don't have Lidar data from saxony and czechia. A friend of mine had access to some close data of this regions end did resampled them for me to get 1° resolution based on lidar.
Which data did you use for regions you don't get? Because I found out that you have whole europe in 1°
I thought the phone gps would be more capable. But you did proof the oppiside. I guess you need to stick with SRTM data as suggested.
Your topographic map is probably made based on same data and the SRTM aligned result maybe even more true then your map.
But keep in mind that SRTM data will fail if you are close to the montains edge and your GPS signal errors tell that you are 20m off the edge down the montain. A tour near the cliff could produce a lot of errors with SRTM.
@Sonny thank you for your work. I guess you don't have Lidar data from saxony and czechia. A friend of mine had access to some close data of this regions end did resampled them for me to get 1° resolution based on lidar.
Which data did you use for regions you don't get? Because I found out that you have whole europe in 1°
@Locus Team, please have a look at http://help.locusmap.eu/attachments/12974 there is something very strange. There is a 300m hight jump even with heavy filter. This have to be an error.
@Hans did you stop the recording on 13:03? I don't know how this can happen.
Hans please could you do the following:
And then repeat a trip with heavy filter? This would help the team alot to fix the GPS altitude error because I have never seen an GPX file like yours from locus.
With the record sensors data option you will create a NMEA file in the background which contains all information your phone does get. With this file locus team can playback your tour over and over again until the GPS altitude filter is fixed.
If your next tour does create a similar issue like 2018-12-28 I will tell you where to find the NMEA file and then the team does have something to work with. You can just attach your GPX file, we will analyse it and tell you if the NMEA file of this day is interesting or not.
@Locus Team, please have a look at http://help.locusmap.eu/attachments/12974 there is something very strange. There is a 300m hight jump even with heavy filter. This have to be an error.
@Hans did you stop the recording on 13:03? I don't know how this can happen.
Hans please could you do the following:
And then repeat a trip with heavy filter? This would help the team alot to fix the GPS altitude error because I have never seen an GPX file like yours from locus.
With the record sensors data option you will create a NMEA file in the background which contains all information your phone does get. With this file locus team can playback your tour over and over again until the GPS altitude filter is fixed.
If your next tour does create a similar issue like 2018-12-28 I will tell you where to find the NMEA file and then the team does have something to work with. You can just attach your GPX file, we will analyse it and tell you if the NMEA file of this day is interesting or not.
@Hans: your first track up to "Schneck" is ok with the LIDAR-corrected elevation values. Up: 1242 m, down: 1240 m, min. elevation: 1062 m, max. elevation 2220m. The slight 2m difference is due to the up-trackpart and the down-trackpart are not exactly identical and start-coordinates are not exactly the same as the finish-coordinates. And the missing meters to the real elevation of the summit (2260m) are because the Opendata source Lidar-files of Bayern are not as dense as of usual, just with a horizontal grid of 50 meter.
For your tour "Kleiner Seekopf" after "Update elevation" I get +1042 m, -1029m, the reason of the slight difference is the same as explained above. I noticed that the down-section of the track is far less detailed (less points) than the up-section. Maybe you could play with and optimize the tracking-profile and the GPS-auto off values as well?
@Locus-team: but it's strange that Statistics-tab of this track says: "Max.altitude"=2220 m but if i move cursor over this trackpoint on the map the dynamic elevations says "2232m" => 12m difference - why?
@Hans: your first track up to "Schneck" is ok with the LIDAR-corrected elevation values. Up: 1242 m, down: 1240 m, min. elevation: 1062 m, max. elevation 2220m. The slight 2m difference is due to the up-trackpart and the down-trackpart are not exactly identical and start-coordinates are not exactly the same as the finish-coordinates. And the missing meters to the real elevation of the summit (2260m) are because the Opendata source Lidar-files of Bayern are not as dense as of usual, just with a horizontal grid of 50 meter.
For your tour "Kleiner Seekopf" after "Update elevation" I get +1042 m, -1029m, the reason of the slight difference is the same as explained above. I noticed that the down-section of the track is far less detailed (less points) than the up-section. Maybe you could play with and optimize the tracking-profile and the GPS-auto off values as well?
@Locus-team: but it's strange that Statistics-tab of this track says: "Max.altitude"=2220 m but if i move cursor over this trackpoint on the map the dynamic elevations says "2232m" => 12m difference - why?
@Falco:
I don't think that this sudden artificial 300 m high-jump of the track is a problem Locus could or should solve with its filter, even not with heavy filter. The problem here is just Hans' GPS-receiver which successive delivered dramatically false elevation values. Until the difference of real altitude (ca. 1900m) and GPS-altitude (1530m) reached its maximum. Suddenly the GPS-receiver reported correct eleavtion values again, so the jump from 1530m to 1900m in the recorded GPX-track.
But locus can not know which of the altitude is correct (is it the 1900m or the 1530m), so a filter makes no sense in this case.
Maybe Hans' GPS receiver is not good, or it was not positioned not ideal (top of backpack), or terrain was difficult (canyon, woods, high rocks around), or something with his auto-GPS-off settings is not ideal.
about the LIDAR data of saxony and czechia: there's no such available as opendata right now, so I'm not able nor allowed to publish deriveded model of them.
@Falco:
I don't think that this sudden artificial 300 m high-jump of the track is a problem Locus could or should solve with its filter, even not with heavy filter. The problem here is just Hans' GPS-receiver which successive delivered dramatically false elevation values. Until the difference of real altitude (ca. 1900m) and GPS-altitude (1530m) reached its maximum. Suddenly the GPS-receiver reported correct eleavtion values again, so the jump from 1530m to 1900m in the recorded GPX-track.
But locus can not know which of the altitude is correct (is it the 1900m or the 1530m), so a filter makes no sense in this case.
Maybe Hans' GPS receiver is not good, or it was not positioned not ideal (top of backpack), or terrain was difficult (canyon, woods, high rocks around), or something with his auto-GPS-off settings is not ideal.
about the LIDAR data of saxony and czechia: there's no such available as opendata right now, so I'm not able nor allowed to publish deriveded model of them.
@Falco:
I have seen your request to record the sensors datas just now. I will do next tour (need better weather). How should I set "SRTM-datas"? "Optimize" or "Replace"?
In which route occurs the 300 m GPS-jump from 1.530 to 1.900 m? At what point?
If the GPS receiver of the phone would be bad: Why do the horizontal datas fit quite good but not the altitude?
To your other points: I never switched off GPS during a tour. I always wear my phone in the leg pocket of my trouser. Along the route of 28.12. there is no dificult terrain. GPS auto off: 60 sec. /20 m/ 60 sec.
@Falco:
I have seen your request to record the sensors datas just now. I will do next tour (need better weather). How should I set "SRTM-datas"? "Optimize" or "Replace"?
In which route occurs the 300 m GPS-jump from 1.530 to 1.900 m? At what point?
If the GPS receiver of the phone would be bad: Why do the horizontal datas fit quite good but not the altitude?
To your other points: I never switched off GPS during a tour. I always wear my phone in the leg pocket of my trouser. Along the route of 28.12. there is no dificult terrain. GPS auto off: 60 sec. /20 m/ 60 sec.
Replace is your solution. But if you do a altitude filter test tour you need to disable srtm replace.
This one does have an unfiltered jump at 13:03 http://help.locusmap.eu/attachments/12974
Maybe the filter doesn't work well if you use 60s. /20 m/ 60s
Even if your GPS is totaly inaccorate because of it's physikal location in your trousers, the jump should get spread across 5 to 10 points instead of making a huge change on only 1 point. It does just look like the filter didn't do anything or even worse, maybe your gps data is fine and this jump is based on an filter issue.
I hope you will see this error again with enabled record sensor data. You will find the files it at [Locus dir]/data/sensors. We are looking for things like 100-200hm altitude change at only one point.
Replace is your solution. But if you do a altitude filter test tour you need to disable srtm replace.
This one does have an unfiltered jump at 13:03 http://help.locusmap.eu/attachments/12974
Maybe the filter doesn't work well if you use 60s. /20 m/ 60s
Even if your GPS is totaly inaccorate because of it's physikal location in your trousers, the jump should get spread across 5 to 10 points instead of making a huge change on only 1 point. It does just look like the filter didn't do anything or even worse, maybe your gps data is fine and this jump is based on an filter issue.
I hope you will see this error again with enabled record sensor data. You will find the files it at [Locus dir]/data/sensors. We are looking for things like 100-200hm altitude change at only one point.
I looked into the file Kleiner Seekopf in detail. I exported the record in Excel (attached). I took the altitudes (I don't know whether are GPS-datas or LIDAR) and calculated the differences.The result: The starting point is close to the reality. From thereon the recorded altitudes are always lower than the reality. Example: Point Nr. 38: 1.100,73 m Reality: rd. 1.300 m. This goes up to point Nr. 110 (1.533,25 m) (Reality: rd. 1.900m). In point 111 is the jump in the recorded data to 1.903. Same effect (less grave) till Point 126 (1.928) and the jump of 170 m to Point 127 (2.098m). Same effect occurs in the down direction in Point 157 (1.670) to 158 (1.383). I think the much higher speed downwarts has here a smoothend effect. The last point of the route is not recorded (I don't know why). Therefore the sum of down shows only 715 m (instead of 1.047 m up).
Could it be that the jumps in recorded data are due to the "heavy filter" I used in this route? And the last point was not recorded due to same reason?
Nearby: In the section of the first jump is a zig zag recorded that never happend in reality Points 109, 110, 111. But that seem to be a real GPS-fault (which I don't understand). Because there are no obstacles in the surroundings. In the other "big jumps" are no such zig zags. Therefore I think the zig zag has nothing to do with the jumps.
I looked into the file Kleiner Seekopf in detail. I exported the record in Excel (attached). I took the altitudes (I don't know whether are GPS-datas or LIDAR) and calculated the differences.The result: The starting point is close to the reality. From thereon the recorded altitudes are always lower than the reality. Example: Point Nr. 38: 1.100,73 m Reality: rd. 1.300 m. This goes up to point Nr. 110 (1.533,25 m) (Reality: rd. 1.900m). In point 111 is the jump in the recorded data to 1.903. Same effect (less grave) till Point 126 (1.928) and the jump of 170 m to Point 127 (2.098m). Same effect occurs in the down direction in Point 157 (1.670) to 158 (1.383). I think the much higher speed downwarts has here a smoothend effect. The last point of the route is not recorded (I don't know why). Therefore the sum of down shows only 715 m (instead of 1.047 m up).
Could it be that the jumps in recorded data are due to the "heavy filter" I used in this route? And the last point was not recorded due to same reason?
Nearby: In the section of the first jump is a zig zag recorded that never happend in reality Points 109, 110, 111. But that seem to be a real GPS-fault (which I don't understand). Because there are no obstacles in the surroundings. In the other "big jumps" are no such zig zags. Therefore I think the zig zag has nothing to do with the jumps.
No, that jumps are definately not due to a filter, neither because of "Heavy" Filter. A filter just smoothes out a track's up-and-down by rule-of-thumb 5-20meters, depending on setting. But not by 100 meters and more. This would make any elevation recording total useless.
The problem with the "Kleiner-Seekopf" track is, that your GPS-receiver had bad reception. It's a general rule that the vertical position is more vulnerable to bad reception condistions, than the horizontal position. So for example, while the measured horizontal postion is off by 20 meters to reality, the elevation could be off 100 meter.. or even more as within your track.
What can you do?
First: position your GPS-receiver so that it can "see" much of the sky, where the GPS satellites are. For example in the top of your backpack or somewhere on your shoulder. Within a trousers' pocket is less ideal.
Second: within Locus: Optimize the GPS auto-off option AND the track recording Parameters. For example disable GPS-auto off, and within the track recording profile set "Distance intervall" = 3m, "Time intervall" = 5s, Trackpoint recording = "Distance and time (both)"
Third: Within altitude manager, choose a method of getting the elevation of a coordinate: Either "Replace GPS values" where elevations are determind just by (LIDAR)-elevation files (what I'm using and I recommend in general). Or "Optimize GPS values" in conjunction with "Heavy filter" where the elevations are determined by your phone's GPS-receiver.
No make some tours and compare the results of this 2 methods. If you are satisfied with one or even both methods you can start to enable GPS-auto off and see if this affects the quality to the worse. Maybe start with smaller values, for example (30, 100, 60)
No, that jumps are definately not due to a filter, neither because of "Heavy" Filter. A filter just smoothes out a track's up-and-down by rule-of-thumb 5-20meters, depending on setting. But not by 100 meters and more. This would make any elevation recording total useless.
The problem with the "Kleiner-Seekopf" track is, that your GPS-receiver had bad reception. It's a general rule that the vertical position is more vulnerable to bad reception condistions, than the horizontal position. So for example, while the measured horizontal postion is off by 20 meters to reality, the elevation could be off 100 meter.. or even more as within your track.
What can you do?
First: position your GPS-receiver so that it can "see" much of the sky, where the GPS satellites are. For example in the top of your backpack or somewhere on your shoulder. Within a trousers' pocket is less ideal.
Second: within Locus: Optimize the GPS auto-off option AND the track recording Parameters. For example disable GPS-auto off, and within the track recording profile set "Distance intervall" = 3m, "Time intervall" = 5s, Trackpoint recording = "Distance and time (both)"
Third: Within altitude manager, choose a method of getting the elevation of a coordinate: Either "Replace GPS values" where elevations are determind just by (LIDAR)-elevation files (what I'm using and I recommend in general). Or "Optimize GPS values" in conjunction with "Heavy filter" where the elevations are determined by your phone's GPS-receiver.
No make some tours and compare the results of this 2 methods. If you are satisfied with one or even both methods you can start to enable GPS-auto off and see if this affects the quality to the worse. Maybe start with smaller values, for example (30, 100, 60)
I'll try and give you feedback. But need some time because of bad weather.
I'll try and give you feedback. But need some time because of bad weather.
I did 3 times exactly the same route. I kept my phone always in hand. The terrain does not have any obstacles, woods, rocks, canyons.
According the topogrfic map: Up: +170m Down: -170 m min: 732 m (guessed) max: 902 m (guessed)
Tracksettings: 3m/1sec/both/20m
1. Trip: Altitude Mgr.: Manuell correction: 1 m; no Filter
Up: 202 m Down: 204 m min: 730 m max: 910 m
2. Trip: Altitude Mgr.: Manuell correction: -38 m Ultra heavy filter
Up: 170 m Down: 181 m min: 741 m max: 910 m
3. Trip: Altitude Mgr.: Peplace GPS values No filtration
Up: 176 m Down: 176 m min: 733 m max: 902 m
Resume: LIDAR datas are for my needs the best choice. GPS is too uncertain.
Attached the recorded sensor datas and the NMEA-report, and the GPX file of one route (the other 2 tracks are realy close - max. distance 3 m in some points).
I did 3 times exactly the same route. I kept my phone always in hand. The terrain does not have any obstacles, woods, rocks, canyons.
According the topogrfic map: Up: +170m Down: -170 m min: 732 m (guessed) max: 902 m (guessed)
Tracksettings: 3m/1sec/both/20m
1. Trip: Altitude Mgr.: Manuell correction: 1 m; no Filter
Up: 202 m Down: 204 m min: 730 m max: 910 m
2. Trip: Altitude Mgr.: Manuell correction: -38 m Ultra heavy filter
Up: 170 m Down: 181 m min: 741 m max: 910 m
3. Trip: Altitude Mgr.: Peplace GPS values No filtration
Up: 176 m Down: 176 m min: 733 m max: 902 m
Resume: LIDAR datas are for my needs the best choice. GPS is too uncertain.
Attached the recorded sensor datas and the NMEA-report, and the GPX file of one route (the other 2 tracks are realy close - max. distance 3 m in some points).
The NMEA datas cannot be attached. Too big (5.6 MB)?
The NMEA datas cannot be attached. Too big (5.6 MB)?
I guess we don't need the sensor data from 2019-01-03 because I don't find any obvious errors there.
I would guess that the error was related to 60 sec. /20 m/ 60 sec. setting because the filter does work based on time change and wasn't applied that well because there were no points to filter in a given timespan. But this is a total guess because I did never use such a setting. Maybe the filter does just work better if you have more points.
If you like you could look for a Recording with an error similar to 2018-12-28_Kleiner_Seekopf.gpx and for that recording NMEA data would be interesting. Otherwise just use the solution because not much people did experience your problem because people who care about the altitude change did already switch to barometric or lidar data.
I guess we don't need the sensor data from 2019-01-03 because I don't find any obvious errors there.
I would guess that the error was related to 60 sec. /20 m/ 60 sec. setting because the filter does work based on time change and wasn't applied that well because there were no points to filter in a given timespan. But this is a total guess because I did never use such a setting. Maybe the filter does just work better if you have more points.
If you like you could look for a Recording with an error similar to 2018-12-28_Kleiner_Seekopf.gpx and for that recording NMEA data would be interesting. Otherwise just use the solution because not much people did experience your problem because people who care about the altitude change did already switch to barometric or lidar data.
I agree. To operate with LIDAR datas are much more accurate and reliable. I have LIDAR for the whole Alps and therefore I will not use GPS for altitudes any more. Thanks to all for your efforts. But now we can close this chat.
Regards and plenty of good tours.
Hans
I agree. To operate with LIDAR datas are much more accurate and reliable. I have LIDAR for the whole Alps and therefore I will not use GPS for altitudes any more. Thanks to all for your efforts. But now we can close this chat.
Regards and plenty of good tours.
Hans
Replies have been locked on this page!