till213
commented
1 week ago Hello,
First of all, thank you for the very detailed report. This is something I can work with!
Yes, altitude... I will have to dive into this topic again a bit deeper, but here is how it is currently implemented in Sky Dolly. And just to let you know that I got your issue and will certainly look into this in more detail.
So yes, there are different ways to measure altitude. From the top of my head:
- Standard pressure altitude (altitude measured based on air pressure, with a reference pressure of 1013.25 hPa respectively 29.92 in Hg - https://en.wikipedia.org/wiki/Pressure_altitude)
- Altitude above the reference ellipsoid WGS-84 (aka "GPS altitude") - https://en.wikipedia.org/wiki/Earth_ellipsoid
- "Orthometric height", taking undulation into account (different magnetic field density of the earth) - https://globalgpssystems.com/gnss/geoids-ellipsoids-and-undulation-height-understanding-the-basics/
- Etc.
Then there is the question what the "system" (here: MSFS) actually measures. Sky Dolly currently records two altitude values ("simulation variables") from MSFS (one is "for information / export" purposes only). Unfortunatelly the SimConnect documentation is a bit sparse about the exact definition, but from practical experiments we get:
- INDICATED ALTITUDE: this seems to be the "pressure altitude". Note that if the pressure is not properly calibrated in the simulation (e.g. by pressing B) then this value will be "wrong" (measured against a wrong air pressure)
- PLANE ALTITUDE - This is the actual altitude being used for replay. Presumably this is some kind of "absolute altitude" in MSFS's own reference world coordinate system (which probably comes closest to the "reference ellipsoid model" aka "GPS altitude")
I just noticed that there is also a "standard pressure altitude" variable, but Sky Dolly is not currently recording it (yet):
- PRESSURE ALTITUDE - Standard Altitude, ie: at a 1013.25 hPa (1 atmosphere) setting.
This might become useful when trying to align the values with other tools (such as Little Navmap).
And finally there is the question what each file format requires the altitude to be - and in the end what the final application makes out of it (Google Earth Pro has options how to interpret the altitude).
From the GPX format description (e.g. from https://en.wikipedia.org/wiki/GPS_Exchange_Format)
"Latitude and longitude are expressed in decimal degrees, and elevation in meters, both using the WGS 84 datum.[6] Dates and times are expressed in Coordinated Universal Time (UTC) using ISO 8601 format.[1]"
So as the GPX format is mostly produced by "GPS trackers" the altitude is measured in relation to the WGS 84 reference ellipsoid (aka "GPS altitude").
Currently the above "PLANE ALTITUDE" simulation variable comes closest to this definition (but it is not clear at all what "PLANE ALTITUDE" actually is: could be some MSFS specific, internal altitude measurement). But this is the altitude not depending on pressure at all, so at the time I chose this as export value for the GPX format... uh... wait a second ;)
I just said that I assumed PLANE ALTITUDE (the value reported by MSFS) to be "height above some reference ellipsoid" (aka "GPS altitude" - it is even documented as such in my code):
https://github.com/till213/SkyDolly/blob/main/src/Model/include/Model/PositionData.h
struct MODEL_API PositionData final : public TimeVariableData
{
// Position
double latitude {0.0};
double longitude {0.0};
// GPS altitude
double altitude {0.0};
// Indicated pressure altitude (analytical purposes only)
double indicatedAltitude {0.0};
...
};However I actually convert this altitude - again - from (wrongly assumed?) 'orthometric altitude' (EGM = earth gravity model - taking earth gravity undulation values into account) to reference altitude:
// Convert height above EGM geoid to height above WGS84 ellipsoid (HAE) [meters]
const double heightAboveEllipsoid = d->convert.egmToWgs84Ellipsoid(Convert::feetToMeters(positionData.altitude), positionData.latitude, positionData.longitude);
const QString trackPoint =
" <trkpt lat=\"" % Export::formatCoordinate(positionData.latitude) % "\" lon=\"" % Export::formatCoordinate(positionData.longitude) % "\">\n"
" <ele>" % Export::formatNumber(heightAboveEllipsoid).toUtf8() % "</ele>\n"
" <time>" % dateTimeUtc.toString(Qt::ISODate) % "</time>\n"
" </trkpt>\n";-> You could try and remove the "undulation values" file from the Sky Dolly Resources\geoids directory (simply remove/rename that entire geoids subdirectory)
With that "undulation values" resource file (which is really optional: Sky Dolly properly checks its existence) removed the heights are not converted at all. Like this you would get the "raw PLANE ALTITUDE" value in the exported GPX file.
And yes, in case of the KML export I indeed simply export the "PLANE ALTITUDE" value "as is" (and mark it as "absolute altitude" value in the KML file). So if this gives the expected value ("-1.5 metres") then I will adjust the GPX export plugin as well!
Is the exported height then more sensible?
Again, I am not quite sure what PLANE ALTITUDE really is ("GPS altitude" or "orthometric altitude above the geoid"), but I remember having had discussions about it with some other developer... but I cannot remember its outcome.
But when you say that the expected altitude at that point is really "-1.5 metres" (instead of "+42 metres") then this conversion is probably wrong
gaboroszkar
Describe the bug GPX export elevation data might be incorrect. Not sure why, but it showed me +42 m at Rotterdam Airport at L apron using the default Cessna 152 aircraft. The elevation using different recording methods show around -1 m elevation there. (Officially the elevation there is -15 ft, but looks like every other software I tried and even the KML export says, that it is not +42 m there, but rather around -1 m, which is much closer to reality than the values in GPX file.)
Inconsistency with KML file. The GPX elevation data is inconsistent with the KML file's elevation data. When I export the same flight in both KML and GPX format, and then import those files in Google Earth Pro, it shows me two paths, and the difference between them is around 40 m (120 ft). (When importing the data in Google Earth Pro, I used "Absolute" as altitude reference in the "Altitude" tab in "Edit Path" window.)
Inconsistency with SimFlightPath. I also recorded a similar path with SimFlightPath (https://flightsim.to/file/15872/simflightpath). The GPX file's elevation data is clearly different. At the same stand, SimFlightPath's exported GPX shows around -1 m, where SkyDolly's exported GPX shows around +42 m.
Inconsistency with Little Navmap. While Little Navmap (https://albar965.github.io/littlenavmap.html) was connected to the sim at the same location, it was recording an Aircraft Trail. (Does this recording automatically when it's connected to the simulator.) I exported this with "File", "GPS Exchange Format (GPX)", "Export Flight Plan and Trail as GPX", and it showed me inconsistent values with SkyDolly.
To Reproduce Steps to reproduce the behavior:
Expected behavior The
<ele>tag's value should show around -1 at the stand instead of the current +42, and the elevation at the stand should show around -1 m in the elevation profile in Google Earth Pro.Application version: "Humble Hawker" (2024.07) Version 0.17.5 (4cf6f06f) Thu Jul 4 12:32:10 2024
Additional context The followings show the Cessna 152 on the ground exported by different applications. They're not exactly the same stand, but all of them are at the same L apron at EHRD.
SkyDolly, first waypoint in the GPX file exported is the following.
SkyDolly, first waypoint in the KML file exported is the following.
SimFlightPath, first waypoint in the GPX file exported is the following.
Little Navmap, first waypoint in the GPX file exported is the following.