Elevation differences between Map Processing Report and Map

I have just finished processing a map using GCPs obtained with a quality GNSS Base and Rover.
I am having a problem with my Map Processing Report versus the displayed map in Projects.

The Map Processing Report is showing the correct elevations for my project while the map shown in Projects is showing totally different elevations as if it did not use my GCPs at all.

Screen shots:

Notice the Map Processing Report has the correct elevations in the -32 range while the map is showing elevation as if my GCPs were not factored in.

Thank you in advance for any response.

1 Like

One is in meters and the other in feet? What exactly is not matching and why are your elevations negative? If you shot GCP’s why wouldn’t they be orthometric and above sea level?

1 Like

Sorry, that is my fault on the feet and yards. I was in a rush.

But you bring up my other problem.

I used Emlid Reach RS2 and + to get my GCPs. They give the vertical in ellipsoid as we can see with the negative values.

How can I get my output to show the orthmetric height?

Here is how I am trying to do it in Pix4D.

My Emlid RS2 (Base) is on an accurate geodetic control point that gives me its coordinates and vertical ellipsoid, geoid and orthometric height.

Plan to obtain orthometric height for all GCP and CP:

What I have:
Datasheet on geodetic control point with ellipsoid, geoid and ortho height:
Ellipsoid height on geodetic control point
Ellipsoid height on my GCPs obtained with Reach RS2 on control point
Base: Ortho Height 2.020, Ellipsoid: -32.371
GCP and CP ellipsoid heights: varying

I took the ellipsoid GCP heights and subtracted them from the RS 2 Base ellipsoid (-32.371) and this is now column F
I then took column F and added it to the RS 2 Base ortho height of 2.02 and got my ortho height in column G

Column G is now what I want to use as my vertical height for my GCPs.

Is this correct? Or am I overlooking something?

I can only tell from the truncated coordinates that you are in/near Atlantic City?

Actually it’s DroneDeploy’s fault for not maintaining the unit of measurement preference. Ours does the same thing in reports vs the Explore interface.

Try this site to use GEOID18 and you observed Ellipsoid heights to calculate your orthometric heights. In that confined of an area the GEOID height should be pretty consistent but it is still best to use the calculator. Just copy your GCP file, open in NotePad and remove all the data except for the LLH. Then swap the Lon and Lat. Most programs use Lat/Lon or Northing/Easting.


Next let’s discuss why you aren’t getting ortho and SPC’s in Reachview. Are you running the RS2 off of a CORS via NTRIP?

Thanks Michael for your answers. You are on almost all of the forums I use to learn all of this information (Drone Deploy, Emlid, Commercial Drone Pilots), and I always value your input.

Please excuse my ignorance in this as I just obtained my Emlid units and I have been reading the Emlid forum and Docs and attempting to digest this info which is still a bit overwhelming but I’m getting there.

“I can only tell from the truncated coordinates that you are in/near Atlantic City?”

Yes, I am in Atlantic City, NJ and I use a closed airport as a training area and I am in luck that there are two high accuracy geodetic control points available with datasheets so I can use them to help learn RTK, PPK and PPP as well as OPUS.

“Next let’s discuss why you aren’t getting ortho and SPC’s in Reachview. Are you running the RS2 off of a CORS via NTRIP?”

I did not know you could get ortho heights off of Reachview. I am not using Reachview 3 so maybe that is the problem. For my RTK I am using my RS2 as my base, placed over an accurate monument for which I have the datasheet. I then am using my RS+ as the rover. I am entering the height of the Base in ellipsoid provided by the datasheet.

Thanks for your time and input as usual.

This makes more sense know with what you have going on. Reachview 2 (Panel) is WGS84 only. Do you know what reference system your control points are based off of? I am thinking they are probably NAD83. This would mean that you need to convert your coordinates for entry into Base Mode because the two do not match each other either horizontally or vertically with the WGS84 ellipsoid and the GRS80 ellipsoid of NAD83.

Ok, I really screwed this up. It might be best if I start over using Reachview 3.

My problem is the Emlids are new, and I have never done GCPs before. I think I will start over so I can get my workflow ironed out.

So the Reaches are expecting WGS 84 and in both RTK and my PPK I was giving it NAD83 2011. I guess this could be the reason why my PPK outputs were always more FLOAT than FIX?

I am going to come up with and post a new workflow. I am going to relearn RTK from scratch.

I have moved my RTK problem over to the Emlid forum as this really has nothing to do with Drone Deploy.



See you there. We can cross-post a link for history.