problems with custom albers nad27 projection

[bolsen@…]

Having a problem with reprojection a shapefile in a custom albers27 projection.

Problem shows up trying to overlay a shapefile in this custom projection over
imagery in another custom projection.

Will attach test case files.

[bolsen@…]

custom albers nad27 esri prj file

[bolsen@…]

proj4 input parameters for custsom nad27 albers

[bolsen@…]

original shapefile custom albers nad27

[bolsen@…]

expected shapefile reproject result, nad27utm16

[warmerdam]

Brian,

I have test converted a single point using testepsg and I seem to get
a value different than the "utm27" file you supplied - a roughly 230m 
displacement in Y.  From "cs2cs" the command looks like this:

warmerda@gdal2200[89]% cs2cs +proj=aea +lat_1=29.5 +lat_2=45.5 +lat_0=23
+lon_0=-96 +x_0=0 +y_0=0 +ellps=clrk66 +units=m +no_defs +to +proj=utm +zone=16
+datum=NAD27
581715 1070148
239958.82       3602393.52 0.76

The corresponding location in your file was:
239958, 3602624

Very good X correspondence, but off in Y.  I've check, and the point is at
(89d46'7.214"W ,  32d31'56.089"N) (using PROJ.4 from the Albers location) 
which is reasonable for UTM 16 (central meridian at 87W) and no too far off
the albers central meridian at 96W.  It is also between the standard parallels
for the Albers projection, though it is a fair ways north of lat_0 at 23N.  

The problem in situations like this to convince ourselves that the difference
isn't just related to translation of projections parameters between different
packages.  

For now, I will post to the list to see if Gerald sees any reason that results
would be undependable for such a conversion.

PS (the albers translation seems to invert well)

[bolsen@…]

Umm...
this actually is a problem with GDAL's prj file parser.
I found out that the directive:

DATUM["D_North_American_1927",

must read

DATUM["North_American_DATUM_1927",

In this case proj4 is correctly passed "+datum=NAD27"

[warmerdam]

Doh!  Let me re-open and reclassify this as a GDAL problem. 

[warmerdam]

I have confirmed that the following produces the proper output:

ogr2ogr out ms_roads_alb27_clip.shp -t_srs '+proj=utm +zone=16 +datum=NAD27'

How were you doing the conversion? 

Keep in mind that ESRI WKT is different than OGC (or OGR) WKT so if you 
want to use one of their .prj files directly you need to prefix it with 
ESRI::, 

eg. 

ogr2ogr -s_srs ESRI::./ms_roads_alb27_clip.prj ...

This applies the various translations necessary, including remapping of
the projection names and datum names.  However, if you leave interpretation
of the .prj file up to the shapefile driver, it will do this automatically.

Closing for now since the software seems to work properly.  Please re-open if
you think there is something I should be changing in the code.