Simone Giannecchini a écrit :
> If you revise the draft document on metadata that I sent you a while
> ago, you would see that we left space for nodata, offset and scale
> values for each band.
Yes I remember and we agree on that. But based on previous emails and on a look
to TransformCategory interface, I have the feeling that it was not clear that
"sampleToGeophysics" (lets rename it "sampleToUnit" - I admit that the former
was a bad name) is nothing else than scale, offset and nodata packaged in a
function. So if we dissociate "sampleToUnit" from Category (so indirectly from
SampleDimension), we have to dissociate scale, offset, nodata and units as well
to remain consistent.
> I am sugesting NOT to apply any automagic code to "guess" no data
> values but to allow users to EXPLICITLY specify them.
I don't remember automagic code to guess no data value. They are explicitly
specified since every Catagory without "sampleToUnit" (lets said "every range
of
sample values without scale and offset") is "no data" from the "geophysics
view"
perspective.
> Once no data values, scale and offset have been specified we
> should try hard to PRESERVE them
This is what current implementation does as far as I can see...
> I think we should separate the management of the so-called
> sampleToGeoPhysics and of the no data values from the portrayal of the
> data (you mentioned more than once separation of concerns if I recall)
Yes, but keep in mind the relationship between concepts. The proposed
TransformCategory wipe out the relationship between "sampleToUnit" and the
SampleDimension attributes (unit, scale...).
If your proposal is dedicaced to portrayal only, and if portrayal doesn't need
"sampleToUnit", then it should not appears at all. All those TransformCategory
interfaces should disaspear. Thats my understanding of separation of concerns.
So what I means by "remove Category interfaces" is: keep only what is needed
for
portrayal, nothing more (otherwise it looks like a proposed replacement for
org.geotools.coverage.Category).
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
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
