[Feature] Elevation correction?

[mircozorzo]

Hi, it may be useful the correction of gps's elevation data?

Mirco

[rodolfo]

+1
Due to the different elevation models, the elevation indicated by our gps receiver can indeed differ considerably from the topographic elevation (depending on the region), so a correction setting would be welcome.

Rodolfo

[Hardy]

Quote from one of my recent responses to similar requests:


I had researched that a few months and many beers ago, cannot remember
too well. Here is what I can still produce off the top off my head:

There is a certain syntax convention (both NMEA and android-java) how
to extract what value from the GPS receivers. But I had tried several
test devices and found that many deliver values not according to the
convention: What some receivers report as WGS84 is actually a
corrected value, and a number of GPS chipsets does not seem to be
capable of giving a correction at all (I can only guess that the
correction must come from a table, and maybe cheaper chipsets do not
have that on-board).

Looking at different devices with the GPS status app gives you a good
idea of what is going on: Some devices return WGS84 and a correction
in smallprint, others the corrected value and the negative correction
in smallprint, and yet others show no correction at all.

In the end I gave up. We are taliking our issue 915. Maybe in the
issue I posted more detail I can recall here.

Best regards,
Hardy

> > Mirco- Hide quoted text -
>
> - Show quoted text -

[rodolfo]

Sorry, I didn't read issue 915.
From all that info, I gather it is difficult (or perhaps impossible) to automatically correct the gps reported altitude under all circumstances.
This fact is imho the best argument to introduce a manual correction setting.
Take the traditional altimeters: before you start walking (riding, driving), you calibrate the altitude from a known location, so at least the next hour, the reading is more or less reliable.
The same procedure could be used in Osmand with the big advantage that the reading is not influenced by a quick weather change.
So before a trip, you could calibrate the altitude, as shown by Osmand and set a correction value.
This can be done in 2 ways:
- enter the real topographical altitude once Osmand has determined your position, then the correction value is calculated, stored and used later on.
- calculate the correction yourself and enter this value.
Personally, I would prefer the first method.
Could this be a practicable improvement?

Rodolfo

[Hardy]

Hello Rodolfo,

 

from my current undestanding of the matter all issues (unpredictabilities) are caused by the different devices' chipsets and not by our code.

 

So the only 'improvement' we could come up with is in deed a very trivial one: An input field for a static correction. 

 

Please note that the correction depends only on 3 things:

- what your device "choses" to answer to the standard java calls (this depends on your device onl, is otherwise static)

- The reference system you would like to use (this is static, and only a minimal impact of usually <1m)

- your postion

Please note that weather, air pressure, moon phase etc, are out of the picture ...!   Hence the correction is STATIC, (unless you move over large distances, usually hundreds of km.)

 

Now if you are smart enough to figure out that your correction is, say, 21m. Would you really need a setting in Osmand to always add 21m to what your device displays ... ?  :-) 

[rodolfo]

Hi Hardy,
I would not call this static correction a trivial one.
In the region where I live (north and south of the Pyrenees), the corrections differ significantly from place to place.
At sea level the correction is about 22 m. In the south Pyrenees mountains the difference varies from 30 to 38 m. and in the north Pyrenees mountains, the difference is 43-50 m. That is ... on my device.
I still remember a trip in Gran Paradiso some 15 years ago, where we hesitated between 2 almost parallel side paths and chose the wrong one because the altimeter deviated by 15m so after 2 hours we ended up in a dead end gletcher. (Nice ibexes there :) )
If Osmand had existed by then, this would probably not have happened, but still I would really appreciate a way to calibrate my device before a walk.
Best regards, rodolfo

[mircozorzo]

Hi, yes it might be good!

Thanks, Mirco

[Hardy]

Hi Rodolfo, What device do you use and what does the GPS status app show you? Does it show WGS84, some corrected value, or a corretion as a separate value (in small print)?

Thx - Hardy

[Sabra Sharaya]

How is a person to determine what method the device uses? In OSMAnd, both of my devices show a number for elevation. When I look at ele tags in OpenStreetMap, usually the numbers are between 200 and 300 in this area, while my devices usually report numbers between 750 and 850. But sometimes the data included with the ele tags seems very old, and sometimes even the latitude and longitude are not quite right. So I don't know which is more accurate between the map data and the device data.

[Sander Deryckere]

I've just noticed that the gps status app gives such a correction.

When I look at the altitude, it shows
Altitude (+47m): 25m
25m is about correct according to the srtm data and what I've always heard.

While in OsmAnd, the shown altitude is 72m.

This is the case on both my devices, I wonder if they both have the same gps reading, or if the gps status app has found something different.

Since we've been advertising the gps status app, we might try asking the developers how they do this.

Regards,
Sander

Op 2 sep. 2012 03:28 schreef "Sabra Sharaya" <sabras...@gmail.com> het volgende:

[Hardy]

Hello Sander,

Yes, that is exactly how the majority of my test devices behave. And
(I am not sure 100%, but believe I remember this correctly) that is
also how java documents it:

The normal function call should report the satellite altitude (WGS84),
which sould be your 72m. Your GPS receiver seems to have a table
interpolating position-dependent corrections (not all receivers have
this), and it can be seen in GPS status.

Just for completeness: Some other devices do not seem to have a
correction table, and yet others seem to (flasely) output the
corrected (not WGS84) value to java.

Here is the main issue: Unfoirtunately I find no java-call to read the
correction value (if provided). Could anybody please double-check,
maybe it is just an oversight of mine. Because if we find one, we are
done, we could simply have a usefule option toggling between
displaying WGS84 or corrected altitude.

Sander, we could also contact the GPS Status author, but he likely
reads the chipsets more directly (which I do not want Osmand to go
into ...). You want to give it a shot and ask him?

For now, I think the best way of operation for OsmAnd users who care
is know their device deviation XXmeters at their home position (off
the internet or GPS Status, filtering in how their devcie behaves),
and for new locations check GPS status do determine the new number. I
pesonally would never use a bogus static correction in Osmand itself,
because for me traveling al lot it would always give me totally bogus
readings, unless I set it to 0.

Best regards,
Hardy

On 2 Sep., 07:49, Sander Deryckere <sander...@gmail.com> wrote:
> I've just noticed that the gps status app gives such a correction.
>
> When I look at the altitude, it shows
> Altitude (+47m): 25m
> 25m is about correct according to the srtm data and what I've always heard.
>
> While in OsmAnd, the shown altitude is 72m.
>
> This is the case on both my devices, I wonder if they both have the same
> gps reading, or if the gps status app has found something different.
>
> Since we've been advertising the gps status app, we might try asking the
> developers how they do this.
>
> Regards,
> Sander

> Op 2 sep. 2012 03:28 schreef "Sabra Sharaya" <sabrashar...@gmail.com> het

> volgende:
>
>
>
> > How is a person to determine what method the device uses? In OSMAnd, both
> > of my devices show a number for elevation. When I look at ele tags in
> > OpenStreetMap, usually the numbers are between 200 and 300 in this area,
> > while my devices usually report numbers between 750 and 850. But sometimes
> > the data included with the ele tags seems very old, and sometimes even the
> > latitude and longitude are not quite right. So I don't know which is more

> > accurate between the map data and the device data.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

[Horst Müller]

I think the different output of different devices is an issue, which could be solved by the community. For example it wouldn't be necessary for each Galaxy S user to find out, how his/her device behaves. One would be enough. A table could be created from which OsmAnd gets its information how to react. If a device isn't listed (yet), there could still be the option for a manual setting.
The height correction factor seems to be more difficult. Honestly I don't understand much about this topic. I have read the following article, and it seems, that even the correction factor used in some gps devices isn't always accurate:
http://www.esri.com/news/arcuser/0703/geoid1of3.html
This would mean, we may need some online service, where we would receive the height for a specified location and hence can calculate the deviation (maybe as part of a plugin?).

2012/9/2 Hardy <hm.gg...@gmail.com>

[rodolfo]

I suppose we consume NMEA 0183 data. So the correction value is available in the GGA sentence. (Height of geoid above WGS84 ellipsoid)
If Java does not support the necessary methods, then at least there is a C lib NMEAlib available.
Peanuts, isn't it Victor? :)

Rodolfo

[Luděk]

Sander, we could also contact the GPS Status author, but he likely
reads the chipsets more directly (which I do not want Osmand to go
into ...). You want to give it a shot and ask him?

I wrote him last week ... related this https://groups.google.com/forum/#!topic/osmand/GHkqQjHhKPY so far I have not received a reply.
Regards
Ludek

[Sabra Sharaya]

That person uses advertising and offers a key to remove the advertisements for a price. So I think it is unlikely that person would give away the app's secrets.

[Luděk]

Autor of GPS status wrote

.....I'm looking also for the same algorithm. I'm currently reading the correction value from the NMEA sentences provided by the GPS. Unfortunately some handsets do not (correctly) implement this so I'm also looking for a simple manual algorithm to convert it on my own......

Autor of Locu swrote he uses NMEA sentences and better system from global geoid model. He uses data from EGM96.

More I didn't found out.
Regards
Ludek

[Hardy]

Hello Ludek, that sounds promising, but just as involved as I imagined
it would be when I researched the matter myself a few months ago ...

So we now have a few spots to check and see if people make progress
there ... :-)

[Sander Deryckere]

I have found this page (http://geographiclib.sourceforge.net/html/geoid.html), which should contain the algorithm, together with data of different precision. Sadly enough, it's not written in Java, so we will have to make our own algorithm.

As a typical Android GPS isn't precise, I assume the lowest precision would be good enough, which makes the data 600kb big

If you look at the data with Gimp, you can see it's a picture of the world, I assume the grey vallues denote the height difference from the geoid to the WSG84 ellipse (possibly multiplied by a factor). But to read the dataset, you need to be able to read the grey value of a certain pixel in that picture.

As one pixel is 30' (in the least precise dataset), I think the function to calculate the right pixel coordinates would be

x = round((latitude+180)*2)
y = round((longitude+360)*2)

Then get the grey value of that pixel, and probably process it (add an offset, and multiply by a constant).

If someone knows how to get a pixel from such an image, go ahead. It's a bit too raw for me.

2012/9/6 Luděk <lud...@gmail.com>