etiennesky / gdal-netcdf Goto Github PK

Just testing and found a back-compatibility issue with current GDAL 1.8.1 code:

(1) exported files using new GDAL NetCDF driver developed here (eg as done during the netcdf_cf tests)
(2) Try to do a gdalinfo on them with gdal 1.8.1, and the GeoTransform isn't detected correctly:

pds@pds-mbp-laptop:~/GIS_Projects/GDAL-NetCDF-Testing/gdal_trans_testing_all_cf1_weld/savedResults/Melb_USGS/refactored_gdal_gtiff$ /usr/local/gdal_1.8.1/bin/gdalinfo melb-small_AEA.nc
Driver: netCDF/Network Common Data Format
Files: melb-small_AEA.nc
Size is 199, 101
Coordinate System is:
PROJCS["GDA94 / Australian Albers",
    GEOGCS["GDA94",
        DATUM["Geocentric_Datum_of_Australia_1994",
            SPHEROID["GRS 1980",6378137,298.2572221010042,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6283"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4283"]],
    PROJECTION["Albers_Conic_Equal_Area"],
    PARAMETER["standard_parallel_1",-18],
    PARAMETER["standard_parallel_2",-36],
    PARAMETER["latitude_of_center",0],
    PARAMETER["longitude_of_center",132],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","3577"]]
Origin = (0.000000000000000,0.000000000000000)
Pixel Size = (-0.000000000000000,0.000000000000000)

Where origin and pixel size should be:
Origin = (1232736.866607666946948,-4118493.958211950026453)
Pixel Size = (30.080459243366306,-30.080459243366494)

Reason why this is happening:

The logic in the old 1.8.1 code inside SetProjection() has a flaw: it first (correctly) reads the GeoTransform from X and Y coordinate variables, but then if the GDAL-added OGC WKT string is added, first looks for 'GeoTransform' string to override the above, and then the 4 corner attributes. And even if the last of these isn't found, it goes ahead and sets blank values.

So I guess there are 2 options:
(1) Update the new code to deal with the issue: and write the "GeoTransform" string whenever WRITE_GDAL_TAGS is enabled;
(2) Publish the back-compat issue, and update the 1.8 driver.

I know it's not ideal, but I slightly favour the former .... to reduce compatibility problems for installed userbase of people using gdal 1.8 and who will want to be able to process files written with the new driver.