Opened 7 years ago

Closed 4 years ago

#6531 closed enhancement (wontfix)

Switching search order of datum.csv and gdal_datum.csv

Reported by: Kurt Schwehr Owned by: Kurt Schwehr
Priority: normal Milestone: closed_because_of_github_migration
Component: default Version: svn-trunk
Severity: normal Keywords:


For setups where GDAL_PREFIX is not defined, having the search for datum.csv before the search for gdal_datum.csv causes the system to look through all the options in cpl_csv.cpp... including /usr/local/share/epsg_csv/ For setups were gdal is only allowed to access white listed dirs/files (or it's killed), this means I'd have to add /usr/local/share/epsg_csv/ to the list even though it doesn't exist (I stash them in a per container location). Rather than remove /usr/local/share/epsg_csv/, switching the order lets the set GDAL_DATA path do the right thing and the process never stats this hard coded directory. I am proposing not to remove this directory at the moment as it's possible that some legacy setups might count on it and I just don't know enough.

Are there any setups where switching the order would break things?

In frmts/gtiff/gt_wkt_srs.cpp:

            pszFilename = CSVFilename( "datum.csv" );
            if( EQUAL(pszFilename,"datum.csv") )
                pszFilename = CSVFilename( "gdal_datum.csv" );


            pszFilename = CSVFilename( "gdal_datum.csv" );
            if( EQUAL(pszFilename,"gdal_datum.csv") )
                pszFilename = CSVFilename( "datum.csv" );

Change History (4)

comment:1 by Even Rouault, 7 years ago

It appears that datum.csv is a file in the CSV files distributed with libgeotiff. It has a structure very close to gdal_datum.csv, but without the final ESRI_DATUM_NAME column. I'm not sure of the use case of searching datum.csv in GDAL. Perhaps if the GDAL CSV files cannot be found but the libgeotiff ones are found ? Anyway it seems safe to me to switch the order of search between both files. And adding my comment in the code so we don't have to dig into this next time

comment:2 by Kurt Schwehr, 7 years ago

Fixed in r34309.

r18584 doesn't give much explanation for what is going on. datum.csv is only referred to in gt_wkt_srs.cpp within gdal. It's also in libgeotiff/geo_normalize.c

Example diff with egm96 and tweaks to make the header line closer. Caps and quotes for datum.csv from libgeotiff.

  • .csv

    old new  
    2 5171,EGM96 geoid,vertical,WGS 84 ellipsoid.,1996,,,1262,Geodesy.,,NASA,OGP,2004/04/27,,0
     25171,EGM96 geoid,vertical,WGS 84 ellipsoid.,1996,,,1262,Geodesy.,,"NASA",OGP,"2004/04/27",,0,

What was the use case for keeping the search for datum.csv in gdal?

comment:3 by Kurt Schwehr, 6 years ago

Related, this patch gives an option to restrict where libgeotiff/cpl_csv.c will look. Related to r34653 adding GDAL_NO_HARDCODED_FIND

  • cpl_csv.c

    diff --ignore-space-change -u a/cpl_csv.c b/cpl_csv.c
    old new  
    870870            sprintf( szPath, "%s/%s", CSV_DATA_DIR, pszBasename );
    871871        }
     874        else
     875        {
     876            sprintf( szPath, "%s", pszBasename );
     877        }
    873879        else if( (fp = fopen( "/usr/local/share/epsg/csv/pcs.csv", "rt" )) != NULL )
    874880        {
    875881            sprintf( szPath, "/usr/local/share/epsg/csv/%s", pszBasename );
    890896        {
    891897            sprintf( szPath, "/usr/local/share/epsg_csv/%s", pszBasename );
    892898        }
    893 #endif
     899#endif  /* GEOTIFF_NO_HARDCODED_FIND */
     900#endif  /* CSV_DATA_DIR */
    895902        if( fp != NULL )
    896903            fclose( fp );

comment:4 by Even Rouault, 4 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to if it is not already reported there.

Note: See TracTickets for help on using tickets.