[gdal-dev] Re: discussion on improvements to the NetCDF driver and CF-1 convention

[Knut-Frode Dagestad]

Etienne,

My group is also very much in support of the suggested improvements, as 
NetCDF/CF is becoming the most important standard for data 
storage/exchange in our community (climate, meteorology, oceanography). 
My group is not much into GDAL driver development (at least not yet), 
but we are now building our future very much around GDAL, so we are 
interested to join the discussion around improved support for NetCDF/CF 
reading and writing.

About some of the mentioned issues:

1) The latest version of CF is 1.5, so it would be better to target 1.5 
(or 1.x) than 1.0. Ideally the driver could be made generic for smooth 
upgrade to newer (or downgrade to older) versions of the CF conventions.

5) It sounds meaningful to assume WGS84 datum if not specified. I 
believe at least 99% of data typically stored in NetCDF/CF will have 
this datum, and even when that is not the case, positioning errors less 
than 100 m should normally have little impact for the types of data. 
Precision on datum level is probably more relevant for more typical 
GIS-data with roads, borders etc.
A warning could however be issued each time the driver has to assume WGS84.

7) We agree in particular that proper handling of time axis is of high 
value. This is one of the issues which is highly relevant for 
climate-data (often 4-dimensional), but not well supported by typical 
GIS-software or standards designed with 2-dimensional data in mind.
A general representation of a time-axis (or even vertical axis) in GDAL 
would be ideal, but that would probably be too much an effort for anyone 
to develop.


Knut-Frode
Nansen Environmental and Remote Sensing Center



On 24/08/2011 22:37, Etienne Tourigny wrote:
> Hi all,
>
> I would like to start a discussion with those interested about fixing
> various issues in the NetCDF driver.
>
> As it stands, it is not fully CF-1.0 compliant, and produces
> geographical grids that are not valid for other software.
> Also, the infamous "up-side down" problem has been addressed for
> importing netcdfs, but needs to be addressed for exporting.
>
> Related ticket: http://trac.osgeo.org/gdal/ticket/2129
> I have been submitting patches for some time to fix the related issues.
>
> I have identified a number of issues, of which the following have been
> fixed partially in my proposed patch.
>
> 1- conform to the cf-1.0 standard for geographical grids (creating lat
> and lon dimensions and variables)
> 2- make netcdf grids "bottom-up" by default, as all software out there
> uses that convention
> 3- fix problems related to floating-point / string conversions (also
> reported in issue #4200 )
> 4- fix metadata handling and duplication (as reported in issue #4204),
> and keep band (variable) metadata outside of the global metadata
>
> Pending issues:
>
> 5- how to deal with netcdfs which have no datum? Can we assume WGS84?
> These files are extremely common, and CF-1.0 has provisions for
> identifying the key variables, but no Proj/Wkt codes.
> 6- fix proper export of projected CRS (this is not fully necessary
> though) with lat/lon values respecting CF-1.0
> 7- handle time axis properly (at least when creating a netcdf) - that
> would be great for import/export of netcdf
>
> Regards,
> Etienne
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev