One of the main reasons for purchasing the M2 was so I could do away with ground control targets. A small portion of the scans we do don’t allow access to lay targets down with an even distribution. So instead I’d prefer to lay checkpoints where possible and not introduce errors from poorly placed gcp’s lol. But following the Emlid docs on Pix4d mapping, I’m seeing a shift for a few centimeters in both Northing and Easting. I’m pretty sure I know why though. My base known point is NAD83 csrs geographic form nad83 csrs UTM zone 10. Ellipsoid elevation is entered for the base, 0 ellipsoid elevation for the images (and WGS84 which is technically wrong), and the geoid’s height above ellipsoid for Pix’s vertical output. Pix4d suggests when not using gcp’s, to use the appropriate geoid model and apply the heights to the images before import. So a better work flow would be maybe:
Convert images from wgs84 geographic to nad83 goegraphic or convert to base from nad to wgs and leave image in wgs84
Convert ellpisoid heigth to CGVD2013
import checkpoints in nad83 csrs and the same for output.
Next question is what software to do the batch conversion. I know Geocalc will work, but it’s a pretty expensive add-on to Global Mapper. There’s NRCAN’s GPS-H software that’s free, but it only converts between CGVD2013 and HT2/CGVD28. Seems to have a radio button for ITRF. I believe ITRF2008 (can’t remember the epoch) aligns with WGS84.
Convert images from wgs84 geographic to nad83 goegraphic or convert to base from nad to wgs and leave image in wgs84
If you enter the known base position in NAD83 in Emlid Studio, the image centers are in NAD83 too. So, additional conversion is not needed. You can just choose NAD83 as a coordinate system for this data in Pix4D. Looks like the difference between the datums caused the shift.
If it doesn’t solve the issue, please tell me more about your workflow and goals:
Which coordinate system and vertical datum do you use at each step of your work? In which of them do you want to obtain results?
Do I get it right that you use checkpoints to check the result’s accuracy? Is the shift equal for all the points?
So if I enter a NAD83 base location, my M2 is actually recoding events in WGS84 with an applied NAD83 shift? Would I be better off converting my NAD83 know point to WGS84?
That it one way to put it, yes. But it really isn’t a shift between 2 systems, but a localization to NAD83. So if you use the base for both your checkpoints and PPK for the drone, they are aligned. Any discrepancy between them would then be down to lever action faults between antenna phase center and camera on the drone, or wrongly entered height for the rover-rod, or incorrect leveling of the rod.
So if I enter a NAD83 base location, my M2 is actually recoding events in WGS84 with an applied NAD83 shift?
Reach M2 just records precise time marks showing when the photos were taken. When you post-process this data, the datum of the calculated coordinates depends on the base’s one. If the base is in NAD83, you’ll see the rover’s positions in NAD83.
Would I be better off converting my NAD83 know point to WGS84?
As Christian pointed out, if you set a base in NAD83 for both checkpoint collection and PPK processing, everything will be aligned. So, there’s no need to transform the base coordinates to WGS84 unless you want the results to be in WGS84.
Ok, one more stupid question. Being this isn’t a project where I can select the coordinate system, how does Emlid Suite know the base was NAD83? I’m simply recording raw UBX logs for both the base and rover. I think my OCD is making me crazy lol!
It doesn’t, and don’t need to know either. When you are finished processing in Emlid Studio you have your coordinates in NAD83 in DMS/Deg, and they can then be converted to another coordinate system representation afterwards.
Emlid Studio indeed has no idea about the base’s datum It actually happens this way:
You enter precise base coordinates in the software. They are already in some datum.
Emlid Studio uses these coordinates during the rover’s position calculation. So, the position becomes aligned with the base’s datum even though the software doesn’t know the datum itself.
It actually happens this way: