UTM nad1927 vs CA state plane nad 1983

[jeffnolan]

I keep having a problem overlaying shape files that are in California State Plane Zone III (nad 1983) and files that are in UTM Zone 10N (nad 1927) in ArcMap.  I sometimes use Global Mapper for translating data, and the two projections line up perfectly in Global Mapper.  When I bring the same layers into ArcMap, there are offset by about 280 feet (about the same as the difference between the nad 1927 and nad 1983 projections in this area.)  I formerly used ArcMap 9.0, and upgraded to 10.2 figuring it was a glitch in 9.0.  I'm having the same problem with 10.2.  I don't think its a problem with the data, since everything works perfectly in global mapper. The utm file is a stock usgs 7.5' topo (Felton Quadrangle.)  The state plane data includes a variety of gis files from santa cruz county and from the Cal. coastal commmission, among others.    It seems like the on-the-fly projection algorithm in ArcMap is buggy.  Any ideas?

[MelitaKennedy]

We used to automatically apply the NAD_1927_To_NAD_1983_NADCON transformation in ArcMap. We no longer do it, so you'll have to apply it.

Open data frame properties. On the coordinate systems tab, click the Transformations button. Depending on what the data frame's coordinate system is, highlight the other one in the top box. In the pull-down (that says None), click it and select the above transformation.

Melita

[jeffnolan]

Thanks, it worked.   I should have asked sooner, it would have saved a bit of frustration.

[JimCousins]

We used to automatically apply the NAD_1927_To_NAD_1983_NADCON transformation in ArcMap. We no longer do it, so you'll have to apply it.

Open data frame properties. On the coordinate systems tab, click the Transformations button. Depending on what the data frame's coordinate system is, highlight the other one in the top box. In the pull-down (that says None), click it and select the above transformation.

Melita

Melita,
When did this default get altered? Is there an option to re-enable it?
Regards,
Jim

[MelitaKennedy]

Hi Jim,

We removed it in 10.1 SP1. It was causing other issues, and we wanted to 'level the playing field'. Canadians, Alaskans, and Hawaiians don't want to use the CONUS version of NADCON, and other countries don't want to see it.

It's possible to write an add-in that would load it automatically (I have a VBA script that would add a different default transformation for NAD27/NAD83). Or add it in an mxd and save that as a template or use that as the base for new mxds. Once a transformation is made active in a map document, it will remain active even if there's no data that uses it.

Melita

[ScottKutz]

The information in this thread appears to help identify the underlying cause of a problem just reported to us today from one of our clients.

Our application is implemented using ArcGIS Engine, so this follow-on question is trying to understand how to use ArcObjects to achieve the same effect of restoring the NAD_1927_To_NAD_1983_NADCON geographic  transformation into the ArcGIS Engine MapControl environment (since it has now been removed).

Our client just upgraded from the version of our application that used ArcGIS Engine Runtime 10.1 to the one that is built on ArcGIS Engine Runtime 10.2.2.

The client's data is also in California and consists of multiple layers, some of which are vector data in UTM Zone 10N (NAD 1983) (customized to units of feet) and TIF file raster data that uses California State Plane Zone II (NAD 1927). The client is reporting that the NAD 27 raster layer is displayed offset approximately 300 feet east of where it displayed in the previous software release.

We are already using the technique outlined in the ArcObjects Help for assigning the NAD_1927_To_NAD_1983_NADCON geographic transformation. We are using the approach from the following Help link, as shown in the sample code below.
http://resources.arcgis.com/en/help/arcobjects-net/conceptualhelp/index.html#/d/000100000m6z000000.h...

// This example demonstrates how to use the IGeoTransformationOperationSet methods.
// Set the NAD27 to NAD83 - CONUS GeoTransformation.
public void ChangeCoordinateSystem1()
{
    ISpatialReferenceFactory2 spatialReferenceFactory = new
        SpatialReferenceEnvironmentClass();
    IGeoTransformationOperationSet geoTransformationOperationSet =
        spatialReferenceFactory.GeoTransformationDefaults;
    // NAD27 to NAD83 - CONUS
    IGeoTransformation geoTransformation =
        spatialReferenceFactory.CreateGeoTransformation((int)
        esriSRGeoTransformation_NAD_1927_TO_NAD_1983_NADCON) as
        IGeoTransformation;
    geoTransformationOperationSet.Set(esriTransformDirection.esriTransformForward,
        geoTransformation);
    geoTransformationOperationSet.Set(esriTransformDirection.esriTransformReverse,
        geoTransformation);
}

Unfortunately, this approach does not seem to have any effect, in that the NAD 1927 data is still displayed in ArcGIS Engine 10.2.2 offset approximately 300 feet east of where the same raster files displayed with ArcGIS Engine 10.1.

We would appreciate if anyone has any insights on how to achieve the effects with ArcObjects similar to the series of steps performed in ArcMap outlined in the earlier posting in this thread from Jan 22, 2014 1:31 PM.

Thanks for your help.

Scott

[ScottKutz]

This entry is just to identify the resolution to the issue described in the previous entry (to the best we can identify via testing).

Continued investigation led us to try our existing application code running with ArcGIS Engine Runtime 10.3.0 (instead of 10.2.2). ArcGIS 10.3.0 successfully performed the geographic transformation calculations between NAD27 and NAD83 during on-the-fly projection processing.

These results indicate the following:

• The existing application code for assigning NAD_1927_To_NAD_1983_NADCON geographic transformation seems to be the correct approach (calling the geoTransformationOperationSet.Set() method, as shown in the previous posting).
• There appears to be an ArcGIS Engine Runtime bug regarding the NAD27-to-NAD83 geographic transformation calculations that:
  • Did not exist in ArcGIS 10.1.
  • Appeared in ArcGIS 10.2.2 (at least in the ArcEngine MapControl's on-the-fly projection processing).
  • Has been fixed in ArcGIS 10.3.0.
• We are reluctant to just dismiss this as "an Esri bug" (especially because we have not been able to locate any documentation describing this type of bug), but the testing results seem reasonably convincing in this case.
• The same ArcObjects application code produces a different result based on whether it executes with ArcGIS Engine Runtime 10.2.2 vs. 10.3.0.
• For some reason, it appears ArcGIS 10.2.2 is unable to (or, does not detect the need to) perform the geographic transformation from NAD27 to NAD83 during on-the-fly projections for this particular pair of "From" and "To" Projected Coordinate Systems.

The resolution is for our client to start using the version of the application based on ArcGIS Engine Runtime 10.3.0.

Scott