Simone Giannecchini a écrit : > 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 the trunk. But they are all changes that I would like to port to the 2.3 branch before the 2.3 release, if possible. > 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. I suggest to bundle the conversion in ImageReader when possible. When it is not, there is some chance that existing JAI operation fit. For example for GTOPO30, the JAI "Lookup" operation is probably good enough. > 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. You are probably refering to the GeneralGridGeometry.reverse(...) method. In addition of the above-cited check, this method also revert the North axis because it assumes that the output device is going to be the screen where the y axis is oriented downward. This is heuristic. We have no garantee that this is what the user wants. This is just more likely in the context of GridCoverage. Outside this context, this is a more risky assumption (which is why I would not like to encourage its usage outside GeneralGridGeometry). In addition, this method do not known which axis to reverse if there is no axis oriented toward North. What about GridCoverage with (time, longitude) coordinate systems like the one used for Rossby wave propagation in ocean? Or GridCoverage with (depth, transect) coordinate systems like the one used by Doopler current meters? This 'reverse(CoordinateSystem)' method make its best effort, but there is a high probability that users will want to swap and reverse their axis differently. So my point is that GeneralGridGeometry.reverse(...) and GeneralGridGeometry.swapXY(...) are just making a guess. This is nothing more than that: a guess that may not be very good for anything else than (longitude, latitude, otherAxis) or (latitude, longitude, otherAxis) coordinate systems. This is okay if don't have any better information. But if we have the user's AffineTransform, this is better information. Don't try to guess which axis the user wanted to revert! GeneralGridGeometry.reverse(...) may guess wrong. Look at the AffineTransform instead. If it was built by the user, it will tell you want the user wants. > 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. The point is that you have an affine transform, but you don't use it for determining if the axis were swapped or not. In the particular case of GridCoverageRenderer, it work anyway because the AffineTransform were created just a few line upper in a code flow that use the same heuristic rules (since it invokes indirectly the same GeneralGridGeometry.swapXY method), but this is somewhat accidental. There is other classes that provide better examples: Class StreamingRenderer at line 609: a 'lonFirst' boolean is defined using GridGeometry2D.swapXY(destinationCrs.getCoordinateSystem()). This 'lonFirst' boolean is then used for handling the 'worldToScreenTransform' transform, which is a user-specified AffineTransform. What is telling you that the output of 'swapXY' is consistent with the user-specified AffineTransform? We have no garantee at all! Imagine that a user *don't* want to swap the (latitude, longitude) axis order. Image that he really wants an image rotated 90° for whatever reason (for example instead of having North axis oriented up, we sometime want to have the boat heading oriented up, in which case the map can be rotated by an arbitrary angle). In current StreamingRenderer code, because of 'lonFirst', line 642 will invokes the wrong AffineTransform.getFoo() method and will probably get a 0 value. In the more complex case of an arbitrary rotation, the current StreamingRenderer code will not work at all (J2D-renderer worked well with arbitrary rotation). Class ArcGridReader: Instead of the code at lines 459 to 483, there is a few more robust alternatives we may consider. For example: build the envelope in (longitude,latitude) axis oder, then transform it to the user-specified CRS using CRS.transform(Envelope). It will work with arbitrary CRS, axis reversal or swapping, rotations, etc. If you don't want to use CRS.transform(...), for example because the CoordinateReferenceSystem is not really know but the CoordinateSystem is know, then maybe the following method (which exists since 2.1) can provides the benifit of both 'reverse' and 'swapXY' method in a more generic and robust way: http://javadoc.geotools.fr/snapshot/org/geotools/referencing/cs/AbstractCS.html#swapAndScaleAxis(org.opengis.referencing.cs.CoordinateSystem,%20org.opengis.referencing.cs.CoordinateSystem) Example for forcing (longitude, latitude): Matrix matrix = AbstractCS.swapAndScaleAxis(cs, DefaultCartesianCS.GENERIC_2D); 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
