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".
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]
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?
Best Answer
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.