I am hoping someone here on this forum can help me understand what is going on here. I have been testing and working with the Mavic 3E for weeks and I am getting conflicting information on what CS the drone is outputting. I am using Trimble’s VRS NOW NTRIP network for corrections and from what I understand they broadcast their corrections in NAD83(2011) (or at least that is what their network is setup on). So, if I am using the Mavic 3E connected to their RTK network does that mean that all of my images are in NAD83(2011) or does the drone do some sort of transformation into WGS84? I have tried a variety of options when importing into Metashape for processing and I cant seem to get a good result when checking against my checkpoints shot with the RS2+. I have used the RS2+ in a base/rover mode to survey in my checkpoints. I first setup the base and connect it to the NTRIP network. Next, I open up a survey in my local coordinate system (NAD83(2011) Ga West EPSG:2240/ Geoid 12b) and survey a point for 3 min. Next, I go into my base settings and select this point from an existing survey and use it as my base coordinates. It shows up in a global CS (LLH). Is this in NAD83(2011) or does Emlid consider their “Global CS” to be WGS84? From there, I turn off the input corrections and turn on correction output to lora radio and connect my rover. I shoot all my GCP’s in GaWest State Planes coordinate system. I bring my cameras into Metashape and convert them to the appropriate state planes coordinate system to match my survey done in Emlid Flow. I align cameras and then import my GCPs and place my markers. The result is all over the place in terms of vertical error (0.1’-0.5’). Am I importing my cameras in the wrong CS. Please help!
Yes, you will be receiving NAD83 corrections but that doesn’t matter to the drone. It is all still line and distance from the base station. The base shows up as LLH because that is what it uses to talk back and forth between the rover (drone) and the satellites. By acquiring the point using a grid coordinate system simply gives you a “mask” over the geographic point that can be used in transformation and other workflows. Your workflow seems correct but I would verify the Geoid being used. At least in my area I am seeing more Geoid18 than 12b.
Thank you Michael. So my drone images should be considered WGS84 when inputting into any photogrammetry software? I was under the impression that they would now be NAD83(2011) since my “base” (VRS network) is in NAD83(2011).
That’s correct. As long as your NAD83 State Plane base point and GCP’s/checkpoints are relative to the site coordinate system the geographic coordinate is background reference data and WGS84 is really for the ellipsoid height.
In my experience this only caused issues when I was trying to export and utilize the drone data in systems that only dealt with WGS84 and had no way to transform, like loading an ortho into Google Earth. The same for GIS. It doesn’t always drop straight in but they have the tools to transform.
I do similar in CAD. I really don’t like some of the things I have seen GCP’s do to my relative accuracy of the drone RTK values so I don’t use them. I do a localization in CAD and rectify to the Surveyor’s information. This helps two-fold because I never know if their datum is grid or Surface and unless you use a custom coordinate system in photogrammetry you can’t drop drone (geospatial) data right into a surface coordinates drawing. It also gives me the opportunity to make a final adjustment vertically to prorate any leftover hundredths of error across the site.
Another problem I have seen is when you acquire geographic (LLH) coordinates from a contractor that did an immediate initialization coordinate localization (basically 5-second single average) that the coordinates can be so far from officially recognized reality that you can’t even tag them. Here again you need the ability to use a custom coordinate system or GNSS localization/site calibration file for photogrammetry.
Michael,
Thank you for that. I just dont see how my “base” (VRS network) could be in NAD83(2011) and my “rover” (Mavic3E) could have image coordinates in anything other than NAD83(2011). Arent the RTK corrections sent to the drone via RTCM3 messages? Typically, the RTCM3 messages contain datum information.
That’s correct, they will technically be NAD83 coordinates despite the geotag saying WGS84 because that is how the system is setup. It may be different elsewhere like Louisiana and California but when I do WGS84 to NAD83 transformations I get the same coordinates all the way down to the 1/1000th of a foot. If there is a difference I probably just don’t know it because of my CAD localizations.
I bet @EBE111057 can shed some more sufficient light. 
Very interesting. So when inputting the images into Metashape, they should be defined as NAD83(2011) since they are receiving corrections from a VRS NTRIP network? They can then be transformed to GaWest state planes to match the GCPs? Thank you for your help.
All CORS are based on ITRF201 datum (WGS84). When I first used my EVO for flying a test site (14ac cutover) I was using the states RTN-no base receiver running on the site. I used my phones hotspot to connect to the RTN with the EVO. I was so excited using my EVO with the states RTN I didn’t think of using a base while flying. All coords in the cameras images are ITRF014 using the ellipsoid heights. That’s what is broadcasted from the RTN.
When I observed the locations of the GCP’s (painted orange circles with a pk nail and cap on stumps), I used the SC State Plane Coordinate System NAD83(2011) Epoch 2010.000. I located the GCP’s before I flew the site. I didn’t realize the UAV would be collecting data in the ITRF2014 datum from the RTN. No problem, I just exported all the GCP’s to the ITRF2014 datum.
I processed all the imagery with the help of Dave Pitman’s advice in Metashape. The UAV data as well as the GCP’s had ellipsoid heights. By the way, I think Metashape is the best software available, pretty cool software.
After processing the imagery, I just created a coordinate system using Metashapes’s (SC3900)coordinate datums/projections with Geoid18 model and exported the DEM and orthophoto. I imported the data into Global Mapper and overlaid the field data onto the states’s 2008 LIDAR surface. It fit within 0.5’, I thought that was pretty cool !
I’ve got to get used to Metashapes’s camera calibration method to really nail down the flown data and imagery. I did finally get a surface that matched the LIDAR within 0.3’. I think that is pretty reasonable accuracy for my first flown site.
All CORS broadcast their data in the ITRF2014 datum. Your controller software converts to the projection you select.
@EBE111057 What corrections provider are you using? It seems like it differs by provider. All CORS stations may broadcast in ITRF2014 but if you are using a VRS network their caster may compute a different reference frame and use that as their source. From all my “research” it appears that Leica and Trimble use a NAD83(2011) reference frame. Thus, the photos tagged with RTK data from the connected VRS provider would have to adopt that reference frame? There has to be something I am missing here with the concept of “rover will have to adopt the base’s reference frame”.
My RTN network is the SC Geodetic Survey, I’ve verified that their broadcast is in ITRF2014 (WGS84). I know that the NGS CORS broadcast in the same datum. Your software in your controller simply re-projects to the projection datum you select, same as with our controllers (Javad). The EVO II receives only the broadcast (ITRF2014) as it has no conversion software so that pretty much confirms what was explained to me by the SCGS personnel.
Leica/Trimble commercial networks may very well broadcast in NAD83(2011) but I find that’s highly unlikely as some of their CORS are part of NGS’s network . Our states RTN have all Trimble Alloy receivers at their stations but that doesn’t really determine what datum is broadcast.
The only way for you to confirm is what I did for my 14ac project. Simply collect the imagery data with the located GCP’s with the projection you normally use for your state and convert the GCP’s to ITRF2014. Or you could collect the GCP’s in the ITRF2014 datum and then compare during processing.
The problem (which is pretty much standard and not really a problem) is that all imagery/GNSS software starts with the ITRF2014 (WGS84) datum from my experience. The state’s projections that are used are re-projected using a 7 parameter Helmert transformation. Emlid’s receivers do the same thing as well as our Javad equipment, you select the projection needed and it’s in your coordinate system.
If your UAV collects the broadcast data (whatever datum it is), if NAD83(2011) then collect the GCP data in the same broadcast datum or your states projection. I haven’t tried starting a project in anything other than Metashape’s default datum of WGS84 (ITRF2014) yet. Once I’m satisfied with the results of my project I output the DEM/Orthophoto’s in my state’s projection NGS SC3900 NAD83(2011). It would seem more complicated if you use anything other than the default datum in Metashape, you’d have create the same projection and to also import the geoid model. All the data collected either by the UAV or GNSS data is based on the WGS84 (ITRF2014) model.
I know this is confusing as it was with me, but the data export from Metashape pretty much confirms everything I’ve said as the DEM/Ortho matches with my GCP’s collected in SC NAD83(2011) to begin with. This was importing the final data from Metashape into Global Mapper comparing with our state’s LIDAR data.
If you could, I would talk with your state geodetic agency to confirm what datum is broadcast or you could talk with other’s in your field to confirm exactly what they are doing.
Ok, I will do further testing. So far, my testing shows that when the images are imported in WGS84 in Metashape the results are the best when comparing to GCPS(check shots). Trimble’s corrections department responded to me saying that their reference frame is NAD83(2011). Something is just not adding up here.
On another note, can someone please tell me what datum the LLH coordinates in the CSV exported from Emlid flow are in? My survey project was setup in NAD83(2011) Georgia West with NAVD88 (geoid12b) heights. @EBE111057 @michaelL
@svetlana.nikolenko can you advise on this topic as well? Your input would be greatly valued and appreciated.
Hi Josh,
Reach RS2+ calculates the position in the same datum as the base. So if your NTRIP provides corrections in NAD83(2011), the Reach RS2+ coordinates will also be in NAD83(2011). And it should be the same for the DJI drone.
It’s still in the same datum as your base—NAD83(2011).
Global CS option always means base’s datum, except for the case when you’re working in standalone mode. In standalone mode, it’s WGS84.
Did you use the NAD83 / Georgia West (EPSG:2240) coordinate system? The one you need is NAD83(2011) / Georgia West. Using the former instead shouldn’t affect the plane coordinates of the GCPs. But it may result in different heights if you use geoid models.
Do you have a benchmark with known coordinates nearby? Let’s create a project in NAD83(2011) / Georgia West, connect to your NTRIP service, and collect this point. Please send me CSVs with it and with the previously collected GCPs. I’ll check the data.
Just as a side note… if you do a lot of post processing with either Emlid Studio or any commercial software, the positions of the CORS data is in WGS84 (ITRF2014) datum with ellipsoid heights. That’s why all CORS transmit their data in WGS84 (ITRF2014)
JHallock,
I use pretty much the same equipment and Metashape.
The only difference is that I setup my Base on an NGS monument that is in NAD83(2011).
Here is my workflow and it will work for you too.
The drone is receiving corrections in NAD83(2011) ellipsoid (You from VRS, me from NGS monument). Your images are now tagged with NAD83(2011) ellipsoid.
I collect my control points with another Emlid Reach Rover. I collect my points in NAD83(2011) ellipsoid.
When I go to process I simply do the following.
In reference Settings use:
Coordinate System (The output system): The State Plane, UTM or whatever projection you need. I use NAD83(2011) NJ and Geoid 18 (You will have to add Geoid 18 from Metashape’s website and edit the State Plane system to use Geoid 18 as your vertical system)
Camera Reference/Images: NAD83(2011) with ellipsoid elevations. (6318)
Marker Reference: NAD83(2011) with ellipsoid elevations. (6318)
- Align Images (You can apply masks, remove bad images before this step)
- Import Control Points and mark them, and assign as GCP or Check.
3.Update Transform - Optimize
- Use Gradual Selection to remove bad points
- Create Point Cloud, Ortho, DEM etc.
Since you are using VRS you don’t need the second Emlid. Use just the one to collect your points and use VRS to receive corrections.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.