Ok, I played with it for quite some time. It's usually a bit more
conservative. But
on some tracks I even get more ascend. That matches the expectations on how the
ascend is sampled. The overall difference is very small. For about 122000m
ascend the difference is about 600m between the algorithms.
I think we should give it a try. I cleaned up the code a bit. Patch is
attached.
Please crosscheck and start a pull request.
Thanks
Oliver
Am Freitag, 10. November 2017, 09:46:53 CET schrieb [email protected]:
> Hello,
>
> My main concern is that Etrex 30 is really sensitive to pressure
> changes, and where I ride my mountain bike this is hilly and sometimes
> very windy, then altimeter records bumps which do not exist in reality.
>
> I do the same ride on a zero wind day, then on a very windy gusty day
> and I can see a "big" difference : 1950 meters instead of 1800 m. Then I
> have to filter out the excessive 150 m.
>
> Then in general getting less ascent means for me getting a more
> realistic value. In general I am happy with 9 points median filter
> (applied to 1 Hz tracks). It seems that it removes wind gusts and keeps
> true terrain bumps (at least on a mountain bike on my usual tours).
>
> Ascent value is something difficult, and having it modified by
> Douglas-Peuker filter is something I would like to avoid. This is the
> target of my modification.
>
> zero
>
> Le 10.11.2017 08:48, Oliver Eichler a écrit :
> > Hi,
> >
> > I can see this occasionally for some tracks, too. So far I did not
> > investigate in depth but my explanation:
> >
> > The caveat of that algorithm is always the last intervall at a local
> > extrema. The error can be up to the threshold value. With other words: In
> > the worst case you miss treshold meters to the summit. If you change the
> > number of points you also change how you approach a local extema. If you
> > are lucky you get much closer to the summit now and thus the ascend (same
> > for descend) is larger. If you have several local "summits" in your track
> > the difference can be quite large. "can" not must be. It depends on how
> > errors sum up or compensate.
> >
> > As far as I understand your changes you you want to sum up multiples of
> > the threshold value only. By that you always sum up a bit less.
> > Naturally this will lead to a lower value. But is it a better value in
> > the sense of being a more precise? You will always favor the lower corner
> > of the error interval. It's less irritating for sure. But is that wanted?
> >
> > Oliver
> >
> > GESENDET: Donnerstag, 09. November 2017 um 21:46 Uhr
> > VON: zero <[email protected]>
> > AN: "Qmapshack mailing list" <[email protected]>
> > BETREFF: [Qlandkartegt-users] Douglas-Peuker filtering and ascent/descent
> > calculation
> >
> > Hello Oliver,
> >
> > fact 1) Few months ago we had a discussion about the way ascent is
> > calculated in QMapShack. At the end the conclusion was that a threshold
> > of 5 meters is used, and this is now in Wiki. Using a threshold is like
> > counting contour lines on a map. I fully agree and I do not write this
> > email to attempt anything against this.
> >
> > fact 2) I capture my tracks at 1 pt/s rate (to get more precision on
> > timing for my Strava segments and because sometimes filters in my Etrex
> > 30x are too rough, even with highest rate). First I send the 1 Hz track
> > to Strava, then I archive it after having applied 1 meter Douglas-Peuker
> > filter.
> >
> > fact 1 + fact2) I always have bigger ascent/descent values after
> > Douglas-Peuker filtering. Until a few days ago it was a mystery to me :
> > why be removing points, ascent/descent could be higher ?
> >
> > After some thinking and trials I modified code in CGisItemTrk.cpp, line
> > 919 :
> >
> > It was :
> >
> > _ if(lastEle != NOINT)_
> > _ {_
> > _ qint32 delta = trkpt.ele - lastEle;_
> >
> > _ trkpt.ascent = lastTrkpt->ascent;_
> > _ trkpt.descent = lastTrkpt->descent;_
> >
> > _ if(qAbs(delta) > ASCENT_THRESHOLD)_
> > _ {_
> > _ if(delta > 0)_
> > _ {_
> > _ trkpt.ascent += delta;_
> > _ }_
> > _ else_
> > _ {_
> > _ trkpt.descent -= delta;_
> > _ }_
> > _ lastEle = trkpt.ele;_
> > _ }_
> > _ }_
> >
> > it is now :
> > diff -r 5cbd43bd4178 src/gis/trk/CGisItemTrk.cpp
--- a/src/gis/trk/CGisItemTrk.cpp Sat Nov 11 15:59:36 2017 +0100
+++ b/src/gis/trk/CGisItemTrk.cpp Sun Nov 12 10:13:51 2017 +0100
@@ -923,17 +923,19 @@
trkpt.ascent = lastTrkpt->ascent;
trkpt.descent = lastTrkpt->descent;
- if(qAbs(delta) > ASCENT_THRESHOLD)
+ if(qAbs(delta) >= ASCENT_THRESHOLD)
{
+ const qint32 step = (delta/ASCENT_THRESHOLD)*ASCENT_THRESHOLD;
+
if(delta > 0)
{
- trkpt.ascent += delta;
+ trkpt.ascent += step;
}
else
{
- trkpt.descent -= delta;
+ trkpt.descent -= step;
}
- lastEle = trkpt.ele;
+ lastEle += step;
}
}
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Qlandkartegt-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qlandkartegt-users
