NTRIP / Project Setup and Coordinate Systems

[tpl124]

Our archaeological project on Cyprus recently purchased two RS3 units, upgrading from our RS+ units. We are hoping to set up these for NTRIP corrections so that we no longer need to use a base station.

The local available NTRIP base stations (the URANUS network) use EGSA '87 (GGRS87). Up to this point, all of our mapping has been done using WGS84 / UTM 36N.

When setting up a survey in the Emlid Flow app, does the coordinate system of the survey project have to match the coordinate system used by the NTRIP? Or can the app/unit correct for the different coordinate systems? Ideally we would like to continue taking points using UTM 36N for consistency across all of our excavation seasons.

[scottmitchell63 (Scott Mitchell)]

Hi there.

Flow does need the corrections to be within the same realisation to work. If you start a project off in flow it will tell you what the requirements for the corrections are in most circumstances.

From screengrab for a project setup with UTM36N flow indicates it requires the corrections in WGS84.

That is where you are stuck I’m afraid. For direct input pretty much all NTRIPs are local or plate level realisations, NAD83, ETRS89 or EGSA87 as per your local provider. We deal with maritime stuff and there are WGS84/ ITRF corrections but they are using huge baselines and as a result are around the decimeter level accuracy at best, which isn’t good for you.

You may have a few options. I would say ideally have your own local base locations in WGS84 UTM36N as you have been doing, it will be the cleanest method.

Block shift of NTRIP data when knowing the local base station position in both systems probably isn’t an option due to rotations etc between systems. That links to the next point.

For RTK you could setup a custom CRS in flow with a 7 parameter shift (using the EGSA87 NTRIP) to get you closer, but that is a bit dangerous as the listed shifts can be of limited accuracy. In the UK for example our WGS84 to ETRS89 (OSGB36) stated on EPSG is good at 1m. So this probably isn’t sufficient, as it requires tests etc to get the transformation right. It would also not provide the tie in with your previous data as they are collected and calculated using different systems. That may not be an issue for expanding to new sites but return visits to sites of interest may cause busts in data.

Your GIS package may be able to offer a better solution to collect in NTRIP and add to previous data sets using 14 parameter shifts if you can find an accurate set of values. If you contact Uranus they might be able to offer the conversion parameters, worth a shot.

Flow does have the localisation tool, which may allow for a custom CRS to be calculated. If you have a network of established ground points already, you may be able to get the conversion from Uranus (EGSA87) to UTM 36N. By uploading the UTM36N coordinates into your project and then occupying them in RTK(EGSA87) flow will create that conversion. I’ve never used it, but when time allows it is on my list to go through the workflow. Hopefully someone from support can follow that up and provide guidance on how/ if that could work for you.

How close is your nearest base station from the Uranus network? I can see two on their website in Limassol and Lefkosia, but not sure if the government NTRIP has a better network. If they offer direct download of rinex data you can use this as PPK in Emlid Studio, RTKlib, or any other Post software such as Carlson GNSS. This only works if you have a short baseline for stop and go type kinematic surveys. If the base station is far away then a local base is best option.

If it is close you could download the data you need from their base stations. Upload that data to a PPP service to get a WGS84 position for the Uranus base station. Then use this updated position to PPK your rovers against Uranus (in WGS84). Again this only works for short baselines. The NTRIP service will likely be calculating you a virtual base close by to allow for the high accuracy fix, where using the long baseline in PPK will likely not provide a fix and maybe not even a good float solution.

Hope that helps in some way. I would say using the local base is best, but maybe the localisation in flow might be a winner for you.

Scott

[ruth.bongon]

Hi @tpl124,

The rover coordinates will be in the same datum provided by the NTRIP service. If you want to have your coordinates in WGS84 but the base broadcasts corrections in GGRS87, then you have two choices, as mentioned by @scottmitchell63:

1. Use the custom CS option in Emlid Flow. You need to know, however, the transformation parameters from GGRS87 to WGS84. The parameters are below, based on this document, quoted verbatim:

The transformation between WGS84 and GGRS87 datums was done using three translation parameters DX = 199.723 m, DY = -74.03 m and DZ = -246.018 m (Fotiou, 2007).

2. Apply localization. This feature allows you to calculate the local CS parameters based on the known local control points, and measurements collected with Reach.

To apply localization, you’ll need to perform the following:

1. Add control points (points in WGS84/UTM 36N)
2. Measure the same control points with the rover in RTK (positions, when connected to URANUS, are in GGRS87)
3. Pair the coordinates of the control points with the measured ones.

The guide on how to apply localization can be found here.

[tpl124]

Thanks for this (and to the previous poster as well). The custom CS has potential, though I have another question regarding getting these coordinate systems to match. If I start a project with a coordinate system of GGRS87, it says to make sure that the NTRIP is in HTRS07, and not GGRS87. I know that HTRS07 is derived from GGRS87, but why does the EmlidFlow app ask for corrections in HTRS07 and not GGRS87?

[tpl124]

I got some more information. The coordinate system being broadcast, since I’m in Cyprus, is NOT GGRS87, but CGRS93, Cypriot local transverse Mercator.

If anyone can direct me to the conversion between that and WGS 84 / UTM36N, that would be great. Otherwise, will attempt to use the localization function.

[ruth.bongon]

Hi @tpl124,

I found this spreadsheet from the Defence Geospatial Information Working Group, which contains the list of parameters for transforming from one datum to the other.

You can create a custom CS with this and the parameters for UTM Zone 36N. However, I recommend contacting your country’s land survey division and asking if they have the official transformation parameters for CGRS93 to the WGS84.