Questions about elevation settings for RS3 as base for RTK drone

I am at a site in New Hampshire, USA. trying to conduct an engineering survey of ongoing construction work and would like to set my base up with elevations in NAVD88. it appears the only option is ellipsoid height which is 70 ft off of site control elevation which is using NAVD88. this is a difficult thing to fix in processing as every photo is not in a correct datum to start with. my setup is RS3 tied to a CORS network, Autel RTK drone, mapping with WebODM then feeding through ReCap and bringing into Civil3d. any insight into how to convert and at what step would be appreciated if there is no way to set up the base correctly at the start. thanks.


It’s the difference between the default recorded height above ellipsoid (HAE) and geometric elevations calculated using a geoid so you need GCP’s. WebODM is not capable of processing using a geoid. If it is a very small area you can calculate the difference and apply the offset to the images or the data after the fact. Personally I NEVER touch the images unless I absolutely have to use PPK. I would rather bring the point cloud into Civil 3D, create the surface and modify the data there.


Hi Brett

Are you establishing a point with the RS3 receiving corrections from the CORS?
If so, the coordinate system used by the CORS will be the coordinate system of the point you collect. If the CORS is referencing NAVD88, then the point you collect will also reference NAVD88.

Then, are you using that collected point set up manually in the RS3 to send corrections to the drone? If so, the same applies. That NAVD88 height will be referenced in the image tags.

If your CORS is referencing ITRFXXXX, then you will indeed be referencing ellipsoid.


I would highly suggest Agisoft Metashape Pro. It’s great image processing software. I’m still finding all kinds of tweaks and functions it can do even after a year of purchasing a single seat. I also use the Autel Evo II Pro RTK. The software was recommended by @dpitman.
I was contemplating pix 4D but I’m glad I listened to Dave !

I use our state’s (SC) RTN for referencing everything to the NSRS while flying. Our state’s RTN is referencing ITRF2014 with ellipsoid heights. I setup my data controller for collecting GCP’s in this same datum. I also process all the imagery in the same datum. After processing imagery and verifying GCP’s with Metashape, it’s a simple matter of exporting to SC NAD 83(2011) epoch 2010.00 state plane coordinates using Metashape. Final imaging accuracies are usually within 2-5cm in both horizontal and vertical components.

The software was fairly easy to learn with some of Dave’s help and the online tutorials on the Agisoft website. I’m convinced it’s the best image processing software available for the cost.



Being able to process using a geoid and transform right out of the software while leaving all the collected data raw was an eye-opener. Having the ability to integrate the data with any Grid, localization, GIS or even something as simple as Google Earth made the delivery of the data to different clients and departments so much easier. Looking back on the days of having to use a $35K receiver, Phantom 4 Pro and a ton of GCP’s seems so far gone but my brain always remembers the days on the ground before GNSS was feasible and using an HP48 calc with IR transfer…


Steps (choose one):

WebODM: In WebODM processing settings, add a vertical offset of -70ft.
ReCap: Import with “Apply vertical offset” checked and set to -70ft.

Double-check the offset direction (-70ft to match NAVD88).
Ensure consistent application throughout the workflow.

As a disclaimer for others who may read this single offset method and think this solves the problem - it doesn’t. If there is any variance in the geoid across the property being observed your map error will be standards +/- whatever that variance is. The larger the tract the more variance there will be and likely more anomolies. The more relief on the surrounding terrain the more variance there will be. If you don’t care about cm-level accuracy this method will work fine but even something as simple as a flat 5 acre tract can easily have a 1-2cm variance in the geoid from one end to the other.


I can survey in the base station location in the Geoid datum being used for control at the Site, and I can pull that point into the base station settings in emlid flow, but it reverts to ellipsoid height even though the point is taken using the control datum in the survey tab of the app. I was tempted to manually enter the control elevation into the base settings, but the manual entry asks for the ellipsoid height. I assume the Geoid and ellipsoid are different in how they interpret elevation over distance and that using that as a workaround would not stand up to scrutiny and could result in minute inaccuracies in the processed data. If I continue to use ODM, I think the GCP approach is the correct one, if I can figure out how to transform datums in Agisoft, that would be a game changer and well worth the cost to me. thank you all for your feedback, overall very helpful. I plan on setting some GCPs tomorrow and will report back on elevation differences between ODM with GCPs and Agisoft with a datum trasformation (assuming I can figure that process out).

My goal is to use the processed data to confirm payment requisitions for a fairly large project. this would be acceptable if it wasn’t being compared to other survey methods. Adding an offset raises quite a few red flags for me and doesn’t quite meet my accuracy requirements, if asked by the contractor this seems like there could be quite a few inaccuracies brought in by just adding an offset. I certainly thought about trying this method out though.

I have downloaded the free trial and am exploring the program. I am working on developing my companies drone capabilities and as it seems to be with anything that is not understood well by the people holding the purse strings, my deliverables have to prove the technology is accurate and is valuable. I think agisoft is the best approach after a weekend with it.

1 Like

I think you have come to the right conclusions based on the information provided. RTK corrections are always provided with ellipsoid values because that is how GNSS works. Your options are to continue using GCP’s in WebODM or start using a photogrammetry software that allows for the use of a GEOID in processing. If you are tying to outside Survey data and want absolute cm-level accuracy make sure to localize your system before shooting GCP’s. Otherwise it is very easy for overall scaling and rotation to be slightly off.