Opened 10 years ago

Closed 3 years ago

#4512 closed defect (wontfix)

netcdf files with longitude between 180 and 360 degrees are incorrectly projected

Reported by: etourigny Owned by: etourigny
Priority: normal Milestone: closed_because_of_github_migration
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: netcdf, projection
Cc:

Description

Some netcdf files contain strictly positive values [0,360] which are not compatible with the way gdal/QGis treat longitude values - they do not wrap around the dateline. This also causes errors with gdalwarp and when combined with other datasets (with [-180,180] values), they are not aligned properly due to a 180 degree longitude shift.

Simple fix is to test for longitude variables (using CF metadata explained in CF sections 4.1 and 4.2) and convert any values in the [180,360] interval ti [-180,180] by subtracting 180 - in IReadBlock and also in SRS detection.

It would be better to address this in GDAL or PROJ, but this fix is much simpler and less involved.

Attachments (3)

tmp3.nc (199.7 KB) - added by etourigny 10 years ago.
file with longitude > 180 (modified from ticket #1894)
tmp4.nc (201.6 KB) - added by etourigny 10 years ago.
modified file with longitude in interval [-180,180]
reduce-cgcms.nc (24.3 KB) - added by etourigny 10 years ago.

Download all attachments as: .zip

Change History (10)

Changed 10 years ago by etourigny

Attachment: tmp3.nc added

file with longitude > 180 (modified from ticket #1894)

Changed 10 years ago by etourigny

Attachment: tmp4.nc added

modified file with longitude in interval [-180,180]

comment:1 Changed 10 years ago by etourigny

Resolution: fixed
Status: newclosed

Fixed in trunk (r23969) and in 1.9 (r23970), changes in netCDFRasterBand::CheckValidData?() and netCDFDataset::SetProjectionFromVar?() .

Can be overridden (in case of unwanted side-effects) with config option GDAL_NETCDF_CENTERLONG_180=0 .

To test the fix, use gdalinfo and/or qgis on the 2 files, they should both have same extents and perfect line-up in QGis.

comment:2 Changed 10 years ago by etourigny

Keywords: projection added; geolocation removed

comment:3 Changed 10 years ago by etourigny

Resolution: fixed
Status: closedreopened

fix is not good with global datasets or datasets that span the dateline, attaching a file of global span.

Changed 10 years ago by etourigny

Attachment: reduce-cgcms.nc added

comment:4 Changed 10 years ago by Even Rouault

Note: r23970 (1.9 branch commit) was reverted in r23973. It might be indeed good to avoid pushing such non trivial stuff in the stable branch.

comment:5 Changed 10 years ago by etourigny

Agreed - I was a bit fast on the commit there, sorry.

comment:6 Changed 10 years ago by etourigny

commited better fix in trunk (r23974). If minimum longitude value is > 180, then subtract 360 from all longitude values.

This fixes gdalwarp with GEOLOCATION when longitude values are > 180, the result is shifted . Also fixes small rasters which are east of the dateline and do not align will global data (which is usually in the [-180,180] interval).

comment:7 Changed 3 years ago by Even Rouault

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: reopenedclosed

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.

Note: See TracTickets for help on using tickets.