Hello, I am using a Reach RS2+ as a base station for a DJI M300 RTK drone for conducting land surveys. I am getting NTRIP corrections through can-net to the base station to get an accurate base location and then using the local NTRIP to send corrections to the drone. The base station uses the average FIX method to get it’s location and height. I am running into issues though with wanting different elevation datums. The RS2+ and M300 RTK heights are ellipsoidal but as I am mapping a coastline, it is giving me an elevation of around -10m. The M300 RTK also collects GPS points in WGS84 and Ellipsoidal but also has the EGM96 Geoid model built in. After flying the mission at 120m AGL, the image properties show the elevations of each photos to be around 110m (120m above the -10m).
If I create a project and use the NAD83 / BC Albers Coordinate system and the CGVD2013 (CGG2013a) vertical datum I get Local height of 4.141m and a global height of -10.929m. If I use this point to manually set my base station, it defaults to the -10.929m. Is there a way to set the base station to the local coordinate system in order for the drone data to have accurate local height data? Or would that create errors between the base station being in local and the drone being in Ellipsoidal height. Seems like a big source of error if all Drone RTK flights are in ellipsoidal but other ground surveyors are using local elevation models.
I process the data in Pix4Dmapper and could manually provide a geoid offset in the image setting but that seems a little janky. The current DSM shows elevations in the negative values which is a big red flag when giving the data to clients.
I agree with Michael. Drones usually use geographic coordinates for navigation. The standard of the EXIF file, which contains the metadata of the photos, also requires geographic coordinates: latitude, longitude, and ellipsoidal height. That’s why projections and vertical datums are usually applied in photogrammetric software.
As I see on the Pix4D website, they support the CGVD2013 (CGG2013a) geoid. So I think it should work well for you.
I also wanted to add a note about the coordinate systems. Since you get the corrections from the Can_Net service, I assume they are in NAD83(CSRS)? If so, your base and, therefore, your drone’s coordinates are also in NAD83(CSRS), not WGS84.
Thanks for the info. I think I have figured it out but may have to ask Pix4D some questions. Pix4Dmatic has the CGVD2013 built in but Pix4Dmapper does not. I have to input the geoid adjustment manually.
Can-Net can send the corrections in both WGS84 and NAD83. Drone still attaches WGS84 / UTM 10N (my area) coordinates according to Pix4D.
My bad, I haven’t noticed that it’s for PIX4Dmatic, not Pix4Dmapper. Anyway, I’m glad to hear that you’ve found a solution.
I see. Still, the software can’t automatically detect the datum of the coordinates. I think it’s possible only if the name of the coordinate system is also transmitted somehow. But usually, the drone/processing software just applies a projection to the geographic data it receives (without datum transformations).
So if you have corrections in NAD83, you get NAD83/UTM 10 N. And if the corrections are in WGS84, the results are in WGS84 / UTM 10N.
