[PATCH] EASE-Grid : libgeotiff cannot read EPSG proj method = 9834 (CT_CylindricalEqualArea) used by EPSG:3410

[etiennesky]

I am having trouble reprojecting data in the EASE-Grid Global Cylindrical Equal-Area Projection.

-> ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed.

The problem comes from a missing "PROJECTION" entry in the WKT after setting the CRS to EPSG:3410.

EASE-Grid Description: ​http://nsidc.org/data/ease/ease_grid.html . EPSG entry 3410 exists for this projection ​http://spatialreference.org/ref/epsg/3410/ ​http://nsidc.org/data/atlas/epsg_3410.html

Specifically, the data is AMSR-E Surface Soil Moisture. ​https://nsidc.org/data/docs/daac/ae_land3_l3_soil_moisture.gd.html Example file: ​ftp://n4ftl01u.ecs.nasa.gov//DP1/AMSA/AE_Land3.002/2010.08.29/AMSR_E_L3_DailyLand_V07_20100829.hdf.gz

The problem: setting the CRS with the command

gdal_translate -a_srs EPSG:3410 HDF4_EOS:EOS_GRID:"AMSR_E_L3_DailyLand_V07_20100829.hdf":Descending_Land_Grid:D_Soil_Moisture tmp2.tif

creates the following structure without projection information ( PROJECTIONCylindrical_Equal_Area), which is different from the "official" WKT

PROJCS["NSIDC EASE-Grid Global",
    GEOGCS["Unspecified datum based upon the International 1924 Authalic Sphere",
        DATUM["Not_specified_based_on_International_1924_Authalic_Sphere",
            SPHEROID["International 1924 Authalic Sphere",6371228,0,
                AUTHORITY["EPSG","7057"]],
            AUTHORITY["EPSG","6053"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4053"]],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AUTHORITY["EPSG","3410"]]

This renders geotransforms impossible:

gdalwarp -t_srs EPSG:4326 tmp2.tif test.tif 
ERROR 1: No PROJ.4 translation for source SRS, coordinate
transformation initialization has failed.

The following command generates the correct WKT (without using the EPSG code), similar to the EPSG definition:

gdal_translate -a_srs '+proj=cea +lon_0=0 +lat_ts=30 +x_0=0 +y_0=0 +a=6371228 +b=6371228 +units=m +no_defs' HDF4_EOS:EOS_GRID:"AMSR_E_L3_DailyLand_V07_20100829.hdf":Descending_Land_Grid:D_Soil_Moisture tmp3.tif

PROJCS["unnamed",
    GEOGCS["unnamed ellipse",
        DATUM["unknown",
            SPHEROID["unnamed",6371228,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Cylindrical_Equal_Area"],
    PARAMETER["standard_parallel_1",30],
    PARAMETER["central_meridian",0],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]

After which I can re-project to WGS84 geographic:

gdalwarp -tr 25067.525 25067.525 -t_srs '+proj=cea +lon_0=0 +lat_ts=30 +x_0=0 +y_0=0 +units=m +ellps=WGS84 +nodefs' tmp3.tif tmp33.tif
gdalwarp -t_srs EPSG:4326 tmp33.tif tmp34.tif

-> Why does GDAL not set the WKT to the correct value (with PROJECTION information) as defined by the EPSG code?

-> Same behavior with EASE-Grid Hemisphere Azimuthal Equal-Area Projections, with EPSG codes 3408 and 3409

[etiennesky]

subset of example file

[Even Rouault]

There are 2 issues :

• For the issue with EPSG:3408 and EPSG:3409, refer to ticket #3828 that contains a patch for both OGR SRS and libgeotiff.
• For the issue with EPSG:3410, I've attached to this ticket a patch for libgeotiff, that is a complementary with the fix already done in OGR SRS for #2659.

[etiennesky]

Great thanks!

The fix for EPSG:3410 works, and the error went away for EPSG:3408 and EPSG:3409, although haven't tested it thoroughly.

Can this be included in the next GDAL release (1.8.1)?

Also are modifications to (internal) libgeotiff contributed to the external library? I was using the external libtiff and libgeotiff libs, and had to switch to internal to apply this patch.

[Even Rouault]

The process is to apply the patch to (external) libgeotiff and then refresh the internal libgeotiff from it. However I'm not a libgeotiff committer and I'm not 100% sure they are correct, so you have to convince Frank Warmerdam to review them and commit if appropriate.

[warmerdam]

Even's patch looks reasonable to me. Applied upstream in libgeotiff (r 2002).

[etiennesky]

Thanks!

Could the fix in ticket #3828 be reviewed and commited to ogr and libgeotiff? It fixes the same issue with LAEA such as EPSG:3408 (which use projection method 1027) mentioned in this ticket.