On 8/31/07, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
> Simone Giannecchini a écrit :
> > my intention was giving the possibility to keep the name of the
> > corresponding JAI parameter but allowing the user to use it with a
> > different object that could then be translated prior to execution into
> > the correct JAI parameter. If you look in the
> > AbstractStatisticsOperationJAI class you can see this behaviour
> > implemented for Histogram and Extrema.
>
> Thanks for the information, I looked at the AbstractStatisticsOperationJAI
> class.
>
> So the ParameterList is left unset regarding the replaced parameters. I was
> wondering what to do about that...
>
> I could update the implementation in that way: if the user provided a
> ParameterList value in whatever way he wish, this explicit value has
> precedence.
> Otherwise the "replaced" value is used. Does it sound like reasonable?
Yeah, it does! I am happy with this change.
>
> It may more than needed for the statistics operations, but I'm maniac about
> details and try to fill holes when I see some. I believe that if we don't paid
> attention to holes, we often paid the price later by unexpected and surprising
> behavior where we didn't expected that. I don't claim however that the above
> suggestion is the correct way to fill that particular hole.
>
>
>
> Side notes about AbstractStatisticsOperationJAI implementation
> --------------------------------------------------------------
>
> Following lines:
>
> AffineTransform gridToWorldTransform = new AffineTransform((AffineTransform)
> ((GridGeometry2D) source.getGridGeometry()).getGridToCRS2D());
> gridToWorldTransform.translate(-0.5, -0.5);
>
> Can be replaced in a more generic way by:
>
> MathTransform gridToWorldTransform =
> (...snip...).getGridToCRS2D(PixelOrientation.UPPER_LEFT);
Applied.
>
>
> Would it be possible to replace lines like:
>
> try {
> // do some stuff
> } catch (Exception e) {
> LOGGER.log(...);
> return anIncompleteObject;
> }
The reason why we coded this behaviour is that the ROI and the
ssubsampling factors are, or at least that's the way we saw them :-),
not essential to run the operation since they are mainly useful for
optimization. Anyway, I admit that it could be misleading in some
cases to not respect them without a message (if the log level is
high/low enough). I will replace the behaviour and also update the
doc to reflect the change.
>
> by either letting the unchecked-exception propagate, or wraps the checked
> exception into a CoverageProcessingException one?
>
>
> Martin
>
Ciao,
Simone.
--
-------------------------------------------------------
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: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
