An alternative way to obtain acceptably good altitude values

[vlmendz]

By allowing OT to obtain altitude data from a digital elevation model (DEM), more useful gain/loss values, vertical profiles and minimum and maximum altitude could be obtained without having a barometric sensor.

SRTM data could be used for this purpose, which has virtually global coverage and, in my opinion, generally good accuracy for typical use cases with OT.

Cons: to use this option, the user must first download/copy the SRTM data of his area of interest to his device.

PS A practical example of this use of DEM can be easily seen with the GPXSee app.

[dennisguse]

I missed the notification.

Definitely doable; we even can take the implementation that AAT is using.
They provide DEM files for download.
Only issue: covering the whole world is kind of huge (at least at a decent compression), so we cannot put it into the APK.
We would need to make user download the data manually and put it into a folder that OpenTracks can read.

But definitely doable.

PS/ sorry I missed the notification

[vlmendz]

[dennisguse]

???

[Leifurh]

How about (yet another) alternative approach - allowing users to upload their own geoid height files (in NGA .bin format for example) for their own particular corner of the world. I recently converted the Icelandic 2011 geoid from ASCI into .bin and it only needs 1 MB of storage. The software could check if the point to be converted lies within the "clipping window" (for lack of a better word) of the file (or files) loaded and use EGM 2008 if not. I would much rather the software used the EGM file to find the orthometric zero (sea level) and left the rest to my GPS. Besides, SRTM only applies between 57°N and 57°S .... outside those limits it's difficult to find good DEM data.

PS Mapit GIS uses this approach but they seem to be rewriting their software and don't expect their next version to be ready till autumn.

[Leifurh]

Here, btw, is a link to the Icelandic geoid - as well as to a number of others available at the ISG.

[vlmendz]

I would much rather the software used the EGM file to find the orthometric zero (sea level) and left the rest to my GPS. Besides, SRTM only applies between 57°N and 57°S .... outside those limits it's difficult to find good DEM data.

The point of taking altitude from a DEM would be precisely not to use GPS for that purpose. In my experience, the average smartphone GPS receiver is very erratic and inaccurate in determining altitude, at least in urban areas.
I understand that this alternative is only applicable if good enough DEM data is available in our area of interest.

[Leifurh]

Well, let me start by retracting my statement that DEM data are difficult to find north of 57°N - in fact ArcticDEM <https://www.pgc.umn.edu/data/arcticdem/> covers the entire northern "cap" of the world down to 60°N - leaving only a 3 degree gap. The problem is more one of laziness I suspect - SRTM solves 90% of the problem so people chose to ignore the remaining 10%. That certainly seems to be the case with Garmin - who already use the approach you are advocating, offering to "correct" the elevation data coming from your GPS using their DEM product. In my (Icelandic) experience their "corrections" are WORSE than useless (I actually suspect they are using the old GTOPO30 <https://en.wikipedia.org/wiki/GTOPO30> data). The theory that elevation data coming from GPS receivers is of poor quality stems from the rather obvious fact that for accuracy in the horizontal plane you want the satellites to be close to the horizon - a satellite directly overhead is not going to do much for your X, Y solution - but is pretty good for Z. Nowadays, with lots and lots (and lots) of satellites available, it becomes more a question of how many of them you can listen to simultaneously. As far as I can see, for multi-constellation, dual-frequency phones (which seem to me to be MORE accurate than Garmin's products), the VDOP tends to be smaller than the HDOP. Perhaps we can agree that allowing the user to choose which approach to use (DEM or EGM) would be optimal?

…

On Sat, May 20, 2023 at 5:00 AM vlmendz ***@***.***> wrote: I would much rather the software used the EGM file to find the orthometric zero (sea level) and left the rest to my GPS. Besides, SRTM only applies between 57°N and 57°S .... outside those limits it's difficult to find good DEM data. The point of taking altitude from a DEM would be precisely not to use GPS for that purpose. In my experience, the average smartphone GPS receiver is very erratic and inaccurate in determining altitude, at least in urban areas. I understand that this alternative is only applicable if good enough DEM data is available in our area of interest. — Reply to this email directly, view it on GitHub <#1312 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4UPHRDGRG3QFYZOH7JMWHLXHBFXBANCNFSM52ODLFJQ> . You are receiving this because you commented.Message ID: ***@***.*** com>

[vlmendz]

Perhaps we can agree that allowing the user to choose which approach to use (DEM or EGM) would be optimal?

Agreed.

In my case I get much better results (accuracy and consistency) from common SRTM data of 3 arc seconds resolution than from the phone GPS.

[Leifurh]

To get back to our earlier discussion of vertical vs horizontal accuracy in cell phones, I left my Google Pixel 6 out on the balcony for a few minutes - it tells me (and I have no way of verifying or disputing the info) that horizontal errors are between 3 and 5 metres whereas vertical error is pretty steady at 3 metres. This is using Sean Barbeau's GPSTest app. The sky view was not perfect with most of the southern sky masked by the building. File attached. I guess we have shanghaied this github page for long enough - if you want to respond my email is ***@***.***

…

On Sat, May 20, 2023 at 12:53 PM vlmendz ***@***.***> wrote: Perhaps we can agree that allowing the user to choose which approach to use (DEM or EGM) would be optimal? Agreed. In my case I get much better results (accuracy and consistency) from common SRTM data of 3 arc seconds resolution than from the phone GPS. — Reply to this email directly, view it on GitHub <#1312 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A4UPHRHXMPLOB6FLW3C7EXLXHC5DBANCNFSM52ODLFJQ> . You are receiving this because you commented.Message ID: ***@***.*** com>