[Gdal-dev] gdalwarp UTM->SPCS

[Frank Warmerdam]

Richard Greenwood wrote:
>> I get the following (obviously I made a poor choice of input position):
>>
>> (100000.000000,2500000.000000) -> (-822713.552290,-6399889.409433)
> 
> 
> Again, I am getting the same results as you are.
> 
> 
> Testing a more representitive point:
> (510000.000000,4885764.000000) -> (592126.581651,1421987.333814)
> whereas the correct result should be approximately:
> 2416793.28   1650070.67
> derived from my rather clumsy use of proj as follows:
> 
> C:\cygwin\home\Rich\gdal\ogr>proj -I  +proj=utm +ellps=GRS80 +zone=12 
> +north +datum=NAD83 +units=m
> 510000.000000 4885764.000000
> 110d52'30.031"W 44d7'29.998"N
> 
> C:\cygwin\home\Rich\gdal\ogr>proj +proj=tmerc +lat_0=40.5 
> +lon_0=-110.0833333333 +k=0.999938 +x_0=800000 +y_0=100000 +ellps=GRS80 
> +datum=NAD83 +to_meter=0.3048006096012192
> 110d52'30.031"W 44d7'29.998"N
> 2416793.28      1650070.67

Richard,

I have tracked down this to a real bug in the importFromProj4() method.
When PROJ.4 strings are converted into WKT format internally by gdalwarp
(or testepsg) the false easting and northing were being copied directly.
The false easting and northing of PROJ.4 strings is always in meters
regardless of the units of the projected coordinate system.  In WKT the
situation is the opposite.  The false easting and northing are always
in the units of the projected coordinate system.  The translation code in
OGR that goes the one way was not translating, but going the other way
(WKT->PROJ.4) it was.

I have committed a fix for this problem.

I would encourage you to update from CVS, or pick up tomorrows nightly
snapshot and try again.

Best regards,

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | Geospatial Programmer for Rent