Linear Project Problems

@Jamespipe @Anya @Andrew_Fraser

DroneDeploy processing is having a really hard time with long linear projects. I know we have discussed this a few times, but I thought it was time to make sure the community understood and see if there is anything we can do as users to resolve some of these issues.

This project would be a really good example for analysis and play.

I started out with PPK and few GCP’s, of which I miscalculated where my surveyors layed them out and ended up with only 3 or 4 in some stretches. I think any project should be able to be localized by 4 points. Four points (and 3) in any triangulation/GPS program that I have ever used creates a constant plan that cannot rotate on X, Y or Z and if they are GCPs the resulting map should scale correctly. Note that I do not have this issue with Metashape. I really prefer not to use it, but am being forced in some of these situations.
The first 3 sections (miles) worked well and our extraction of linework for integration into our GPS survey and machine control was within 4-inches and allowed us to layout sawcuts needed very accurately. The 4th section got a little wonky, but I was able to do a little manipulation in Carlson Civil to get it good. The 5th section is now unusable.
This spurred a setting of more GCPs at midpoints of the initial GCP’s which now gives me 6-8 per mile. Still using PPK the images and checkpoints in QGIS look very close, but when the map was reprocessed using the additional GCPs there is still something wrong. Comparative measurements are not working out and my previous manipulations are not working. They are on mile 3 so I need to keep this rolling so I can keep in front of them.
Through working with online support I was told that GCP proximity to the edge of images is an issue. This needs to be resolved. I am flying both sides of the ROW, am getting around 8-10 matches of each point and the GCPs are directly in the centerline of the road so maybe the tolerance settings are a little tight?
Also I have been told that DD uses a boxed area (as you would see when manually uploading images) which has to be accounting for an enormous amount of uneeded area on this particular project. Ten miles of winding and undulating roadway is a very large area when boxed.
Last but not least, linear flight is so close and we have done allot of work getting it where it is, but it still does not function efficiently which is one reason why I am using the Yuneec and not the DD flight app. We have to be able to establish manual waypoints starting at a mid-point of the stretch of corridor and wrap around to end at the same point. This saves a ton of battery, but also is much more safe because it is much easier to maintain VLOS.
We will get there, but I assume that many contractors, inspectors and municipalities could greatly benefit from tightening this process up. Thanks for all of your hard work!

I have inserted the reprocessing of Section (mile) 5 and adding GCPs made it worse! I am at a loss at this point. I am going to process without GCPs at all and see what I get. Shifted about 4ft to the south. The tie-ins are very close on the ends of the stretch which tells me that there was something up in processing with using the intermediate GCPs.

Oh, and here is the calc area vs the mission.

Here is an example of a quick reduction I do when manually uploading. Should be much less calc area.

I exported the Non-GCP map, imported it into Carlson Civil and it is better than the other two GCP maps. Ugh! :angry: Note the precision of the alignment. The red sawcut is exactly where it should be and the drive matches perfectly! This is just fine if it is consistent, but what the heck do I do if I need grade? PPK alone is not going to be close enough…