How to convert ITRF14 (2022.5) from CSRS to WGS84 for PPP

Hi,

I have collected RAW data log and processed the .obs file at the Canadian NRCAN CSRS-PPP service.

I followed EMLID PPP documentation and chose the Static and ITRF processing mode and received the following coordinate

ITRF14 (2022.5)
Latitude: 25° 7’ 36.74039"
Longitude: 25° 7’ 36.74039"
Ell. Height: -4.533 m

And

UTM (North) Zone 40
2779966.340 m (N) 337557.053 m (E)

I now need to insert the ITRF14 coordinates received from CSRS into my EMLID base manually to have PPP.
I came to understand that EMLID RS2 uses WGS84. Is there anyway to convert ITRF14.

I’m using my EMLID RS2 as a RTK base station for autonomous robots so high precision is a must.

Many thanks,

You always assume the datum of your correction source. That being said, NRCAN should be delivering in CSRS 83 2011 and ITRF 2014 epoch 2022.5. I would enter in the ITRF 2014 coordinates and then project or transform your data after the fact using ESRI, QGIS, TBC, or etc. You can also use the NRCAN tool below in the link.


2 Likes

Thank you.
I’m not an expert in this field so slowly trying to understand the following:

  1. Is there a huge difference between ITRF2014 and WGS85?
  2. Does EMLID base mode uses WGS85? If yes, why can’t they add ITRF2014 so it is an easy copy past PPP correction from majority of free services. (This is maybe a question to the EMLID team)
  3. I tried the CSRS link you mentioned above, but it mainly convert ITRF2014 to NAD83 and not WGS85

The main reason I’m converting to WGS85 is I was told that the base mode correction in EMLID uses this datum and not ITRF2014.

Please correct me if I’m wrong.
Many thanks,

Please explain what you mean by “base mode correction” ?
How are you using the receiver (s) ?
What are you trying to achieve?

1 Like

I’m installing an EMLID RS2 antenna to be a fixed base station to send very accurate RTK corrections to multiple moving robots around the city through NTRIP.
To determine a very precise base station antenna location I followed the EMLID PPP method mentioned here:
https://docs.emlid.com/reachrs/tutorials/post-processing-workflow/ppp-introduction/

Through this method, I would simply collect RAW log for 24 hours and upload it to CSRS to be processed. CSRS will provide a very precise location of where my base station is. I then manually insert the acquired coordinates as the Base Station Coordinates (as shown below)

My issue is CSRS provides coordinates in ITRF2014 datum while EMLID uses WGS84. I’m looking for any method to convert from ITRF to WGS. I wish EMLID gives the choice to choose the datum.

Perfect. Okay, you have established the position via PPP where you are going to set up you RS2 as a base to provide RTK correction to various rovers in the area.

With the RS2 mounted on the point, in Reachview3, you set Base Mode to Manual and enter the coordinates. If you specified a pole height when collecting the point, then you enter the pole height again here.

That is it. Now you are ready to send corrections to the rovers. You don’t need to convert the coordinate to something else unless you are trying to match some other particular CRS, for example a projected coordinate system.

3 Likes

Hi Layth,

You don’t need to convert the coordinate to something else unless you are trying to match some other particular CRS, for example a projected coordinate system.

Just wanted to give some details about this tip Dave shared. When you choose a coordinate system in ReachView 3, you’ll see a note about the required base datum:

So, it’s not necessarily WGS84. If the required datum matches the one from your PPP service, you can just go with these coordinates. If not, you’ll need to transform them. You can use an online converter or a GIS app for that.

1 Like

Alright, so this would should through the app.
It doesn’t show when I access my EMLID through wifi/Ip address.

Will definitely check it. Many thanks.

Hi, to give additional details about the question 1 you asked in this message :

By design ITRF2014 and WGS84 are close to the centimeter-level. However, if you work with high-accuracy applications, and you have to choose between these two, always go for ITRF2014, as it is the only system you can use to determine the coordinates of a new point with a centimeter accuracy.

That being said, from the UTM coordinates you gave, you are located in Lithuania. There seems to be a high quality GNSS network there.
That means you can probably post-process your base in PPK mode in Emlid Studio, instead of PPP, and get the base coordinates in ETRF2000 datum.

Using the official local geodetic datum, when there is one, is better if you are to work with other data sources such as GIS data collected by a surveyor. For instance, there is currently a 60 - 70 cm difference between ITRF2014 and ETRF2000, so this is something you want to know and understand if ever you come across such gaps in your analysis.

1 Like

Hi Florian,

Thank you for your reply. I’m actually in Dubai. Not sure why it showed you Lithuania.
would ppk work for base station only?

“For instance, there is currently a 60 - 70 cm difference between ITRF2014 and ETRF2000, so this is something you want to know and understand if ever you come across such gaps in your analysis.” Can you elaborate on this please?
Many thanks,

@layth.mahdi

Oh, my bad then, I must have mistyped the UTM coordinates or the UTM zone.

Then, you are not really concerned by ETRF2000 datum, which is valid for Europe mostly. But to answer you with simple words, ETRF has been derived from ITRF at a given reference epoch. Due to tectonic motion, ITRF2014 and ETRF2000 difference is growing by a few centimeters every year, the current difference being at around 60 - 70 cm.
So that means that if you use data in ITRF2014 from several years ago, and you compare it to data collected in ITRF2014 today, you have by design a difference in position that is only due to tectonic motion and not to GNSS precision.
I don’t know about the tectonic motion in Dubai. If it is a significant number of centimeters per year, it’s better to be aware of it.

It can work for any receiver able to log its raw data. But if you use it on a rover, that means you get coordinates after a post-processing step and not in real-time. For robotics applications, it is probably not suitable. It really depends on what you do with the rover trajectory of course.