Ticket #877 (closed defect: fixed)

Opened 9 years ago

Last modified 9 years ago

problems with custom albers nad27 projection

Reported by: bolsen@… Owned by: warmerdam
Priority: high Milestone:
Component: OGR_SRS Version: unspecified
Severity: normal Keywords: GDAL
Cc:

Description

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.

Attachments

albers27.prj Download (505 bytes) - added by bolsen@… 9 years ago.
custom albers nad27 esri prj file
albers27.proj4 Download (101 bytes) - added by bolsen@… 9 years ago.
proj4 input parameters for custsom nad27 albers
nad27albers.zip Download (17.8 KB) - added by bolsen@… 9 years ago.
original shapefile custom albers nad27
nad27utm16.zip Download (18.1 KB) - added by bolsen@… 9 years ago.
expected shapefile reproject result, nad27utm16

Change History

Changed 9 years ago by bolsen@…

custom albers nad27 esri prj file

Changed 9 years ago by bolsen@…

proj4 input parameters for custsom nad27 albers

Changed 9 years ago by bolsen@…

original shapefile custom albers nad27

Changed 9 years ago by bolsen@…

expected shapefile reproject result, nad27utm16

Changed 9 years ago by 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)

Changed 9 years ago by 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"

Changed 9 years ago by warmerdam

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

Changed 9 years ago by 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.

Note: See TracTickets for help on using tickets.