Coordinate system transformation : ITRF, ETRF, WGS84

Clear introduction about Global and local referential (Lantmateriet) : “Positions determined by the GNSS method Precise Point Positioning (PPP) are in the same reference frame as the orbits, i.e. usually a realization of ITRS, e.g. ITRFyy, IGSyy or WGS84, where “yy” represents the year of the realization. The coordinates change with time in the ITRS realizations, because of the plate tectonics. Hence,the determined coordinates are given in the epoch of the observations. For practical applications like mapping and referencing spatial data , a static system/frame, which does not change with time, is desired. For this purpose, ETRS89 has been developed for Europe. ETRS89 coincides with ITRS at epoch 1989.0.”

Another simple reading about dealing with ITRS, ETRS and WGS84 is at Confluence website.

Nota : the transformations made by GIS software from WGS84 to local referential are precise at 1 meter only. For centimeter accuracy, use a geodetic software taking into account the velocities of the ITRF referential relative to the local referential (e.g. ETRF for Europe).

There are many WGS84 realizations. The latest compares with ITRF08 and ITRF14, see table below:

YearRealization (Epoch)For all practical purposes equivalent to:
1987WGS 1984 (ORIG)NAD83 (1986)
1994WGS84 (G730)ITRF91/92
1997WGS84 (G873)ITRF94/96
2002WGS84 (G1150)ITRF00
2012WGS (G1674)ITRF08
2013WGS (G1762)Compares to ITFR08 within 1cm Root Mean Square (RMS) overall
Table of WGS84 compared to ITRF from

For US, WGS84 (G1762) is equivalent at 1cm to ITRF14. For France also ITRF14 ~ ITRF08 at less than 1cm, the transformation is given here

For France, the official referential is RGF93, which in its latest version is defined as ETRF2000 (epoch 2009.0) ( ).

Position and velocities of the IGS stations in ITRF2014 at epoch 2010 is given at this adress

Tools to Convert between referentials

Reference online tool to convert between ITRF and ETRF :

Coordinate transformation software for France : Circé IGN

Coordinate transformation software : PROJ

Example : converting from ITRFxx (epoch XXXX) to RGF93

We have made a GNSS survey in May 2020 that we want to convert to France official referential in a projection. The GNSS referential will then be ITRF14 (epoch 2020.1), and the French referential will be RGF93 with the associated projection Lambert93. In order to do so, we need to make some referential transformation, and also some conversion between cartesian coordinates, geographic coordinates and projected coordinates.

To transform ITRF14 (epoch 2020.1) to RGF93, use this site and choose ETRF2000 (epoch 2009) as equivalent to RGF93 (see this post), for the velocities you must choose the one of the nearest IGS station (positions and velocities given at ITRF official site or Euref site). Then to transform cartesian to geographic coordinates, use Circé IGN software. And finally, use also Circé to convert to projected coordinate system.

More information

GNSS processing with open-source softwares

The main methods of GNSS processing are (1) the classical differential correction with a permanent base station, and (2) the Precise Point Positionning (PPP) method that does not require a base station and uses precises clock and ephemeris data.

The tools used can be softwares or web-services. Among software we can distinguish between commercial softwares (e.g. Trimble Business Center TBC), open-source softwares (e.g. RTKLib), and scientific softwares (Bernese, Gamit/Globk). We will introduce RTKLib and web-services.


RTKLib is the main open-source library and software to process GNSS data. It can do conversion, post-processing, navigation, plotting, and so on.

Note : Several versions of the software exist and they behave somewhat differently. I’ll try to describe them one by one but you’d better check carefully your results compared to another “official” reference in order to validate your process.

Versions of RTKLib :

  • Official software, with actual version 2.4.2. Does not work for me in post-processing as it is not possible to load base station Rinex data.
  • Emlid Fork here. Should be best for conversion of UBX (Emlid raw format) to RinexFor. For what I can say, it worked for conversions, for post-processing of the base station, but it was not stable for post-processing of rover.
  • RTKLib_Explorer fork here. Located on the really rich blog about GNSS and RTKLib named RTKLibExplorer, this tool works well and is well documented. The setting of parameters for static processing and obtain a single position is hard (set ON for “Output Single for Sol outage” and set a value for Max Sol Std)

Complementary tools for dealing with POS files from RTKLib and CSV files from ReachView :

PPP web-services

Static GNSS correction with web-service

This processing is done with static GNSS correction using a network of permanent stations.

RGP IGN , good for France, gives results in many coordinate systems including RGF93-Lambert93

GNSS complentary data and tools

GPS and Glonass ephemeris data, along with atmospheric data at

and also here (search more simple)

and also here (search simple too)

IGS Antenna calibration file (does not contain Emlid Reach RS2) : igs14.atx

List of IGS stations : here

GPS Calendar to get the GPS week : here or at IGN site

Julian calendar to get GPS day : here or at IGN site

Offset between GPST (GPS Time) and UTC : here

More information

Filtering of DEMs

Several algorithms can be used to filter DEMs. Most simple and common are:

A less common but very recognized and efficient:

Examples of such filters on an noisy DEM :


Click on caption to enlarge. r : radius

Processing of a GNSS survey in RTK or PPK mode made with Emlid Reach RS2 device


Processing of GNSS data from a survey made with an Emlid Reach RS2 base and rover (applies also for RS+ device) in RTK mode but with a base installed on an unknown location. The base position must then be post-processed and 2 main workflows are possible. First implies to calculate the Delta (difference) between a priori and corrected position for the base station, and then applying this delta to the rover. Second one implies to post-process also raw data from the rover, as in a PPK survey.

The described workflow was set up for France dataset and referential. France official reference frame is RGF93, which corresponds to ETRF2000 (epoch 2009).

Surveying with Emlid Reach RS2

I’ll don’t enter into details of surveying, but just few points that will allow accurate post-processing of the survey.

First, save all the raw data from the base and the rover in UBX format rather than Rinex or RTCM3. This is the more complete format for Emlid devices.

Second, carefully write down and save the a priori position of the base station in ReachView app. It is this position that is used when transmitting the correction to the rover, and it is different from the position that will be found into Rinex header. Thus, when calculating the delta between a priori and estimated (corrected) position, we will need this information.

Third, the referential used by Emlid devices is WGS84. For a survey made today (2020), it corresponds to ITRF14 (epoch 2020). Thus, when setting information such as base station location into ReachView app during a survey, the location must be set into this referential.

Processing the base

The base beeing set up on an unknown location during the survey, its position must be corrected. The general workflow is described in Emlid reach tutorial, but the steps below give other information allowing an accurate positionning.

Transform the UBX files of the base and the rover (raw data from the Reach RS2) to Rinex with RTKConv. Better not to use the Rinex file that can be logged in the receiver as it does not contain as many informations as the UBX.

Correct the base position with one of the two correction methods below : (1) Precise Point Positionning (PPP) processing, or (2) static differential correction with permanent stations around.

Base Method 1 : PPP Processing

In case of dual frequency receiver, the PPP solution gives better results if the logging time is long enough (min. 4-5 hours, best 12-14h) and if you wait few days (minimum 4 days, optimal 14 days, see IGS site ) before processing as the ephemeris and clock are recalculted more accurately.

Use a web-service to do this processing. E.g. :

PPP workflow

The results of PPP is generally given in the same reference frame as orbits, which is WGS84 current realization, that corresponds today (2020) to ITRF2014 epoch 2020.

To transform ITRF2014 to RGF93, use this site and choose ETRF2000 (epoch 2009) as equivalent to RGF93 (see this post), for the velocities you must choose the one of the nearest IGS station (positions and velocities given at ITRF official site or Euref site). Then to transform cartesian to geographic coordinates, use Circé IGN software. And finally, use also Circé to convert to projected coordinate system.

Base Method 2 : Static GNSS differential correction with permanent station

In case of processing the base station relative to permanent stations, the corrected position is given in the same referential as the reference station. Thus for France using RGP stations, the results will be given in RGF93, no further conversion needed as it is the local official reference frame.

Use either RTKPost either a webservice such as RGP one for France. Choose 30s Rinex dataset instead of 1s. This avoids time dependant correlation.

Static differential GNSS correction

Calculation of Delta between a priori and corrected base position

This calculation is pretty simple, just make sure you have the same reference frame between a priori and corrected positions. Be sure also not to use geographic coordinates, but either geocentric coordinates or projected coordinates. The scheme below describes this process with geocentric coordinates.

The addition of 7cm come from the fact that Emlid Reach RS2 antenna is not calibrated and it is not of standard dimension. Then if you obtain the corrected base station from a web-service, the result will be under-estimated by approximately 7cm. If you don’t use a web-service but a software post-processing with for example RTKLib, no need to add these 7cm.

Delta base station

Processing the rover

Two possibilities appear to process the positions of the rover.

Rover Method 1 : Delta

Making sure we have the a priori position of the base station as recorded by ReachView app, we can calculate the correction rover positions by applying the same delta as the one between the a priori and the corrected base position. This is only possible if the distance between the rover and the base is short (let’s say <1km) as this does not take earth curvature into account.

Rover correction using Delta method

Rover Method 2 : Post-processing differiential GNSS

This is the same method as for a PPK survey, we process the rover positions relative to the base station with RTKPost. Be sure to set the base to the corrected position. The corrected positions of the rover will output in a POS file, and in the same referential as the base position.

The initial positions of the surveyed points were stored in a CSV file in ReachView app during survey, and contains for each point the name, the antenna height, and the start / stop time of logging.

The corrected positions in the POS files, and the time-span from the CSV file are merged using a utility such as

Rover correction with differential GNSS

Example of full process using base method 2 and rover method 2:

1- conversion of UBX files to Rinex with RTKConv
2- BASE correction: Correction with RTKLib in static mode compared to the nearest permanent GNSS base (30s Rinex). Use of GPS + Glonass(+Galileo). The result is obtained in the base station referential, therefore in RGF93 (epsg 4171).
3- ROVER correction: Correction with RTKLib in Kinematic mode compared to the corrected base position. Use of GPS + Glonass(+Galileo). The result is obtained in the base station referential, therefore in RGF93 (epsg 4171).
4- Association of the corrected POS format rover file with the CSV survey file from ReachView app. This is done with the Python program "". !!! The ellipsoidal height is contained in the "height" field and NOT in the "elevation" field
5- Transformation of geographic coordinates into projected coordinates with Circé IGN. For this we must reformat the CSV file obtained to have the format desired by Circé, namely ID Long Lat Height (list of possible formats in the help of Circé)
6- Reformatting the file output by Circé. Use of the AWK scripting language.
7- Re-assembly of the file from 6 with that of 4
8- Estimation of uncertainties by combining those of the base with those of the mobile, by sum in quadrature. 
9- Estimate of the deviations with the positions from some control points

Example of full process using base method 1 and rover method 1:

1- Note the a priori coordinates of the base. They are indicated in ReachView app at the time of the survey, and !!!!!! as they do NOT correspond to the coordinates of the RINEX header.
They are expressed in WGS84, i.e. in ITRF14 (epoch 2020.1 for our survey in March 2020), and they are expressed in LLH coordinates (Longitude Latitude Height).
Subtract the antenna height (Full height from the ground to the antenna phase center) from the H component. 
2- Convert these LLH coordinates to XYZ coordinates (Cartesian three-dimensional geocentric), for example with Circé IGN. Always be sure to re-format files from Circé that are badly screwed up.
3- Obtain corrected coordinates of the base.
We use the values ​​given by a web service such as the NRCAN-PPP which gives the coordinates in the GPS reference system (ITRF14 epoch 2020.1). In that case, !!!!! you will have to be careful because the height estimated by this web-service is underestimated by around 7cm (this must be a problem with the non-calibrated antenna of the Reach RS2). It will therefore be necessary to add this value to the ellipsoidal height later on, as the coordinates we use are now the one expressed in cartesian geocentric XYZ referential
4- Calculate Delta X, Delta Y, Delta Z on the base. Beware of the Delta sign to go from a priori coordinates to the corrected coordinates.
5- Retrieve the coordinates of the mobile. It is a CSV from ReachView. These coordinates are in LLH (ITR14 epoch 2020.1).
Convert these LLH coordinates to XYZ coordinates, for example with Circe IGN
6- This file contains Cartesian coordinates from the RTK but without correction of the base. This file is normally in id X Y Z format ..... it must be rewritten according to this form: id X Y Z Vx Vy Vz. The coordinates X Y Z will be modified by applying the Delta of the base. The Vx Vy Vz correspond to the  velocities (m/y) of the zone in the reference system used. For example in our case, we will use the velocities of the Marseille station in ITRF14, which can be obtained from the site 
7- Transform the global referential to a local referential. In our case we will go from ITRF14 (2020.1) to ETRF2000 (2009). The latter corresponds to RGF93. This transformation is done with the online tool on EUREF 
Save the results in a text file. We will only keep id X Y Z 
8- Convert Local Cartesian coordinates to Local projected coordinates with Circé IGN. We will use RGF93 to RGF93-Lambert93. Make sure to properly re-format the file from Circé

More information