Difference between datum transformations in QGIS 3.4 and ArcMap 10.7

Question

Could someone briefly explain the difference between how datum transformations are handled by QGIS versus ArcMap? For example, I am under the impression that in QGIS you can simply select a destination CRS when exporting a layer and this operation handles the datum transformation and reprojection. Whereas, in ArcMap this is broken into 2 steps. Could someone explain the method of transformation in QGIS vs ArcMap?

Answer 1

QGIS is using nowadays Proj version 6 that is using late-binding just like ArcMap. That you can often make a conversion with just selecting the CRS of input and output means that QGIS has found only one candidate transformation. This is the case with conversion from EPSG:4326 to EPSG:3650 if user does not open the Advanced parameters menu. However, if user opens Advanced parameters they will find 7 transformations to select from.

What happens is that Proj is doing a spatial analysis between the area covered by the data and area of validity of the transformations. This is documented in https://proj.org/development/reference/datatypes.html

enum iso19111_types::PROJ_SPATIAL_CRITERION

Spatial criterion to restrict candidate operations. Values: PROJ_SPATIAL_CRITERION_STRICT_CONTAINMENT

The area of validity of transforms should strictly contain the are of interest. PROJ_SPATIAL_CRITERION_PARTIAL_INTERSECTION

The area of validity of transforms should at least intersect the area of interest.

Spatial test "contains" finds only one candidate transformation which is the "ballpark" one. Spatial test "intersects" finds 6 more candidate conversions and they are included in the list in the Advanced parameters menu.

It is also possible to get a list of the candidate transformation from command line with projinfo tool. Projinfo informs also if additional grid shift files are needed for using the transformation.

projinfo -s epsg:4326 -t epsg:6350 --spatial-test intersects -o proj
Candidate operations found: 7
-------------------------------------
Operation n-¦1:

unknown id, Inverse of NAD83 to WGS 84 (1) + NAD83 to NAD83(2011) (1) + Conus Albers, 5 m, USA - GoM OCS

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80

-------------------------------------
Operation n-¦2:

unknown id, Inverse of NAD83 to WGS 84 (18) + NAD83 to NAD83(2011) (1) + Conus Albers, 2 m, unknown domain of validity

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=FL +step +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80

-------------------------------------
Operation n-¦3:

unknown id, Inverse of NAD83 to WGS 84 (38) + NAD83 to NAD83(2011) (1) + Conus Albers, 2 m, unknown domain of validity, at least one grid missing

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=ethpgn.gsb +step +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80

Grid ethpgn.gsb needed but not found on the system. Can be obtained from the proj-datumgrid-north-america package at https://download.osgeo.org/proj/proj-datumgrid-north-america-latest.zip

-------------------------------------
Operation n-¦4:

unknown id, Inverse of NAD83 to WGS 84 (23) + NAD83 to NAD83(2011) (1) + Conus Albers, 2 m, unknown domain of validity, at least one grid missing

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=lahpgn.gsb +step +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80

Grid lahpgn.gsb needed but not found on the system. Can be obtained from the proj-datumgrid-north-america package at https://download.osgeo.org/proj/proj-datumgrid-north-america-latest.zip

-------------------------------------
Operation n-¦5:

unknown id, Inverse of NAD83 to WGS 84 (27) + NAD83 to NAD83(2011) (1) + Conus Albers, 2 m, unknown domain of validity, at least one grid missing

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=mshpgn.gsb +step +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80

Grid mshpgn.gsb needed but not found on the system. Can be obtained from the proj-datumgrid-north-america package at https://download.osgeo.org/proj/proj-datumgrid-north-america-latest.zip

-------------------------------------
Operation n-¦6:

unknown id, Inverse of NAD83 to WGS 84 (21) + NAD83 to NAD83(2011) (1) + Conus Albers, 2 m, unknown domain of validity, at least one grid missing

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +inv +proj=hgridshift +grids=alhpgn.gsb +step +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80

Grid alhpgn.gsb needed but not found on the system. Can be obtained from the proj-datumgrid-north-america package at https://download.osgeo.org/proj/proj-datumgrid-north-america-latest.zip

-------------------------------------
Operation n-¦7:

unknown id, Ballpark geographic offset from WGS 84 to NAD83(2011) + Conus Albers, unknown accuracy, World, has ballpark transformation

PROJ string:
+proj=pipeline +step +proj=axisswap +order=2,1 +step +proj=unitconvert +xy_in=deg +xy_out=rad +step +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80

Proj4 and Proj version 5

In Proj4 all transformations went through a common pivot system EPSG:4326. GDAL was made to read the parameters of the coordinate systems, transformations etc. from a bunch of csv files (coordinate_axis.csv, datum_shift.csv, ellipsoid.csv, gcs.csv etc.) which were derived from the EPSG database. Datum shift parameters were stored into datum_shift.csv and the header line is quite informative.

"SEQ_KEY","COORD_OP_CODE","SOURCE_CRS_CODE","TARGET_CRS_CODE","REMARKS","COORD_OP_SCOPE","AREA_OF_USE_CODE","AREA_SOUTH_BOUND_LAT","AREA_NORTH_BOUND_LAT","AREA_WEST_BOUND_LON","AREA_EAST_BOUND_LON","SHOW_OPERATION","DEPRECATED","COORD_OP_METHOD_CODE","DX","DY","DZ","RX","RY","RZ","DS","PREFERRED"

Pay attention to fields "COORD_OP_CODE", "SOURCE_CRS_CODE", "TARGET_CRS_CODE", and "PREFERRED". It means that it was possible to have several operation betwees two CRS codes but only one of them was labeled as "PREFERRED". The preferred coord op was used as a default when only EPSG codes of the source CRS and target CRS were given . For using some other transformation user had to define both CRS with full Proj strings.

The preferred coordinate operation was selected by the best knowledge of the main GDAL developer in year 2010. You can read more about that history from this GDAL GitHub issue https://github.com/OSGeo/gdal/issues/2219.