Using RTK CORS State Network Converting to NAVD88

I’m planning to try the Reach RS+ with our State Reference Network using RTCM data over NTRIP. I’m not sure if this matters but it says the coordinates for the casters are NAD83-2011 Epoch 2010.00. I’m guessing they are mentioning this for PPK. For RTK, I assume the Reach can get realtime corrections from this network by just entering the server address and login credentials, correct? Do I have to set anything else?

The photogrammetry software converts the Drone images’ horizontal coordinates between the WGS84 coords embedded in the images to State Plane NAD83 and I assume just uses the height values as-is with no conversion. You essentially instruct the software to ignore the coordinates in the images though and use the ground control point coordinates as your baseline coordinates.

So I’m assuming that if I use the Reach to measure my own ground control points, the coords are WGS84 and I would need to convert the heights to NAVD88 manually before inputting into the photogrammetry software? This would give me NAVD88 heights in the output instead of WGS84. Assuming I got this all right, where is a software tool to do that?

Using my RTK machine (Javad Victor LS) accessing the SC RTN, the software in the rover needs to set as the same datum as the broadcast. I have two M2’s I use for static only and haven’t used the RTK in Reach software yet. Using Reachview 3, you can set the datum and projection in it. Whatever state you’re in, I would verify that the seleced projection is correct by occupying an NGS passive station to make sure you are using the right one before starting any project. You will have problems if you don’t.

I have no clue how to do this.

I’m not sure this is necessary and I looked through the Reachview docs and couldn’t find where you would even do this? According to this post Ground Datum Use - #21 by jmiranda

“Generally speaking network are adjusted to certain datum, but they all broadcast WGS84 (Lat, Lon, Ellipsoidal Height.In other words, the network receivers track the same information from the satellites than your Emlid Reach does. It is the software that takes care of transformations.”

My photogrammetry software easily converts to any coordinate projection (EPSG #) I choose. So wouldn’t I just survey the ground control in WGS84 (which is what the drone uses), process it, and then if I wanted the resulting output files in a different coordinate system just choose that on the export? If I wanted NAVD88 heights, I think I still would need to find a software tool that will do that conversion for me before I input the ground control coordinates into the processing software.

Hi @jazee,

Yes, Reach can receive real-time corrections regardless of their coordinate system. However, the ReachView 2 supports only WGS84, and even if your NTRIP caster provides corrections in NAD83, all calculations will be in WGS84. It means you get coordinates with an offset equal to the offset between WGS84 and NAD83. However, I also must tell that this offset is very small.

“Generally speaking network are adjusted to certain datum, but they all broadcast WGS84 (Lat, Lon, Ellipsoidal Height.In other words, the network receivers track the same information from the satellites than your Emlid Reach does. It is the software that takes care of transformations.”

This is the right sentence, except for the one fact that your caster sends the base position in NAD83 when the ReachView 2 expects WGS84.

The ReachView 3 supports different coordinate systems, including NAD83. Could you clarify whether you work with an Android device? If so, I’d suggest you try the ReachView 3 open beta version.

The open beta for iOS devices will be available soon.

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.