[Proj] Albers reprojection anomoly?

[Gerald I. Evenden]

It is difficult for me to comment on the PROJ.4 aspects of this problem
as the example
involves a datum shift and ancillary computations that are not part of
PROJ.4 as I
define it.  Thus blaming Albers projection seems specious at the moment.
Can someone
reduce the operation to its parts:

1. inverse of Albers to geographic
2. datum conversion
3. forward to UTM

I can comment on 1 and 3.

Thank-you.

On Wed, 2005-06-29 at 14:10 -0400, Frank Warmerdam wrote:

> Gerald, or others,
> 
> In bug report:
>   http://bugzilla.remotesensing.org/show_bug.cgi?id=877
> 
> a user reports that albers reprojection seems to not match what
> he expects.  Based on his test datasets, I get:
> 
> input (+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):
> 
>   581715E, 1070148N
> 
> output (+proj=utm +zone=16 +datum=NAD27):
>   239958E, 3602624N
> 
> output (expected for UTM 16 NAD27):
>   239958E, 3602624N
> 
> As you can see the PROJ.4 translation seems to match well in
> X but not in Y.  The user reports the expected information based
> on reprojection with Global Mapper and ArcGIS.  
> 
> Can anyone comment on whether these values are in a region 
> of reasonably validity for the UTM and Albers projection code?
> Can anyone provide external verification one way or the other for
> these albers to UTM conversions? 
> 
> Feel free to look into the bug report for details. 
> 
> Best regards,

-- 
_____________________________________________________________
Jerry and the Low Riders: Daisy Mae and Joshua
"The most certain test by which we judge whether a country is
really free is the amount of security enjoyed by minorities"
---Lord Acton, 1907 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20050705/c47fcdbd/attachment.html