If you look around the net, most examples of doing topographic mapping for large land areas are only using nadir photos, no obliques. This doesn’t make much sense to me as are the obliques fairly critical in the accuracy of generating Topographics Maps / Digital Elevation Models (DEM) ?
Hi!
That’s a great question! When carrying out the photogrammetry you can run various algorithms to create a DEM from a sparse point cloud. You are correct in that using some oblique images within a dataset comprised mainly of Nadir images can increase the accuracy of a map. It can also help with some common issues such as DSM bowling which can pop up every once and a while. Please let us know if you have any questions moving forward.
Best,
Zach
I am quite surprised no one out there (including DroneDeploy?) seems to have run well controlled tests using different combinations of image types in data acquisition for large area mapping (including DEMs) to identify accuracy for different workflows. In other words, where the law of diminishing returns begins to really take effect. Shows you how new this whole industry is.
I would hazard a guess that because drone deploy can’t capture oblique images yet they don’t want to encourage you to do something you can’t to with thier app.
I agree, oblique images can vastly help to improve to accuracy of your data.
I have experimented with both and using Nadir images with GCPs has proven to be more accurate from a survey standpoint. Most solutions don’t support GCPs with oblique images for obvious reasons. The only thing I has seen the introduction of oblique images do is clean up vertical faces.
Tested by taking several spot checks across 3 different sites with a Topcon Hiper V 915mhz base and rover setup.
That seems surprising that just nadir and GCP would be more accurate than with GCP AND obliques, especially in the Z plane. If you were just talking accuracy in the XY plane then that makes sense to me. How did you verify the accuracy and did you verify the elevation accuracy between different methods? Although for photogrammetry, it seems the altimeter accuracy of the drone would have the biggest effect on Z plane accuracy.
First, I just want to make sure we are talking about the accuracy of the ground capture and not the “accuracy” of the modeling of a structure or how “pretty” it looks… To get to your most important comment, yes the accuracy of the altimeter and constant value of the drone in flight would be the first opportunity for error to arise so in my opinion is the most important first step that you have a well-maintained and reliably functioning drone.
If you have dealt with GCP’s much you will notice that when locating them in the pictures the further you are from the point the harder it is to locate that actual center as located by the GNSS receiver. This distortion is exponentially higher when you are at an oblique angle and even further away from the GCP. You can tweak the algorithms all you want and all you are doing is introducing more error into an already error-prone process.
As for my process, I sampled the same 3 jobs with 3 different flight methods being NADIR, oblique and oblique orbital. The GCPs were elevation benchmarks on each of the sites that had been surveyed in with a robotic total station and auto-level so that the accuracies were within thousandths of a foot. I then collected the GCPs with a Topcon Hiper V base and rover setup. Here arrives the first introduction of error. The GCP network went from a localization of thousandths to hundredths. (0.003-0.005’ to 0.02-0.05’)
Once the data was received back from the missions, the point clouds were processed with Carlson Precision 3D and a triangulated surface was created. That surface was then uploaded to the Topcon FC-5000 data collector and a surface stake operation was performed sampling the same 10 checkpoints. The checkpoints were additional points collected in between the GCPs.
Results:
The two subdivision Nadir flights were done with DroneDeploy. Due to the inefficiency of using DroneDeploy’s snake pattern on linear projects Litchi was used for the Nadir. All oblique images were captured by Litchi. All image processing and GCP tagging was done with DroneDeploy. I attribute the high amount of Z error on the oblique flight for Lagos Subdivision on the type of terrain it was flying. Oblique imagery created quite allot of images with obstructions due to stockpiles and a large pond. The road project was not applicable to the orbital method.
As a last advisory, I had a colleague of mine run a Kespry mission on the Lagos Subdivision project. His average Z error was 0.28’. This was quite a bit better than the oblique flight I ran which I attribute to Kespry having algorithms that are designed for their oblique camera and the fact that they use PPK instead of GCPs. This confirms for me that we will not be paying $30k+ per year for less accurate results, more cumbersome setup and less flexible platform I think they have a good product, just not for the type of data we are consuming.
My original inquiry was regarding nadir + oblique, not nadir OR oblique.
Out of curiosity what was your GSD for these tests?
GSD depends on the project, but these were flown anywhere from 240-270ft.
The basis of my analysis was to prove which method was the best. I have run a couple of combo missions and compared, but not to this extent. In my experience obliques do nothing to improve the accuracy of Z for our use. Our use case is purely measuring ground elevation for preconstruction topographics, stockpile volumes, construction production rates, roof inspections and as-built surveys. Improving the 3D model of an above the ground structure is of no interest for us in this arena. Everything above ground in our method is derived from BIM models. If we wanted to survey a building we would use a laser scanner.