Bryce L Nordgren a écrit :
> I sense opportunity to make a RenderedCoverage in Geotools, which may
> combine a Coverage with a ColorModel; Potentially backed by RenderedImage?
This is what GridCoverage2D does - it is backed by a RenderedImage. We use that
as a matrix, since RenderedImage can be backed by floating-point values (float
or double primitive type) with an arbitrary number of bands which doesn't need
to be RGB (for example JAI uses them for the real and imaginary part of complex
numbers).
Using RenderedImage as matrix has two advantages:
* Allows us to display the data, even if it is just intermediate results
and not yet the final one.
* Leverage the JAI tiling capabilities, which allow us to perform
calculation on only part of an image.
* Leverage the I/O framework for GeoTiff and other formats.
It has one drawback: image I/O and rendering have restrictions. For example
IndexColorModel can display only unsigned integers having no more than 16 bits.
The ViewType enumeration is an attempt - admitly criticable - to conciliate
"data" with "Java2D restrictions".
> ISO TC/211 is defining a suite of standard sensor models (e.g. "camera")
> and associated metadata for 3&4 (ISO 19130). If you "leave room" for 3&4,
> you may well have a system capable of displaying/processing satellite data
> products directly, without first resampling onto an EPSG-friendly grid. I
> know the MODIS fire algorithm will lose all scientific credibility if you
> "resample first."
I must admit that I'm not familiar with ISO 19130. I'm sure that in order to do
things right, we need to take it in account. However it is worth to point out
that current model doesn't require any kind of spatial resampling (to
EPSG-friendly grid or whatever). The "sample to geophysics" transforms are about
pixel values only - it could be understood as a kind of units conversion, only
slightly more sophesticated because it handles "no data" values as well.
> The point is, each of these concerns is separate. Independent. Unrelated
> to the others. I suspect we will run into problems very quickly if we
> collapse these independent concerns into a single Enumeration.
As said previously, the enumeration is not about spatial resampling but could be
understood as "kind of units of measurement" where the enumeration of "kind" is
driven by Image I/O and rendering restrictions in Java:
GEOPHYSICS: are my data in some units I can use for calculation?
RENDERED: are my data in some units compatibly with Java2D restrictions?
etc. Because it is quite Java-specific, I do not expect to see them in an
international standard.
In summary, I agree that we need to put ISO 19130 (sensor model for imagery) in
the mix, but I don't think that it is incompatible with the enumeration. The
enumeration doesn't try to handle every cases. It just tries to said in which
"category" the data fall regarding Java2D restrictions. All the rational behind
that stuff is to provide the minimal information needed in order to build a
chain of JAI operations as efficient as I can without compromising data
integrity.
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
