Distances aren't reading correct in Orthomosaic?

[Ssrojas1]

Hello, 

I'm processing my orthomosaic and the distance within my images isn't correct. Flight had 80% overlap for front and sides. 

Say I have the distance between 2 GCPs as ~72.6m, but my ortho is measuring ~444.5m  in Drone2Map. Also, some distances within the image can be correct but then next to it, can be ~100m off. Can anyone offer any reasons this would be happening? It happens whether I import GCPs or not.

 

Also, when I process the ortho alone, the report Preview looks fine, but once I process the DSM and DTM, the figure gets this strange artifact to the left of the image. I've clipped the processing to the extent of 5+ images in the overlap figure.  

 

 I really appreciate any information anyone can provide. 

 

[Anonymous User]

I'm curious how you're handling your coordinate information. I've never seen a software suite that does a really good job of handling datum transformations in an explicit, unambiguous, and self-documenting way. This is especially true when working across multiple software suites.

Here are the questions I would nail down before my data goes into Drone2Map.

Where do the image geotag coordinates come from?

Where do the GCP coordinates come from?

Are these coordinates in the same datum/realization/epoch? (also, when do datum transformations occur in your processing workflow?)

What is the expected accuracy of both sets of coordinates?

Does Drone2Map interpret the coordinates in their true coordinate system?

There's a lot of hidden error that goes into a project if these things are unknown. Perhaps one of them is causing your problem.

Happy to talk through this - as I'd like to understand others' success with Drone2Map.

[ssrojas]

I'd really appreciate talking this through with someone. 

Where do the image geotag coordinates come from?

From what I've read online EXIF metadata. I'm using a DJI Drone, so I also know that the altitude needs to be adjusted in Drone2Map. I've also been experimenting with this, as I input 197ft as my flight altitude, and my altitude from Image Table goes from ~22 to ~60m. Which I feel makes sense, my only question is: Online I've read the "height is in reference to the ellipsoid" because of GPS and "height is relative to the ground" meaning where you took off was considered "0 elevation". So if anyone has a better/clearer explanation for this, I would appreciate it! 

Where do the GCP coordinates come from?

We used two Trimble R9 base stations. I processed them through CSRS-PPP, and I'm actually struggling with this part. The older version of Drone2Map had a "Ellipsoid" and "Height above ellipsoid" option, but with the June updated and Advanced License that is no longer options. After processing these surveys I want to compare them to past DEMs, so I'd like to build them in Ellipsoidal and later convert them to any geoid. But now, I need to find a way to use NAD1983 UTM Zone 15N and the Ellipsoidal Height. 

If I choose NAD 1983 UTM Zone 15N, Drone2Map wont let me choose any Ellipsoidal-based vertical Coordinate System besides NAD 1983.

[Anonymous User]

For simplicity, this is a USA centric comment.

Your drone GPS records its horizontal position in WGS84 and vertical position as "height" above the WGS84 ellipsoid.

Your drone also uses a combination of sensors (I am not familiar with DJI) to determine its AGL for flight control purposes. This takeoff elevation should not be used for geospatial work, especially if there are significant changes in terrain relief in your flight area. I hope someone with a differing opinion/more knowledge could chime in on this point.

At some point in your workflow you will likely want to convert the ellipsoidal elevation to orthometric elevation. Orthometric elevation is what most people think of as "above mean sea level". The correct way to do this is more involved, but the important bit is that you are comparing apples to apples with your coordinate reference systems. 

[Anonymous User]

so I'd like to build them in Ellipsoidal and later convert them to any geoid.

This is how I do things also. So the key is to make sure that your GCPs and photo tagging are in the same coordinate reference system. The drone native GPS is WGS84/height above ellipsoid. You'll need to verify the coordinate system output by your GPS correction software.

If I choose NAD 1983 UTM Zone 15N, Drone2Map wont let me choose any Ellipsoidal-based vertical Coordinate System besides NAD 1983.

This makes sense... D2M is forcing you to use NAVD here?

[JerryBartz · Accepted solution]

Very good thoughts.

We have learned quite a bit about GCP's and making a high resolution basemap. The result was evaluated by comparing with a commerical basemap with an accuracy of 3 feet.

Our first lesson was unless you have a good density of control, spatial distortion can be present at the control point; even if you use 4 pix per control point.

Next, the further the distance from a control point, the more inaccurate orthomosaic. Our campus is approximately 190 acres. We flew an 80% overlap, crisscrossing survey with about 8 control points.  Control point data, including  Z values, were input using a table. The Ground Control point coordinates, WGS 1984, were collected, with a Trimble geoxplorer 6000 and the data post processed to an accuracy of between 15-50 cm. Later comparison with 3 foot commerical data, confirmed that the GCP'sData at the control points were later confirmed to be within 3 feet. As we moved from the control points to the edges of the D2M orthomosaic, ground errors of approximately 21 feet were observed. We continued to improve accuracy of the orthosmosaic. Trimble readings were use to confirm and improve the accuracy of the 3 foot commercial data. The coordinates at the edges of the boundary were confirmed and the orthomosaic adjusted. Still in the interior we can have some unadjusted areas with 6 to as much as 12 feet of error.

This was early D2M. Rubber sheeting of the orthomosaic does not correct all of the interior.

[ssrojas]

Thank you for this! Very Helpful and actually sounds very similar to my issue. My edges throughout all surveys seemed distorted, and I believe since some surveys were very narrow long stretches, there could be more distortion "throughout" my orthos. 

You said: "The Ground Control point coordinates, WGS 1984, were collected, with a Trimble geoxplorer 6000 and the data post processed to an accuracy of between 15-50 cm." and "Later comparison with 3 foot commerical data, confirmed that the GCP'sData at the control points were later confirmed to be within 3 feet."

Can I ask how you determined the accuracy of each of these? 

Also, you said: "The coordinates at the edges of the boundary were confirmed and the orthomosaic adjusted." or "rubber sheeting" is this georeferencing? 

[JerryBartz]

Accuracy is an interesting topic. The accuracy of various Esri basemaps may vary slightly in your area. They do in mine, the greater Dallas Fort Worth Texas area. A commercial basemap is based on survey points. They have good internal accuracy. You can find a permanent photo visible object. You can determine its coordinates with ArcPRO. You compare that map value with the value you can determine with a device such a Trimble Explorer. Then you compare your D2M orthomosaic with your commercial base map.

Yes, rubber sheeting is georeferencing your orthomosaic to the commercial basemap.  I have about 50 various control points in the 190 acres. Still I can find an area that does not agree with the commercial base map by more than 3 feet. 

But I have never had errors as large as those you cited.

Very interested to see how you resolve the problem. We all learn from one another.

[Anonymous User]

Thank you for sharing your experiences with this. From what I've seen there are very few solid perspectives of "putting it all together" in one place online.

For ground control point and ground check point density planning I recommend the NSSDA standard here. NSSDA is a US federal standard for geospatial accuracy testing and reporting. That document has a good description on GCP density.

If you're using a geo6000, you're likely using GPS Pathfinder Office for differential correction. Trimble's documentation for this software is not great. It's very unclear what datum/realization/epoch is used for the corrected output points. Sure, the datum/realization/epoch of the correction source (CORS, etc) is used. But there's ambiguity when multiple coordinate frames are present in the published data. For example, you can configure the receiver to WGS84 (no datum shift), but Pathfinder Office outputs NAD83(2011) due to the base station reference frame. Now, your coordinates have an invisible ~1.5m shift.

[JerryBartz]

The problem may be that you tagged control points with incorrect photos.

D2M can give you approximately 10 photos per  control point, if you are using crossing traverses of study area, by that I mean one traverse roughly NS and another traverse at approximately 90 degrees to the original traverse. The double traverse usually results in multiple photos for a  control points.

How many photos did you tag to a single control points? I generally use one each from the north, south, east and west of the control point.