Opened 2 years ago

Last modified 2 years ago

#6531 new enhancement

Switching search order of datum.csv and gdal_datum.csv

Reported by: Kurt Schwehr Owned by: Kurt Schwehr
Priority: normal Milestone:
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 (3)

comment:1 Changed 2 years ago by Even Rouault

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 Changed 2 years ago by Kurt Schwehr

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 Changed 2 years ago by Kurt Schwehr

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 );
Note: See TracTickets for help on using tickets.