[gdal-dev] NetCDF data upside down when read by gdal
Roger André
randre at gmail.com
Wed Feb 18 15:45:16 EST 2009
Hi All,
- I am attempting to use a NetCDF file as a data source for a raster layer
in Mapserver. According to a very useful email sent in November 2005 from
Norman Barker,
http://lists.osgeo.org/pipermail/mapserver-users/2005-November/012153.html,
and from Mapserver documentation at
http://www.mapserver.org/ogc/wcs_format.html#netcdf, it seems like this
should be possible using Mapserver's gdal driver to read the file. However,
I am running into some problems when trying to implement these examples
using GDAL 1.5.2, released 2008/05/29.
- The NetCDF file which I am using to test with is a "CF Convention" sample
file which I downloaded from
http://www.unidata.ucar.edu/software/netcdf/examples/tos_O1_2001-2002.nc.
This file contains information about sea-surface temperatures, and when
viewed by gdalinfo has the following characteristics:
$ gdalinfo tos_O1_2001-2002.nc
Driver: netCDF/Network Common Data Format
Files: tos_O1_2001-2002.nc
Size is 512, 512
Coordinate System is `'
Metadata:
NC_GLOBAL#title=IPSL model output prepared for IPCC Fourth Assessment
SRES A2 experiment
NC_GLOBAL#institution=IPSL (Institut Pierre Simon Laplace, Paris, France)
NC_GLOBAL#source=IPSL-CM4_v1 (2003) : atmosphere : LMDZ (IPSL-CM4_IPCC,
96x71x19) ; ocean ORCA2 (ipsl_cm4_v1_8, 2x2L31); sea ice LIM (ipsl_cm4_v
NC_GLOBAL#contact=Sebastien Denvil, sebastien.denvil at ipsl.jussieu.fr
NC_GLOBAL#project_id=IPCC Fourth Assessment
NC_GLOBAL#table_id=Table O1 (13 November 2004)
NC_GLOBAL#experiment_id=SRES A2 experiment
NC_GLOBAL#realization=1
NC_GLOBAL#cmor_version=9.600000e-01
NC_GLOBAL#Conventions=CF-1.0
NC_GLOBAL#history=YYYY/MM/JJ: data generated; YYYY/MM/JJ+1 data
transformed At 16:37:23 on 01/11/2005, CMOR rewrote data to comply with CF
standards and IPCC Fourth Assessment requirements
NC_GLOBAL#references=Dufresne et al, Journal of Climate, 2015, vol XX, p
136
NC_GLOBAL#comment=Test drive
Subdatasets:
SUBDATASET_1_NAME=NETCDF:"tos_O1_2001-2002.nc":lon_bnds
SUBDATASET_1_DESC=[180x2] lon_bnds (64-bit floating-point)
SUBDATASET_2_NAME=NETCDF:"tos_O1_2001-2002.nc":lat_bnds
SUBDATASET_2_DESC=[170x2] lat_bnds (64-bit floating-point)
SUBDATASET_3_NAME=NETCDF:"tos_O1_2001-2002.nc":time_bnds
SUBDATASET_3_DESC=[24x2] time_bnds (64-bit floating-point)
SUBDATASET_4_NAME=NETCDF:"tos_O1_2001-2002.nc":tos
SUBDATASET_4_DESC=[24x170x180] sea_surface_temperature (32-bit
floating-point)
Corner Coordinates:
Upper Left ( 0.0, 0.0)
Lower Left ( 0.0, 512.0)
Upper Right ( 512.0, 0.0)
Lower Right ( 512.0, 512.0)
Center ( 256.0, 256.0)
- The SUBDATASET of interest is the "tos" one, and when queried by gdalinfo
it shows that it contains 24 bands, each of which varies by
NETCDF_DIMENSION_time that increments by 15. When specifically queried by
gdalinfo, this SUBDATASET looks like this:
$ gdalinfo NETCDF:"tos_O1_2001-2002.nc":tos
Driver: netCDF/Network Common Data Format
Files: none associated
Size is 180, 170
Coordinate System is `'
Origin = (0.000000000000000,90.000000000000000)
Pixel Size = (2.000000000000000,-1.000000000000000)
Metadata:
NC_GLOBAL#title=IPSL model output prepared for IPCC Fourth Assessment
SRES A2 experiment
NC_GLOBAL#institution=IPSL (Institut Pierre Simon Laplace, Paris, France)
NC_GLOBAL#source=IPSL-CM4_v1 (2003) : atmosphere : LMDZ (IPSL-CM4_IPCC,
96x71x19) ; ocean ORCA2 (ipsl_cm4_v1_8, 2x2L31); sea ice LIM (ipsl_cm4_v
NC_GLOBAL#contact=Sebastien Denvil, sebastien.denvil at ipsl.jussieu.fr
NC_GLOBAL#project_id=IPCC Fourth Assessment
NC_GLOBAL#table_id=Table O1 (13 November 2004)
NC_GLOBAL#experiment_id=SRES A2 experiment
NC_GLOBAL#realization=1
NC_GLOBAL#cmor_version=9.600000e-01
NC_GLOBAL#Conventions=CF-1.0
NC_GLOBAL#history=YYYY/MM/JJ: data generated; YYYY/MM/JJ+1 data
transformed At 16:37:23 on 01/11/2005, CMOR rewrote data to comply with CF
standards and IPCC Fourth Assessment requirements
NC_GLOBAL#references=Dufresne et al, Journal of Climate, 2015, vol XX, p
136
NC_GLOBAL#comment=Test drive
tos#standard_name=sea_surface_temperature
tos#long_name=Sea Surface Temperature
tos#units=K
tos#cell_methods=time: mean (interval: 30 minutes)
tos#_FillValue=1.000000e+20
tos#missing_value=1.000000e+20
tos#original_name=sosstsst
tos#original_units=degC
tos#history= At 16:37:23 on 01/11/2005: CMOR altered the data in the
following ways: added 2.73150E+02 to yield output units; Cyclical dimension
was output starting at a different lon;
lon#standard_name=longitude
lon#long_name=longitude
lon#units=degrees_east
lon#axis=X
lon#bounds=lon_bnds
lon#original_units=degrees_east
lat#standard_name=latitude
lat#long_name=latitude
lat#units=degrees_north
lat#axis=Y
lat#bounds=lat_bnds
lat#original_units=degrees_north
time#standard_name=time
time#long_name=time
time#units=days since 2001-1-1
time#axis=T
time#calendar=360_day
time#bounds=time_bnds
time#original_units=seconds since 2001-1-1
Corner Coordinates:
Upper Left ( 0.0000000, 90.0000000)
Lower Left ( 0.0000000, -80.0000000)
Upper Right ( 360.000, 90.000)
Lower Right ( 360.000, -80.000)
Center ( 180.0000000, 5.0000000)
Band 1 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=15
NETCDF_time_units=days since 2001-1-1
Band 2 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=45
NETCDF_time_units=days since 2001-1-1
Band 3 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=75
NETCDF_time_units=days since 2001-1-1
Band 4 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=105
NETCDF_time_units=days since 2001-1-1
Band 5 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=135
NETCDF_time_units=days since 2001-1-1
Band 6 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=165
NETCDF_time_units=days since 2001-1-1
Band 7 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=195
NETCDF_time_units=days since 2001-1-1
Band 8 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=225
NETCDF_time_units=days since 2001-1-1
Band 9 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=255
NETCDF_time_units=days since 2001-1-1
Band 10 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=285
NETCDF_time_units=days since 2001-1-1
Band 11 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=315
NETCDF_time_units=days since 2001-1-1
Band 12 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=345
NETCDF_time_units=days since 2001-1-1
Band 13 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=375
NETCDF_time_units=days since 2001-1-1
Band 14 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=405
NETCDF_time_units=days since 2001-1-1
Band 15 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=435
NETCDF_time_units=days since 2001-1-1
Band 16 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=465
NETCDF_time_units=days since 2001-1-1
Band 17 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=495
NETCDF_time_units=days since 2001-1-1
Band 18 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=525
NETCDF_time_units=days since 2001-1-1
Band 19 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=555
NETCDF_time_units=days since 2001-1-1
Band 20 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=585
NETCDF_time_units=days since 2001-1-1
Band 21 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=615
NETCDF_time_units=days since 2001-1-1
Band 22 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=645
NETCDF_time_units=days since 2001-1-1
Band 23 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=675
NETCDF_time_units=days since 2001-1-1
Band 24 Block=180x1 Type=Float32, ColorInterp=Undefined
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=705
NETCDF_time_units=days since 2001-1-1
- I am able to test that I can extract one of these bands with GDAL, and
convert it to GeoTIFF with the following command:
gdal_translate -b 1 NETCDF:"tos_O1_2001-2002.nc":tos sea_temp_band_1.tif.
Here however is where the first problem appears. As you can see from the
screenshot of the sea_temp_band_1.tif that I've posted at
http://2.bp.blogspot.com/_-yICqdt0mtY/SZxtI4yUHdI/AAAAAAAAA-I/z7W_O6qBXho/s1600-h/upside_down_netcdf.jpg,
the data in the file appears to be represented upside down. Since this file
is a sample from the Unidata web site, I'm reasonably confident that the
file follows the CF convention. Every NetCDF file I have tried to read with
GDAL has had this problem, including ones that I have created with
gdal_translate. As you can see from the gdalinfo output above, the
georeferencing and pixel dimensions seem to be reasonable. In the past I
have used flip_raster.py to "fix" this, and created an intermediary
GeoTIFF. Now that I would like to use the NetCDF itself as the data source
to feed a WCS service, this is no longer an acceptable solution. Of
interest though, is that the georeferencing info between the flipped and
unflipped files are exactly the same. See below:
- Flipped file:
---------------
$ gdalinfo flipped_sea_temp_band_1.tif
Driver: GTiff/GeoTIFF
Files: flipped_sea_temp_band_1.tif
Size is 180, 170
Coordinate System is `'
Origin = (0.000000000000000,90.000000000000000)
Pixel Size = (2.000000000000000,-1.000000000000000)
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 0.0000000, 90.0000000)
Lower Left ( 0.0000000, -80.0000000)
Upper Right ( 360.000, 90.000)
Lower Right ( 360.000, -80.000)
Center ( 180.0000000, 5.0000000)
Band 1 Block=180x11 Type=Float32, ColorInterp=Gray
- Unflipped file:
-----------------
$ gdalinfo sea_temp_band_1.tif
Driver: GTiff/GeoTIFF
Files: sea_temp_band_1.tif
Size is 180, 170
Coordinate System is `'
Origin = (0.000000000000000,90.000000000000000)
Pixel Size = (2.000000000000000,-1.000000000000000)
<snip> (Metadata removed for clarity)
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 0.0000000, 90.0000000)
Lower Left ( 0.0000000, -80.0000000)
Upper Right ( 360.000, 90.000)
Lower Right ( 360.000, -80.000)
Center ( 180.0000000, 5.0000000)
Band 1 Block=180x11 Type=Float32, ColorInterp=Gray
NoData Value=1.00000002004087734e+20
Metadata:
NETCDF_VARNAME=tos
NETCDF_DIMENSION_time=15
NETCDF_time_units=days since 2001-1-1
- I'm unsure if this is a bug in GDAL, or an incorrectly formatted NetCDF
file. So, would it be possible for someone who has a NetCDF file that is
read "right-side-up" to post it as a sample for me to test with?
Thanks in advance,
Roger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20090218/f8ef8bec/attachment-0001.html
More information about the gdal-dev
mailing list