There's actually no simple way that I know of to automate altitude AGL estimation along a defined track, but I can describe the method I use in case it is of interest to anyone or, even better, if anyone can suggest a more efficient method.
Litchi exports a kml file that defines track points at the mission waypoints (plus 4 extra track points per waypoint to define each curved turn). For the current example that looks like this:
View attachment 93214
We can extract the lat/long pairs from the sparse output, import them into Igor Pro, and run a custom function to create cumulative distance for each waypoint. The kml file also gives altitude AGL at each track point, based on Litchi's DEM and the mission waypoint altitudes above the take off point, so now we have lat/long/distance/altitude AGL values, but it has no information about altitude AGL between the track points, and so the values are only correct at those track points:
View attachment 93215
GE can display a continuous, interpolated, altitude MSL profile for this track, and you can also clamp it to ground to get a continuous ground elevation profile MSL under the track, but it will not display the difference and you cannot export the data, so that's a dead end in terms of trying to generate the flight altitude AGL resolved across the entire track.
However, we can use the
GPSVisualizer website tool to apply a DEM that discards the altitude data, creating a second file that has ground elevations MSL rather than flight altitude.
View attachment 93216
Now we have two data files, one describing the flight path altitude AGL and another describing the ground track altitude MSL under the flight path, but only at the sparse waypoints that define the mission. If we add these datasets then we can reconstruct the mission altitudes MSL at the mission exported track points:
View attachment 93217
Note that it looks approximately as expected, since all but one mission waypoint had identical altitudes above the takeoff point. The variation, which is of the order of a couple of meters, is due to differences in the DEM used by Litchi vs. the DEM used in this calculation.
The linear interpolation of the flight altitude MSL is usable, since that is how Litchi flies the mission. That's not so for the ground track elevation data however, since the ground does not behave like that in general between mission waypoints. It would be great if GPSVisualizer could take such a track defined by sparse track points and create an elevation profile at an arbitrary spatial resolution, but it will not do that - it only returns elevation data at the input track points.
To get around that problem, we can take the lat/long/distance/flight altitude MSL data and run a linear interpolation scheme to produce new values at equal distance intervals. In this case I created 1000 interpolated triplets giving a uniform spatial resolution of approximately 5 meters:
View attachment 93218
View attachment 93219
Processing those track points again using GPSVisualizer's DEM also generates a much higher resolution ground elevation profile:
View attachment 93220
Now we can subtract the high-resolution ground elevation profile from the flight altitude MSL profile to get a high-resolution flight altitude AGL profile:
View attachment 93221
Comparing this to the second graph that shows only flight altitude AGL at the exported track points illustrates the reason for generating the higher resolution ground profile.
