I spent all day last Saturday with a surveyor who owns a Leica RTK rover. We set the base station coordinates from the Leica (after converting Easting’s & Northings) and then moved the Reach rover to around 15 locations and checked the position accuracy. Our results were around 20mm in comparison to the Leica on elevation. So all good.
However is it possible to put Easting’s and Northings into the base station. He also asked if we could get the actual elevation and not use wgs84 which is what it appears to be doing.
One last question. I have had some 1.2mm Ali ground plane discs laser cut. Can they be anodized! Or will this defeat the objective?
Hey Andrew,
I was also hoping to output reach’s geographical coordinates (lattitude and longitude) to grid coordinates (eastings and northings) i cant see how in the reach veiw ap but maybe by outputting the solution via the bluetooth option and using another app like rtkgps+. I am yet to test this myself.
By “actual height” i assume u mean a local height datum? In order to do this u will need a local geoid model and find away of inputting it into reachveiw i do believe this is possible.
Just some info you know to understand exactly what is going on with RTK and Coordinate Systems.
The Leica GNSS actually works in Lats & Longs or Cartesian. The Eastings and Northings are a representation of the value when a Coordinate System is attached to the job in the receiver. When a user inputs Eastings and Northings into the base station, the coordinate system converts the values back to Lats and Longs to set the base position. The RTK message is sent and then the Rover computes it’s position, Then on the Rover, the coordinate system is applied and you see the Eastings and Northings.
When the surveyor said can you put the actual elevation rather than WGS84 value, he is asking if you can put the Orthometric Height in rather than using the Ellipsoidal Height (WGS84). The difference between these values is call the Geoid and he most likely has a Geoid Model attached to his coordinate system which handles this. In some instances, you can just enter the Orthometric height in as the Ellipsoidal height where the Geoid separation is small but where the separation is large, this difference can cause performance issues.
I was wondering how long it would take before These sorts of questions would arise. The fundamental question is about how much functionality you would want to shoehorn into the Reach.
There are literally hundreds of coordinate systems that need to be supported if they decide to take that route. There is the Proj4 project which they could use but the level of support load on EMLID is going to increase exponentially as soon as they implement this.
Then there is the question of elevation - ellipsoids, geoids and the implementation and support of geoid models. Good luck with that
At the end of the day, applications that require this sort of functionality also require additional survey functionality and it is best handled in an external app allowing EMLID to focus on supporting and enhancing the core functionality of the Reach. The tight integration of the IMU data is a much bigger win than competing with hundreds of survey apps which are readily available.
