Elevation issues from NAVD88 vert

kevin.sauerwald · January 8, 2024, 10:43pm

Not sure whats going on. Using Mavic3E to shoot, taking GCP’s with Emlid RS2.
The drone does WGS84 and my GCP’s were in NAD83 PA S, vert was ellipsoid.

I need to get my elevations in NAVD88 like everyone else in the US. So in reading lots of posts. I should do step 1, set my export as NAD83 PA S, vert as “arbitrary”.
Here is a GCP target we shot

So when I do step one and select this same point it says the elevation is 446.378, after step one what is that in ? I know its feet, but I guess it converts the ellipsoid into feet ?

So now when I go to pull in my GCP’s from the file where I converted everything to be NAD83 PA S feet, they are spot on in N & E, but 100’ up in the air. Is that expected and I need to then tell it to correct to the ground point and then it will all be fixed ? or did I do something totally wrong.

so review
-Drone WGS84
-set output to NAD83 PA S Feet, vert arbitrary
-run step one, GCP point vert shows 446
-import GCP’s that are captured NAD83 PA S feet, Vert NAVD88 feet - imported as NAD83 PA S, Vert arbitrary
-This GCP shows up in the air at 559’ and the ground is still in the 440’s

I do something starting that is wrong ? or need to do something interesting from here on out ?
If I do this all non “arbitrary” vert, things line up. I just need my elevations in NAVD88 so they match the rest of the US’s map records.

Thanks for any help… let me know if there are any questions… its confusing.

Mike_K · January 12, 2024, 9:43pm

Hi Kevin,
Can you upload your quality report to this posting? It will help us understand what is going on.

Are you marking your GCPs, and are they in your selected vertical coordinate system? Can you also attach some screenshots?

Andrew_Milanes · January 14, 2024, 12:21am

Since Pix4DMapper doesn’t support local geoids, you have to manually enter a geoid offset.

kevin.sauerwald · January 14, 2024, 4:29pm

So this could just be me not understanding the process here with correcting offset with initial build and then how to use the GCP’s that are spot on…

So here is shot of the output settings with my correction and my blue GCP showing pretty close to correct

Now when I go to put in my GCP’s which are recorded correct for elevation, what should this look like ? I assume no offset since its correct ?

Lets say I do that… if its correct… it says hey you are about to change your coord system

If I say yes… my Blue GCP is off again by -112.

So if I start over and switch back my Coord system with offset of -112.xxx everything shows elevations correct of the 559.
Then I put in my correct GCP’s (which show 559) and then put in in the offset of -112, my points do lay on top of my GCP’s, so all is good… strange…

so I guess I solved my issue but it make no sense to me why you would put the offset in for the GCP’s since they are 100% correct. Someone want way to weigh in on that ?

Andrew_Milanes · January 14, 2024, 6:17pm

You’re not putting in a vertical offset per se. You are manually entering the conversion from ellipsoid height to orthometric height for this location. If you set your GCPs to checkpoints and re-optimize, your checkpoints should be fairly close (within a few feet).

This is one “feature” of Pix4DMapper that Pix4D refuses to improve. Matic supports local geoids while Mapper does not.

The manual geoid offset works fine for small projects but not for large projects where the offset is not constant over the entire area. For this reason I always convert my image coordinates to state plane navd88 using Trimble Business Center. Then import a new exterior orientation file. The input and output coordinate systems are the same and I set the vertical to arbitrary so that no offset is applied. It’s one extra step but it ensures everything is correctly translated.

Daniele_Lecci · January 16, 2024, 8:04am

Hi @kevin.sauerwald,

Please take a look at this article:

In PIX4Dmapper you have 3 options:

→ Select a constant height shift. Recommended for small areas where geoid and ellipsoid can be considered parallel in a small portion of terrain. This approach will introduce inaccuracies in case of a large area or significant variations between the ellipsoid and geoid. Make sure to add the right sign (+ or -) to the constant shift.

→ Use a Global geoid model. Use EGM84, EGM96, or EGM2008

→ Use a local geoid model in combination with a third-party application. Typically, the local geoid models in different formats (ASCII, .grd, .tiff, etc.) and the transformation tools are provided by the national mapping institutions.

Additionally, as my colleague Mike suggested, please share with us the quality report of your project

Cheers,
Daniele

kevin.sauerwald · January 16, 2024, 6:44pm

here is the quality report you asked for. I just wondered why I need to do the offset when I do the GCP, since those are spot on… or is it because my orig was offset, everything needs to be offset ?

HilltownWaterTower_Redo_report.pdf (2.2 MB)

Daniele_Lecci · January 17, 2024, 10:54am

Hi @kevin.sauerwald,

Thank you for the quality report. I see that there are no GCPs in that processing round. Is this expected?

When you define the offset from the ellipsoid model, you are not actually adding/removing this value, but you are just “defining” the vertical coordinate system of your points to be at some elevation above the ellipsoidal model (this needs to be done because we have only global geoids model in PIX4Dmapper).

All of this, assuming that the vertical coordinate of your images is correct in the database.

Let me know if this helps you and if you are getting satisfactory results.

Daniele