#4068 closed defect (fixed)
[PATCH] EASE-Grid : libgeotiff cannot read EPSG proj method = 9834 (CT_CylindricalEqualArea) used by EPSG:3410
Reported by: | etiennesky | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OGR_SRS | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
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
Attachments (2)
Change History (7)
by , 13 years ago
Attachment: | tmp1.tif.gz added |
---|
comment:1 by , 13 years ago
Summary: | EASE-Grid : gdal does not properly set WKT from EPSG codes → [PATCH] EASE-Grid : libgeotiff cannot read EPSG proj method = 9834 (CT_CylindricalEqualArea) used by EPSG:3410 |
---|
by , 13 years ago
Attachment: | libgeotiff_read_epsg_method_9834_CEA.patch added |
---|
comment:2 by , 13 years ago
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.
comment:3 by , 13 years ago
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.
comment:4 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Even's patch looks reasonable to me. Applied upstream in libgeotiff (r 2002).
comment:5 by , 13 years ago
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.
subset of example file