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.
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.
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.
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.
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).
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
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:
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.
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.
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?
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.
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?
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)?
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.
