QGIS vs ArcGIS Pro Raster Reprojection – Differing Results Between QGIS Warp and ArcGIS Pro Project Raster

arcgis-procoordinate systemgdalwarpqgisraster

I recently projected a raster from EPSG:6340 (NAD83(2011)/UTM zone 11N) to EPSG: 32611 (WGS 84/UTM zone 11N) using the "Warp (reproject)" tool in QGIS (i.e., the gdalwarp). I noticed that there was a minor shifting issue for 1.1m for X and 0.5m for Y.

I further used the Project Raster (Data Management) in ArcGIS Pro to apply the same projection and got much better result.

I was wondering why these two tools result in such a different result. I started concerning if the gdalwarp is working correctly.

I did a small test using one test point as follows:

Test Point EPSG 6340 > X: 382794.912012 Y: 3764790.23875

(1) Reproject the test point to 32611 with ArcGIS Pro X: 382793.794251 Y: 3764790.79647

(2) Reproject the test point to 32611 with QGIS X: 382794.912012 Y: 3764790.238854

There are 1m and 0.5m off on X and Y.

Best Answer

If two different software give different results it is impossible to say which one is shifted. There should be a third authorized reference that is known to be correct. ArcGIS Pro also seems to support 9 different transformations between EPSG:6340 and EPSG:32611. I did not test those but I suppose that they would give slightly different results.

enter image description here

QGIS is using Proj and that library supports only one transformation

projinfo -s epsg:6340 -t epsg:32611 --spatial-test intersects|more
Candidate operations found: 1
-------------------------------------
Operation No. 1:

unknown id, Inverse of UTM zone 11N + NAD83(2011) to WGS 84 (1) + UTM zone 11N, 2 m, Puerto Rico - onshore and offshore. United States (USA) onshore and offshore - Alabama; Alaska; Arizona; Arkansas; California; Colorado; Connecticut; Delaware; Florida; Georgia; Idaho; Illinois; Indiana; Iowa; Kansas; Kentucky; Louisiana; Maine; Maryland; Massachusetts; Michigan; Minnesota; Mississippi; Missouri; Montana; Nebraska; Nevada; New Hampshire; New Jersey; New Mexico; New York; North Carolina; North Dakota; Ohio; Oklahoma; Oregon; Pennsylvania; Rhode Island; South Carolina; South Dakota; Tennessee; Texas; Utah; Vermont; Virginia; Washington; West Virginia; Wisconsin; Wyoming. US Virgin Islands - onshore and offshore.

PROJ string:
+proj=pipeline
  +step +inv +proj=utm +zone=11 +ellps=GRS80
  +step +proj=utm +zone=11 +ellps=WGS84
WKT2:2019 string:
CONCATENATEDOPERATION["Inverse of UTM zone 11N + NAD83(2011) to WGS 84 (1) + UTM zone 11N",
SOURCECRS[
    PROJCRS["NAD83(2011) / UTM zone 11N",
        BASEGEOGCRS["NAD83(2011)",
            DATUM["NAD83 (National Spatial Reference System 2011)",
                ELLIPSOID["GRS 1980",6378137,298.257222101,
                    LENGTHUNIT["metre",1]]],
            PRIMEM["Greenwich",0,
                ANGLEUNIT["degree",0.0174532925199433]],
            ID["EPSG",6318]],
        CONVERSION["UTM zone 11N",
            METHOD["Transverse Mercator",

It seems that for Proj, GDAL, and QGIS the tranformation NAD83(2011) to WGS 84 (1) does actually nothing

gdaltransform -s_srs epsg:6340 -t_srs epsg:32611
Enter X Y [Z [T]] values separated by space, and press Return.
382794.912012  3764790.23875
382794.912012603 3764790.23885384 0

By this closed Proj ticket it is correct to do nothing https://github.com/OSGeo/PROJ/issues/829 and also https://www.uvm.edu/giv/resources/WGS84_NAD83.pdf states that "For all practical applications WGS84 ellipsoid and GRS80 ellipsoid are identical."

However, there seems to be different NAD 1983 realizations and this may lead to shift of about a meter https://community.esri.com/t5/coordinate-reference-systems-questions/grs-80-to-wgs84/td-p/849211. The ESRI engineer suggests

If there's no need to transform (you can treat NAD83 and WGS84 as equivalent (cell size > 1-2 meters)), use the null transformation method or the geocentric translation (leave the parameter values as zeroes).

For sub-meter accuracy you should probably know also the epochs (times) of your source data and into what WGS84 epoch you want to do the conversion. Proj/GDAL/QGIS do have support for dynamic coordinate systems nowadays https://gdal.org/user/coordinate_epoch.html but I do not really know how they are used.

Related Question