UTM zone 10N is not recognized from the tif file

[mkulvietis@…]

Hello Frank,

   we are having problems with the projection information in the .tif file. 
If I use FW tools 1.05
to check the tif file I see PROJCS["WGS 84 / UTM zone 10N"]..., however using GDAL 1.32v, GDALGetProjectionRef function returns 
PROJCS["unnamed" ....

What I discovered is this piece of code in frmts\gtiff\gt_wkt_srs.cpp:

..........
        if( psDefn->PCS != KvUserDefined )
        {

            if( GTIFGetPCSInfo( psDefn->PCS, &pszPCSName, NULL, NULL, NULL ) )
                bNeedFree = TRUE;
            
            oSRS.SetNode( "PROJCS", pszPCSName );
            if( bNeedFree )
                GTIFFreeMemory( pszPCSName );

            oSRS.SetAuthority( "PROJCS", "EPSG", psDefn->PCS );
        }
.........

Here, psDefn->PCS = 32610, but it is not giving the correct PROJCS name, because function GTIFGetPCSInfo tries to open non-existing pcs.csv file... However! there is include file epsg_pcs.inc, which contains code numbers for psDefn->PCS and it has correct definition:
           ValuePair(PCS_WGS84_UTM_zone_10N,	32610)

My question would be why GDAL doesn't use these correct code numbers to return the PROJCS string?

[warmerdam]

Martynas, 

The pcs.csv file is part of the GDAL distribution.  It is found in gdal/data
within the source tree and somewhere in the FWTools tree (I don't have a win32
system handy).  When using FWTools you are expected to use it through the
FWTools Shell.  The FWTools Shell sets a number of environment variables 
including the GDAL_DATA environment variable which should be used to find
the pcs.csv file. 

Are you using gdalinfo from the FWTools Shell?  If you use it from a another
commandline environment or if you call the FWTools DLLs without setting up 
the environment/config options properly you will run into problems like this.

PS. GDAL does not attempt to use the string representations associated with
PCS codes that come from the .inc files.  Mostly that is because they are 
now a decade out of date.  

Best regards,

[mkulvietis@…]

thanks, I didn't know about GDAL_DATA variable, it really solved the problem:
  CPLSetConfigOption("GDAL_DATA", gdal_data_path);