I have a question in regards to going from dynamic ITRS coordinate systems to the static UTM one.
I have a GNSS Base station and recorded data for 24 hours to do precise point positioning (PPP) with the Canadian PPP service. (I did wait a few weeks to have optimal satellite orbit data before starting the PPP)
I now have to the base coordinates in ITRF2020 2024.2 supplied in Lat, Lon and Ellipsoid height.
In the end I need the coordinates in UTM32 N with WGS84 Ellipsoid height.
(The data I have to work with is in UTM)
I am not sure if all the intermediate steps are necessary; currently I do the following.
Convert Lat, Lon, Hgt using python to geocentric Earth Centered Earth Fixed (ECEF) format
Use ETRF/ITRF Coordinate Transformation Tool (ECTT) (online) to go from ITRF2020 2024.2 ECEF to ETRF1989 1989.0 ECEF
Convert the ETRF1989 1989.0 ECEF coordinates to WGS 84 and UTM32 N WGS84 Hgt (EPSG: 25832) in python once again
I did not find any information about whether the conversion | ITRF2020 2024.2 ECEF to ETRF1989 1989.0 ECEF | Is correct to receive the UTM coordinates. (As far as I have read the UTM system is based on the ETRF1989 System and they should be the same)
In the end I would like to have a centimeter accurate position of my GNSS in UTM by this method.
I am almost sure someone here knows a way to slim down this conversion nightmare using a GIS, that would be awesome to know about.
The UTM can be in any realisation (NAD83, ITRF, ETRS89, GDA94, ED50, etc) it all depends whether the project datum is set with the floating ITRF or fixed to one of the plate level realisations. Does your use case require the geodetics to be in ETRS89? If so, does it have a specific epoch? For instance here in UK we use ETRS89 but it is derived from EUREF97 (2009.76) which is “ETRS89” but held to a set epoch. Your case may be similar. If so you would need to generate the correct velocites for use in the ECTT, using something like UNAVCO plate generator.
If you can use ITRF then the NRCAN should give you the final EN for UTM32 on report and EL height is WGS84 anyway (GRS80 but the difference is tiny between them). For UTM datums we would always use ITRF, but that is because our clients are using ITRF based datums, so best to check your use case.
As far as your step by step process goes. If you have a reliable python workflow then great. As long as the transformation in step 2 is good then the rest is fine. Certain software will take ECEF. Have a look around for converters. Unfortunately flow doesn’t like ECEF coords, which may be something that can be added in in future.
Unfortunately we do not have any PPP services for ETRS89. Which is a nonsense, when NAD83 and GDA are covered by OPUS, NRCAN and AUSPOS. It would be great to have that service but I can’t see it coming. The closest you will find is Trimble RTX. They will allow a few variations of ETRS / EUREF but limited to certain bits of hardware. Emlids are not on the list. You could take local NTRIP network data if you have access and PPK your data to gain ETRS89 but again you need to know which version is being used to ensure accuracy.
As for GIS. You would need to setup a transformation to get from ITRF 2020 (now) and ETRS89 (then) and have layers set for import etc (ETRS89 as the base CRS and import layers as ITRF). I’ve got basic dabble experience there so not sure how to do that.
For checking accuracy of results you may need to download data from CORS station and run through PPP to get ITRF position. Then transform to see how accurate this is in the correct ETRS89. So for here in UK, I could download OSNet data (EUREF97 2009.76) and then upload to NRCAN to give me ITRF2020. This is then transformed using the parameters in ECTT and the result is compared to listed position on the rinex header or on OSnet website.
The ITRF vs ETRS is a tricky one to navigate. hopefully you get a solution which is reliable, but I would check your client requirements first to make sure what you need as the base.
Hi, I see you use epsg 25832 which is some where in Norway, right?
The tool you should be looking for is SKtrans. It does the transition from ITRF to UTM that you need.
Firstly, I agree with @scottmitchell63. The UTM coordinates are often referenced to a specific geodetic datum, ETRS89 or WGS84, for example. You mentioned EPSG:25832, which is ETRS89 / UTM zone 32N.
Are you based in Norway? If so, the ETRF version of ETRS89 realization in Norway is ETRF93 epoch 1995.0 based on this scientific article.
After that, convert the ECEF coordinates to LLH and apply the UTM projection. Unfortunately, the transformation tool doesn’t seem to have an API, so you need to do the transformation manually every time.
You can also convert the computed coordinates in LLH to EPSG:25832 in Emlid Flow, but since you’re using Python to automate the process, then I believe it would be faster for you to automate the whole process before and after the ITRF/ETRF transformation tool process.
I haven’t tried the tool @TB_RTK mentioned, but maybe it’s also worth looking into.
I have also tested the more cumbersom manual way with velocities and convertion that @ruth.bongon pointed out. Fun but alot of work.
Both work but Sktrans is way faster can handle batch import
Link here WGS84 to ITRF08 - #8 by TB_RTK
Thanks for sharing the old threads and your expertise. Those were really informative. I enjoyed the whole read, and I’m sure others will find them helpful as well!
