[gdal-dev] Problem with GDAL data folder in 1.9

Etienne Tourigny etourigny.dev at gmail.com
Tue Apr 10 17:00:09 EDT 2012


I suspect you get "expected" results if you force the crs like this:

gdal_translate -a_srs EPSG:26943 in.tif out.tif
gdalinfo out.tif

On Tue, Apr 10, 2012 at 5:41 PM, Ivan Lucena <ivan.lucena at pmldnet.com> wrote:
> Hi Etienne,
>
> OK, let's keep the focus on 1.9. I did what you said:
>
>>  Can you try using 'gdalsrsinfo EPSG:26943' with gdal 1.9 and
>>  associated data dir?
>
> And I got the same result from gdalsrsinfo as you did (using only 1.9) but I still getting a different result from gdalinfo with a image that clearly has that same EPSG code as we could see by the listgeo.
>
> Coordinate System is:
> PROJCS["NAD_1983_StatePlane_California_III_FIPS_0403",
>    GEOGCS["GCS_North_American_1983",
>        DATUM["North_American_Datum_1983",
>            SPHEROID["GRS_1980",6378137,298.257222101]],
>        PRIMEM["Greenwich",0],
>        UNIT["Degree",0.0174532925199432955]],
>    PROJECTION["Lambert_Conformal_Conic_2SP"],
>    PARAMETER["False_Easting",2000000],
>    PARAMETER["False_Northing",500000],
>    PARAMETER["Central_Meridian",-120.5],
>    PARAMETER["Standard_Parallel_1",37.06666666666667],
>    PARAMETER["Standard_Parallel_2",38.43333333333333],
>    PARAMETER["Latitude_Of_Origin",36.5],
>    UNIT["Meter",1]]
>
> PCS = 26943 (NAD83 / California zone 3)
> Projection = 10433 (SPCS83 California zone 3 (meters))
> Projection Method: CT_LambertConfConic_2SP
>   ProjFalseOriginLatGeoKey: 36.500000 ( 36d30' 0.00"N)
>   ProjFalseOriginLongGeoKey: -120.500000 (120d30' 0.00"W)
>   ProjStdParallel1GeoKey: 38.433333 ( 38d26' 0.00"N)
>   ProjStdParallel2GeoKey: 37.066667 ( 37d 4' 0.00"N)
>   ProjFalseEastingGeoKey: 2000000.000000 m
>   ProjFalseNorthingGeoKey: 500000.000000 m
> GCS: 4269/NAD83
> Datum: 6269/North American Datum 1983
> Ellipsoid: 7019/GRS 1980 (6378137.00,6356752.31)
> Prime Meridian: 8901/Greenwich (0.000000/  0d 0' 0.00"E)
> Projection Linear Units: 9001/metre (1.000000m)
>
> It seems to me that the GTIFF driver tries to interprets the WKT instead of just pass it on. Is that right? It doesn't seems to be doing it right.
>
> Thanks,
>
> Ivan
>
>
>
>


More information about the gdal-dev mailing list