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 > * ksshan...@gmail.com > * > */ > > > > > On Wed, Aug 24, 2011 at 14:37, Etienne Tourigny <etienne...@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@lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@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: hieb...@uvic.ca Tel: (250) 472-4521 Fax: (250) 472-4830 _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
