we faced a new problem yesterday. Not related to hardware and not related to Reachview app itself as its now well underttanded.
Here is the testing scenario where we have found a problem related to our location.
We have two benckmark at the office that have been placed by a surveyor. We have the coordinates form them.
We installed REACH Base on one known point en entered coordinate:
1- We had to convert our coordinate that are EPSG: 32188 to EPSG:4326 to fit Reach RS
2- We surveyed the second known point
3- Export surveyed point and compare to absolute coordinate (already surveyed second point)
We the entered all the coordinates into ou GIS and we have theses differences between REACH measurement and Surveyor measurement: X: 0.452m Y: 0.843m Z: 0.56m differences
we used the tool provided here for conversion: mygeodata.cloud and converted from one EPSG to other EPSG.
I suspect this is a Geoid problem. Surveyor projection is NAD83 MTM 8 and geoid CGDV28 (HTV2) (Canadian hybrid geoid).We then converted X and Y but not Z. First problem I anticipated was Z offset but not on X and Y as we converted the projection systems.
We absolutely need to find the workflow to be able to work on previously surveyed lands by surveyors. Other than that, we will be unable to use our two REACH
Solution for the mobile is FIX - Kinematic - Collection time (20 seconds) 20+ satellites - precision by default (5cm)
Entered Survey, entered Antenna height (pole measurement + Reach unit as mentioned in the instructions)
Placed the pole on the survey point and clicked collect point.
Export the point in DXF format and compare with that second point.
I think this is probably a workflow mistake we will continue to work on it and test further
It’s was a conversion mistake.
We did the same workflow again and we got a point 9mm from the known coordinate.
We will continue to test and post our results here.
Please, add ore EPSG or give us the possibility to enter our own. We really dont like to convert coordinate on the feild when working with benchmark.
May I know how has been the going to-date regarding your beacon surveys as I want to also use my RS+ for relocation of beacons that are on EPSG2053 and EPSG2054 projections. In the absence of any other workflow I would convert all target my coordinates for the beacons that I am searching for to lat/lon.
It would have been better to be able to enter projected coords manually (as you rightly pointed out).
Our ReachView 3 app supports different coordinate systems, including EPSG:2053 and EPSG:2054.
To import beacons’ coordinates to the app, you can upload a CSV file with the Name, Easting, Northing, and Elevation of each point. The manual import of coordinates is not supported now, but we’ll consider adding it in the future.
Thanks Kseniia. I’ve done the importation already. But setting up on a beacon with EPSG 2054 coordinates I still have to first convert that pair of coordinates to lat/lon as I cannot manually enter x/y base coordinates - only lat/lon
You are right, base coordinates should be entered in lat/lon. It is a software requirement needed to apply all the transformations in the correct way. After you enter the base coordinates in degrees, you can collect other points with the rover in EPSG:2054 in meters.
This is a very troublesome requirement. Could it not be possible to enter the coordinates and height of the base in EPSG at the stage of creating a project in Reach View 3 and in this application get its conversion into lat/lon and ellipsoidal height for manual input in Reach View 2.
I agree. Of all the GNSS field softwares I have used, it is common in the base setup for to either enter a “here” position after the base has got a good position or select a point number to occupy that has already been measured. This would be in the selected coordinate system, IN USER SELECTED UNITS, NOT LAT/LONG.
Being a SC Surveyor, we use ifeet units for FIPS SC3900 ZONE. All measurement units are in either meters or ifeet.
Latitude/Longitude units are meaningless and have no easy way for measure without conversion to the user grid system. Also, determining an ellipsoid-geoid height separation in the field is not ready available most times. The software should compute the transformation from latitude/longitude/ellipsoid that the receiver determined to the user selected coordinate/geoid system. This is typical for base setup in most all GNSS field softwares.
I’m sure Emlid is aware of this, as the method they use does cause much confusion as has been posted on this forum.
The current base setup methodology needs to change in order to attract more Surveyor users.
Thanks for your suggestions! I’ve passed them to our team.
RTCM3 can transmit geographic coordinates only. That’s why the base position should be entered in degrees. We’ll think about if there is a way to add other options to the ReachView 3 in the future.
