On 3/22/12 1:32 AM, Hein Zelle wrote:
Yes, the netCDF-Java Grid API is the obvious place to put this
capability. The TDS option would be a nice addition but would be built
on top of the netCDF-Java capabilities, so not a replacement for the
thanks for discussing this in detail. I would like to contribute if I
can, although I don't have any experience coding with the NetCDF-Java
interface so far.
I would be in favour of a generic solution, but I'm wondering if, in
this case, it isn't something that should go into IDV itself. The
fact that a grid wraps and how to deal with it is something
application-domain specific. NetCDF (theoretically) doesn't have to
contain earth grids. There are other applications where the
functionality would make sense (direction axes), so it could be seen
as a generic dimension property (solve in NetCDF) or as something
earth-grid specific (solve in IDV). If it's solved in NetCDF,
shouldn't it be solved in the base C library as well?
In this case, we are talking about making a change in the netCDF-Java
Scientific Data Type (GridDataType) API which is above the low level
generic bit reading. Since the GridDataType API knows about the
structure and nature of Grids, it should be able to handle this case.
For the other cases you cite, the corresponding FeatureTypes could
handle these or perhaps it could be bubbled up to the FeatureType layer.
The C library does not (yet) have a Scientific Data Type layer, but
when/if it does that would be the place to put similar code.
Ferret (noaa) has a similar problem, and solves it in the application
with a "modulo" flag for dimensions and recognition of specific lon
dimensions. I'm not sure if they split requests in 2 when requesting
a small region, but I can find out if there's an interest.
NOAA/ESRL/PSD and CIRES