If so, is there a reasonable way to translate the points to WGS84 in QGIS? I assume I could find a known point near me and measure the offset.
thanks,
steve
for RTK work:
There could be more to the story than this, but if your CORS supplies a NAD83 base coordinate, then your WGS84 position will be offset by the difference of the CORS base station coordinate. (NAD83 - WGS84 = offset). This is because ReachView expects a WGS84 base coordinate and it is being given a NAD83 coordinate, so there is an error that can be described as a simple offset in Long, Lat, Height and applied to each of your rover’s position results.
for PPK work:
Just convert the CORS base coordinate from NAD83 to WGS84 and manually enter that base coordinate in RTKPOST.
I think so, but I’ll let someone who uses QGIS every day give that answer.
I asume that nearly everyone in the US has this challenge? I’m using Indiana’s Department of Transportation CORS network. Their instructions say set your rover to NAD83. When I compare my results with google earth images (using QGIS to export KML files), I see a consistent ~1 meter shift.
I assume the shape file created by the rover lists the projection as WGS84. I wonder if I use the CVS file…and tell QGIS the projection is NAD83 if that will work…I’ll try that report back!
Well it will probably be close, but I don’t think it will be exact. I’m guessing you would mostly see notice a difference in height (the height difference between your base and rover as defined by the WGS84 ellipsoid vs. the NAD83 geoid)
I think shifting the coordinates would be the most best way.
After some testing, including locating a high precision geodetic mark, it appears the reach reports coordinates relative to NAD83 when using the Indiana Department of Transportation CORS network. Good news, it appears to be dead-on for NAD83. NAD83 and WGS diverge about 1 meter here.
Height also seems NAD83 ellipsoid correct, which is about 33 meters below the geoid.
The height is easier to live with. It would be helpful if the json and shp files were labeled correctly (i.e. NAD83).
Please add my vote for supporting other GCSs, especially when communicating with a CORS.
2 Likes
Steven,
We are finding the same here in Utah!
We’ve taken over a dozen points using Reach using different settings as well as 3 different Trimble setups for comparison at a known benchmark and a few stable monuments.
We assumed that the processed Reach data would be WGS84, however, the CORS base data we’ve used is NAD83 and we think that is forcing our output data to be converted. When we use Vdatum to convert final elevations between the vertical datum (ellipsoidal heights) and compare to positions acquired using our Trimble survey gear on the same control point, NAD83 matches quite nicely (the offset between the two vertical datum is about 60 cm).
We are in the process of field testing our Reach setup so we’ll have more locations after next week in a different geographic area to compare. Still more digging to do, but we’ll post our findings after this next set of data.
Reach receives NTRIP caster’s coordinates and expects them to be in WGS84. Rover’s position is calculated relatively to the received base position, so you will have this error embedded in all the points you collect. I can not guarantee any good results in a situation where the base position comes in an unexpected format.
All the casters I’ve had a chance to work with have a mountpoint that provides base coordinates in WGS84.
1 Like
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.