Simone Giannecchini a écrit : > Well, with the given semantic I might get an error back since it might > really be that w and/or h in the raster space are 0 after the > rounding you describe in the javadoc. > Same thing would not apply if we followed JAI's or > (rectangle2d.getBounds() if you like) approach. > > What do you think about this issue?
I think it is a hard one... I remember that I while ago I spend a few days inspecting why "Affine" operation was failing until I identified this rounding mode issue. If we just replace the current GeneralGridRange behavior by the JAI's one, we would move the exception from one place to an other. It would work for images cropped to 1x1 pixels, but resampling of ordinary images using the "Affine" operation would fails in some cases. It was a while when I worked on this issue, so we may need to try in order to revisit what the exact error was. But I think it was related to the images being 1 pixel larger than expected. The javadoc gives the example of the [-0.25 ... 99.75] range rounded to [-1 ... 100], but in practice the real cases are rather ranges like [-0.0000001 ... 99.9999999]. We intented [0 .. 100], but rounding in the JAI's way gives us [-1 .. 100]. The above problem could be avoided by usage of some small tolerance value (an epsilon). But the choice of that epsilon value is an arbitrary choice, one that I usually find hard to choose. As a comparaison, java.awt.geom.AffineTransform uses a tolerance value but has a quite extensive discussion about it. You can look at http://java.sun.com/javase/6/docs/api/java/awt/geom/AffineTransform.html and scroll down to "Handling 90-Degree Rotations". On my side, I'm unable to provides such a good and rigourous discussion (I may look naive, but one reason why I like so much Sun's technology is that I tend to be admirative with the way they nail down their choices with theorical background). The "nearest integer" rounding mode was a way to eliminate completly the need for an arbitrary epsilon value, but it was done at the sacrifice of JAI's semantic (smallest envelope containing fully the original one). Cropping to the smallest image that contains fully the requested envelope make a lot of sense. But if we do so the "epsilon value" issue will be back, and we would need to test Resample2D (especially when delegating to JAI's "Affine") for trying to identify what was its issues (I don't remember exactly which exception we got) and if we can find a workaround. One possible approach could be that a GeneralGridEnvelope working in JAI's rounding mode may needs an explicit "epsilon" argument. But it just push the choice later (we would still need to choose an epsilon value in Resample2D). An other, less disruptive approach would be to make a special case for 1x1 images only. Do you need the JAI's behavior in the general case, or would it be suffisient to make a special case of the 1x1 pixel case? If we needs the JAI's behavior in the general case, do you have any though about the epsilon value issue? (do we need it, which value, where to specify it)? Martin ------------------------------------------------------------------------- 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
