After reading this article How to transform data from NAD83 to WGS84 and based on my personal experience (taking RTK GNSS measurements with multi-frequency multi-constellation receiver hooked up to ORGN NTRIP caster referenced to NAD83(2011) epoch 2010.00), I want to share some notes.
The article suggests QGIS as a tool just to proceed with warning potential users how it could easily go wrong with no warnings. However, it doesn’t provide any methods to verify the results or the method itself except for trusting the process. Since my first attempts (independent from the content of the article) to transform my observations have failed, I was looking for the verification method and found some.
First of all, as far as I understand QGIS uses GDAL/ORG and PROJ. This toolchain has a very useful command projinfo
for testing the transformation. You’d need to understand WKT output that it will spit out, but you can much easier spot the situation when it’s going to use a ballpark low-precision transformation.
For instance, this query:
projinfo -s EPSG:6319 -t EPSG:7665
among many other things spits out this string:
Conversion from NAD83(2011) (geog3D) to NAD83(2011) (geocentric) + Inverse of ITRF2008 to NAD83(2011) (1) + Inverse of WGS 84 (G1762) to ITRF2008 (1) + Conversion from WGS 84 (G1762) (geocentric) to WGS 84 (G1762) (geog3D)
It explains in fairly good detail what it’s going to do and has some useful keywords such as geog3D
which means that it expects input and provides output in degrees of latitude/longitude as well as ellipsoidal height, see EPSG:6319 for details. It also mentions 0.01 m
at the beginning and in the context of OPERATIONACCURACY[0.01]
which is pretty self-explanatory.
Then, you can actually attempt transforming an individual set of coordinates using cs2cs. The easiest way is to throw them into its input stream like this using echo
:
echo 45.3260398861N 122.57538285W 107.533 | cs2cs EPSG:6319 EPSG:10605 --t_epoch 2025 -f "%.11f" -v --only-best=yes --no-ballpark
This command has some excessive parameters (the last three) since they only make sense when there are multiple possible transformations (see the output of projinfo
, in this case, it clearly states Candidate operations found: 1
anyway).
EPSG:10605 is the most recent realization of WGS84, WGS 84 (G2296) and the target epoch parameter supplies the necessary context to the time-dependent transformation since WGS 84 (G2296) is a dynamic CRS (again, note the terms DYNAMIC
and Time-dependent Coordinate Frame rotation (geocen)
in the projinfo
output). %.11f
defines the decimal output format.
Going through various epochs (dates) and WGS84 realizations equivalent to, say, ITRF 2000, 2008, 2014, etc., you’ll see different results for the same input, showing a consistent drift. This is something that OSM doesn’t take into account at all. Consider that when trying to match more recent precision data to earlier precision data stored in the OSM database.
However, if you somehow picked a specific epoch and decided to convert your dataset into it, you can easily verify the result against the reference transformation. To do that, take one or more coordinate sets from your dataset (coordinates of one vertex or point), run them through the desired transformation using cs2cs
, and do the same using NOAA/NGS Horizontal Time-Dependent Positioning tool. This tool supports both 2D (NADCON) and 3D (GEOCON) transformations.
HTDP doesn’t save you from the pain of trying to understand this matter and make an educated decision about it. But it does allow you to quickly try various transformation parameters.
This article isn’t meant to be a tutorial or a step-by-step instruction, so don’t treat it as such, and don’t demand it to be that.
Discussion