Martin Desruisseaux <[EMAIL PROTECTED]> wrote on 03/11/2006 07:28:16 PM:
> Bryce L Nordgren a écrit : > > [DiscreteGridPointCoverage.list().toArray() is bad] > > --- (Note: just noticed that you explained exactly what I'm saying > below in a next paragraph. > It sound like that we are in agreement) --- > > [DiscreteGridPointCoverage.list().toArray() is bad] Yup. :) > > Suggested Mitigations: > > ====================== > > 1] I propose that any Set<GeometryValuePair> returned by any gridded > > coverage throw UnsupportedOperationException for the toArray() call, which > > is a mandatory feature of the Collections interface. This contractual > > violation should be specified in GeoAPI space, as all clients should expect > > this restriction, and no implementation can get around it. Further, the > > iterator() method shall return an iterator which dynamically creates the > > objects of the Set, and NO BACKING STORE is permitted. > > Yes, exactly. We could said that as a note in the javadoc, but I > don't think that we should words > that as a mandatory contract. I would rather words that as > recommandation (warning the users that > most implementations are likely to behave that way), but would let > implementors do whatever they > want. After all, some implementors way have some reasons to allow > calls to "toArray()" for small > lists (debugging purpose, etc.). I tend to view an interface set such as GeoAPI as an agreement between implementors and users. Users have every reason to seek guarantees that a Set of this nature _not_ maintain a backing store (issue 1: primary). If they are implementing middleware (where the Set might be returned to _their_ clients), they may very well wish to guarantee that toArray() will fail without taking positive action to this effect (issue 2: secondary). This is especially the case if the only reason to allow it is for debugging. Making a constraint optional gives implementors more freedom, but users less certainty. > > 4] We will want to provide an interface for Set implementations with no > > backing store. Implementations of this Set employ specialized iterators > > (also specified by GeoAPI interfaces) to create these objects dynamically, > > on demand, and NEVER all at once. Implementations of this Set interface > > shall be guaranteed to produce their elements on demand and never store > > them in something like an array. > > But why a new interface for that? Aren't the current Java Collection > interfaces suffisient (except > maybe for an Iterator.next(Object) method)? I agree that we may need > a new Iterator interface > extending java.util.Iterator, but shouldn't it be the only one? Negative. They are insufficient because they do not guarantee to the user that there will be no backing store. They are also insufficient because there are pre-existing implementations of the Java Collections interfaces distributed with every JVM since 1.2: someone might confuse the use of such an implementation with "Standard Java Practice". Catastrophe in the making. Check out Chapter 5 of the ISO 19123 primer - Draft 4. I have an example DynamicSet interface and implementation there. The interface extends java.util.Set and is essentially just a tagging interface: Implementations of DynamicSet promise not to maintain a backing store. The implementation extends AbstractCollection instead of AbstractSet because AbstractSet does Very Naughty Things with the equals() and hashCode() methods. There is also a Generator interface capable of iterating, reporting size(), and calculating contain()-ment. > > 6] Additionally, it becomes imperative to provide implementations (say, of > > interpolators) which never cause the creation of GridCells or GridPoints. > > This may require the creation of implementation-specific accelerator > > objects (e.g., recognizing that the DiscreteGridPointCoverage is backed by > > RenderedImage, and knowing how to obtain the RenderedImage object, > > translate the request into a JAI operation.) > > The old Coverage interface already provided an indirect way for that: > > Coverage.getRenderableImage(0,1).createDefaultRendering(); > > In the specific case of GridCoverage2D implementation for example, > it returns directly the > underlying RenderedImage. However, I agree that the above may not be > suffisient. For example it > doesn't say if the returned RenderedImage is the backing store or a > dynamically created image. But > does the user need to know that? RenderedImage is 2D. 3D Grids cannot return it, so sticking something like this on Coverage imposes some unwanted limitations. However, we _can_ make a RenderedImage implementation which selects a 2D slice out of a 3D or 4D grid. (Or even out of a 2D grid not backed by Java 2D.) The GeoAPI interfaces should be completely free of Java 2D influence. However, this doesn't matter. To isolate GeoTools from the particular Coverage implementation employed, we must write adapters between the 19123 coverage objects and Java 2D anyway. We can make these more efficient if our own implementation is used, but we certainly should not assume that an org.opengis.coverage.discrete.DiscreteGridPointCoverage object is backed by something that starts with org.geotools. :) > We need some way to provide interoperability with Java2D, but note > sure that we need tiling at the > interface level. They are managed by JAI. I will try to select some > methods from the legacy OGC > 01-004 that still of some use for ISO 19123 interfaces (exactly like > GeoAPI interfaces derived from > ISO 19111 kept some OGC 01-009 methods), and generate a new javadoc > for discussion purpose. And will > look at the proposed extensions in ISO 19123 primer :) I suggested Tiling to manage the ISO 19123 representational objects, not the actual data. :) ISO 19123 objects are a bigger problem than gridded data management--especially when the backing implementation already manages tiling for us! :) In terms of specifying Coverage Implementation Units, here's what I will do: I will specify a basic skelaton of classes needed for DiscreteGridPointCoverage and ContinuousQuadrilateralGridCoverage. I will only specify implementations for the classes associated with the PointFunction. I will defer specification of the derived CoverageFunction until a later date. Likewise, all methods which return a Set<GeometryValuePair> will for the moment throw an UnsupportedOperationException. At some later date, when interested people have had an opportunity to spin up on the issues and chime in, we can specify whatever clever implementations arise from the discussion. At that time, the unsupported methods can be revisited and fleshed out. Until that time, Chapter 5 can serve as a focus of discussion and people should feel free to download and edit to include a description of their own clever (efficient) implementation ideas. Bryce ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
