RS2 as NTRIP

It really depends. When you export RV3 points to CSV, there is no attribute that describes the datum. So if you import the points in QGIS, you absolutely need to specify the CRS correctly. This is a common issue in GIS: people confuse defining the CRS with reprojecting/transforming the data. The former leaves the coordinates unchanged and only states in which CRS they are while the latter will modify the coordinate values from a source CRS to a target CRS.

If you imported NAD83 points in QGIS but told it it’s WGS84, the software wouldn’t know to do anything with it. It trusts the info you’re feeding it. No transformation would happen then. The correct way to do it would be to import as NAD83, then export as WGS84 or use a geoprocessing tool to transform.

I don’t know what your pipeline is exactly but you might be making the exact same error with all your data so it ends up matching anyway.

3 Likes

Thanks for that. All of our survey data comes out of FieldGenius but regardless it is just a CSV file so there’s nothing special about it. In QGIS it is set to transform on the fly and this is where the GeoTiff comes in, not the CSV points. The CSV points get upload to DroneDeploy as GCP’s on a specific EPSG code.

So this is where I am confused even more. When I connect my RS2 via NTRIP for GCPs and the base point, then export those points in the CSV it shows this.
Shared with CloudApp

I was under the impress the decimal side was WGS84. The post above states that it is not but simply a decimal version of the NAD83(2011) as the NTRIP is in NAD83(2011) Ellipsoid Height.

I used Geographic Calculator to transform the state plane coordinate to WGS84 using the following settings.
Shared with CloudApp

Now when I open the CSV of the newly transformed coordinates, it shows the same as the decimal version that was originally in the CSV from RV3.
Shared with CloudApp

So is it safe to assume that my original assumption that RV3 does provide both state plane and WGS84 is correct?

And too further complicate things… you may want to get in a habit of moving from US Survey Foot to International Foot in the USA. Obviously the rest of the world prefers metric… but USA will NEVER change to that in the surveying world, etc. (Yeah, yeah, metric is so baby simple, but some things just will not change).

“NGS and NIST to Retire U.S. Survey Foot after 2022 | News | National Geodetic Survey” https://geodesy.noaa.gov/web/news/us-survey-foot.shtml

“Fate of the U.S. Survey Foot after 2022: A Conversation with NGS | Webinar Series | National Geodetic Survey” https://www.ngs.noaa.gov/web/science_edu/webinar_series/fate-of-us-survey-foot.shtml

Also, here is some good information about coming new datum replacement 2022. Warning, the audio is terrible until about 19 minutes in or so.

“Datums | New Datums | National Geodetic Survey” https://www.ngs.noaa.gov/datums/newdatums/background.shtml

So yeah, once you get the hang of NAD83 and NAV88 etc, shit gonna change before you know it. Including the software you’re currently used to. : /

That is odd indeed!
I tried placing your N/E coordinates and transforming them in QGIS to WGS84, I get the same coordinates as you. I just can’t see how Reach knows the input system, and thus why it is correct?

Can your converter do ECEF/3D Cartesian in NAD83?
If I convert the other way, from WGS84 to NAD83, I get:
X: 833332.8236
Y: 707902.5615
Z: -6262883.5405

How does this fit in your local system ?

1 Like

Ill try to check this evening. I also sent in a support request and something in Facebook to ask them to come into this thread and shed some light on this for us.

@wizprod I did the exact same thing in QGIS and was about to post the result before I saw your message. This is puzzling. Either QGIS did not transform but simply reprojected, or the GNSS data is in WGS84, or there is another explanation that goes beyond my knowledge.

I did it with an expression in the field calculator:

1 Like

How is this different than transform on the fly?

1 Like

It does the same calculation, but I didn’t have to save anything to a file, it is all done in memory. The main advantage of the field calculator is that you can calculate all sorts of things. For instance, this weekend I wanted to calculate the UTM meridian convergence - the angle between the grid and true grographic north, which changes the further you go from the central meridian - for certain polygon centroids. It’s easier to learn than full blown python scripting and often does the job perfectly.

1 Like

That’s pretty awesome! Not that I foresee myself using it for what we do but seems like a pretty good skill to learn. Thanks!

Hey guys,

Chiming in to second some of the comments above :slightly_smiling_face:

If the VRS station transmits NAD83 geographic coordinates (latitude, longitude, and elipsoidal height), Reach will provide NAD83 geographic coordinates as well. If the base station transmits WGS84 coordinates, Reach, in turns, will output WGS84 coordinates.

Keeping the connection to VRS doesn’t make any difference: Reach already knows its averaged in fix position, and all the rovers’ coordinates will be calculated relative to this known point.

1 Like

The Easting/Northing/Elevation is in State Plane coordinates (elevation in US Ft.) The decimal should still be Lat/Lon/E Ht (Ht in meters) but referenced to NAD83 if I am thinking correctly.

Have you tried converting State Plane to WGS84 and see what it gives you?

1 Like

Yes. If you see the later section of that same post, I converted the state plane to wgs84 and it was the exact same lat long height that was in the csv from RV3.

3 Likes

So there is an instance above where I collected in NAD83 for state plane and it also gave the decimal version which appeared to also be WGS84? When multiple of us tried the conversion, we all arrived at the same WGS84 coordinate. Does RV3 convert NAD83 to WGS84 itself?

1 Like

Sorry, didn’t catch that. the attached picture is real blurry.

Keep in mind, different areas NAD83 and WGS84 are very close to one another (inches).

1 Like

Hi Seth,

I agree with @jp-drain-sol. The LLH coordinates should be in NAD83.

Could you share the exact CSV export from RV3 along with your coordinate system configurations in the app?

1 Like

Sent in a PM. Thanks.

Got it, thanks. Just to make sure I didn’t mix anything up: does your VRS station transmits its position using geographic coordinates (latitude, longitude, and elipsoidal height)?

Yes I believe so. It’s also in NAD83.

Just confirmed it is lat, long, ellip height.

Hi Seth,

Tatiana has shared the CSV file with me, and I transformed the NAD83 LLH coordinates to WGS84. As I can see, there is about 1/2 an inch difference in coordinates, so they are indeed very similar.

1 Like