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

James Hiebert hiebert at uvic.ca
Thu Aug 25 13:50:09 EDT 2011


FWIW my organization is a heavy user of both GDAL and geographic netcdfs (usually disparately since GDAL can't always handle the CF-1.x compliant files that we have/use/create).  So if you're assessing need in the community, I'll add a +1.  Not sure how much I can help; I'm not an expert in either CF or GDAL, but have used them enough to be able to attest that the support could be improved.
Cheers,

~James

On Thu, Aug 25, 2011 at 10:26:09AM -0600, Kyle Shannon wrote:
> Etienne,
> I am all for the improvements.  I am a little short on time for the next 2-4
> weeks, but I would like to spend some time on this.  I think that the closer
> we get to a CF-1.x compliant file the better.  That also gives us a little
> better specification to work towards.  I hope to have some more time soon to
> work on this.  There does seem to be more interest in the driver and the
> file format recently.
> 
> kss
> 
> /**
>  *
>  * Kyle Shannon
>  * ksshannon at gmail.com
>  *
>  */
> 
> 
> 
> 
> On Wed, Aug 24, 2011 at 14:37, Etienne Tourigny <etiennesky at yahoo.com>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
> >

> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
James Hiebert
Lead, Computational Support
Pacific Climate Impacts Consortium
http://www.pacificclimate.org
Room 113, University House 1, University of Victoria
PO Box 1700 Sta CSC, Victoria, BC V8V 2Y2
E-mail: hiebert at uvic.ca
Tel: (250) 472-4521
Fax: (250) 472-4830


More information about the gdal-dev mailing list