Jody Garnett a écrit :
> I cannot afford to be scared off of trunk; and I don't want to cut
> a 2.5.x branch right now
I don't think that it is necessary - If I introduce any incompatibility, I would
consider that as a bug unless the old behavior was erroneous (but I don't think
there is so many of them). Current work is mostly internal mechanic which should
have few visible effect on API. The replacement of "geophysics(boolean)" method
by "view(ViewType)" is probably the most noticeable one, and is backward
compatible through deprecation cycle.
More API changes may occurs when the coverage I/O work will begin, but we are
not yet there. The best design document that we could use as a starting point
for this part is Simone's "Coverage I/O metadata" draft, if he agree of course.
The recent email discussion come simply from a clash of use cases: I use
coverage for geophysics data, up to the extreme point where the coverage module
lost totally all its interest if those data are not carefully handled in every
steps of the operation chain. I never handle RGB images, and because of that the
coverage module was poor for RGB image handling, overly complex and raised a lot
of legitimate complains. Simone do a different work that I don't do, involving
shape recognition among other. This is an other domain, very complex on its own,
which doesn't need all the stuff related to geophysics measurements. For those
guys, many GridCoverage constructs are more weights than helpers.
The result is a schysophrene coverage support in GeoTools. The base classes are
biased toward geophysics support because I wrote them, and RGB guys have good
reason to dislike some parts of it. The I/O and rendering parts are biased
toward RGB, and this biais is a reason why GeoServer doesn't seems appropriate
for the geophysics data that I want to render. When looking at the whole chain
from base classes up to I/O and rendering, everyone on both sides have reasons
to be unsastified.
To conciliate those two points of views we need to revisit and criticize what
has been done so far on both sides. If they were some feeling of frustration, it
may come from human attachment that developers have with their own work. If we
make it clear that current code status is the result of historical circonstances
like main goals at the time the code was written, it may help to not confuse
critisizm with attack.
As for merging the two points of view in the coverage module, the first step in
my point of view is to get ride of the GridCoverage2D.geophysics(boolean) method
and remplace it by something a little bit more elaborated, which can handled RGB
data. This is not an idea that I invented recently - I talked about this idea
with Simone a few years ago, but never had the time to implement it up to
recently. Again this is (at this stage) compatible changes and a lot of work are
actually code cleaning, so I don't think that we need branching.
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
