Hallo,
ok, understood. Still it makes more questions …
We use EMLID, NTrip (to put data in GPS mock location) and ESRI - apps, on Nokia 4.2 android phone
I added directly in ESRI App (with data from RS2, thru NTRIP, …) point: trees. And these were “planted” on soil level, not 100m above.
I added directly lines: (golf stuff: hazard, bunker,…) also on soil level
I took x/y data to add trees indirectly in ESRI online → also planted on soil level.
Hmmm, I would expect a difference reading last posts conclusion.
Maybe for your further analysis.
Best Christian
Could you export the points via CSV file and check if they are ok at that stage, I mean before they go into ESRI. Reach View 3 would probably be the easiest app to use, just to check the system is getting the correct height before checking details of the apps you’re using.
I never worked with ESRI, so I am not sure how to solve this. But if you’re after the correct heights I’ve just posted a workaround here that you can use in the meantime. But you would have to use reach view 3 or any other survey app that can export CSV files to use in Excel.
Georeferenzierung: RTK service SAPOS - NRW - DE (see link here under)
Lage / Lageangabe: Kartesische Koordinaten XYZ im ETRS89/DREF91 in der Realisierung 2016
Höhe / Höhenangabe:
Ellipsoidische Höhe bezogen auf GRS80
NHN-Höhe bezogen auf DHHN2016 (Höhenstatus 170) bei Nutzung des GCG16
I guess that’s the root of the issue. To work correctly, Reach requires ellipsoidal heights coming from NTRIP. As far as I understand how NTRIP casters work, they should have a mount point, which transmits ellipsoidal heights. I’d suggest contacting your provider to check if they have one.
Der amtliche Höhenbezugsrahmen DHHN2016 (Höhenstatus 170) wird im SAPOS® über RTCM 3 als DE_DHHN2016_NH übermitt elt. Die dafür notwendigen Transformationsinformationen („Coordinate Transformation Mess ages“ ) sind in den speziell dafür vorgesehenen Botschaften 1021 und 1023 des RTCM integriert und werden kostenlos abgegeben. Sofern der Rover diese Transformationsbotschaften 1021 und 1023 verarbeiten ka nn, ist eine Auswertung nach Aktivierung im Rover möglich . Die „Coordi nate Transformation Messa ges“ des SAPOS® NRW basieren auf dem bundesweiten AdV-Quasigeoid GCG2016, das für NRW Undulationswerte mit einer durchschnittlichen Genauigke it von 1 cm liefert. Gebrauch shöhen im DHHN2016 im Höhenstatus 170 können mitt els GNSS-HEPS-Mess ungen über SAPOS®mit einer Gesa mtgenauigke it von bestenfalls2 bis 3 cm (SAPOS®-Höhengenauigke it und -Modellgenauigke it) bestimmt werden.
As far as I know, these messages cannot be read by Emlid currently. Vertical heights output by Reach are thus ellipsoidal heights and you need to specify a transformation to orthometric in your target software.
At the moment, to operate correctly, Reach requires ellipsoidal heights and geographic coordinates from the base. On the rover, you can collect points in the local coordinate system.
DHHN2016 vertical datum provides orthometric heights. That’s why you have the wrong coordinates on the rover.
I’d suggest checking with SAPOS if they can provide ellipsoidal heights.
Also, Gabriel shared the info about RTCM3 height transformation messages. For now, we’re investigating how we can support them.
As said, when it runs, I have no problems using Reach, Lefebure and internal Mock up positions. These are correct also in height (Gütersloh is at 79m …)
It always did. My point from the beginning was, that the combination of Reach RS2 with Ntrip and Lefebure gives the right results out of Lefebure (into Android mock positions).
THis is a work around. INteresting for all those that find “data point collection” in Reach view not practically enough. And or need the input in other tools: openstreetmap, … ESRI , … whatsoever…
Best CHris
We’re constantly working on improving ReachView in general and the Survey tool particularly. So, your feedback is a great help for us! If you have a request for some specific features, don’t hesitate to post them.