Comparing vector reprojection between GDAL 1.3.1 and ArcMap 9.0

Submitted by dylan on Sun, 2006-07-30 03:04.
UPDATE:

it looks like the mysterious NAD_1927_To_NAD_1983_6 transform is actually a localized transform for the Quebec area. Furthermore, ESRI has informed us that this is not in any way a default transform, rather the first in the list. In summary, regardless of the software that you are using to do this type of work, always know your data and do your homework on the available methods. Thanks to Matt Wilkie for the detective work.

 
The Experiment
Quick comparison of the results of a vector projection using both OGR (GDAL wich uses the Proj4 library) and ArcGIS 9.0. Ideally both methods should return just about the same coordinates. The GDAL tools use the NADCON grid corection for datum shifts in the US and Canada, while ArcGIS provides several transformation methods (NADCON being one of them). Figure 1 demonstrates the dialog box where datum transformation parameters are set in ArcGIS. The default (first) method in this list NAD_1927_To_NAD_1983_6 is more than slightly confusing. Perhaps the rationale for this approach is explained somewhere, but I have certainly never come across it. In order to better understand any possible differences in the results of a datum shift operation, the three following operations were performed:

OGR ogr2ogr -s_srs 'prj=latlong datum=NAD83' -t_srs '+proj=utm +zone=11 +datum=NAD27' output.shp input.shp
ArcToolbox transform from NAD83 GCS to NAD27 UTM Zone 11 (NADCON)
ArcToolbox transform from NAD83 GCS to NAD27 UTM Zone 11 (NAD_1927_To_NAD_1983_6 transformation)

 
Analysis

OGR vs. ArcMap 1: ArcToolbox projection dialog message
Fig 1: projection dialog in ArcMap
OGR vs. ArcMap 1: coordinate shift
Fig 2: observed coordinate shift
ArcMap default datum transform output in red.
OGR vs. ArcMap 1: easting shift regression
Fig 3: ArcMap vs. OGR easting values
OGR vs. ArcMap 1: northing shift regression
Fig 4: ArcMap vs. OGR northing values

Several comparisons where done to assess the three dataum shifting methods. First the output from the cs2cs command (used for datum shift operations among other things) was compared with the same operation on a the NGS NADCON website. The two methods appeard to be the same for at least 10 decimal places. Next, the first coordinate from a polygon projected across datums (with the three methods described above) was compared. The OGR and ArcGIS (NADCON) methods produced identical results, however the ArcGIS (NAD_1927_To_NAD_1983_6) method produced odd results. It appeared as if the coordinates where transformed, but not corectly. Finally, the same coordinate was datum shifted using proj directly: with the same odd results as the NAD_1927_To_NAD_1983_6 method. An analysis of these coordinates as compared to the corectly shifted coordinates is presented in figures 2 through 4.

 
Results

As discovered in an earlier experiment, vector projection within a single datum by OGR and ArcGIS yielded nearly identical results. This is certainly a good thing if you are using both of these programs in your work flow, or sharing with others critical of open source tools. Based on these simple tests, the output from OGR and ArcGIS (using the NADCON transform) are functionaly identical. This is also a good thing. However, the default transform presented in the project feature dialog within ArcToolbox (Figure 1) is still a bit puzzling. While it appears to perform some soft of coordinate projection, it is certainly not the correct one. Also, it is worth noting that using the proj command directly for a similar operation results in the same odd output! It should be said however, that proj is not designed for datum shifts. Instead, the command cs2cs should be used.

 
Conclusions

What have we learned? While I wasn't expecting OGR and ArcGIS to produce different results, it is nice to see that when used properly they produce nearly identical output. Perhaps someone can shed some light on the default, and somewhat bizzare NAD_1927_To_NAD_1983_6 datum transform method in ArcGIS 9.0. Details on the tests can be found below:

 

  1. Compare datum shift (NAD83 -> NAD27) Proj 4.9 and NGS NADCON: [exactly the same]
    echo "-119.560953035858461 37.06968077687506" | \
    cs2cs +proj=latlong +datum=NAD83 +to +proj=latlong +datum=NAD27 -w5
    
    NAD83 NAD27
    Lat Lon Lat Lon
    cs2cs 37.06968077687506 -119.560953035858461 37d4'11.0339"N 119d33'35.93485"W
    NADCON 37.06968077687506 -119.560953035858461 37d4'11.03390"N 119d33'35.93485"W


  2. Datum shift NAD83->NAD27 of first coordinate in sample polygon, into UTM Zone 11:
    [note problems with ArcGIS default transform]
    NAD83 NAD27
    easting northing easting northing 2D shift
    ogr2ogr 272323.66132 4105670.61614 272404.60847 4105470.64705 215.731
    ArcMap NADCON 272323.66132 4105670.61614 272404.60847 4105470.64715 215.731
    ArcMap Default Transform 272323.66132 4105670.61614 272318.10172 4105467.33107 203.361


  3. Quick test: does proj 4.9 return the same results as ogr2ogr across datums? [NO]

    #1st coordinate from polygon GCS NAD83:
    echo "-119.560953035858461 37.06968077687506" | proj +proj=utm +zone=11 +datum=NAD83
    272323.66       4105670.62
    echo "-119.560953035858461 37.06968077687506" | proj +proj=utm +zone=11 +datum=NAD27
    272318.10       4105467.33
    203 m difference in UTM coordinates
    
  4. Comparison of OGR (correct) and ArcGIS defualt (incorrect) datum shifted coordinates in R.

    #analyse in R:
    #cols 1, 2 are arcmap x,y 
    #cols 3, 4 are ogr x,y
    paste arcmap_9.ascii ogr.ascii |  awk ' /\./{print $1, $2, $3, $4}'  > raw_coords.dat
    
    #start R
    R
    a <- read.table('raw_coords.dat')
    names(a) <- c('arc_x', 'arc_y', 'ogr_x', 'ogr_y')
    attach(a)
    
    #analysis of residuals
    par(mfcol=c(2,2)) ; plot(lm(arc_x ~ ogr_x), col='blue', cex=0.3)
    par(mfcol=c(2,2)) ; plot(lm(arc_y ~ ogr_y), col='blue', cex=0.3)
    
    #RMSE:
    sum(sqrt((ogr_x - arc_x)^2 + (ogr_y - arc_y)^2)) / length(ogr_x)
    88.02054 [meters]
    

Submitted by matt wilkie (not verified) on Wed, 2006-08-02 16:58.

I asked ESRI about this, their response: The 'default' transformation that Dylan refers to, NAD_1927_To_NAD_1983_6, is just the first in the alphabetical list. As it turns it out, it uses NTv2 and is designed for Quebec. ArcGIS generally doesn't set any default transformations but leaves it to you to decide which one is most appropriate. Dylan's data is outside the area covered by the NTv2 grid file, so essentially no tranformation occurs when he uses NAD_1927_To_NAD_1983_6. A better reference for him, which does list the methods, parameters and areas of use for the transformations is:
http://support.esri.com/index.cfm?fa=knowledgebase.techarticles.articleShow&d=21327

-- Melita Kennedy Product Specialist ESRI, Inc.

Even if mistaken about the "default", thank you for conducting the experiment and telling us about it. Otherwise I would sailed along quite happily usiing the wrong selections myself. Also thanks to you we also know that provided the appropriate transformation method is chosen equivalent results can be achieved with both ArcGIS and GDAL, so we are all free to choose the tool most readily at hand.

Submitted by victor (not verified) on Tue, 2006-08-01 21:29.

The datum shift reference in the ESRI doco (http://edndoc.esri.com/arcobjects/9.1/default.asp?url=/arcobjects/9.1/ComponentHelp/esriGeometry/esriSRGeoTransformation3Type.htm) points to an EPSG code for the shift (1573). If you look this up in the EPSG database (http://www.epsg.org/) , it references a NTV2 Canadian Transformation (specifically for Quebec as mentioned above.) The funny thing is, this grid should not work outside of Quebec. In searching through all of the NAD27 -> NAD83 shifts (the mathematical ones anyways), nothing comes close to the shift (~ dx=60.0, dy= 108.2, dz=192.600000).

Submitted by dylan on Wed, 2006-08-02 06:00.

Interesting indeeed. I didn't think to lookup the EPSG code mentioned in the EDN article. Could this suggest that there is no error-checking involved in the application of a transform within ArcGIS 9.0?


Submitted by Paul K (not verified) on Sun, 2006-07-30 22:53.

Well IMHO there should be no such thing as a "default" set of datum transformation parameters for a datum, and ArcGIS and OGR are both wrong in allowing the user to use a default transformation without further prompting. It just so happens in this case that the one OGR uses (NADCON) is the most accurate available for the area covered by your data, but in the general case (worldwide) this is very hard to determine and there normally is no such thing as a default. The transformation that should be used depends on the exact area covered, accuracy required etc.

In most cases in GRASS, when choosing projection parameters, the user is interactively prompted and forced to make a decision on which datum transformation to use. I feel this is "a good thing" because, in the best traditions of the steep learning curve in GRASS (!) it makes the user think about the meaning of their data and how reliable they expect the result of the processing to be (garbage in garbage out etc.).

Submitted by dylan on Mon, 2006-07-31 17:15.

Thanks for the comment Paul. Without a doubt I agree in regards to the approach where the user must select an appropriate dataum transform. However, I must admit that the first time I used GRASS, I was forced to take out my old text book on cartography [1] and read up on things. Perhaps some pressure on both the GDAL (proj4) and ArcGIS side will help to get things moving in the right direction.

PS: interesting website on the France datum shift grid creation!



[1] Robinson, A.H.; Morrison, J.L.; Muehrcke, P.C. & Guptil, S.C. Elements of Cartography John Wiley and Sons, 1995.


Submitted by Steve (not verified) on Sun, 2006-07-30 04:24.

Hey Dylan:
If you look at this page
http://edndoc.esri.com/arcobjects/9.1/default.asp?url=/arcobjects/9.1/ComponentHelp/esriGeometry/esriSRGeoTransformation3Type.htm
You can see the description as Quebec. I think this means that the particular NAD conversion is tweaked for Quebec. If you look at some of the other constants you will see that there are other NAD to NAD custom conversions that must be tweaked for certain areas. Don't ask me why ESRI chose that one as the default. This is all of course conjecture. The only way to nail this down is to look at the parameters that it uses for the NAD shift. I thought it might be hidden somewhere in the file system but I don't see it.
Check out this doc
http://www.usace.army.mil/usace-docs/eng-manuals/em1110-2-1003/c-5.pdf
and search for Quebec. The later results show that there is a lot of crustal movement about Quebec and the Great Lakes so perhaps this is a "realignment" of the transformation which takes these changes into account.

By the way, thanks for doing this benchmarking. People do this stuff all the time with Statistical software as well. They usually use SAS as the gold standard. It was based upon some of these results:
http://www.practicalstats.com/Pages/excelstats.html
http://www.agresearch.cri.nz/Science/Statistics/exceluse1.htm
http://www.cof.orst.edu/net/software/excel/no-stats.php
http://www-unix.oit.umass.edu/~evagold/excel.html

that I advise people to NEVER do statistical analysis in Excel except for things like Mean and Median.

Submitted by dylan on Mon, 2006-07-31 17:30.

Hi Steve thanks for the comments. The ESRI link was interesting, but not particularly enlightening in regards to the actualy parameters involved.

In regards to statistical analysis, I would highly recommend R as it is both multi-platform and open source. In addition it has some excellent packages for interfacing to RDBMS, GDAL, and GRASS.

Ditto on the Excel comment!