Support Website Contact Support Blog

Generated mesh elevation is about 100 feet off


I am working on my 1st Pix4d project. I am using a firefly 6 RTK drone with a Sony RX1 42mp camera. Our drone works in WGS 84 coordinates, and the vertical datum is WGS Ellipsoid in meters. I am working in in the USA in Wisconsin State Plane, Central Zone NAD83, US Survey feet. We are not using GCP’s because we have an RTK/PPK equipped drone. We currently use some bare earth LIDAR that our local government(s) have generated as our base topography. That data has a vertical datum of NAVD 88. When I run steps 1 and 2 and spot check the mesh generated, the elevation of the mesh seems to be roughly 100 feet lower than the LIDAR data. I have spoken to the drone folks to make sure I understood the output datum from the drone for the geo tags and I am pretty sure that I have that setup correctly. When I look at the elevation of the base station and the drone when it is sitting on the ground the elevation is about where I would expect it to be in comparison to the LIDAR data. When I generate the DSM/DTM will the data be at the same elevation as the mesh generated in step 2? I am hoping someone could help me with some trouble shooting steps as I am on my third try and I am not looking forward to all the point cloud editing I need to do to get the DSM/DTM to generate cleanly (only to find that the surface is off again).


Scott Timan

Hi @stiman,

Could you please share here the Quality Report of the project together with some screenshots showing the issue? I’d help us understand the problem better. Thanks!

Ok. Since we did not have any GCPs (the whole idea with the RTK drone is not to have to place any out) I decided to look at the most recent aerial image available of the site and pick out some power pole bases that were around the project to add in as GCPs. Using Global mapper v21.1 with the project set up in the correct state plane coordinates I imported the world imagery data of the site and the local lidar data. I then picked out 7 poles that I am pretty sure have not been moved since the LIDAR was collected. I placed a point at each point and assigned each point an elevation from the LIDAR data. After running step one it looks like the surface grid is now close to the elevation I am expecting it to be. I then ran step 2 but now I have ran into issues with the point cloud (The tops of the buildings and hills are chopped off). I am attaching two reports. The first report is the original run of the project where the Surface is lower than the LIDAR: Blair_DPRAIL_420ft_3-24-20_report.pdf (1.3 MB) the second is from this latest run where the surface is close to the correct elevation with the GCPs added: Blair_DPRail_420ft_3-24-2020_Corrected_report.pdf (1.3 MB) I am also attaching two screen shots to illustrate what I am see about the elevation issue:

the cyan surface is the LIDAR surface and the blue surface is the original pix 4d surface. This picture is a cross section in the showing the difference in elevation: I hope this gives you enough information for a start.


Looks like a geoid issue. Personally I avoid allowing Pix4D do vertical transformations as it doesn’t support custom geoids like 12B and 18 for the US. When you process your PPK data, do you have the option of exporting to csv? My process is to generate a geotag csv from my processed PPK data in state plane feet using the appropriate geoid. Then import to Pix4D. Be sure to set your vertical to arbitrary in Pix4D so it won’t do any vertical transformations.


Thank you for the response. I figure it might be something along those lines. What we typically do is generate a geotag text file from the drone autopilot logs that has the processed RTK or PPK WGS 84 data for each picture (along with the other camera data) and then import the pictures and text file into PIX4d so we don’t have to tag each photo.

If I am reading your comments right, you would pull the x, y, and z data from the text file into a GIS program that can read the coordinate system data correctly and then re-project it into the correct state plane system and then write it back to the text file that PIX4d brings in. Then set up the PIX4d project to just use the state plane system without any transformation. I have Global Mapper as my go to GIS program. The only thing I worry about is the vertical datum. I am not sure on how it handle the WGS84 ellipsoid to state plane transition. I need to check on how Global Mapper would handle that aspect of it.

It sounds like a good thing to try. I will give it a shot. Thank you for the suggestion.


Can your PPK processing software export to state plane using geoids? I have a Wingtra and right now it only exports global coordinates (lat, long, ellipsoid height). So I import the global coordinates into Trimble business center and covert to state plane nad 83, navd 1988. Then export back out as a csv for import into Pix4D.

For small sites you can use your images in global coordinates and manually enter the difference between the geoid and ellipsoid in Pix4D.


The drone software only exports the geotag data in wgs84 just like yours. I will have to peruse the same solution you have. I have a email out to Global Mapper to see if it can do what you have explained. The sites I am working with are fairly large so having it adjusted right will make a difference on the edges. I think we may have a copy of Trimble Business Center I will need to check as that might be an option.

I haven’t used this before, but you might want to try this tool from NGS: vDatum