Real life flight KML files start with the plane under ground

[michaelochs]

Describe the bug I tried to use SkyDolly to have MSFS2020 fly a flight that I flew in real life in a Cessna 172. Unfortunately the GPS coordinates even of the in board GPS are not exact to the cm, so when launching this flight, my plane moves back and forth between being a couple of feet under ground and being up to 20 feet above the ground but then falling down due to the lack of movement.

I thought I could select the 'Start on ground' option in the flight view but I can't click that box. It seems that all the info in there is read only.

To Reproduce Steps to reproduce the behavior:

1. Import a KML file of a real world flight
2. Play it back

Expected behavior The plane starts on the ground.

Application version: Version 0.9.0

Additional context Here is the tracklog file I used: tracklog-B0B3680D-589D-4931-B1E0-118C5EF8C8D6.zip

[till213]

Yes, this is a known issue and also documented here:

https://flightsim.to/file/9067/sky-dolly

Refer to chapter „Known issues“.

This is due to the fact that altitude data is currently taken „as is“, without any transformation. For the IGC (International Glider Commission) format the altitude is (as an example) a GPS measurement, referring to the WGS84 ellipsoid, whereas the terrain data in MSFS is referring to the EGM2008 geoid (most likely, according to experimental findings by other scenery developers).

Why am I mentioning the IGC file format here? Because there the GNSS altitude is explicitly specified to be referring to the WGS84 ellipsoid (there is actually another „pressure altitude“ in the „B records“ in the IGC file, referring to „standard pressure“ - but this one also results in „random“ altitude offsets, possibly even more so).

For altitudes in KML files I have yet to figure out whether the „source“ of the altitude is (can be) specified, and specifically what flightaware.com and flightradar24.com are actually exporting (I assume GNSS altitude as well, referring to the WGS84 ellipsoid).

My initial thought was to simply add a simple altitude offset on imported altitude data, based on some (manual or automated, if connected with MSFS) calibration at either the start- (takeoff) or endpoint (landing). But as it turns out such a simple homogeneous altitude offset would not suffice, especially for long airliner flights, due to different g force at various locations. So the flight path would either be aligned at take-off or landing, but possibly not both.

That is where the so-called undulation comes into play, basically defining the altitude difference between the WGS84 ellipsoid and the EGM geoid.

Unfortunately such files containing the undulation values for the entire planet are a multiple in size (MiB) of the current Sky Dolly installation size, so I‘ll have to give this some thought (apparently the MSFS installation also contains a 50+ MiB undulation file - but that would cause a dependency on an „undocumented feature“: the format could change at any time, the file could be relocated, not to mention that Sky Dolly would have to reliably locate that file in the first place, keyword: Steam vs Microsoft Store variants, custom installation paths etc.).

In short: this is work in progress and subject to future enhancements.

P.S. Undulation, geoid, EGM96, EGM2008 etc. was all new to me a couple of days ago, too :) As a matter of fact I just had a very insightful discussion about this topic with another developer starting two days ago.

[till213]

Oh and yes, all values in the „Simulation Variables“ dialog, including the „Start on ground“ values, are „read-only“. They represent the actual „simulation variables“ (sometimes „pretty-printed“ for the user) that have been captured from MSFS.

The „Start on ground“ is a boolean flag determined by MSFS (the flight simulator in general, or simply the „SimConnect server“) and is recorded by Sky Dolly at the very beginning of the recording. Upon replay, if that flag is set this makes the MSFS properly align the aircraft on the ground - especially the wheels (which would otherwise „sink“ into the runway/taxiway etc.).

But for imported flights this flag is not set (yet), as I do not yet check whether the given start coordinates are really on ground (some KML files from flightaware.com have a path actually starting only shortly after take-off, when the aircraft is already airborne).

Oh and I just now realised that you are importing a „self-created KML“, recorded with a „real flight“ - nice :)

[till213]

Hello,

Some updates: I have just started with this "imported aircraft not aligned with ground when taxiing/take-off/landing" issue and did some initial experiments, namely with the GeographicLib and conversion between WGS84 reference ellipsoid and geoid altitudes

Extremely simplified: altitude values referring to the WGS84 reference ellipsoid are typically GNSS (e.g. GPS) altitude measurements, whereas altitude values referring to the ellipoid are mostly referring to "mean sea level" (there are also different earth gravity models (EGM), with different precision) - but depending on the concrete location that may be above or below the "mean sea level", due to a different gravity force ("g force") at each location.

The difference altitude between WGS84 and geoid (EGM) altitudes is also called "undulation", and my initial thought was that the "misalignment" was caused by this difference.

A relative simple explanation about the difference between WGS84 and the various geoid models can e.g. be found here, which also offers an online evaluation for those "undulation values":

https://www.unavco.org/software/geodetic-utilities/geoid-height-calculator/geoid-height-calculator.html

Well, to summarise... the "undulation" wasn't the problem.

In fact, I first tried with other so-called IGC (international gliding commission) files which explicitly define in their specification that the "GNSS altitude" (= the altitude measured by e.g. GPS, Galileo or Glonass or any other GNSS) shall reference the WGS84 ellipsoid.

However the couple of examples that I've tried so far all seem to report an altitude relative to the geoid instead of the WGS84 reference ellipsoid - which, again, according to the specification is actually wrong.

How did I tell that the IGC files had an altitude close to the geoid? Because the reported values were quite close - but not quite, with an error around +/- 3 meters, sometimes up to 10 meters (in most cases also "too low", that is "below ground") - to what both MSFS 2020 and Google Earth reported to be the altitude at that point. But the undulation was typically in the range of 50 meters, so subtracting this value from the assumed WGS84 altitude would make matters even worse (= the aircraft would "deep dive" even more into the ground).

Or in other words: the fact that the reported values in the IGC files were way closer to the geoid altitude rather than the expected WGS84 reference ellipoid altitude made me conclude that those IGC files were simply violating the specification.

So what does that have to do with your KML track then? Because you have mentioned that you recorded this track with GPS yourself, so I was super curious what your "altitudes" would be!

And in fact they also seem to be geoid related instead of WGS84 (again, GNSS altitude data is typically recorded with the WGS84 reference ellipsoid as reference). So I assume that the software (on your GPS device?) does the conversion to geoid altitude values - but this is fine, since we are talking about KML and the KML format expected altitude values "above sea level" (there are actually a couple of different altitude modes for KLM, but "above sea level" is as specific as it gets).

Also, I noticed that your track is actually pretty exact (unlike with other IGC and KLM files, especially also coming from e.g. flightaware.com or flightradar24.com - the later two report "standard pressure altitudes", which is even more "hit and miss" with actual ground altitude). For instance in Google Earth I see:

So this is pretty accurate, I would say, and probably "as good as it gets" (interestingly the accuracy seems to have changed during the flight, so when you taxi home the path is higher than when taxiing for take-off - or vice versa).

And when I replay this imported KML in Sky Dolly - which is what we're after, in the end ;) - the aircraft (depending on which one I choose for replay) is almost on the taxiway.

Now I agree that what we see here is not satisfactory - but I am comparing your file with the other (IGC) files that I've tried, which were way off (in the range of up to 5 - 10 meters "below surface").

To summarise:

• Undulation is not the problem respectively trying to correct the imported tracks by the undulated values does not help at all (it might still be useful for "IGC files which actually follow the specification")
• The possibility to manually adjust the altitude values by some offset is probably (still) the way to go (can perhaps be automated in case a flight in MSFS is "active", in which case one can query the "ground altitude" at the given location)
• Further processing ("smoothening") of the track may be required, e.g. to assume that all altitudes are "on the ground" until a "noticeable difference in altitude change is detected"

The later may be tricky in case a) the aircraft position recording starts (only) shortly after take-off and most importantly b) that smoothening would not take taxiway / runway altitude differences into account (and the aircraft may still "sink into (or float above) the runway").

A tricky problem... I'll see what I can do.

[michaelochs]

Thanks for looking into this. I see this has merged, and sorry for not replying earlier. Looking forward to trying out the latest versions of SkyDolly!

[till213]

Thanks for looking into this. I see this has merged, and sorry for not replying earlier. Looking forward to trying out the latest versions of SkyDolly!

While this issue was automatically closed with the merge of the feature branch that introduced „undulation corrected altitude values“ (and introducing the third-party „GeographicLib“ which provides all the heavy-lifting) the actual non-alignment of „KML altitude values“ (which are actually „altitude above mean sea level“ and not (necessarily) „GPS altitude“ values referring to the WGS84 reference ellipsoid) is not solved yet.

That means I really need to „probe“ the actual ground altitude in MSFS and align the imported altitude values (those which are deemed „on the ground“) accordingly, and/or provide means to manually specify a „global altitude offset“ parameter.

In any case this is still „work in (future ;)) progress“, but please feel free to re-open this issue (or create a new one).

[till213]

Just re-opened this issue, as still not implemented.

[michaelochs]

Maybe one potential solution here could be to actually force points on the ground when they are:

• within a certain distance from the ground
• below a certain speed

And then have a linear transition between the clamped altitude and the actual altitude around the speed threshold or something?

This would address taxiing in the air.

[till213]

"force points on the ground"

Well, that's exactly the idea here ;)

However that requires knowing the exact "ground altitude", and there is no straigt-forward way to query this value for a given lat/lon position via the SimConnect API.

That is, there is the possibility to query the ground altitude for the given current position of the "user aircraft". Of course we can "teleport" the user aircraft first to the desired lat/lon location (which was commonly done back in the "FSX days", so I understand according to several discusssion forum entries), which is an "asynchronous operation" (like everything really via SimConnect).

We can handle "asynchronousity" just fine, but there might be a bigger issue: in case we "teleport" the user aircraft "to the other end of the world" MSFS may yet to have to download the actual ground geometry - and while doing so I don't know whether we would get a reasonable "ground altitude" value (I doubt so).

In other words: we would have to wait for an "unspecified amount of time" (depending on the download speed of the scenery) until the ground value could reliably be determined for the desired lat/lon.

So perhaps this requires an "interactive" approach where the aircraft would be teleported to each desired lat/lon and the user would have to confirm - interactively, via some "wizard dialog" - that the scenery has been (sufficiently) downloaded.

On the other hand it is my understanding that MSFS essentially stores a "basic world model" on the harddisk already, and the reported ground altitude values based on this "basic model" might be sufficiently accurate.

Or put differently: I just have to try it ;)