Dave Pitman
Well-Known Member
You are using the same X/Y but different Z values (approx. difference of 28)
EVO RTK Map Process with 4 GCPs and 2 CHECKPOINTS
- Thread starter jmason702
- Start date
You are using the same X/Y but different Z values (approx. difference of 28)
OH wow, Did not notice, my brain is a lil fried.... I copied and pasted yours, so we should be good
Dave Pitman
Well-Known Member
Actually, a quick look at the project location in Google Earth dictates that your elevation #s are probably closer to WGS84 than @elistechnology 's #s.
Last edited:
Dave Pitman
Well-Known Member
Looking at the exif data on a random image, MAX_424, it lists the height above MSL as 745 meters referenced to WGS84. The ground level in that image is approx. 738 meters. I think your flight height was higher than 7 meters so something is amiss with the drone's elevation #. What was your approx. flight height?
I am by no means any expert in this. I only know how to use my equipment and workflow and could be totally wrong.
The thing confusing me alot with this is:
Using a not too accurate elevation map of the area it seems the ground(orthometric height is around 740 meters.
But the elevations in the images are all around 740 meters. Shouldn't these elevations be around 740 meters + the altitude of the drone flight? Unless these elevations are height above ellipsoid. If they are height above ellipsoid, then the flight altitude should be around 90 to 100 feet?
From the GCP Excel sheet, I see there are several elevations given. Column D seems to be orthometric height in ft, column E seems to be orthometric height in meters (meters to feet conversion matches) and I think that column H is height above ellipsoid. This means that the Geoid in this area is around -30 meters since Orthometric height H = Ellipsoidal height h - Geoid n.
I will reprocess Pix4D assuming that the images have elevations based on the height above ellipsoid. And I will use the control points column H for heights above ellipsoid.
As DavePitman mentioned I will weight the Control Points and Image elevations the same as elistechnology.
Dave Pitman
Well-Known Member
I think you are correct that there is a transformation variable floating around in here that is skewing the #s. Without doing any math and just looking at the imagery, I would guess the flight height is closer to 130 feet, but that's just a WAG. Jeff will have to confirm. Perhaps the elevation corrections that were sent to the drone were not referenced to WGS84 but to the State Plane used (geoid)?
Flight height calculated by agisoft: 112ft
GCPs that @jmason702 attached to photos are exported from EMLIDs ReachView app (am i wrong?), ReachView always export points same way:
A B C D E F G H
Name, Easting, Northing , Elevation, Description, Longitude, Latitude, Ellipsoidal height, otherdatathatnotintrestsusasmuchrightnow
B, C, D - coordinates + heights set by user in project
F, G, H - WGS84 + elipsoidal heights
@jaja6009 Pix4D and mine Agisoft calculate similar and acceptable errors.
DroneDeploy missing something that Agi and Pix has.
Dave Pitman
Well-Known Member
What is the thought on this....
NTRIP is sending corrections in NAD State Plane, and the drone thinks it is receiving in WGS84. Isn't the shift now between WGS84 (Original) and NAD83 (2011) shifted a meter or two? And couldn't this shift on a curved ellipsoid be the offset he is getting in elevation? Not a large shift, but a shift. I only say this as on the Emlid forum when I was learning, I was told that the new Reachview 3 with its datum transformation support needed the datum going out to match the datum coming in. So if I wanted NAD83(2011) output, I needed NTRIP, VRS or setup on a known point to all be NAD83(2011).
Another point of concern... I think Drone Deploy when it see's his camera model, assumes that the elevations are AGL orthometric in EGM96. I will try to process in Drone Deploy tonight if I get a chance. (My school has the ridiculously priced Enterprise Version with all the bells and whistles.)
NTRIP is sending corrections in NAD State Plane, and the drone thinks it is receiving in WGS84. Isn't the shift now between WGS84 (Original) and NAD83 (2011) shifted a meter or two? And couldn't this shift on a curved ellipsoid be the offset he is getting in elevation? Not a large shift, but a shift. I only say this as on the Emlid forum when I was learning, I was told that the new Reachview 3 with its datum transformation support needed the datum going out to match the datum coming in. So if I wanted NAD83(2011) output, I needed NTRIP, VRS or setup on a known point to all be NAD83(2011).
Another point of concern... I think Drone Deploy when it see's his camera model, assumes that the elevations are AGL orthometric in EGM96. I will try to process in Drone Deploy tonight if I get a chance. (My school has the ridiculously priced Enterprise Version with all the bells and whistles.)
Dave Pitman
Well-Known Member
By the exif, the drone thought it was 7 meters AGL. What vertical datum were the NTRIP corrections referenced?
I am not 100% sure what corrections the RS2 is sending to drone now that you bring it up. nothing in reach view tell me this. I know on this data set, I just set up base first thing let it get a fix. set up my gear, turn on RTK on the drone then it got its fix and flew the mission. I did not survey a point beforehand, even if I did, I have no way to tell what corrections it is sending to the drone.
But if you go back to page 2 the map I processed with just checkpoints, has an error of over 1000 inches in elevation. so there is no way the drone is getting corrections in state plane.
Similar threads
