Thanks Simone for your answers.
Simone Giannecchini a écrit :
>> - Why "CoverageCrop" is not called "Crop"? No other operation are
>> prefixed by "Coverage".
>
> I don't remember. I guess it was not to confuse it with the JAI crop
> operation.
Many other operations share the same name ("Add", "Multiply", "Divide", "Exp",
"Rescale"...). From an other point of view, it make obvious that the
GridCoverage "Rescale" operation maps to the JAI "Rescale" operation. We should
probably be consistent (prefix all operations with "Coverage" or none of them).
> 1> I have always found Resample too complex. Resample shoud do
> resample not resample, crop, warp, reproject and scale :-). If I just
> want to crop a coverage to a certain envelope why should I use
> resample? On the other hand, if I want to scale a coverage by 2 on
> each side, why should I use resample and provide a gridgeometry?
Right, the method signature of the "Resample" operation is complex and "scale"
convenience method are worthy. But they could be implemented under the hoop as
wrappers around the "Resample" operation; users would not notice the difference.
> 2>Performances. Doing a scale using a warp can lead to bad
> performances, hence I want to have the freedom to choose which
> algorithm wo use for scaling, and I want to do just a scaling.
>
> IMHO, Resample should do just what it is meant for, that is :
>
> -resample a certain coverage
> -reproject a certain coverage
> -scale coverage in the case that known final dimensions have to be
> honored (scale and the other similar operation do not honorate
> ImageLayout bounds while warp does honorate it)
"Resample" can do warp, crop and scale because they are all special cases of
the
"Resample" operation. The "Resample" operation inspects the user's arguments
and
select the fatest branch (warp, scale or crop) capable to perform the required
work. This is very true that "Warp" can be slow, but "Resample" should not
select that branch if an "Affine" can fit (if it does, it is a bug). So the
performance penality should not occurs.
In other words, the fact that "Resample" can delegates to "Warp", "Crop" or
"Scale" according user's arguments is an optimization for making it as fast as
possible in some common cases.
> Simpler, smaller operation (closer to the JAI ones btw) mean better
> user experience. And in general following more closely the way JAI is
> built, that is using simple, well-defined operations for
> well-recognized tasks, is better ( in my opinion :-) ).
I fully agree with scale and crop convenience methods for better user
experience. How the methods are implemented under the hood is an other topic.
There is some value into sharing common code between our "Scale", "Crop" and
"Resample" operations (lower risk of inconsistency between "Scale" and
"Resample", more extensive tests, etc.). One possible approach is to try to
refactor those three operations (including moving some code from "Resample" to
"Scale" and "Crop") so that "Scale" do just scales, "Crop" do just crops (as
you
suggest), and "Resample" delegates to one of them when it has detected a
special
case.
> Trying to sum up, I think that we could avoid returning a
> BufferedProcessor when doing AbstractProcessor.getInstance . To me it
> seemed strange that, having an implementation of DefaultProcessor,
> this method, whose javadoc says "Returns a default processor instance"
> instead of returning me a DefaultProcessor it returns a
> BufferedProcessor.
Right, I admit that this is inconsistent.
> I think that the default processor should be a DefaultProcessor which
> would not interfere with disposing coverages. If someone wants
> buffering we should create a buffered processor and just forget about
> the disposition.
Sound like a good thing to do, but I would like to find some solution about
disposal - I don't have any control on who will invoke Coverage.dispose(). I
will try to think how I can organize listeners in the context of public a
'doOperation' method.
Martin
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
