Perhaps this is an issue with one of my original data sources, but I've searched extensively to address this problem both through ArcGIS and R.

I've got 2 separate sources of a county layer SourceA and SourceB.

I'm trying to project the SourceA layer so that it aligns with the SourceB layer.

The original SourceA layer is in NAD83, UTM zone 10 projection:

proj4string :[+proj=utm +zone=10 +datum=NAD83 +units=m +no_defs+ellps=GRS80+towgs84=0,0,0]

The SourceB layer is in NAD83, Albers, California.

proj4string : [+proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0 +y_0=-4000000 +datum=NAD83 +units=m +no_defs+ellps=GRS80 +towgs84=0,0,0]

I've tried to transform the county data using both R and ArcGIS, but am having problems.

When I try to project it in ArcMap, the program puts in a string of characters (see circled image below: WGS84 to NAD 83 + WGS84 to NAD83) in the geographic transformation section, which it shouldn't because they're both supposedly in NAD83... (right?), and it won't let me take that string off the chart with that little X button. If I run it anyways, as setup in the screenshot below, it throws an error "invalid extent for output coordinate system".

arcmap screenshot

When I use use spTransform in R to project the SourceA data to Albers California, it runs the transformation and results in a skewed county shape in comparison with the original SourceA shapefile (which is in UTM). I think this is to be expected (see screenshot below). But... that transformed layer won't align or even show up on the same map with the SourceB data that is also projected in NAD83, Albers California .

The SourceA layer after spTransform to Albers California reads the following proj4string:

proj4string :[+proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0+y_0=-4000000 +datum=NAD83 +units=m +no_defs+ellps=GRS80 +towgs84=0,0,0]

transformed SourceA data

Here's the R code using the spTransform command to transform the original SourceA data into NAD83 Albers, California resulting in the image above. Sourced from spatialreference.org:

county <- spTransform(county,CRS("+proj=aea +lat_1=34 +lat_2=40.5 +lat_0=0 +lon_0=-120 +x_0=0 +y_0=-4000000 +ellps=GRS80 +datum=NAD83 +units=m +no_defs"))

Three zipped shapefiles illustrating the problem can be downloaded off this dropbox link. 1) SourceA original projection, NAD83 UTM zone 10, 2) SourceA transformed to NAD83 Albers California through R's spTransform, and 3) SourceB in NAD83 Albers California.

Is there something wrong with the original SourceA or SourceB projection information? Any suggestions?

  • I was able to repeat this result using qgis. If I load SourceA then SourceA transformed into qgis, with a default CRS of WGS84 and transform on the fly, they overlap exactly. But if then set the CRS to UTM zone 10, I get the image shown here. If I set the CRS to California Albers, I get images that overlap exactly at the left (western) edge, but the original (UTM) layers is only 2/3 the width of the Albers layer. Now it gets really weird. If I zoom out, the original layer matches the transformed. If I zoom in, the missing fraction changes as I pan around. This is crazy.
    – Llaves
    Commented Sep 21, 2014 at 4:41
  • Since you have an answer to your ArcGIS Desktop question I think you should remove your R question so that it conforms to the "one question per question" of the Tour. If you still need an R answer you can always ask that part of the question in a new question.
    – PolyGeo
    Commented Oct 24, 2017 at 7:08

2 Answers 2


The problem is that the data was never in UTM to begin with, and so by having a UTM projection, the file was ultimately being told to be something it wasn't. (Such is life) :) Reprojecting it doesn't fix the problem, because the transformation math is based on coordinates that don't match the assigned projection.

To fix this I deleted the .prj file, and then changed the coordinate system of the dataframe to a few projections I thought might be close. Here in California we often use UTM or State Plane systems, and county governments often use the later. Modoc County is in State Plane Zone I. When I assigned the coordinate system State Plane Zone I Feet, the data (with the unassigned projection) snapped right into place, which is a good sign that that's its original projection. I then assigned the data the State Plane projection permanently. Now you can reproject it if you like and the math will be accurate.

  • Thanks for the help Sarah! I didn't actually have to delete the .prj file. The Define Projection tool in ArcMap appears to take care of that. Commented Sep 23, 2014 at 4:23

To figure out which file has a problematic projection and get additional clues about how to fix it, you can plot the maps on an ArcGIS basemap. This will get the shapefiles to appear on the same screen so you can see which is problematic. In this case you can quickly see that the SourceA file is plotted off in the Atlantic Ocean far from it's proper location in California, while the SourceB file lines up appropriately.

enter image description here

A second clue to find out how to assign the proper projection comes by seeing that the SourceA object appears far larger than the correctly positioned SourceB file, which suggests that it is not projected in meters projection, but probably in US feet instead, hence why it looks ~3x too large. Some of the StatePlane projected coordinate systems use feet and this is often used by counties, so it is a good projection to try.

You can run the Define Projection tool in ArcMap to the NAD 1983 (2011) StatePlane California I FIPS 0401 (US Feet) and it will move it to the proper place with perfect alignment.

If this hadn't worked, several colleagues told me that it can be a painful process to try out all possible predefined projection systems. Furthermore, you can potentially still end up without a solution if the file is corrupted, under a custom defined projection system, or somehow completely distorted in its coordinate system.

I haven't been able to fix this in R yet.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.