First of all an annotation. I am currently working exclusively on 2.3.x, I will port all the fixes I am making to trunk not before the end f the month. Which version are you working on?
On 11/12/06, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > 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). > Be careful with the assumption that -9999 is just pad values, for example in netcdf you can have separate pad value and no data value and none of them may be NaN. I agree that the best way to handle the no data value would be by converting it, whatever it is, to NaN in memory. Unfortunately there are cases when this is difficult to do because we did not write the ImageReader as it happens for the GTOPO30 where I am using the RawImageReader. On the other hand I used this approach with the esri ascii grids, where I wrote the ImageReader, and I converted the -9999 to NaN. I can easily write a simple JAI operation for performing a conversion on the fly bewtween whatever the no data value the ImageReader we are using provides us with and NaN, but once again this would add some. Let me make a couple of experiments tomorrow about this approach. > > > 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. Mmmmhh, heuristic? I remember that reverse for example was telling me if the CRS was pointing in the absolute direction or not using the CRS AxisDirection, I would not call this heuristic and it was exaclty what I was looking for. > 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. > In the GridCoverageRenderer an extent and an envelope (with its crs) are given hence the transform between world and grid 8 and the viceversa ) are computed using them. It is not so clear to me what you are saying. I guess I'll have to take a look at the proposed methods. > 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 think method should make my life easier not the converse :-). If i was asked to choose between prettier or easier to use code I would go for the easier to use. > I will create an utility class and commit in a few hours. > > Martin > See what I said at the beginning of this email. Thx, Simone. -- ------------------------------------------------------- Eng. Simone Giannecchini President /CEO GeoSolutions http://www.geo-solutions.it ------------------------------------------------------- ------------------------------------------------------------------------- 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
