I have been having constant issues with the processing report showing that checkpoints are good but when I check the data in Civil 3D there can be a 1’-5’ shift horizontally. The maps are not holding the horizontal values of the GCP’s and then are saying that the checkpoints are correct in the processing report.
I have escalated several of these cases and the team keeps making changes but it seems that every change they make things only get worse…
Any updates on this. I have started seeing some weird numbers with the H520E RTK imagery now. If I process the map without any ground control my camera GPS location RMSE’s are right around 1ft XY and 0.4ft Z but when I introduce GCP’s the number as all over the place and more up around the 1m range across the board with the vertical being slightly less for the most part.
My rationality for this is that our drone and running on the same RTKNET via NTRIP which broadcasts NAD83(2011) coordinates. The rover has data collector software which use NAD83 natively and projects it to our local State Plane Coordinate System which the values in the GCP file are based on. The drone on the other hand works in WGS84 but I don’t know exactly how it negotiates the NAD83 corrections. WGS84 and NAD83 are very close in some areas and not so in others spread across the United States but we have to keep in mind that not only are there difference in the horizontal reference frame but they use different ellipsoids as well. WGS84 has its own and NAD83(2011) uses the GRS80(2010.00) ellipsoid. Factor on top of that which GEOID you are using and there is the additional split in vertical. Because we are localized to the site benchmarks our checkpoints come out fine in DroneDeploy but the data always has to be given a final alignment in CAD.
Is this common to anything you are seeing?
The support team has been working on one of my maps for several days now. It was not holding GCP horizontal values. It looks like yesterday they may have figured something out but I am still waiting to hear back. Also giving DJI Terra a try for local processing.
Thanks Sam - sounds like a projection /export issue on the surface, but I will await the support team’s verdict. What’s the URL of the project? (I don’t need the public link)
Support email from today:
We recently upgraded our geodetic projection system to use datum shift grids. Where available, these provide the most accurate datum transformations. While they worked great for GCP tagging, photogrammetry, and visualization in the DroneDeploy web app, they failed to work as expected for exports in some coordinate systems, leading to the observed misalignment.
We are rolling back the usage of these datum shift grids until we can be sure that they are consistently applied across all parts of the DroneDeploy platform.
Also I always check my CRS and assign it in every DWG. I have mapcsassign on a hot key 
I have been able to confirm that with RTK on NTRIP the the fact the network RTK service is sending NAD83 corrections and between the drone and DroneDeploy is WGS84 that it is causing a shift. The GPS relocation RMSE on the accuracy report mirrors this. The RMSE’s of the GCP tagging and the checkpoint reporting is then deemed as good. The issue then arises in CAD because the information when exported is transformed (more technically shifted) from WGS84 to State Plane by DroneDeploy and there is then a shift required in CAD to align. This does not cause a problem in our workflow as we always verify alignment in CAD with the localized site control so using drone data straight off the NTRIP is fine. We chose to leave our drone data native so that we can work in GIS and real world coordinates but a shift in CAD is normally required when dealing with construction projects. Users should be aware of this and also know that the difference between NAD83 and WGS84 is not consistent across CONUS where some areas will be couple of meters separated and others like the east coast will be very close but they are still not the same so you should always verify your data to maintain cm-level accuracy. I am assuming the same happens with the P4RTK when NAD83 sourced corrections are used. Particularly with GCP’s are also acquire with a rover running the same NTRIP. This is something DroneDeploy is going to have to consider in their transformations. @Sam_De_Long @Jamespipe
Dude I have no idea what is going on. I ran into the same thing on a map from Friday. The worst part is that just the ortho is shifted. The DXF and Point Cloud does not have the shift the ortho does. I might just have to start bringing an emlid and setting it up for corrections on a localized site to the P4RTK.
How are you bringing the point cloud into CAD? You are not going to be able to see these shifts very easily at all in contour maps without points of reference.
Point cloud I’m working with in AgTek. Trust me it was pretty easy to see the shift in contours when a water truck is 2 ft to the west of where its contours are.
I thought the point cloud and DXF weren’t off?
My apologies. The point cloud and contours are in the correct position. The ortho is off. See attached snips.
Look at how the Eco block contours are displayed.
The actual point and the GCP target.
After I shift the ortho
Contours fit the blocks better.
See that’s what I am saying. It is so hard to tell unless you know exactly what is going on. It sort of looks like the contours are a little northwest but when you put them in their correct place it becomes obvious. 1ft contours is really hard to gauge.
