Simone Giannecchini a écrit : > As you might remember, I would like to separate the geophysics non > geophysics duality from the coverage themselves so that we stop > running into the duality images vs models this is trying to push some > time in that direction.
Giving more though to that since that time, I now believe that it would not be appropriate. This "duality" is closely linked to the nature of the data - it is not something that we can treat as an ordinary operation, because it is not an operation that we apply at one specific point and then forget about it. Knowing that a data is geophysics is a knowledge that must accompagnish the coverage all the way in the processing chain. Example: (coverage) ---resample---> (coverage) --->convolution---> (coverage) If interpolation is "bilinear", we must switch to geophysics view before the resample operation. But if the interpolation is "nearest neighboard", we can switch to geophysics view only after resample, before convolution. As you can see, this is not something that the user decides like an ordinary operation: "I want to convert to geophysics view now". For efficienty the decision is taken by the coverage framework at a moment that depends on the nature of the operation. If this handling of geophysics data is not desired, we must provide a mechanism that allows user to declare that a coverage must be handled as photographic. But for those who work with geophysics data, I believe that we need this mechanism. This is related to the unit of measurement. Units are an essential information that must accompagnish geophysics data all the way - not something that you put in an operation and then forget about it. It is possible to declare the units of a packed view in such a way that Unit A = packedView.getUnit(); Unit B = geophysicsView.getUnit(); UnitConverter C = A.convertTo(B); Where "C" is exactly the "sampleToGeophysics" conversion, but as a UnitConverter object rather than a MathTransform1D. If we understand that "sampleToGeophysics" is actually the definition of the units of pixel values in a packed coverage, we understand that this is something that must really accompagnish the coverage all the way - you can not separate it. I will make that clearer (and implement the above) when we will switch from JSR-108 to JSR-275: http://jcp.org/en/jsr/detail?id=275 (note that I'm a member of JSR-275 - I care about this issue since a long time). For record there how we define a Unit from a converter: http://jscience.org/api/javax/measure/units/Unit.html#transform(javax.measure.converters.UnitConverter) > I am not a fan of null values even though I have used them a lot in > the past :-). Given that a large amount of code in GeoTools just cast object without checking the instance, replacing optional value by sub-interfaces is replacing a risk of NullPointerException by a risk of ClassCastException. Returning null for an optional value is common practice. Declaring an interface for each optional values or operations leads exponential growth of interface. If the purpose was type safety, then TransformCategory and VisualizationCategory are not enough. You also need the combinaison of those, starting with TransformVisualizationCategory and yet more if other interfaces are added. The authors of java.util.Collection faced a similar issue (why Collection optional operations are not declared in a separated interfaces)? There is their answer: http://java.sun.com/javase/6/docs/technotes/guides/collections/designfaq.html#1 > I don't see how a category called TransformCategory extending category > and MathTransform1D can be confusing. It is a category that specify a > 1D transform between input values and output values. This transform > can be anything. The fact that the transform can be anything is the problem. The confusing part is not that we don't know the object type - as you said it is very clear from the interface name and method signature. The problem is that we don't know what this transform is. Imagine that GridCoverage.getGridToCRS() was renamed GridCoverage.getTransform() - This is a transform from what to what? "Grid to CRS" or "CRS to Grid"? Or is it the transform between the lenght of my feet at the captain's age? If we do not define the *source* and the *target* (or in other words, the purpose of the transform), it become useless. 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
