Rs3 nad83(csrs)

Can Emlid confirm there are actual differences in these two projections (NAD83(CSRS) vs. NAD83) - see attached screenshots? I’m running into issues using NAD83(CSRS). When I compare my RS3-collected check points on-site (in NAD83(CSRS)) against LiDAR data also outputted in NAD83(CSRS), the difference in the vertical access is very large (hundreds of millimetres). If I convert the check points to NAD83 using Global Mapper, the agreement with LiDAR data (NAD83(CSRS)) is really good (<20mm). It could be an issue with the software I’m using to process the LiDAR data (DJI Terra), but I’d also like to rule out it being an Emlid issue.

There is DJI forum thread here that is relevant.

The forum entry on 2-20 10:48 is important, which is as follows:

Hello, I have noticed this issue a long time ago. In DJI Terra, you need to actually select the original NAD83 instead of NAD83(CSRS). According to my tests, NAD83 original is actually NAD83(CSRS) and NAD(CSRS) is … well something else around 1,5m off. I hope they are gonna fix this someday, it’s annoying.


Hi @davidevanr,

NAD83 and NAD83(CSRS) are two different realizations of NAD83. NAD83(CSRS) is the current realization used in Canada.

Did I understand correctly that you have a Reach receiver and use the RINEX observation file in DJI Terra? I don’t have any experience with post-processing in DJI Terra, but do you manually input the precise coordinates of the base in the software, or do you use the coordinates from the RINEX header?

1 Like

I use my RS3 as a base for the drone mission (arbitrary point), meanwhile the RS3 is collecting RINEX data while the flight is on-going. I submit the RINEX to NRCan and receive PPP coordinates/elevation when I return to the office, and then manually enter new base station coordinates in DJI Terra. The LiDAR data is then adjusted to the new coordinates and ellipsoidal height.

1 Like

I see. Here’s the definition of NAD83 and NAD83(CSRS) according to NRCAN:

NAD83 has undergone several updates since we first introduced it in 1986. It has evolved from a traditional, ground-based, horizontal control network called NAD83(Original) to a space-based, dynamic 3D realization called NAD83(CSRS).

NAD83(CSRS) represents a dynamic 3D realization of NAD83(Original). Canada and the U.S. collaborated to redefine NAD83 in relation to the ITRF through a seven-parameter transformation using VLBI stations common to both systems. We keep NAD83(CSRS) aligned to the North American plate using the NNR-NUVEL-1A estimate of plate motion.

I read the thread you shared, and I’m afraid you would need to wait for DJI Terra’s fix on handling these two datums in their software.

1 Like

It might help to check into a known control point if there is one nearby. I’m not sure what province/territory you are in (zone 10 makes me suspect out west), but here is Ontario’s HCM and VCM GIS:

https://www.lioapplications.lrc.gov.on.ca/COSINE/index.html?viewer=COSINE.OntarioViewer&locale=en-CA

Another thought comes to mind… what vertical datum are you using ? NAD83 is simply a horizontal datum.

If you flying here in the USA, NAD83(2011) EPOCH 2010.0000 and NAVD88; GEOID 18 is the common system used. Also, if your using an RTN service, most are broadcasting in ITRF2014 with ellipsoid elevations at least here in SC. We usually fly using the RTN and post process the imagery in the same datum. Once all imagery is processed, we then export into our states horizontal projection and NAVD88 Geoi18 vertical datum.

Accuracies in horizontal and vertical components usually check <5cm against our ground control and targets.

You might review your translation from different horizontal and vertical datums. To me, that appears to be the issue.

1 Like

My guess would be one of the following vertical datums for the final orthometric heights:

  1. CGVD2013a (ie. the newest GPS derived one)
  2. CGVD28 (ie. the old spirit levelled one)
  3. HTv2.0 (ie. a hybrid geoid model allowing for the direct transformation of ellipsoidal heights in the NAD83(CSRS) reference frame to orthometric heights that are compatible with CGVD28. HTv2.0 is based on the gravimetric geoid model CGG2000 and includes 1926 GPS constraints on benchmarks whose ellipsoidal heights are in NAD83(CSRS) at epoch 1997.0).

Here is an overview of many/most of the horizontal and vertical datums of Canada (mind you, this is written from the perspective of someone from Ontario and there are certainly provinical/territorial/local ones that I am unaware of/unfamiliar with):

See p.22 for an explanation of many of the datums of Canada.