NetCDF file lacks georeferencing

[warmerdam]

The attached netcdf file does not have any georeferencing reported, though it does have lat, and lon arrays. It seems like the lat and lon values are irregular, so it likely couldn't be represented using a geotransform, but perhaps it should be represented as having geolocation arrays (see RFC 4)?

dimensions:
        xdim = 300 ;
        ydim = 200 ;
variables:
        float lon(xdim) ;
                lon:long_name = "longitude" ;
                lon:units = "degrees" ;
                lon:scale_factor = 1.f ;
        float lat(ydim) ;
                lat:long_name = "latitude" ;
                lat:units = "degrees" ;
                lat:scale_factor = 1.f ;
        float ssha(ydim, xdim) ;
                ssha:long_name = "Gridded SSH anomaly in GoM" ;
                ssha:units = "centimeters" ;
                ssha:scale_factor = 0.1f ;

I wonder if the proposed netcdf improvements in #1808 would help?

Filed on behalf of ACT (a project sponsor).

[warmerdam]

Problem NetCDF file

[Kyle Shannon]

When gdalinfo is run on this file, it reports only 1 band. the lat/lon bands are not read in as bands. I am familiarizing myself with the driver more and more, but it appears that I would have to populate two bands for lat/lon in order to use the geolocation array metadata. If that is the case, should the lat/lon bands always be imported as bands? I am a little confused.

[etourigny]

The file has the following structure which is not standard

$ ncdump -h c001.dt_ssha.nc  
netcdf c001.dt_ssha {
dimensions:
	xdim = 300 ;
	ydim = 200 ;
variables:
	float lon(xdim) ;
		lon:long_name = "longitude" ;
		lon:units = "degrees" ;
		lon:scale_factor = 1.f ;
	float lat(ydim) ;
		lat:long_name = "latitude" ;
		lat:units = "degrees" ;
		lat:scale_factor = 1.f ;
	float ssha(ydim, xdim) ;
		ssha:long_name = "Gridded SSH anomaly in GoM" ;
		ssha:units = "centimeters" ;
		ssha:scale_factor = 0.1f ;

// global attributes:
		:creation_date = "Thu Mar 29 12:48:26 2007" ;
		:title = "Map of NRT-SSHA in GoM from Jason-1" ;
}

$ cdo sinfo c001.dt_ssha.nc 
   File format: netCDF
    -1 : Institut Source   Param       Time Typ  Grid Size Num  Levels Num
     1 : unknown  unknown  -1          con  F32       300   1       1   1
     2 : unknown  unknown  -2          con  F32       200   2       1   1
     3 : unknown  unknown  -3          con  F32     60000   3       1   1
   Horizontal grids :
     1 : generic      > size      : dim = 300
     2 : generic      > size      : dim = 200
     3 : generic      > size      : dim = 60000  nx = 300  ny = 200
   Vertical grids :
     1 : surface                  : 0 
cdo sinfo: Processed 3 variables. ( 0.00s )

Other software such as cdo and ncview are also unable to correctly identify this data, therefore we cannot support this particular format.

The file can be fixed with the "ncrename" utility from "NCO" like:

ncrename -d xdim,lon tmp1.nc
ncrename -d ydim,lat tmp1.nc

The resulting is standard and is supported by ncview and cdo:

$ ncdump -h tmp1.nc
netcdf tmp1 {
dimensions:
	lon = 300 ;
	lat = 200 ;
variables:
	float lon(lon) ;
		lon:long_name = "longitude" ;
		lon:units = "degrees" ;
		lon:scale_factor = 1.f ;
	float lat(lat) ;
		lat:long_name = "latitude" ;
		lat:units = "degrees" ;
		lat:scale_factor = 1.f ;
	float ssha(lat, lon) ;
		ssha:long_name = "Gridded SSH anomaly in GoM" ;
		ssha:units = "centimeters" ;
		ssha:scale_factor = 0.1f ;

// global attributes:
		:creation_date = "Thu Mar 29 12:48:26 2007" ;
		:title = "Map of NRT-SSHA in GoM from Jason-1" ;
		:history = "Sun Dec  4 03:58:32 2011: ncrename -d ydim,lat tmp1.nc\n",
			"Sun Dec  4 03:58:28 2011: ncrename -d xdim,lon tmp1.nc" ;
}
$ cdo sinfo tmp1.nc
   File format: netCDF
    -1 : Institut Source   Param       Time Typ  Grid Size Num  Levels Num
     1 : unknown  unknown  -1          con  F32     60000   1       1   1
   Horizontal grids :
     1 : lonlat       > size      : dim = 60000  nlon = 300  nlat = 200
                        lon       : first = 262.5  last = 278.5  degrees
                        lat       : first = 18.5  last = 30.5  degrees
   Vertical grids :
     1 : surface                  : 0 
cdo sinfo: Processed 1 variable. ( 0.00s )

However, the grid structure is unevenly-spaced, which is not supported by the driver:

$ gdalinfo --debug on tmp1.nc
GDAL_netCDF: 
=====
calling nc_open( tmp1.nc )

GDAL_netCDF: driver detected file type=1, libnetcdf detected type=1
GDAL_netCDF: dim_count = 2
Warning 1: No UNIDATA NC_GLOBAL:Conventions attribute
GDAL_netCDF: var_count = 3
GDAL_netCDF: 
=====
SetProjectionFromVar( 2 )

GDAL_netCDF: bIsGdalFile=0 bIsGdalCfFile=0 bBottomUp=1
GDAL_netCDF: set bBottomUp = 1 from Y axis
GDAL_netCDF: Longitude is not equally spaced.
GDAL_netCDF: bGotGeogCS=0 bGotCfSRS=0 bGotGeoTransform=1
GDAL_netCDF: SetGeoTransform(0.000000,1.000000,0.000000,0.000000,0.000000,1.000000)
...

This issue has been added to netcdf improvements page (section Dimension/grid issue).

[etourigny]

I have looked further into this file, and the main problem is that it has repeating lon/lat values on the edges (with sst value of 0):

$ ncdump c001.dt_ssha.nc 

netcdf c001.dt_ssha {
dimensions:
	xdim = 300 ;
	ydim = 200 ;
variables:
	float lon(xdim) ;
		lon:long_name = "longitude" ;
		lon:units = "degrees" ;
		lon:scale_factor = 1.f ;
	float lat(ydim) ;
		lat:long_name = "latitude" ;
		lat:units = "degrees" ;
		lat:scale_factor = 1.f ;
	float ssha(ydim, xdim) ;
		ssha:long_name = "Gridded SSH anomaly in GoM" ;
		ssha:units = "centimeters" ;
		ssha:scale_factor = 0.1f ;

// global attributes:
		:creation_date = "Thu Mar 29 12:48:26 2007" ;
		:title = "Map of NRT-SSHA in GoM from Jason-1" ;
data:

 lon = 262.5, 262.5, 262.5, 262.5, 262.5, 262.5, 262.5, 262.5, 262.5, 
    262.5383, 262.595, 262.6517, 262.7083, 262.765, 262.8217, 262.8783, 
[...]
    278.405, 278.4617, 278.5, 278.5, 278.5, 278.5, 278.5, 278.5, 278.5, 
    278.5, 278.5 ;

 lat = 18.5, 18.5, 18.5, 18.5, 18.5, 18.5, 18.5, 18.5, 18.5525, 18.6175, 
    18.6825, 18.7475, 18.8125, 18.8775, 18.9425, 19.0075, 19.0725, 19.1375, 
[...]
    30.1225, 30.1875, 30.2525, 30.3175, 30.3825, 30.4475, 30.5, 30.5, 30.5, 
    30.5, 30.5, 30.5, 30.5, 30.5 ;

 ssha =
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0.06345267, 
[...]
    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ;
}

Fixing the file this way allows it to be read by gdal/qgis, ncview and cdo. The data appears to be in the Gulf of Mexico (consistent with the metadata :title ="Map of NRT-SSHA in GoM from Jason-1")

ncrename -d xdim,lon tmp1.nc
ncrename -d ydim,lat tmp1.nc
cdo selindexbox,11,290,11,190 tmp1.nc tmp3.nc

$ gdalinfo -nomd tmp3.nc
Driver: netCDF/Network Common Data Format
Files: tmp3.nc
Size is 280, 180
Coordinate System is `'
Origin = (-97.433332108254930,30.349999156078148)
Pixel Size = (0.056666657916107,-0.064999990623091)
Corner Coordinates:
Upper Left  ( -97.4333321,  30.3499992) 
Lower Left  ( -97.4333321,  18.6500008) 
Upper Right ( -81.5666679,  30.3499992) 
Lower Right ( -81.5666679,  18.6500008) 
Center      ( -89.5000000,  24.5000000) 
Band 1 Block=280x1 Type=Float32, ColorInterp=Undefined
  NoData Value=9.96920996838686905e+36
  Offset: 0,   Scale:0.100000001490116

As the problem is with the data file, closing this bug as invalid.