Properly referenced geotiff loading in wrong

[AndrewGiles]

The geotiff is exported from Pix4d in State Plane NAD83(2011) South Carolina International Feet (as defined by EPSG 6570).  It imports properly into Global Mapper, AutoCAD Civil 3D, Hypack, and Trimble Business Center.  We have found the issue but can not explain why it is happening and thats my question, why?

When you bring it into ArcGIS, its loading it in with a custom coordinate system that is defining the latitude of origin as 31.5.  The problem is, the real latitude of origin is 31.83333333.  So Arc is placing the image to the south by .33333333 degrees.  If you go into the toolbox and define the project to the proper definition for 6570, the geotiff is then displayed properly.

Why is this going on with Arc only?

[XanderBakker]

I don't think ArcGIS invents a shift of one third degree. There must be  something in the definition of this custom coordinate system, but to be sure the file itself should be examined. Have tried contacting support?

[AndrewGiles]

I don’t think it invents the shift either.  I agree, something in the file is telling arc to load the tif with that custom coordinate system. The problem is, the file loads fine in other programs.  When you pull the spatial metadata in those other programs, the latitude of origin is correct, as are all the other definitions of the coordinate system.

What’s also interesting and maybe a coincidence is 31.83333333 is equal to 31 degrees 50 minutes. Is arc somehow reading the degrees minutes as decimal degrees?

Is there a way to examine the file without loading it in a GIS program?

Also the file is on Dropbox for anyone that wants to look at it.  I tried contacting support last night but I am only using a trial version.  I don’t use arc typically, this was brought to my attention by someone else that wanted to work with the tif in arc.

[XanderBakker]

There are libraries in python that allow to examine the header of a GeoTIFF file, but I don't know if you would want to go there and there may be other software solutions available to investigate any metadata. 

One question, before you load the TIFF do you define the desired (correct ArcGIS coordinate system) in the dataframe? 

[AndrewGiles]

Yes, I have tried it both ways.  If I define the projection coordinate system first and then load the tif, you get the same result with the wrong latitude of origin.

[MelitaKennedy]

I just checked the definitions for all South Carolina state plane zones for NAD83 and later re-adjustments like 2011. They all have 31°50'0" for the latitude of origin (the definition has a macro identifying it as DMS). Because it's a raster, it might be a problem in the header, or how the header is being interpreted. So this may be a specific-to-raster problem.

I thought I had a copy of listgeo available, but it was quite old so I might try to get a newer version or gdalinfo up-and-running again. Feel free to drop me an email (mkennedy at esri dot com) with the dropbox location and I'll try to repro and send it on to the raster team.

When you redefine the coordinate system, do you modify the existing one or use the Esri definition? If the latter, that confirms that the Esri projection engine has the correct definition but there's something we're not reading correctly in the geotiff's header.

Melita

[AndrewGiles]

Gdalinfo was the key to solving this mystery as I figured it out last night.  I will write up a reply to the original question.

[AndrewGiles]

One of my colleagues was able to find a current version of gdalinfo and that was the key to finding out what was being embedded in the header.  I will attach a screen shot of a side by side comparison of headers.  

On the left is the header from the tif before import into Arc and on the right is the header corrected with the definition from Arc after redefining the projection. 

We can compare line by line the differences.

1. Lines 6 and 7 we have the Geographic Coordinate System and Datum description.  We see the NGN and National Geodetic Network appear in the original vs. the NAD83 (2011) and NAD83 NSRS 2011.  Very interesting because the NGN is the datum for Kuwait.
2. Line 10 we have Spheroid definition with EPSG code 6318 in the original and EPSG code 1116 in the Arc edit.  Upon looking up code 6318, there are two entries for it: 1) NAD83 (2011) and 2) National Geodetic Network of Kuwait.  The code 1116 has three entries, one of which is NAD83 (NSRS 2011). 
3. Line 13 we have the Prime Meridian definition with EPSG code 4318 in the original and EPSG code 6318 in Arc edit.  Code 4318 is yet another code for the NGN, Kuwait's National Geodetic Network.  Again 6318 doubles for NAD83 2011 and the NGN.  Both these datums define the prime meridian the same way.

At first I thought Pix4D was erroneously embedding this information but all the files run through gdalinfo showed the correct header.  The next thing we did, was import the tif into Global Mapper to crop some of the jagged edges off of the map.  It was then exported out of Global Mapper and that is where the erroneous information was being embedded.

Its still interesting that the other software programs were able to load the tif properly but Arc was the only one sniffing out that something wasn't quite right with the tif.  Any idea as to why that might be?  I theorized that Arc is actually using the EPSG codes to load projection definitions and not the definitions embedded in the tif.  Maybe an Arc expert can weigh in on this?  Anyways, the problem is solved for now.  Thanks for the help, consideration, and anymore feedback that may come.

[MelitaKennedy]

Thank you! I'm glad to hear that you've got it working.

I wanted to clear up the EPSG well-known IDs issues. WKIDs are unique within an object type. For instance, coordinate reference systems (projected, geographic, and vertical) will have unique WKIDs. Geodetic datums (used to make GeoCRS) can have overlapping WKIDs with CRS as can units of measure, coordinate operations (geographic/datum transformations and "projections"), ellipsoids, etc. So---

6318: NAD83 (2011): Geodetic CRS (2D)

4318: NGN: Geodetic CRS (2D)

6318: National Geodetic Network: Geodetic Datum

1116: NAD83 (NSRS 2011): Geodetic Datum

1116: Arc 1950 to WGS 84 (4): coordinate transformation

1116: Heard Island and McDonald Islands: area of use

4318: USA - Montana - Billings: area of use

My guess is that they've cross-connected 6318--maybe assuming it was the datum rather than the GeoCRS. 

Melita

[AndrewGiles]

You bring up an interesting point Melita, especially about cross connected definitions of units of measure.  Could Arc be getting some math wrong somewhere with the origin of latitude to make it exactly 1/3 degree of latitude off to the south?  Could the formula be off for radians to degrees?  I'm just taking wild guesses here.

See my most recent response to the original question for more information.