Switching search order of datum.csv and gdal_datum.csv

[Kurt Schwehr]

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" );

to

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

[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

[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

@@ -1 @@
-"DATUM_CODE","DATUM_NAME","DATUM_TYPE","ORIGIN_DESCRIPTION","REALIZATION_EPOCH","ELLIPSOID_CODE","PRIME_MERIDIAN_CODE","AREA_OF_USE_CODE","DATUM_SCOPE","REMARKS","INFORMATION_SOURCE","DATA_SOURCE","REVISION_DATE","CHANGE_ID","DEPRECATED"
-5171,EGM96 geoid,vertical,WGS 84 ellipsoid.,1996,,,1262,Geodesy.,,NASA http://cddis.gsfc.nasa.gov/926/egm96/egm96.html,OGP,2004/04/27,,0
+"DATUM_CODE","DATUM_NAME","DATUM_TYPE","ORIGIN_DESCRIPTION","REALIZATION_EPOCH","ELLIPSOID_CODE","PRIME_MERIDIAN_CODE","AREA_OF_USE_CODE","DATUM_SCOPE","REMARKS","INFORMATION_SOURCE","DATA_SOURCE","REVISION_DATE","CHANGE_ID","DEPRECATED","ESRI_DATUM_NAME"
+5171,EGM96 geoid,vertical,WGS 84 ellipsoid.,1996,,,1262,Geodesy.,,"NASA http://cddis.gsfc.nasa.gov/926/egm96/egm96.html",OGP,"2004/04/27",,0,

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

[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

@@ -870 +870 @@
             sprintf( szPath, "%s/%s", CSV_DATA_DIR, pszBasename );
         }
 #else
+#ifdef GEOTIFF_NO_HARDCODED_FIND
+        else
+        {
+            sprintf( szPath, "%s", pszBasename );
+        }
+#else
         else if( (fp = fopen( "/usr/local/share/epsg/csv/pcs.csv", "rt" )) != NULL )
         {
             sprintf( szPath, "/usr/local/share/epsg/csv/%s", pszBasename );
@@ -890 +896 @@
         {
             sprintf( szPath, "/usr/local/share/epsg_csv/%s", pszBasename );
         }
-#endif
+#endif  /* GEOTIFF_NO_HARDCODED_FIND */
+#endif  /* CSV_DATA_DIR */
 
         if( fp != NULL )
             fclose( fp );

[Even Rouault]

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 ​https://github.com/OSGeo/gdal/issues if it is not already reported there.