[geotk] questions about GridCoverage
martin.desruisseaux at geomatys.fr
Thu Feb 2 09:12:57 EST 2012
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
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)
> 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
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.
More information about the Geotoolkit