It is mistake to expect that
if elevation stats are not (almost) same, a mistake is involved.
As there is no single correct way how to provide the result.
For elevation aware GPX files,
if it is the planned route, the total elevations stats depend on
Used source of date ( SRTM3=90x90 m, SRTM1=30x30m, LIDAR based, other )
Used postprocesing of these data ( noise or artefact filtering )
Used postprocesing of the rouite elevation profile.
if it is the recorded track, it additionally depends on,
if barometer altitude or GPS altitude was recorded,
if altitude was replaced by SRTM equivalent data.
how noisy was 3D GPS position in case of GPS altitude,
how noisy was 2D GPS position in case of SRTM altitude.
How/if was done the altitude filtering during recording.
How/if was done the altitude filtering during presentation.
Quite a lot of variability to get the same results.
Different procedures and different date provide different results.
Without topografic feedback it is not possible to say
what filtering parameters ( for given typical scenario ) gives results
close to reality.
Not enough filtered GPS altitutes and partially also SRTM-like altitudes
overshoots total stats, as there are altitude jumping artefacts
due 3d/2d position inaccuracy.
Too strong filtering undershoots the stats.
On 05/03/2017 08:05 AM, 'Osmandtrier' via Osmand wrote:
And there is a mistake. Opening a recorded gpx-file with an other
gpx-viewer, the other party gpx-viewer shows a different difference of
altitude than osmand.
So my idea was, perhaps osmand use the srtm-data. So I replaced the
recorded elevation-data with srtm-data. I got also a different
difference of altitude than osmand.
--
Poutnik ( The Pilgrim, Der Wanderer )
https://github.com/poutnikl/Brouter-profiles/wiki
--
You received this message because you are subscribed to the Google Groups
"Osmand" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
