# Coordinate transformation differences in ArcGIS, QGIS and Google Earth Pro

I have a shapefile with points in Adindan UTM 37N coordinates. Now there seem to be roughly two ways of converting those coordinates to WGS84.

When loaded in Google Earth Pro the points are about 150m shifted to the southwest compared to in QGIS.

In ArcGIS both of these behaviours are possible. When using on-the-fly projection with 'Adindan_To_WGS_1984_1' selected in the Data Frame Coordinate System Transformation the result is the same as in QGIS, (both using towgs84 geocentric translation -166,-15,204).

When <None> is selected however the result is the same as in Google Earth. (This is only possible in on-the-fly projection, the Project tool always selects the closest match by default, just as with KML export.)

This Google Earth/ArcGIS <None> behaviour is a black box for me, but in this case of converting Garmin GPX data in Adindan it seems to be the correct behaviour, so my question is: What happens in this case, and is it possible to do the same transformation with QGIS/proj4? (I tried using +towgs84=0,0,0,0,0,0,0 but that causes an even bigger shift in a different direction)

For example: The Adindan coordinate [391000, 1221000] is converted to [38.002975, 11.045626] by QGIS and to [38.002148, 11.044758] by Google Earth.

Another way to use the coordinates is to interpret them as being WGS84 UTM 37N, then they transform to [38.002132, 11.043761]

• The GE-calculated coordinates have had no transformation applied. They're still Adindan coordinates. – mkennedy Mar 7 '16 at 18:26
• I checked this by unprojecting EPSG:20137 to EPSG:4201 in ArcGIS's projection engine. Results were lon=38.002147846 lat=11.04475812 – mkennedy Mar 7 '16 at 18:33
• thanks, so that's when you don't supply a transformation. Any idea what kind of transformation it uses when you don't supply one? It is different from using no transformation at least. Your first comment I don't understand, obviously the converted coordinates are lon,lat so they are not Adindan, right? – PTT Mar 9 '16 at 7:24
• They're still on the Adindan datum (lon,lat); they haven't been converted to WGS84. If you don't supply one, probably nothing happens. In essence, the lon-lat coordinates are treated as if they're on the target/output GCS/datum, but have the same values as the input GCS. – mkennedy Mar 9 '16 at 18:50

There are two things happening during this coordinate transformation: reverse projection (from x,y in meters to latlong) and datum transformation (from latlong in one datum to latlong in another datum). Now when the datum transformation properties are not fully known this whole datum transformation is skipped. This happens when no datum or to_wgs84 parameter is present.

When no transformation is selected in ArcGIS it skips the datum transformation, and interprets the latlong coordinates as being WGS84. The same happens in Google Earth, since the datum in the .prj file of a shapefile is usually not fully defined (not in the ESRI version at least, QGIS stores an additional fully defined .qpj file, according to OGC specifications).

The reason that in the end these untransformed coordinates are still different from interpreting them as WGS84 UTM 37N is that also the projection is dependent on the used ellipsoid. When the size of the ellipsoid is slightly different the conversion factor from degree to meter is also slightly different, giving a slightly scaled result.

Now to get the Google Earth/ArcGIS <None> behaviour in QGIS the proj4 string to be used should have an incomplete datum definition. By default all projections in QGIS are from EPSG and are fully defined, so a custom CRS should be added with incomplete parameters, like "+proj=utm +zone=37 +ellps=clrk80 +units=m +no_defs". Note that this always skips the datum tranformation, so it depends on the project CRS if it is displayed as wanted, in this case the display CRS should use the WGS84 datum.

To transform the shapefile to correct Adindan coordinates first convert it to WGS84 using an incomplete datum, and then back to Adindan using a fully defined datum. For example with ogr2ogr:

ogr2ogr -s_srs "+proj=utm +zone=37 +ellps=clrk80 +units=m +no_defs" -t_srs EPSG:32637 test_wgs84.shp test_adindan.shp

ogr2ogr -s_srs EPSG:32637 -t_srs EPSG:20137 test_adindan_correct.shp test_wgs84.shp

(Google Earth can also do the correct tranformation if the datum transformation parameters are fully known. If "TOWGS84[-166,-15,204,0,0,0,0]" is added to the datum definition in the .prj file it will do the datum transformation.)