@JamesC I think that you may have found the same bug that I have already raised with the contour export for maps exported using EPSG 27700. It seems that the elevation values are not translated from WGS84 correctly, meaning that they are significantly out.
Strangely, this conversion issue doesn’t impact on the point cloud - so to work around this, I have exported the point cloud to Cloud Compare, then used this to produce the contours.
Hi @JamesC!
The issue I have noticed with the offset is due to the ellipsoid model being used. Because 27700 references OSBG36 rather than GRS80 there is an offset throughout the map. We are working on a feature that will allow you to scale the z values within the finished map which will help to correct this issue. Sadly, I don’t have a firm ETA on the feature. For now, I would go with the workaround that @dronesondemand mentioned in his previous post. Please let me know if I can help with anything else moving forward.
Best,
Zach
What are the front and side overlaps of your missions? I am getting noticeably better maps with 90% front overlap and 80% side overlaps on my P4P drone. Previously I was using 80%/80% overlaps but I am finding that 90% front overlaps results in much more even spacing of the photos and thus better map results. So my layest suggestion is to fly a mission at no lower than 250’ over the highest feature with 90% front overlap and 80-85% side overlap even if it is sunny but still with low winds (< 2.2 meter per sec).
Regards,
Terry.
Terry, I’m at 75% Sidelap and 85% Frontlap.
Predominantly my requirement is a high res aerial image that’s in proportion with itself and to scale, hence flying at such a low altitude. However, I’m regularly going to need elevational data also so it could be I end up having to do two missions to give me the best of both worlds. One at low level and another at a higher, quicker rate. The higher the drone the wider it’s field of vision and the faster it flies at, reducing the amount of ‘sag’ along the way.
@dronesondemand , I’m going to need to look into that. Thank you. The alternative I guess is to grab the entire export in ACAD and move it’s objects by the set amount required to offset the GCPs at their right value, pulling the rest of the export with it.
Thank you all. Unfortunately given the 60mph winds we’ve experienced over the past few days I’ve not been permitted to get out to play so will just have to see how it goes. My trial expires soon, again. 
Again due to rubbish weather here in the UK, it’s taken until last week to get back out with the drone to experiment a bit more. What I noticed over the weekend in the DD software is an option to now ‘Calibrate’ the processed map with a z-value, which I think is what @zach1 mentioned back on the 17th January.
Bearing in mind I didn’t carry out this new mission with GCPs, I do have have dozens of z-values dotted about the site. I’ve given one position its actual value and the map has calibrated. Great! Is there now a way however to now add further values to the already processed model? The ‘Location’ measurement tool of course now gives the same level reading as that inputted by me to calibrate one particular point, but due to the gradual fall in height the drone suffers over a large area coupled with a bowling effect, is there a way for me to insert another dozen z-values, including roads and flat roofed buildings to help iron out the map?
Hi @JamesC,
Currently, we use the one input from the Elevation Calibration to generate the rest of the elevation values throughout the map. If you would like to include more Z values within the map I would recommend using GCPs. Please let us know if we can help with anything else.
That’s annoying, although I’m grateful for the response. I haven’t always got the ability to lay target markers out and nor do I always have detailed survey infoprior to carrying out the mission.
The main purpose of carrying out a mission would be to save spending several thousands on a detailed survey until such time we are properly committed to its purchase. As you know, I have had problems the whole way through with either focusing problems, inaccurate z-values or bowling effect. It’s been infuriating.
I would rather pay a bit more to add known z values manually, to correct an inaccurately processed map than be forced to upgrade from Pro to Business to then pay an additional $49 per map in an attempt to correct it. Some of the results have been disastrous, even when using GCPs. Surely it makes sense to allow us the best opportunity of producing the most accurate map possible by granting us the opportunity to correct the inaccuracies and therefore I encourage DD to release this functionality.
I thought all of my prayers had been answered when I spotted the option to calibrate, but it seems not.
Making sure to take of from an average elevation as close to the center of the project helps, but if you are wanting to replace surveying you should be using GCPs.
Alternatively, you can create GCPs without doing any surveying or hiring it out. You don’t even need real elevations, just relative ones and if there are any objects visible on or around the site there are several options to get good enough coordinates to improve your results. Run an auto-level loop to get the elevations.
Can we get a link to the disastrous GCP map?
Thanks for your input. If you go back to my entries above on 10th January, you’ll see the mission flown first without GCPs and a second with. The first suffered a severe bowling effect rendering the map useless, but even with the GCPs, whereas the location of the values of the GCP positions were near as damn it perfect after the process, the roof heights of the immediately adjacent flat roofs and horizontal ridges were up to 1.7m out. All of the locations shown on the map are on the ground and are relatively accurate. The four up on the roof of the buildings are not. With or without the GCPs, it therefore makes sense to be able to correct the inaccuracies of the processed image.
In terms of the mission vs survey, the purpose of the mission is to give us a very rough idea what we are looking to buy. Does the site fall 2m across it, 10m or 20m? What are the X x Y dimensions? Once we are committed to purchasing the site we will of course spend £kkk’s on a detailed survey. The drone was never intended to be seen as a replacement.
Hi @JamesC,
Because GCPs aren’t being used you can expect an inaccuracy of around 1-3 X your GSD within the map. I would recommend a compass calibration before each mission to mitigate any inaccuracy from the drones GPS system. You could also carry out an IMU calibration before the mission. As @MichaelL mentioned previously, to get absolute accuracy you would need to incorporate GCPs.
Zach, please look back at my posts dated 10th January as mentioned above. You will two maps. One without GCPs, the other with. As explained, despite using GCPs on the second process of the same mission, it imagined buildings being up to 1.7m taller than they were, despite being immediately between 2 or 3 GCPs. It imagined flat roofs with huge gradients across them. There’s just no explanation of these inconsistencies.
The drones are regularly calibrated so have no alternative but to think it is a failure of the software. Like I said, I get terrible results without GCPs and mediocre results with but not always being able to use GCPs, it would help massively if I were able to correct the software’s failure by manually giving it nudge in the right direction. Is there any reason why additional areas of calibration could not be implemented? Surely it can only help improve the results, in the same way as GCPs.
So are you on Pro or Business? I tried to review the posts. The last one said you didn’t want to upgrade, but you have to have business for GCP’s right?
Currently on a Business trial desperately trying to make it work for us. I don’t particularly want to purchase Business over Pro if I can’t get it to work effectively. I certainly can’t upgrade to Business to enter the odd couple of known levels manually to correct a map but then have to pay a further $49 for the benefit on to of the higher subscription cost. That said, unless I use GCPs I get the bowling effect which doesn’t just throw the z values out by a smidge as Zach suggests, they go tens of metres out. If i can correct/calibrate a small number of values, the map will flatten out to something that resembles what’s actually on the ground
It’s a real shame. The concept of the software is great, only in order to implement the various workarounds, it seems I first have to migrate to iOS to help with the focusing issues and pay 3x the price to manually input a couple of figures, and that’s in addition to the $49 per mission. I don’t think I’m asking too much of it. I thought we were doing was relatively simple in the grand scheme of what I understood DD could do.
It’s infuriating. Each time I’m on a trial, either we’re hampered by weather and it runs out prematurely (like now) or something else software related goes wrong. Trial expires tomorrow I think. Out experimenting again tomorrow but won’t have time to process the maps and export to evaluate the results before the clock stops again.
Not sure what we’re going to end up doing. I like the concept, I love the interface, the options available…it’s just that technically it doesn’t work and when something doesn’t work as it should at a basic level, I have trouble spending vast more sums of money to help it work when even that’s a workaround and not performing as it should.
The level of support the staff have given is second to none, but I do feel more could be done on the developing/corporate side to help us help the software achieve the results it should be achieving.
Hi @JamesC,
Can you clarify where you are placing the GCPs? I would also suggest taking a look at our GCP Checkpoints support doc to see how you can verify the accuracy of your current GCPs.
Cheers,
Christina
Thanks Christina.
The image below is that of an elevation using GCPs. All but the four markers up on the red roofs are survey pegs, -mapped, measured and processed as GCPs. Their xyz are accurate. The markers’ levels within the processed map are more or less spot on and demonstrates that the software used the values I entered through the excel file.
What I can’t for the life of me understand however is how it’s managed to record the heighrlts of the adjacent buildings being up to 1.7m different to what they actually are. It makes no sense at all. What levels are outside the GCP zone I can completely accept their values might revert back to a non-GCP map, but not inside the zone and is why it would greatly assist to be able to correct other known z values of a processed map (or possibly prior to). I can’t be expected to climb up on top of a pitched roof to sit a target map down every time I want to fly. That said, I’d like to be told what I’m doing to cause such a discrepancy. I’d rather not be correcting anything.
I’m aware that I’m beginning to sound like a broken record, but I simply cannot understand how the vertical measurement of four buildings, not one, not two, can be so far out when sited immediately next to GCPs.
Again, I really appreciate the support within the forum and other staff that have emailed me.
So, to get some clarification… The building to the southwest is the subject and your “adjacent” building is to the northeast of that? And it’s 1.7m off? Can you share a link to the GCP and non-GCP maps?
I’m unable to provide direct access to the map due to its location (albeit Mods and Admin have it) but I’ve put together a table to calculate the discrepancies. Note that the table was produced before DD allowed us to calibrate the map and hence the need to subtract one datum from the another. Column H is basically the difference between the GCP and what DD recorded and you can see that the differences between them is a consistent 46.8 - 46.9m, giving an accuracy of between 0.001m - 0.136m. Perfect, but so it should be because I’ve given the values of them. Without the GCPs however, the measurements are something like 15m adrift due to the bowling effect. The GCPs are responsible for flattening the image out to true, although I’ve been taking a ton of oblique photos on subsequent maps (without the horizon) to help avoid the bowling effect when not using GCPs. I has definitely helped to some degree.
But when you then move down to known heights of adjacent buildings on the table, they’re out by 1.265m and 1.705m. Could I expect the double pitched roof to be out so far (1.7m)? Possibly, due to it being outside the GCP zone, but not the 1.2m. The flat roof is right next to a GCP and within the GCP zone.
It is definitely outside the GCP network and on the edge of the map so I think that explains it partially, but I would expect a little better. This grade of GPS is 1-3m (closer to 1), but the sheer fact that you have GCP’s should help…
BEaWARE of the well-known systematic SfM doming (elevation) error which typically occurs as the SfM workflow accumulates lens calibration error when processing image blocks acquired using traditional (linear/parallel) flight lines. This doming error can be mitigated (at least to a certain extent) when curved, convergent flight paths are used. Google “Gently Curved, Convergent, Non-traditional Drone Flight Paths”. The justification for using curved flight paths can be found in the following research:
Minimising systematic error surfaces in digital elevation models using oblique convergent imagery
First published: 16 March 2011
https://doi.org/10.1111/j.1477-9730.2011.00623.x
Results of the simulation process, the laboratory test and the practical test are reported in this paper and demonstrate that an oblique convergent image configuration eradicates the systematic error surfaces which result from inaccurate lens distortion parameters. This approach is significant because by removing the need for an accurate lens model it effectively improves the accuracies of digital surface representations derived using consumer‐grade digital cameras. Carefully selected image configurations could therefore provide new opportunities for improving the quality of photogrammetrically acquired data.
I hope this helps.
Jim Dow