Hi Frank, Yes, we can say that there is nothing wrong with the WKT, but the EPSG notation is quite important for me and that is missing. And yes, we could say that there is probably something wrong with the GTIFF driver. But - Don't let Ethiene knows that I did again ;) - I ran the 1.9 gdalinfo with the 1.8 GDAL_DATA folder and the problem diapers. The WKT is complete. Weird right?
Anyway, I will prepare a small sample of that file and attach it to a ticket. Thanks, Ivan > -------Original Message------- > From: Frank Warmerdam <[email protected]> > To: Ivan Lucena <[email protected]> > Cc: [email protected] <[email protected]> > Subject: Re: [gdal-dev] Problem with GDAL data folder in 1.9 > Sent: Apr 10 '12 15:05 > > Ivan, > > I don't see any *errors* in the new results. The order of the > standard parallels is arbitrary. But it is odd how different the > PCS name is and that the EPSG authority code is not preserved. > > I will note that gdalsrsinfo against 1.9 for EPSG:26943 reports: > > ... Ah Etienne already beat me to this. > > In any event, I think you would need to file a ticket and provide a > sample file demonstrating the issue for us to track through. It > could be something specific about the geotiff driver. > > Best regards, > > > > On Tue, Apr 10, 2012 at 12:50 PM, Ivan Lucena <[email protected]> > wrote: > > Hi There, > > > > I am getting some weird results from a simple geotiff file and it seems to > be a problem with the data folder. > > > > If I run gdalinfo using GDAL 1.9 or 1.8 with the data folder installed > from 1.8 the WKT comes with no EPSG Authority code: > > > > D:\> set GDAL_DATA=D:\GDAL-1.9\data > > D:\> gdalinfo sf1.gtif > > 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]] > > > > Even tough listgeo shows: > > > > 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) > > > > But if I use gdalinfo 1.8 or 1.9 with the data folder from 1.8 the WKT > appears to be better. > > > > D:\> set GDAL_DATA=D:\GDAL-1.8\data > > D:\> gdalinfo sf1.gtif > > PROJCS["NAD83 / California zone 3", > > GEOGCS["NAD83", > > DATUM["North_American_Datum_1983", > > SPHEROID["GRS 1980",6378137,298.2572221010002, > > AUTHORITY["EPSG","7019"]], > > AUTHORITY["EPSG","6269"]], > > PRIMEM["Greenwich",0], > > UNIT["degree",0.0174532925199433], > > AUTHORITY["EPSG","4269"]], > > PROJECTION["Lambert_Conformal_Conic_2SP"], > > PARAMETER["standard_parallel_1",38.43333333333333], > > PARAMETER["standard_parallel_2",37.06666666666667], > > PARAMETER["latitude_of_origin",36.5], > > PARAMETER["central_meridian",-120.5], > > PARAMETER["false_easting",2000000], > > PARAMETER["false_northing",500000], > > UNIT["metre",1, > > AUTHORITY["EPSG","9001"]], > > AUTHORITY["EPSG","26943"]] > > > > The authority code are correct and standard_parallel_1, > standard_parallel_2 are identical to listgeo information. > > > > I got this files from the SVN branch 1.8 and 1.9 and I compiled and > install it myself but I also tried that same steps with the OSGeo4W > environment and got the same results. > > > > Does it means that there is something wrong with the data folder in 1.9 or > is that part of a new approach of dealing with that particular kind of > projection? > > > > Regards, > > > > Ivan > > > > > > > > _______________________________________________ > > gdal-dev mailing list > > [email protected] > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > > -- > > ---------------------------------------+-------------------------------------- > I set the clouds in motion - turn up | Frank Warmerdam, [email protected] > light and sound - activate the windows | http://pobox.com/~warmerdam > and watch the world go round - Rush | Geospatial Software Developer > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
