Can we post this on a wiki page? This is the best explanation I've
gotten about this stuff.
C
Martin Desruisseaux wrote:
Andrea Antonello a écrit :
It's basically just rasters, but I think can additionally can have
multiple dimensions. It's not my area of expertise.
Multiple dimensions in the sense of voxels?
It may also be time axis. Any valid CRS
(org.opengis.referencing.crs.CoordinateReferenceSystem) can be used, so
axis may be depth, time, pressure, etc.
Yeah, our coverage API is just coming to maturity. And I think it still
does not do much raster analysis at all. We're working on data loading
and rendering first, and sticking it all behind standards based
interfaces. So this actually sounds like an area where our communities
can learn a lot from one another.
There is some very basic processing tools. Resampling (or reprojection),
convolution, gradient magnitude, and the usual basic operators like
addition, subtraction, log, exp...
For example with very large datasets (which are more and more common
today) we are going to have problems because of to high amount of
memory requests.
Geotools coverage module is build on top of Java Advanced Imaging.
Actually the above-cited convolution, log, exp, etc. operators are just
wrappers around the JAI's operators. Simone's work is continuing in the
directory of leveraging JAI capabilities. By the way, JAI is also used
at Nasa.
Home page and success stories:
http://java.sun.com/products/java-media/jai/
Available JAI operations (usable in Geotools if a wrapper exists):
http://java.sun.com/products/java-media/jai/forDevelopers/jai-apidocs/javax/media/jai/operator/package-summary.html
Current development (including link to demos):
http://jai-core.dev.java.net/
JAI uses tile caches for managing large images. The image "seems" to
hold fully in memory (from the programmer point of view), but actually
part of the image (tiles) can be discarted at any time and recomputed
more than once on demand, or flushed to disk. The JAI's API give us
great control on tile cache mechanism. The inconvenient is that JAI's
API is complex and take time to master. Some time I have the feeling
that JAI was a good old Fortran library translated to Java.
An example: to create a map of the total contribution area (the area
that drains water in every pixel) you have to follow the
flowdirections of the elevation model. In every pixel the algorythm
look for the next pixel, which means that this could go diagonal
throught the data matrix, i.e. I can't just read row by row and evaluate.
In JAI, you can perform yours work as is the whole image was holding in
memory. Reading and flushing tiles to disk can be performed by JAI tile
cache mechanism without the need for the operator developper to care
(but the image operation may be more efficient if he care).
Geotools mostly relies on JAI for 2D operation. The steps are:
1) Developper write their operation as a JAI operation.
2) Then, wraps the JAI operation in a GridCoverage operation.
This is why Geotools grid coverage framework seems to provide no raster
analysis framework at all. Actually it does provide a very minimalist
one, or to be more accurate it inherit it from JAI. However the Geotools
- JAI mapping mechanism need to be improved (I believe that it is part
of Simone's work).
JAI is 2D only. Geotools handle the 3D case as a stack of 2D rasters,
the 4D case as a stack of 3D coverages (which are themselves stacks of
2D rasters), etc. It is suffisient for basic need, but may not be
suffisient for more elaborated operations.
Martin.
--
Chris Holmes
The Open Planning Project
thoughts at: http://cholmes.wordpress.com
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
