[geotk] questions about GridCoverage

[Martin Desruisseaux]

Hello Pablo

First a quick note about the Geotk coverage I/O design. There is two kind of 
readers: ImageReader and CoverageReader. The ImageReader classes are defined on 
top of standard Java library. They work only in pixel space and known nothing 
about geographic coordinates. Then CoverageReader wraps ImageReader. 
CoverageReaders usually don't perform reading by themselves; they just try to 
convert parameters from geodetic space to pixel space before to delegate the 
work to ImageReaders.

One advantage of this approach is that since ImageReader is standard API, we can 
use custom implementations like NetcdfImageReader with other libraries. It also 
allow to work at pixel level for those who want so. One inconvenient is that we 
are constrained to ImageReader API, and it is sometime hard to retrofit geodetic 
parameters into ImageReader parameters.


Le 02/02/12 13:55, Pablo Rozas Larraondo a écrit :
> 1.- How ImageCoverageReader decides which of the 6 xy planes it selects? (this 
> variable has 6 z values)

Each variable is considered as an image. The standard ImageReader allows us to 
read an image at a particular index, so in your case the 'imageIndex' parameter 
value would range from 0 to 5. In Geotk we also defined an interface, 
NamedImageStore, which is implemented by ImageReaders whose images have a name, 
like NetCDF. Invoking the getImageNames() method in this interface should 
returns the list of variables found in the NetCDF file. The index in the list 
match the 'imageIndex' used for reading an image. I mean if "Low_cloud_cover" is 
at index 1 in the list returned by 'getImageNames()', then you can get this data 
by invoking NetcdfImageReader.read(1);

CoverageImageReader returns the same list (in a different form) when invoking 
its getCoverageNames() method. Again you can pass the index of the desired 
coverage to the 'read' method.


> 2.- uwindcoverage.evaluate(new Point2D.Float(X, Y), values) returns values as 
> "[F at 10d0eae" when I expect [float] according to NetCDF variable descriptor. 
> How should I read this values?

The "[F" prefix is the standard Java syntax (probably a legacy from Java 1.0 old 
days) for an array of type float[]. To see the content of this array, we need to 
write:

System.out.println(java.util.Arrays.toString(theArray));

Your value should be at index 0 in that array.

> 3.- Does it makes sense that: uwindcoverage.getDimension() = 4, if its defined 
> as 2D?

Yes, since your data seems to be really 4 dimensional - (x, y, z, t) I presume. 
The "GridCoverage2D" name may be misleading, but it actually means "a 
two-dimensional slice in a 4D cube". More specifically, only 2 dimensions - 
usually (x,y) - can have a span of more than 1 pixels. All other dimensions - 
usually (z, t) - most be only 1 pixel width. Nevertheless those extra dimensions 
can have a valid value: the 2D slice contains (x,y) data at a particular (z,t) 
position.


> 4.- Do you consider convenient to define new methods for GridCoverage2D as: 
> .getMaxValue(), .getMinValue(), .getAverageValue(), .getUnit(), etc to get 
> information similar to the one contained in the original grib file? I think 
> they could be very helpful for application development...

The min, max and unit are specified in the SampleDimension. Each coverage can 
have many SampleDimension. In this use case, I think there is only one 
SampleDimension by coverage so we can ignore the multi-SampleDimension cases for 
now.

     GridSampleDimension band = coverage.getSampleDimension(0);
     double min = band.getMinimumValue();
     double max = band.getMaximumValue();
     Unit<?> unit = band.getUnits();

Note that the above returns the minimum and maximum values *declared* in the 
image metadata - in this case in the NetCDF standard attributes. They are not 
min or max values computed by iterating over the pixel values. The later was the 
job GridCoverageProcessor in the legacy OGC 01-004 specification. But this 
specification is now deprecated and we have not yet designed a good replacement.

     Regards,

         Martin