[geotk] NetCDF GridCoverage resampling

[Martin Desruisseaux]

Hello Aaron

You are right, the support of ProjectedCRS has not yet been implemented in the 
Geotk NetCDF adapters. The reason why Geotk works at the NetcdfFile level is in 
part historical (the NetcdfImageReader class was initially developped at the 
time of NetCDF 2.2), and in part because we needed a package capable to read 
IFREMER data, some of them having their own non-CF convention.

I think that your proposition of wrappers around GridDataset rather than 
NetcdfFile is excellent. Jon Blower told me about GridDataset, but I didn't had 
the opportunity to investigate yet.

I will try to fix the limitation of NetcdfCRS (add the support of 
CoordinateAxis2D and finish the ProjectedCRS wrapper) during the Christmas 
holiday. If you have the opportunity to look for GridDataset wrapper on your 
side (and if you wish to do so), it would be greatly appreciated :)

On our side, we need to push Geotk for OSGEO incubation in order to make it more 
contribution-friendly. This is on our list of thing to do soon.

	Regards,

		Martin




Le 17/12/10 05:03, Aaron Braeckel a écrit :
> It appears that getConversionFromBase() is not yet implemented on NetcdfCRS.
> Based on my reading of this class, the code seems to be lacking the projection
> detection step from files read via the NetCDF API. In the NetcdfImageReader
> classes it appears that most of the code works at the NetcdfFile/NetcdfDataset
> level. I'm not sure if you are aware, but the NetCDF API has several high-level
> feature types, including what they call the GridDatatype/GridDataset. This is a
> higher-level gridded coverage abstraction that allows for reading of many
> different files, including Netcdf 3/4 (multiple conventions), HDF (multiple
> conventions), GRIB 1, GRIB 2, McIdas, etc. Not all of these formats are CF
> compliant, but the NetCDF API is capable of reading all of these formats into
> GridDatatypes with projection objects and relevant metadata. NetcdfFile objects
> include semantics related to Variables and Attributes, and GridDatatypes
> interpret these lower-level NetCDF concepts into grid types.
>
> It's not completely clear to me whether the existing code is intentionally
> oriented towards only NetCDF formats and the CF/COARDS conventions, but the
> GridDatatype logic in the NetCDF API might be an easier way to read gridded
> information from the large set of formats that can be interpreted as grids by
> the API. I believe there is a relatively straightforward mapping between the
> projection logic on these classes to Geotk projection classes.
> Any thoughts? I could put some time into implementing portions of this logic if
> that would be productive, or I could take a break from my
> reprojection/resampling task for a couple of weeks. If this part of Geotk is not
> aimed towards my intended use of NetCDF, another option might be for me to
> implement what I need by making use of the Geotk transformation/re-projection
> logic without the Geotk raster resampling logic. Or perhaps I'm missing
> something... ;)