Orthophotogrametry Elevation Processing

jf121 · Oct 11, 2022

Per the responses to my thread about Altitude Errors, I now understand that the elevation or 'altitude' of the drone and the images it captures are relative to the WGS ellipsoid. When I survey the ground control points, the xyz are in State Plane Ft with z = feet above NAVD88. I am using agisoft metashape to process the survey data. I keep getting very poor results.

Understanding that the elevations of the cameras (photos) are relative to WGS, I specify the reference system for my cameras as WGS (meters). When I load in my xyz control points I specify that they are in stpft, with elevations in feet.

Is this the correct way to process data? It seems as though agisoft does not realize that the altitude is relative to the WGS ellipsoid - it seems to assume that the elevation datums are the same.

P.S. I dont recall having this issue with my DJI Phantom II

Dave Pitman · Oct 11, 2022

jf121 said:
Is this the correct way to process data? I

You are close. In metashape import your photos. Metashape will recognize the crs based on the image exif data. Align the photos.Next, before you import your control points, convert the cameras to the crs used for the points.
Now when you import your points and specify the crs (which now matches the cameras) you should be good.

jf121 · Oct 12, 2022

Dave,

I still don't think that is solving my problems. I am aware that I have to set the camera reference as WGS 84 and my makers (in my case) to NAD83 / Delaware (ftUS). If I change the Coordinate System of the project, it does not convert the cameras to my desired coordinate system. It merely prescribes the value of latitude and longitude to Northing and Easting (ft) with conversion:

e.g. Longitude = -75.4 --> Easting (ft) -75.4

If I use the convert tool, it does, in fact, convert from WGS to State Plane feet. However, the vertical datum is still the ellipsoid, not NAVD88. Does optimizing the alignment perform the transformation? If so, the RTK is essentially useless since I still need dense GCPs.

Thanks,

jf121 · Oct 12, 2022

I realized that I have to modify the State Plane feet coord system to the NAVD88 datum after viewing the following tutorial:

However, I do not have a NAVD88.gsf file so I cannot make the conversion.

Also, what geoid does autel use, (12, 12A, 18?)

Dave Pitman · Oct 12, 2022

A more simple and straightforward approach may be to correct the actual vertical offset by applying the offset to the image exif. It is very easy with an app called Redtoolbox. There is a free trial to see if it works for you. Or track down the appropriate geoid model to import into Metashape.

jf121 · Oct 12, 2022

Dave,

This video helped me understand my issue:

geoid agisoft ellipsoidal germany - Search Videos

www.bing.com

However, I require a .tif or other raster that represents the conversion to NAVD88. Is there such a raster available? And from where?

For now, I am converting the GCP to the ellipsoidal height using values found using the NGS's tool assuming the Geoid is 12A . . .

jf121 · Oct 12, 2022

I also came across this free tool:

Editing, Creating and Viewing EXIF data with free Exif editor

Exif Pilot - free exif editor. View, create and edit EXIF, EXIF GPS, IPTC, and XMP data. Import or export EXIF or IPTC tags from/to XML, MS Excel or Text files.

www.colorpilot.com

I will report back to the forum to let folks know how well it works.

yarrr · Oct 15, 2022

jf121 said:
Dave,

This video helped me understand my issue:

geoid agisoft ellipsoidal germany - Search Videos

www.bing.com

However, I require a .tif or other raster that represents the conversion to NAVD88. Is there such a raster available? And from where?

For now, I am converting the GCP to the ellipsoidal height using values found using the NGS's tool assuming the Geoid is 12A . . .

Agisoft Metashape: Geoids

Shelby Griggs · Oct 16, 2022

Geoid models are just a tool, all produce NAVD88 orthometric heights when applied to the the NAD83 ellipsoid heights. Each ground model is keyed to a specific NAD83; realization. The latest would be NAD83(2011) and Geoid18.

In all but a few locations in the USA which I believe were specifically the Gulf Coast area, Geoid 12Aband 12B we're the same, I know that to be true in my part of the world in the PNW.

I assume you were NOT using a RTK drone or even PPK, otherwise you would already be corrected to NAD83 and a local geoid model.

Dave Pitman · Oct 16, 2022

Shelby Griggs said:
I assume you were NOT using a RTK drone or even PPK, otherwise you would already be corrected to NAD83 and a local geoid model.

Hi Shelby.

It sounds like the OP is not using receiving NTRIP corrections on the drone. So, the elevation would indeed be referenced to wgs84 elipsoid. Then, he is using ground control referenced to state plane. Thus, the offset. That said, it is pretty easy to assign the geoid offset in Metashape if you know what it is on the project site.

Also, there are NTRIP providers in the US that are not using NAD83. But probably not many. I often use my own NTRIP base through a service provided by Emlid they call Emlid Caster, And in this case, the base is often set up on an averaged single point collected referenced to wgs84.

So, yeah, dealing with the elipsoid / geoid offset is not that uncommon.

jf121 · Oct 17, 2022

Shelby Griggs said:
Geoid models are just a tool, all produce NAVD88 orthometric heights when applied to the the NAD83 ellipsoid heights. Each ground model is keyed to a specific NAD83; realization. The latest would be NAD83(2011) and Geoid18.

In all but a few locations in the USA which I believe were specifically the Gulf Coast area, Geoid 12Aband 12B we're the same, I know that to be true in my part of the world in the PNW.

I assume you were NOT using a RTK drone or even PPK, otherwise you would already be corrected to NAD83 and a local geoid model.

Shelby,

I am using the EVO II Enterprise RTK (which is why I am posting in this section). I am connected to a Virtual Reference System (VRS), specifically, USACE/Keynet. It was my assumption that the RTK would return elevations orthometric heights. However, the altitude of the images in the .exif files are off by roughly the difference between the geoid and NAVD.

For now, I will continue adjusting my GCPs to the geoid elevation and then correcting it in post processing.

jf121 · Oct 17, 2022

jf121 said:
Shelby,

I am using the EVO II Enterprise RTK (which is why I am posting in this section). I am connected to a Virtual Reference System (VRS), specifically, USACE/Keynet. It was my assumption that the RTK would return elevations orthometric heights. However, the altitude of the images in the .exif files are off by roughly the difference between the geoid and NAVD.

For now, I will continue adjusting my GCPs to the geoid elevation and then correcting it in post processing.

yarrr said:
Agisoft Metashape: Geoids

Unfortunately, I cannot access agiosoft webpages. Likely due to the fact it is a Russian company.

Shelby Griggs · Oct 17, 2022

NTRIP corrections are going to in general be Latitude/Longitude/Ellipsoidal heights from any RTN in the USA. If working a small area, the Geoid model offset to NAVD88 is going to generally be a constant, HOWEVER, be aware that it really changes place to place, it can be feet different over a larger area. BEFORE adjusting to GCP's, it would be best if everything is in the final reference frame ie: NAVD88 generally in USA. In my work (mostly manned flights with a bit of UAV), we correct the aircraft data to NAVD88 and the GCP's to NAVD88 before running through processing of the images. I am not familiar with all the software for UAV image processing, BUT I would think same procedures would be good practice.

Since you used a correction service via receiving NTRIP corrections, your aircraft data is differentially corrected, BUT the heights in the EXIF data are ellipsoidal. If a small project, perhaps you could manually edit that data to NAVD88? NGS has tools for doing that. GEOID18 Interactive Computation | GEOID | Data & Imagery | National Geodetic Survey