I am working with two digital elevation model data sets: LiDar and UAV DEMs. Both flights were conducted in the same location along a coastal shoreline showing the intertidal area with lots of bare rock and sand. The UAV layer is older and has poor accuracy compared to the LiDar file which is a newly conducted flight. The UAV digital elevation model is inaccurate by ~5-10m. The photos below show the logarithmic error of the UAV DEM.

SW-NE cross-section over the figure above, showing a logarithmic increase in bias from West to East: enter image description here

NW-SE cross section, showing not as strong but still considerable gradient:

enter image description here

Is there a tool in QGIS, Global Mapper, or Pix4D that can modify this UAV layer to improve the accuracy? I have tried the 'rubber sheeting' method in both QGIS 3.1 and Global Mapper, but did not have any luck. My assumption about the UAV DEM is there were issues during the pre-processing stage, perhaps with the flight overlap % or the qualities of the GCPs used to process it. I don't have access to the older files so cannot go back and add anything to the project to improve the model, unfortunately.

I am new to remote sensing, and have yet to work with python, CAD, or postgis.

  • Your UAV surface is off 5-10 meters from the LiDAR surface? This sounds like a vertical datum issue. What vertical datum is your LiDAR referencing and what vertical datum is your UAV surface referencing? Also, Structure from Motion performs poorly in forested areas. Maybe some of the upland areas were forested and those errors are represented in the UAV surface? – GBG Feb 22 at 19:25
  • Thanks for your comment- Sorry, there is a 10cm difference in the vertical datum yes. I am not sure I understand the next question about what vertical datum they are referencing- They are both orthometric datums. There are cliff faces in both the raster layers and some forested areas! The LiDAR was collected via helicopter remote sensing (standardized throughout the province) and the drone was conducted on two Phantum drones with differing resolutions and non-uniform ground point RTKs (given it is a challenging tidal region to place GCPs) – Rebecca Dodge Mar 25 at 17:39

Was your LiDAR data produced by a contractor? If so, you should have a report that accompanies the data that details the vertical datum of the LiDAR. In the USA a vendor will typically produce a LiDAR dataset that reference the North American Vertical Datum of 1988.

The vertical datum of the GNSS tagged images of my Phantom 4 Pro return elevations referencing the WGS84 ellipsoid. Where I am from this is a ~20 m difference so comparing LiDAR to a drone surface generated from the drone EXIF data will not work. I suspect this is your issue.

In order to force the sUAV flight to reference NAVD88 I need to collect ground control points and ensure those ground control point Z values reference NAVD88 before processing in the structure from motion software(SfM). There are some steps required (settings and downloads) to force these ground control points conform to NAVD88 using my Trimble 7x centimeter edition GNSS.

Confirm the vertical datum of your LiDAR. Confirm the vertical datum of your SfM surface. Confirm the vertical datum of your RTK data. If your SfM drone surface is not using the same vertical datum as the LiDAR you will need to reproduce the SfM surface. Applications like vDatum will convert between vertical datums such that you could adjust your GCPs to the same vertical datum as the LiDAR. Then reprocess the drone data.

If your drone flight did not include any GCPs then you may need to re-fly your beach. The GNSS Z values from a consumer grade drone will not produce accurate enough values to result in a surface model of sufficient quality to compare change against a LiDAR dataset.

Can you explain the workflow of using non-uniform ground point RTKs?

  • This comment was useful- I will answer the questions you pose. The lidar was produced by a government agency and I obtained the data in a LAS file and converted it to geotiff. It did not come with a report. The lidar reference system is: EPSG: 2961-NAD83 (CSRS)/UTM zone 20N. The drone reference system is: EPSG: 4326-WGS 84-Geographic. However, I projected the drone layer to the same reference system at the lidar one (EPSH 2961-NAD83). – Rebecca Dodge Mar 29 at 17:10
  • From what I understand- I have to change the vertical datum of my GCPs to match the lidar reference system and reprocess the flights. Do you know if there is an equivalent vDatum for those not in the US? It doesn't give me a Canadian region setting. I was not a part of the drone fligts/placing of GCPs so I cannot speak to the methods that were chosen. I was only just given this data to process and work with the best I could. – Rebecca Dodge Mar 29 at 17:20
  • Sorry, I do not know about using vDatum outside of the USA. Keep in mind the EPSG code you mention are coordinate reference systems and different from the many vertical datums your z values might be expressed in. @mkennedy may provide some insight into your problems. – GBG Mar 30 at 15:29
  • Maybe you could use PyProj to do the conversion but I have no experience with that. proj.org/operations/transformations/vgridshift.html – GBG Mar 30 at 16:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.