GPX: Elevation gain/loss is way off.

[mkubik]

The elevation gain / loss values are wrong by factors. The app claims to have e.g. 1209m gain on a 30km tour. But when I import it into Google Earth, it's only about 560m. Can you elaborate on how this value is calulated in OsmDroid?

[vshcherb]

Can you please share GPX track or its part so we can reevaluate it.

[mkubik]

Sure. Please see https://drive.google.com/open?id=0B07G9J_jSVbCanF1Qmh6Y3B5S1k

[Zahnstocher]

It seems that every small GPS inaccuracy (height) is accumulated. For example 485 483 483 483 484 479 483 counts as 7m down and 5m up, but probably the way was flat. I think it would help to smooth the elevation profile before the calculation to eliminate the small GPS errors.

[vshcherb]

Even if we want to change the algorithm, what would be the smoothing algorithm then?

[sonora]

Yes, if anybody has an idea, please step forward! I had been looking into this extensively, because it has bugged me for years, but so far I have failed to find a good and simple enough algorithm to reliably fix this ... Basically all algorithms I have tried also failed to detect gradual inclines like when hiking up mountain slopes ... so they were pretty useless.

On Mon, Sep 21, 2015 at 1:37 PM, vshcherb notifications@github.com wrote:

Even if we want to change the algorithm, what would be the smoothing algorithm then?

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-141948690.

[mkubik]

I found this one: https://strava.zendesk.com/entries/20944466-Elevation-Gain

Maybe this is the key. From a starting point (=p1), you wait for the next peek (=p2)(that point where you start going down). Then you calculate the difference from p2-p1 which you then sum up to gain. You can play around with a threshold to detect the peek, may 3 or 4 meters.

[vshcherb]

I think the algorithm could be changed to calculate the average (min or max or any other aggregate function) ele for 10 seconds (or other interval) for example and then calculate differences between these averages. The disadvantage that algorithm assumes the altitude is either going up for 10 seconds or going down for 10 seconds, but not both (!)

These parameters are configurable...

[mkubik]

I was thinking on something like this. Funny detail: It seems to be close to what Google Earth reports with a threshold of 13m. "elevation" is a simple array of Integers

            int el1 = 0, el2 = 0, i = 0;
    int start = elevation[0], end = 0, thres = 13, act_thres = 0;
    for(i = 0; i < elevation.length-1; i++) {
        end = elevation[i+1];
        if((end - start) > 0) {
            act_thres = end - start;
        }
        else {
            start = elevation[i];
        }

        if(act_thres >= thres) {
            start = elevation[i];
            el2 += act_thres;
            act_thres = 0;
        }

    }
    System.out.println(i+ " Elements. Elevation (smooth): "+ el2);

[vshcherb]

I would put threshold 10m or even 5m but it seems logical to me. This approach has a problem not catching 5-10 m hills

[mkubik]

True. It also results in about 1700(if thres = 1) compared to the current algorighm which gives 1209. But that may be caused by resetting start to a lower (negative) elevation, so we're probably accumulating too much. We could introduce another threshold to compensate low negative changes, e.g. 500, 499, 498, 502: In this case gain would be 4. With a negative threshold of, say 2, we would get to overall gain of 2. I'm also not sure if this would work with other files, but my friend had a garmin GPS and that one also reported about 500m for my file, I don't remember the exact value, nor to I know how garmin does that calculation (may be barometric)

[mkubik]

If you want it more sophisticated, you could try to use the HDOP value as some sort of error correction, but that would introduce a dependency to that value in the gpx file. I didn't check, but that value may be optional in GPX file format....

[sonora]

Thanks for your feedback, this was really helpful because it inspired me ... :-)

I think the solution should be something like this: We track the actual series of measured values in something like a trend-channel. No summation of altitude gain or loss takes place until the measured values leave the trend channel, defined by some threshold (could be 10m) above/below its observed extremes. The values may either leave a rising trend channel by falling below its lower threshold, or leave a falling threshold by rising above the upper threshold. In both these cases of a breakout being detected the overall altitude gain or loss value is updated by the net gain/loss of the trend channel before the breakout, and a new trend channel is started.

It is a little bit like analyzing a stock market chart. I hope I have the time to code it in the next few days and test it.

Best, Hardy

On Mon, Sep 21, 2015 at 6:46 PM, mkubik notifications@github.com wrote:

If you want it more sophisticated, you could try to use the HDOP value as some sort of error correction, but that would introduce a dependency to that value in the gpx file. I didn't check, but that value may be optional in GPX file format....

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-142038955.

[mkubik]

Love your way of thinking! Immediately when I read "trend-channel", this was what I thought about as well :-)

Now we know what finance maths is good for (besides guestimating future ;-) )

I'd love to test whenever you have something...

[sonora]

;-)

I am preparing for an expedition in October, do not have much time. But I have quickly implemented my basic idea today. While I am not very certain I did get it completely right yet, please feel free to test the nightly and report what you think. The only empirical parameter in there is the threshold defining when a "trend channel" is left (i.e. a "turnaround" is discovered), currently set at 10 m. (Or as Victor put it: Any hills or wiggles <10m will be neglected). I have tried a few synthetic tracks and think the results are correct, but lots more testing is required.

Thanks - Hardy

On Wed, Sep 23, 2015 at 8:32 AM, mkubik notifications@github.com wrote:

Love your way of thinking! Immediately when I read "trend-channel", this was what I thought about as well :-)

Now we know what finance maths is good for (besides guestimating future ;-) )

I'd love to test whenever you have something...

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-142507833.

[vshcherb]

I reviewed the code looks correct, though in the end it is not very easy to verify.

[sonora]

Victor,

thanks for double-checking! Yes, it will be some more work to know how good it is. I suggest 2 ways:

(1) I have already done: I have "hand-manufactured" gpx tracks with a limited number of elevation points, and verified that they behave exactly as expected: the "trends" seem to be correctly detected and summed.

(2) Now think (maybe mkubik can help) we need to analyze "real world" tracks and see if the code produces what we think reflects the reality. From my first tests, it of course depends on the quality of the recording. "Well-behaved" elevation values taken with good GPS fixes sum up very correctly. When the noise in the elevation recording exceeds the 10m threshold, then the noise of course adds to the values summed up. For many tracks I have checked, unless you are on a steep mountain side hiding many satellites, 10m seem to be a reasonable threshold. Maybe we should also feed some of our tracks to other (online) GPX analyzers to compare what results they produce.

We cold maybe derive the threshold from hdop somehow, but for now I shy away from that because it adds obscurity and complicates verification, I suggest getting a feeling for fixed thresholds first.

Thx - Hardy

On Thu, Sep 24, 2015 at 8:58 AM, vshcherb notifications@github.com wrote:

I reviewed the code looks correct, though in the end it is not very easy to verify.

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-142833893.

[mkubik]

I checked all my tracks (about 15) against Google Earth. Most of the tracks are between 20 and 100% too low. The track I uploaded for you seems to be a lucky hit :-) So I'd think we might be closer if we either reduce the noise-channel to, like 5m, and also test other services that calculate the elevation gain (suggestions?) Let me know if you want my tracks for testing. I'd prefer to send them per pn, and not post it publicly...

But: Great work so far, Thank you!

[sonora]

Yes, we can take this to PM so we can discuss more intensively.

I have the following suggestions:

If you google "online gpx analyzer", you will find at least half a dozen online tools, basically all of which give different results, and have different methods, apparently from very simple summation of all noise like we had it to more complex. I have to say in principle I like our new method best because it is rather transparent and has only 1 empirical parameter.

I think what you should do is this: Look at some tracks you have in a graphical representation of one of the online GPX analyzers, and decide what you THINK the result should be (by optically judging and summing what should be true elevation change and not noise). Best shorten the tracks in an editor if they are too long or too complex, we can verify the algorithm much better with short tracks than very long ones.

Then, look at the tracks in a notepad/editor window and decide why my new analysis comes to a different result: Is there a lot of oscillation <10m, which the algorithm filters as "noise", but which you actually think is not noise? It of course depends a lot on the terrain you are using: If there are many 5-9m oscillations in your landscape which you would like to see captured , then yes, going back to a 5 m noise threshold would help. But from my tests a lot of mountain tours near steep rock cliffs or in foggy weather cause a lot of near 10m noise, which with a 5m threshold would all be summed up (so we lose the benefit of the new algorithm).

I can provide a test build with a 5m threshold, but I think we better first get a feeling for what our tracks look like, what we think is noise, and what we expect as the analysis result.

I will also go through my tracks as find time, and will test high-Alpine terrain as well as more leveled desert floor tours. It may be very challenging to find a threshold which makes good sense in all terrains, for all weather conditions, and all device GPS sensitivities, let's see ... :-)

On Thu, Sep 24, 2015 at 7:43 PM, mkubik notifications@github.com wrote:

I checked all my tracks (about 15) against Google Earth. Most of the tracks are between 20 and 100% too low. The track I uploaded for you seems to be a lucky hit :-) So I'd think we might be closer if we either reduce the noise-channel to, like 5m, and also test other services that calculate the elevation gain (suggestions?) Let me know if you want my tracks for testing. I'd prefer to send them per pn, and not post it publicly...

But: Great work so far, Thank you!

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-143000642.

[sonora]

PS: Just looked at about a dozen of my tracks, and my feeling is that 10m threshold is actually WAY too optimistic, most of them seem to require more like 20-30m threshold to get rid of enough noise. (But many are taken in steep terrain, and some are taken with intervals >30sec, which increases noise due to the GPs being switched off between measurements. Also, some are taken on low end devices. so all sorts of things to consider here.) But I find rather few tracks where a 10m threshold is a significant improvement over our previous simple summation algorithm, other than for tracks take in very shallow terrain in good weather with a high end device, and GPS always on.)

On Thu, Sep 24, 2015 at 10:48 PM, Hardy hm.gglmail@gmail.com wrote:

Yes, we can take this to PM so we can discuss more intensively.

I have the following suggestions:

If you google "online gpx analyzer", you will find at least half a dozen online tools, basically all of which give different results, and have different methods, apparently from very simple summation of all noise like we had it to more complex. I have to say in principle I like our new method best because it is rather transparent and has only 1 empirical parameter.

I think what you should do is this: Look at some tracks you have in a graphical representation of one of the online GPX analyzers, and decide what you THINK the result should be (by optically judging and summing what should be true elevation change and not noise). Best shorten the tracks in an editor if they are too long or too complex, we can verify the algorithm much better with short tracks than very long ones.

Then, look at the tracks in a notepad/editor window and decide why my new analysis comes to a different result: Is there a lot of oscillation <10m, which the algorithm filters as "noise", but which you actually think is not noise? It of course depends a lot on the terrain you are using: If there are many 5-9m oscillations in your landscape which you would like to see captured , then yes, going back to a 5 m noise threshold would help. But from my tests a lot of mountain tours near steep rock cliffs or in foggy weather cause a lot of near 10m noise, which with a 5m threshold would all be summed up (so we lose the benefit of the new algorithm).

I can provide a test build with a 5m threshold, but I think we better first get a feeling for what our tracks look like, what we think is noise, and what we expect as the analysis result.

I will also go through my tracks as find time, and will test high-Alpine terrain as well as more leveled desert floor tours. It may be very challenging to find a threshold which makes good sense in all terrains, for all weather conditions, and all device GPS sensitivities, let's see ... :-)

On Thu, Sep 24, 2015 at 7:43 PM, mkubik notifications@github.com wrote:

I checked all my tracks (about 15) against Google Earth. Most of the tracks are between 20 and 100% too low. The track I uploaded for you seems to be a lucky hit :-) So I'd think we might be closer if we either reduce the noise-channel to, like 5m, and also test other services that calculate the elevation gain (suggestions?) Let me know if you want my tracks for testing. I'd prefer to send them per pn, and not post it publicly...

But: Great work so far, Thank you!

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-143000642.

[sonora]

PS2: When analyzing your GPX tracks, please also have a look at the "quality" of the recordings indicated by the behavior of the dhop values. High quality-recordings with dhop consistently say 3-5 m of course behave differently (and could benefit from a threshold as low as 5m) from recordings with some or many problematic sections where dhop may be as high as 50+ m (sometimes continuously, sometimes only for single points.).

The obvious idea could be to not use a static threshold to detect significant up/down turnarounds in a track, but to couple the breakout threshold for each trend to the current maximum of the dhop observed during the current trend. Easier coded than explained, actually. But it could also lead to undesired effects, and it would arouse questions which are not explained by an "easy" answer like for our current algorithm, where the simple principle is "All up/down trends of amplitude <10m are ignored to smooth the noise".

On Thu, Sep 24, 2015 at 11:42 PM, Hardy hm.gglmail@gmail.com wrote:

PS: Just looked at about a dozen of my tracks, and my feeling is that 10m threshold is actually WAY too optimistic, most of them seem to require more like 20-30m threshold to get rid of enough noise. (But many are taken in steep terrain, and some are taken with intervals >30sec, which increases noise due to the GPs being switched off between measurements. Also, some are taken on low end devices. so all sorts of things to consider here.) But I find rather few tracks where a 10m threshold is a significant improvement over our previous simple summation algorithm, other than for tracks take in very shallow terrain in good weather with a high end device, and GPS always on.)

On Thu, Sep 24, 2015 at 10:48 PM, Hardy hm.gglmail@gmail.com wrote:

Yes, we can take this to PM so we can discuss more intensively.

I have the following suggestions:

If you google "online gpx analyzer", you will find at least half a dozen online tools, basically all of which give different results, and have different methods, apparently from very simple summation of all noise like we had it to more complex. I have to say in principle I like our new method best because it is rather transparent and has only 1 empirical parameter.

I think what you should do is this: Look at some tracks you have in a graphical representation of one of the online GPX analyzers, and decide what you THINK the result should be (by optically judging and summing what should be true elevation change and not noise). Best shorten the tracks in an editor if they are too long or too complex, we can verify the algorithm much better with short tracks than very long ones.

Then, look at the tracks in a notepad/editor window and decide why my new analysis comes to a different result: Is there a lot of oscillation <10m, which the algorithm filters as "noise", but which you actually think is not noise? It of course depends a lot on the terrain you are using: If there are many 5-9m oscillations in your landscape which you would like to see captured , then yes, going back to a 5 m noise threshold would help. But from my tests a lot of mountain tours near steep rock cliffs or in foggy weather cause a lot of near 10m noise, which with a 5m threshold would all be summed up (so we lose the benefit of the new algorithm).

I can provide a test build with a 5m threshold, but I think we better first get a feeling for what our tracks look like, what we think is noise, and what we expect as the analysis result.

I will also go through my tracks as find time, and will test high-Alpine terrain as well as more leveled desert floor tours. It may be very challenging to find a threshold which makes good sense in all terrains, for all weather conditions, and all device GPS sensitivities, let's see ... :-)

On Thu, Sep 24, 2015 at 7:43 PM, mkubik notifications@github.com wrote:

I checked all my tracks (about 15) against Google Earth. Most of the tracks are between 20 and 100% too low. The track I uploaded for you seems to be a lucky hit :-) So I'd think we might be closer if we either reduce the noise-channel to, like 5m, and also test other services that calculate the elevation gain (suggestions?) Let me know if you want my tracks for testing. I'd prefer to send them per pn, and not post it publicly...

But: Great work so far, Thank you!

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-143000642 .

[sonora]

PS3: Ok, I got curious and had to try: The version with the dynamically adjusted threshold is online now, please also try today's nightly.

Current rule is now: "All up/down trends of amplitude <X are ignored to smooth the noise, where X is the maximum observed hdop value of any point which contributed to the current trend (but at least 5 m as the minimum noise threshold)".

More complicated than before, and we also have one ore empirical parameter (since for the dynamic adjustment we could also use 1.5_hdop or 2_hdop, etc.). But this algorithm has the potential of producng better results for a much wider variety of tracks recorded under both very good (noise<5m) or rather bad (hdop>>10m) conditions.

On Fri, Sep 25, 2015 at 12:31 PM, Hardy hm.gglmail@gmail.com wrote:

PS2: When analyzing your GPX tracks, please also have a look at the "quality" of the recordings indicated by the behavior of the dhop values. High quality-recordings with dhop consistently say 3-5 m of course behave differently (and could benefit from a threshold as low as 5m) from recordings with some or many problematic sections where dhop may be as high as 50+ m (sometimes continuously, sometimes only for single points.).

The obvious idea could be to not use a static threshold to detect significant up/down turnarounds in a track, but to couple the breakout threshold for each trend to the current maximum of the dhop observed during the current trend. Easier coded than explained, actually. But it could also lead to undesired effects, and it would arouse questions which are not explained by an "easy" answer like for our current algorithm, where the simple principle is "All up/down trends of amplitude <10m are ignored to smooth the noise".

On Thu, Sep 24, 2015 at 11:42 PM, Hardy hm.gglmail@gmail.com wrote:

PS: Just looked at about a dozen of my tracks, and my feeling is that 10m threshold is actually WAY too optimistic, most of them seem to require more like 20-30m threshold to get rid of enough noise. (But many are taken in steep terrain, and some are taken with intervals >30sec, which increases noise due to the GPs being switched off between measurements. Also, some are taken on low end devices. so all sorts of things to consider here.) But I find rather few tracks where a 10m threshold is a significant improvement over our previous simple summation algorithm, other than for tracks take in very shallow terrain in good weather with a high end device, and GPS always on.)

On Thu, Sep 24, 2015 at 10:48 PM, Hardy hm.gglmail@gmail.com wrote:

Yes, we can take this to PM so we can discuss more intensively.

I have the following suggestions:

If you google "online gpx analyzer", you will find at least half a dozen online tools, basically all of which give different results, and have different methods, apparently from very simple summation of all noise like we had it to more complex. I have to say in principle I like our new method best because it is rather transparent and has only 1 empirical parameter.

I think what you should do is this: Look at some tracks you have in a graphical representation of one of the online GPX analyzers, and decide what you THINK the result should be (by optically judging and summing what should be true elevation change and not noise). Best shorten the tracks in an editor if they are too long or too complex, we can verify the algorithm much better with short tracks than very long ones.

Then, look at the tracks in a notepad/editor window and decide why my new analysis comes to a different result: Is there a lot of oscillation <10m, which the algorithm filters as "noise", but which you actually think is not noise? It of course depends a lot on the terrain you are using: If there are many 5-9m oscillations in your landscape which you would like to see captured , then yes, going back to a 5 m noise threshold would help. But from my tests a lot of mountain tours near steep rock cliffs or in foggy weather cause a lot of near 10m noise, which with a 5m threshold would all be summed up (so we lose the benefit of the new algorithm).

I can provide a test build with a 5m threshold, but I think we better first get a feeling for what our tracks look like, what we think is noise, and what we expect as the analysis result.

I will also go through my tracks as find time, and will test high-Alpine terrain as well as more leveled desert floor tours. It may be very challenging to find a threshold which makes good sense in all terrains, for all weather conditions, and all device GPS sensitivities, let's see ... :-)

On Thu, Sep 24, 2015 at 7:43 PM, mkubik notifications@github.com wrote:

I checked all my tracks (about 15) against Google Earth. Most of the tracks are between 20 and 100% too low. The track I uploaded for you seems to be a lucky hit :-) So I'd think we might be closer if we either reduce the noise-channel to, like 5m, and also test other services that calculate the elevation gain (suggestions?) Let me know if you want my tracks for testing. I'd prefer to send them per pn, and not post it publicly...

But: Great work so far, Thank you!

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-143000642 .

[mkubik]

I only found http://trackreport.net as the only one (from like 4 or 5 that I checked) that does some more intelligent calculation. However, thinking more about your last approach, I think we might just try to use HDOP as the only threshold, no static minimum. I'm going on a MTB tour today with a few guys so I may be able to compare different devices. with the 9/26 nightly.

[sonora]

I spend 3 or so hours yesterday using our nightly of 9/25, going through dozens of tracks I have on my devices, collected with OsmAnd over the last 5 years or so on quite a selection of hardware.

I made one small heuristic change (using 2*hdop as an approximation for vdop), and have to say that now OsmAnd produces very plausible results for >90% of the tracks I tested, and certainly much better results than the online and other analyzers I have access to. (I compare by looking at the elevation graphs, and manually summing what I expect the result should be.)

I cannot completely get rid of a static minimum threshold because it is needed for devices not reporting hdop at all, but 5m is a reasonable minimum noise threshold for vertical GPS data in all cases, I think.

So now I am thrilled to hear what your evaluation says.! I think we should leave it as is, it is much improved.

For all tracks where you think we are noticeably off, please manually inspect them point-by-point to try to find out why they may be off. In all cases I found it was immediately plausible that there were very bad measurements included, which essentially voided the up/down trend channel on a portion of the track to a degree where not having a perfect result on the basis of the data was "plausible".

Best, Hardy

On Sat, Sep 26, 2015 at 10:18 AM, mkubik notifications@github.com wrote:

I only found http://trackreport.net as the only one (from like 4 or 5 that I checked) that does some more intelligent calculation. However, thinking more about your last approach, I think we might just try to use HDOP as the only threshold, no static minimum. I'm going on a MTB tour today with a few guys so I may be able to compare different devices. with the 9/26 nightly.

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-143409336.

[mkubik]

Sounds good to me. One thing I noticed was that on round trips the climb and descend values now are much closer, so thanks for your great effort in fixing this!! I'll get back to you in the next few days on how this latest change compares to what others on our trip will have later today.

[sonora]

Ok, thanks! Yes, the difference between ups and downs on round trips is a quality indicator, and helps debugging what happened on one of the legs. I have also tested jogging rounds for which I have many repetitions of the same round over the years, so I can check they always come out with similar analysis values now, another quality indicator :-)

I will be on an expedition in October (mostly offline), testing this, too, be back Nov 1 or so.

Thx- Hardy

On Sat, Sep 26, 2015 at 11:08 AM, mkubik notifications@github.com wrote:

Sounds good to me. One thing I noticed was that on round trips the climb and descend values now are much closer, so thanks for your great effort in fixing this!! I'll get back to you in the next few days on how this latest change compares to what others on our trip will have later today.

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-143413019.

[mkubik]

Just returned. Elevation calculated was 780m, 2 guys with barometric gps figured 600 and 610m.

Sent from SMail on Android

On 26/09/15 17:44:04, Hardy notifications@github.com wrote:

Ok, thanks! Yes, the difference between ups and downs on round trips is a quality indicator, and helps debugging what happened on one of the legs. I have also tested jogging rounds for which I have many repetitions of the same round over the years, so I can check they always come out with similar analysis values now, another quality indicator :-)

I will be on an expedition in October (mostly offline), testing this, too, be back Nov 1 or so.

Thx- Hardy

On Sat, Sep 26, 2015 at 11:08 AM, mkubik notifications@github.com wrote:

Sounds good to me. One thing I noticed was that on round trips the climb and descend values now are much closer, so thanks for your great effort in fixing this!! I'll get back to you in the next few days on how this latest change compares to what others on our trip will have later today.

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-143413019.

---

Reply to this email directly or view it on GitHub: https://github.com/osmandapp/Osmand/issues/1722#issuecomment-143465015

[fangly]

I see mentions of both HDOP and VDOP in this thread. Obviously, what we really need is VDOP, the vertical dilution of precision, for the purpose of correcting elevation. I don't know about other devices, but mine, a Sony Xperia Z1, only records HDOP, not VDOP. So, Sonora's approximation (VDOP~2*HDOP) may be a good idea, I think. However, this paper (http://www.nrem.iastate.edu/class/assets/nrem446_546/week3/Dilution_of_Precision.pdf) has interesting information that states that HDOP and VDOP are not necessarily linked proportionally. It further states that VDOP degrades with latitude, which could perhaps be useful informaition.

[sonora]

Yes, exactly, not very many consumer devices report vdop at all, so we need to make a lot of assumptions here, and we are deep into empirical research ... :-)

From what I can see, for the purposes of what OsmAnd can and will do on a mobile device and "on the fly", i.e. without any post-processing of the recorded data, what we have achieved over the last few days is probably about as much as we could hope for ... :-)

Best, Hardy

On Sun, Sep 27, 2015 at 9:16 AM, Florent Angly notifications@github.com wrote:

I see mentions of both HDOP and VDOP in this thread. Obviously, what we really need is VDOP, the vertical dilution of precision, for the purpose of correcting elevation. I don't know about other devices, but mine, a Sony Xperia Z1, only records HDOP, not VDOP. So, Sonora's approximation (VDOP~2*HDOP) may be a good idea, I think. However, this paper ( http://www.nrem.iastate.edu/class/assets/nrem446_546/week3/Dilution_of_Precision.pdf) has interesting information that states that HDOP and VDOP are not necessarily linked proportionally. It further states that VDOP degrades with latitude, which could perhaps be useful informaition.

— Reply to this email directly or view it on GitHub https://github.com/osmandapp/Osmand/issues/1722#issuecomment-143526329.