Hello,

few days ago I've tried my first 2D mapping mission including the terrain awareness and KML import. I've downloaded the DSM from USGS, dataset SRTM 1 Arc second global.
Importing it and planning went fine, but in the field the flight height was abut 100 m higher then planned.

Now, I suppose the problem is the orthometric vs ellipsoidal height of the imported DSM.

Did anyone found out an easy way to just download the DSM of desired area and throw it in the flight planning app, without having to do heavy calculation/conversion?

I suppose if you consider simple arithmetic "heavy calculation/conversion", then it would be too much to simply get the ellipsoid/geoid separation for your location and add it to the DSM? Or obtain a DSM in HAE.

patiam Posted at 5-3 08:13
I suppose if you consider simple arithmetic "heavy calculation/conversion", then it would be too much to simply get the ellipsoid/geoid separation for your location and add it to the DSM? Or obtain a DSM in HAE.

Patiam,
I just went the QGIS way. Downloaded my DEM via SRTM downloader plugin from Earthdata (got an *.hgt file), importet my kmz as boundaries, clipped the HGT with Raster by Mask and created a tfw file with OSGeo4W shell.

Now I have to test it. Do you think this is a good way?

To be honest, I have a geoid file for my country in byn format, but don't know how to add it to the DSM ;). And obtaining a DSM in HAE is unknown to me.

It is unlikely that the Geoid height varies much over the extent of your flight area (maybe by a meter or less) So just get the geoid value for a single point in the center of your flight area and add that to your DSM (which is in Othrometric height, H) to get a DSM in HAE (h)
H = h – N.
H + N = h


Ellipsoid height (h) is the difference between the ellipsoid and a point on the Earth’s surface. It is also called the geodetic height (not to be confused with geodetic datums). If you have coordinates that were captured with a GPS receiver, the elevation data reference the ellipsoid, meaning it has to be transformed to match the more accurate geoid instead.

Geoid height (N) is the offset value between the reference geoid and the ellipsoid models.

Orthometric height (H)—AKA the one you really care about— is the distance between a point on the Earth’s surface and the geoid. As we already discussed, the geoid represents Mean Sea Level. When you hear elevation data described as “X feet above (or below) sea level,” that’s referring to orthometric height.


https://www.propelleraero.com/bl ... ats-the-difference/


UNAVCO

patiam Posted at 5-3 13:21
It is unlikely that the Geoid height varies much over the extent of your flight area (maybe by a meter or less) So just get the geoid value for a single point in the center of your flight area and add that to your DSM (which is in Othrometric height, H) to get a DSM in HAE (h)
H = h – N.
H + N = h

I understand the drawing, but I don't understand how my geoid height is not varying trough the extent. The height differences are up to 60 m on a 40 ha area, so the geoid varies accordingly in every point.

Or do you mean that I should just fixate one point of the DSM and that the others will ne calculated automatically in the P4RTK flight app?

The ellipsoid is a smooth-ish curved surface. The Geoid height is irregular but on the scale you mentioned does not vary by the amount you are reporting.

You have a DSM in Orthometric height. If you add the Geoid height to your DSM you will have one in HAE. Because N does not vary that much on a small scale you can use a single value.

What is the center Lat/Lon for your site? And the corners? Try entering them here to prove to yourself that N does not vary as much as you think.
And one more question- you have RTK fixed during your flight, correct?

The corners are 45.5805190081, 16.6319150594. I took 274 m from one of the drone images (from the drone GPS) and when I put them into this calculator, it gives me +48,63 m for ellipse and +225,37 m for geoid.

Perhaps I did not write my first post understandable. The whole flight with DEM as background was 100 m off. The moment I saw the drone climbing to 200 m (instead of 105) and beginning the mission, I stopped it. so I could not see if it would do any terrain follow.

I do PPK, not RTK. With GCPs.

BTW, thank you for spending your time

PPK is great but not for terrain following. You can't do terrain following w/o RTK fixed (you need high accuracy in RealTime, not Post-Processing). When RTK is not fixed the A/C is using barometric pressure for altitude. This is not accurate enough and too noisy for reliable conversion to HAE or orthometric height.

I should have asked that question first, it would have saved time.

See this thread: https://forum.dji.com/forum.php? ... =248710&pid=2545237

And this may be of interest: https://forum.dji.com/forum.php? ... =181111&pid=2043460

patiam Posted at 5-4 07:39
PPK is great but not for terrain following. You can't do terrain following w/o RTK fixed (you need high accuracy in RealTime, not Post-Processing). When RTK is not fixed the A/C is using barometric pressure for altitude. This is not accurate enough and too noisy for reliable conversion to HAE or orthometric height.

I should have asked that question first, it would have saved time.

Now that is interesting. I've done a lot of mapping on steep slopes with the DJI P3P and P4P, but using Map pilot. It's a great app that is easy to use, no importing, no ellipsoid, geoid. You just select terrain awareness and the app calculates it. No RTK, no PPK, just plain GNSS. And it came out well.

So I believe that with GCPs and good planning you don't need RTK.

What's the minimum altitude above your DSM that Map Pilot will let you fly using TA?
If it works so well, why don't you use Map Pilot to fly your P4RTK w/ TA?

This comes down to decisions made by the developer. Some devs are more risk averse (especially when they may be on the hook to replace your drone if their software crashes it). And some solutions are more elegant than others. It's quite possible the Map Pilot folks came up with a way to achieve decent TA even with the unreliable Z information available w/o RTK, but DJI's haven't.

I'm not saying terrain following can't be done w/o RTK. I'm saying that for the P4 RTK DJI + GS RTK, DJI advises against it, and multiple users that have done it (you included) have reported undesired and potentially dangerous results.
I don't disagree with your last statement in general; one can achieve just as good or better results using PPK + GCPs as with RTK. But if you want to use TA w/ the P4R + GS RTK, PPK doesn't cut it.

dario.finderlegmail.com Posted at 5-3 09:45
Patiam,
I just went the QGIS way. Downloaded my DEM via SRTM downloader plugin from Earthdata (got an *.hgt file), importet my kmz as boundaries, clipped the HGT with Raster by Mask and created a tfw file with OSGeo4W shell.

Thanks for this good info.