ArcGIS Desktop 10.4 Coordinate System Issues

[ErikNelson]

I just updated to 10.4 and seem to be having some issues with Coordinate systems.  Specifically a county coordinate in Wisconsin.  In 10.3.1, all of my layers show up in the same place, in 10.4 my county coords will not work and my shapefile and imagery displays in different parts of the open document.  I uninstalled 10.4 and in reinstalled 10.3.1 and everything works perfect again.  Anyone else having any odd issues with 10.4?

[DanPatterson_Retired]

You did forward this on to the 10.4 beta people?  The help files are now updated to include 10.4 references, so you may be able to check for the differences/issues there. So far, I don't see any groups formed as of yet

[ErikNelson]

I haven't forwarded this on to anyone.  I am pretty sure the download I installed was a final release.  I will just use 10.3.1 for the time being as I know it works.

[DanPatterson_Retired]

Erik... here is the what's new link for 10.4  You can switch to other versions on the drop down. 

What's new in ArcMap—ArcGIS Help | ArcGIS for Desktop

[MelitaKennedy]

Erik,

Okay, I have a bunch of questions, which should help narrow down what's happening.

Are you using WISCRS? Or the older county system? Which county? And does it use transverse Mercator or Lambert conformal conic?

Can you determine whether it's the raster or the vector data that isn't working correctly? I suspect the raster. There was a lot of work down to our branch of GDAL (which handles raster coordinate systems).

If you look at the coordinate system definitions of both data layers, are there any differences?

Thanks,

Melita

[ErikNelson]

Melita,

I am in fact using WISCRS, its for Pierce County, WI.  It is Lambert Conformal Conic as well.  All of my Raster data is in UTM, the only thing I am using in the county coords is a tiling scheme I am working on, so I am assuming its the vector data that isn't working properly.  10.3.1 displays everything perfectly, but 10.4 would not.

Thanks,

Erik

[MelitaKennedy · Accepted solution]

What I'm seeing is that the definition for Pierce county in the projection engine (a low-level library) shows 1 standard parallel, scale factor, and latitude of origin in the definition. In ArcMap, it's displaying 2 standard parallels (2 is equal to 1), so that shouldn't be causing a problem. That is, the definition without an explicit standard parallel 2 should be mathematically equivalent in the software to the one with an explicit standard parallel 2.

Setting aside the tiling scheme, do the raster and vector layers overlay in ArcMap? If they're overlaying fine there, but not once tiled/published to a service, that changes the area of software that needs to be looked at.

Any chance you could send me a small version of the vector data so I can test it here? If so, mkennedy at esri dot com. Or I have to recommend that you call technical support to get it officially into the system, and so that someone else who might call in can be linked to the same bug.

Thanks,

Melita

[ErikNelson]

Just sent you an email with the data.  Thanks Melita!

[MelitaKennedy]

This is an FYI (for your information) for others.

The data had a non-Esri coordinate system definition in its prj file. One was that the projection name was "Lambert_conformal_conic_2SP" but we interpret that okay. There was also an "EXTENSION" keyword which contained the PROJ4 definition. We ignore that too. Something about that was messing up our reading of the AUTHORITY keyword, but that wouldn't/shouldn't affect interpretation of the rest of the definition.

I'm most suspicious of the linear UNIT keyword which had the correct mathematical definition of a US survey foot, but the name differed and ArcGIS was treating it as a custom unit. Because the data was going to be used in a tiling scheme, there might be some hiccup there. I'm still looking into it.

I suggested to Erik that if he wanted to try 10.4 again, to redefine the data with the Esri coordinate system. He reported that did clear up the offset he was seeing.

Thanks for checking that, Erik!