Dear Calogero,
in latest geotools (2.7-M3) emanuele has extended the CoverageCrop operation
in order to
use also a polygon or multiploygon to crop a raster. It is rather
experimental but I would like to hear from you
if there are any problems.

Here is the description of the operation from the javadoc:

==org.geotools.coverage.processing.operation.Crop

The crop operation is responsible for selecting geographic subarea of the
source coverage. The CoverageCrop operation does not merely wrap the JAI
Crop operation but it goes beyond that as far as capabilities.

The key point is that the CoverageCrop operation aims to perform a spatial
crop, i.e. cropping the underlying raster by providing a spatial
Envelope<eclipse-javadoc:%E2%98%82=gt-coverage-2.7-SNAPSHOT/src%5C/main%5C/java%3Corg.geotools.coverage.processing.operation%7BCrop.java%E2%98%83Crop%E2%98%82Envelope>(if
the envelope is not 2D only the 2D part of it will be used). This
means
that, depending on the grid-to-world transformation existing for the raster
we want to crop, the crop area in the raster space might not be a rectangle,
hence JAI's crop may not suffice in order to shrink the raster area we would
obtain. For this purpose this operation make use of either the JAI's Crop or
Mosaic operations depending on the conditions in which we are working.

*Meaning of the ROI_OPTIMISATION_TOLERANCE parameter*
In general if the grid-to-world transform is a simple scale and translate
using JAI's crop should suffice, but when the g2w transform contains
rotations or skew then we need something more elaborate since a rectangle in
model space may not map to a rectangle in raster space. We would still be
able to crop using JAI's crop on this polygon bounds but, depending on how
this rectangle is built, we would be highly inefficient. In order to
overcome this problems we use a combination of JAI's crop and mosaic since
the mosaic can be used to crop a raster using a general ROI instead of a
simple rectangle. There is a negative effect though. Crop would not create a
new raster but simply forwards requests back to the original one (it
basically create a viewport on the source raster) while the mosaic operation
creates a new raster. We try to address this trade-off by providing the
parameter 
Crop.ROI_OPTIMISATION_TOLERANCE<eclipse-javadoc:%E2%98%82=gt-coverage-2.7-SNAPSHOT/src%5C/main%5C/java%3Corg.geotools.coverage.processing.operation%7BCrop.java%E2%98%83Crop%E2%98%82Crop%E2%98%82ROI_OPTIMISATION_TOLERANCE>,
which basically tells this operation "Use the mosaic operation only if the
area that we would load with the Mosaic is strictly smaller then
(ROI_OPTIMISATION_TOLERANCE)* A' where A' is the area of the polygon
resulting from converting the crop area from the model space to the raster
space.

*ROI*
By providing a ROI parameter, the coverage can be cropped by any set of
polygons, even disjuncted ones. When the ROI is provided, the JAI's Mosaic
operation will be used.
At least one between *Envelope* and *ROI* must be provided. If both of them
are provided, the resulting area will be the intersection of them.
ROI geometries must be in the same CRS as the source coverage.
ROI must be any among a
com.vividsolutions.jts.geom.Polygon<eclipse-javadoc:%E2%98%82=gt-coverage-2.7-SNAPSHOT/src%5C/main%5C/java%3Corg.geotools.coverage.processing.operation%7BCrop.java%E2%98%83Crop%E2%98%82com.vividsolutions.jts.geom.Polygon>,
a 
MultiPolygon<eclipse-javadoc:%E2%98%82=gt-coverage-2.7-SNAPSHOT/src%5C/main%5C/java%3Corg.geotools.coverage.processing.operation%7BCrop.java%E2%98%83Crop%E2%98%82MultiPolygon>,
or a 
GeometryCollection<eclipse-javadoc:%E2%98%82=gt-coverage-2.7-SNAPSHOT/src%5C/main%5C/java%3Corg.geotools.coverage.processing.operation%7BCrop.java%E2%98%83Crop%E2%98%82GeometryCollection>of
the two.

*NOTE* that in case we will use the Mosaic operation with a ROI, such a ROI
will be added as a synthetic property to the resulting coverage. The key for
this property will be GC_ROI and the type of the object
Polygon<eclipse-javadoc:%E2%98%82=gt-coverage-2.7-SNAPSHOT/src%5C/main%5C/java%3Corg.geotools.coverage.processing.operation%7BCrop.java%E2%98%83Crop%E2%98%82Polygon>.

==
Some code that uses this operation can be found here:
http://svn.osgeo.org/geotools/trunk/modules/library/coverage/src/test/java/org/geotools/coverage/processing/CropTest.java
<http://svn.osgeo.org/geotools/trunk/modules/library/coverage/src/test/java/org/geotools/coverage/processing/CropTest.java>
Regards,Simone


-------------------------------------------------------
===
Notice that our office phone number has recently changed!
Please, update your records!
===
Ing. Simone Giannecchini
GeoSolutions S.A.S.
Founder
Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584962313
fax:      +39 0584962313
mob:    +39 333 8128928


http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.linkedin.com/in/simonegiannecchini
http://twitter.com/simogeo

-------------------------------------------------------



On Thu, Sep 30, 2010 at 3:27 PM, Calogero Zarbo <[email protected]> wrote:
> Hello,
> i need some help about how to clip a raster using GeoTools 2.6.1 Library.
> I have a FeatureCollection (took from PostGis or from a simple ShapeFile),
where i can retrieve the single Features, and i need for all of them to clip
the corrispondent part of the raster and compute the average value of the
clipped area.
>
> Note that the Feature's bounds to clip in the raster, could be a complex
Polygon with many sides.
> Is there enyone that know a solution for that kind of problem?
>
> Best Regards,
>
>
> Cal
>
>
------------------------------------------------------------------------------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Geotools-gt2-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
>
------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to