Hello Simone
Thanks for your feedback.
Simone Giannecchini a écrit :
> Well, in this is the sentence "by definition" may have a different
> meaning for different people because it is at the same time subjective
> as well as dependent on the data source. Some examples, in GTOPO30 the
> nodata value is -9999 and the same applies to esri ascii grid files,
> hence, in general it is important to be able to handle values
> indicating the no data value that are not real "NoData" i.e. NaN. Many
> scientists I have met really want to use value different from NaN for
> indicating the missing value (hey, do not ask me why, it is their will
> :-) ) hence I only tried to reflect what happens in reality.
Yes, I realize this need and agree with. I handle a lot of data myself where
"no
data" is -9999. In this context, -9999 is called "pad value". We have to
distinguish between:
- The "pad data" value in the data file.
- The "no data" value in memory.
It is very important that the "no data" value in memory is NaN, otherwise a lot
of grid coverage operations will produce false results (interpolation,
grandient
magnitude, etc.). In my opinion, the conversion between NaN (in memory) and the
pad value (in the data file) should be handled by the ImageReader /
ImageWriter.
I tried various approach (including hacking the CategoryList), and I have found
that handling at the ImageReader / ImageWriter level is what work the best. For
example the classes in "org.geotools.image.io" already handled that :). On a
conceptual point of view, it also make sense to consider the choice of pad
value
as a formatting issue (especially in text files).
> Well, I see that you never fought with the reversed-axis problem but
> believe me when everybody understands lon,lat while our crs where
> mostly lat,lon these methods come pretty hand to reverse things .-).
> As of now I am starting to remove the from most plugins but they are
> still useful.
I agree that such kind of methods are usefull, but I'm not sure that the ones
in
GeneralGridGeometry are appropriate. They were private on purpose, because they
apply heuristic rules in order to "guess" what the axis order may be in the
absence of AffineTransform. But when an AffineTransform is already available as
in the GridCoverageRenderer case, a more rigourous approach is to inspect the
AffineTransform coefficients. I commited a few minutes ago a method in
XAffineTransform doing that.
http://javadoc.geotools.fr/snapshot/org/geotools/referencing/operation/matrix/XAffineTransform.html
(see the new 'getSwapXY' method)
> Well you went right to the point of this thing, performances. I use
> this methods to produce envelopes from GridRange and MathTransform and
> to produce Transforms from Envelopes ans GridRange in in many places.
> I am writing from memory but I think we are using it inside most most
> coverage plugins to build envelopes from world files, inside the
> StreamingRenderer. Consider also that GeoServer sits on top of all
> these components, hence if we can avoid creating useless objects we
> should do that because in a server side environment creating useless
> object is something we want to avoid. You know what, we could move
> this methods in a utility class much like the CRS or CRSUtilies in
> order to have clear in mind that these methods are just utilities
> methods.
I can move them in an utility class then (will try to find which utility class
could be appropriate). But actually the only usage I found right now was in
RendererUtilities, and it was possible to avoid it by constructing a slightly
offseted envelope.
I will create an utility class and commit in a few hours.
Martin
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
