Going by memory as far the Resample operation is concerned, I think I
understand to what you are referring to. Many JAI operations like Affine,
Scale, SubsampleAverage, FilteredSubsample, etc.., do NOT respect the
ImageLayout minX, minY, width and height hints. Citing the Affine
operations:
"It may be noted that the minX, minY, width and height hints as specified
through the JAI.KEY_IMAGE_LAYOUT hint in the RenderingHints object are not
honored, as this operator calculates the destination image bounds itself.
The other ImageLayout hints, like tileWidth and tileHeight, however are
honored.".
I found myself facing this quite some times; my suggestion is simple to use
warp when you want to ensure that some final dimension are meet, which I am
sure you know.
Going back to the actual issue of having very small areas becoming empty
because of rounding, I fully understand you point of view, in fact I think
we should try to somehow preserve it.
However, thinking loudly, the current behavior of the mentioned
GeneralGridRange contructor is correct only in the use case you mention,
that is either you have a target gridrange or you have a targetGridToCRS
that you want to preserve. In case one was doing a simpe spatial crop, that
means I just have a 2D envelope and no target range of transform, the
implemented behavior would be misleading since I'd say that the right
behavior would be the one underlined by the JAI's Crop javadocs, that is
getting the smallest area that includes the requested area.
Summarising, I think that:
- when you are resampling and you have a targert GR or a targetGridToCRS the
current behavior is correct (this is more a resample than a real crop) since
it strives to meet what the user would expect.
- when you are croppping simply providing an envelope, we should probably
switch to the JAI's crop semantic and try to never throw exceptions if the
intersection in the model space between the coverage envelope and the crop
envelope is not empty even if very small.
Does this make sense to you?
Ciao,
Simone.
On Tue, Jul 29, 2008 at 4:45 PM, Martin Desruisseaux <
[EMAIL PROTECTED]> wrote:
> Simone Giannecchini a écrit :
>
>> a clarification, by Affine you mean the simple Affine or the Warp Affine
>> (I would assume the second).
>>
>
> I'm not sure it was about the exact type of JAI operation used. I don't
> think that JAI itself was failing. If I remember right, it was about the
> destination image not meeting the conditions for which an AffineTransform
> "gridToCRS" has been computed, and this was generally occuring after some
> kind of affine operation. But again we would need to try for being sure.
>
> The bottom line is that if we computed a "gridToCRS" transform for an image
> 100 pixels width and we got an image 101 pixel widths because of the
> rounding error described in GeneralGridRange javadoc, that "gridToCRS"
> transform is wrong. Not completly wrong, but a 10 km error can be a lot for
> some computation purpose.
>
> Martin
>
--
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 333 8128928
http://www.geo-solutions.it
-------------------------------------------------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
