Jody Garnett <[EMAIL PROTECTED]> wrote on 11/09/2006 04:37:57 PM:
> Bryce L Nordgren wrote: > Hiya Bryce :-P :-P > > If there were such a thing as a Map, where the Keys were geometry objects, > > and the Values were a particular arbitrary class (possibly containing > > geometry objects); this is almost precisely the definition of a coverage > > via 19123. (Make the keys "DomainObjects" to be perfect.) Does anyone > > object to making the Coverage interface extend Map? The implication is > > that the individual entries in the Map are not themselves Features. (This > > agrees with 19123.) The coverage itself is the feature. The drawback to > > this analogy is that Maps have a size() and can generate a finite keySet, > > entrySet, and Collection of Values. A coverage does not necessarily have > > any entries (it could calculate Values from an equation which accepts > > Keys.) Any opinions on whether this size()/keySet()/entrySet()/values() > > issue should influence the extension of Map? > > > Well the KeySet does not have to store individual entries; only provide > an iterator to them. Good point. But iterating over an infinite set is also problematic. > In FeatureCollection land we probably should have the same relationship > between a KeySet (lets call it FidSet) and the contents > that you describe above. Something to consider is a subclass of Set that > supports spatial query... Hmmm. I think you're describing TransfiniteSet ala 19103, which is a superclass of Set. Both have contains(), but Set can have iterators. The iterators bite us. > > Can someone tell me if coverages would break existing feature code? My > > concern is with how coverages expose data. > I have been waiting to hear back on this; RobA has had feedback a couple > times on this - in a similar fashion I need to understand how a > "operation" is used to define a coverage to ensure that the Feature > Model Operation and Coverage Operation can get along. > > You get data from a coverage by calling the "evaluate()", > "select()", or "list()" methods and providing a location. (Discrete > coverages have more methods to access data and more > > associations with data-bearing-entities.) A coverage does not expose data > > via attributes. This is obviously only a concern if Coverage extends > > Feature, and client code is written assuming all Features expose data as > > attributes. Is this issue important or trivial? > > > Not sure I understand; some points of reference: > - Coverage is intended to extend Feature > - Feature access is safely done via Expression > - SLD allows you to define Expressions against a GridCoverage as part of > a RasterSymbolizer (assume it selects out "record values" representing > different bands for use in mathmatical expressions resulting in one of > Red, Green, Blue for visualization). We might be able to make Coverage extend feature. We might also just want to provide a coverage implementation of the Feature interface. The second one might be more in line with the spirit of 19100. I haven't really resolved this issue in my own mind yet. Regardless, a "Coverage" will be manipulated with the feature interface. A "Coverage" will advertise a standard set of operations (list(), select(), find(), evaluate(), evaluateInverse()). It's just like determining methods using reflection on a class, only we're exposing the "operations" using the feature interface. At least that's how I recall it should work. We could make a POJO<->Feature adapter which exposes public fields as Feature attributes and public method signatures as Feature operations. Then we just write Coverage as a POJO and adapt it into the Feature interface. But we'd have to allow run-time extension. I think this is why I was looking at EMF. I'll have to dwell on this one. > So as long as Coverage understands Expression (see recent email > messages) you should be fine. What is interesting is ensuring that the > Coverage supports enough description about its contents to allow users > to create useful expressions. Righto. I need to delve into archives w.r.t. Expression. Gotcha. > > The special case of a discrete coverage is just a collection of homogeneous > > records (not themselves features) which are indexed by geospatial location. > > A discrete coverage is very much like a database table. A discrete > > coverage _can_ provide values for size(), can generate the Sets and > > Collections listed above, and can therefore fully implement the Map > > interface. > > > Understood; and I wonder in what sense a Coverage cannot? (Perhaps it is > a pure math coverage of infinite precision? In which case the logical > thing to do would be to create a KeySet can test set membership but have > "Integer.MAXINT" for size()? But you are correct the model would be > broken ... Bingo. Broken model bad. Don't forget can't iterate over an infinite set. Two broken contracts. > > An implementation of DiscreteCoverage could also implement TableModel. > > (More generically, we could write an adapter which provides TableModel > > functionality given a DiscreteCoverage, and vice versa.) DiscreteCoverage > > would also lend itself to implementing (or adaptation to) > > java.sql.ResultSet. Both options explicitly communicate that a > > DiscreteCoverage is a set of entries, each of which have the same > > attributes (columns). These adapters probably should be written in terms > > of Map.Entries, if Coverage extends Map. > > > I would be a bit happier if we implement it as what it is; and write > adapters to TableModel (swing) or DataProvider( SWT) etc... we can use > other code for help in naming of course. Adapters are good. I just wanted to emphasize that coverages enforce "all records contain the same fields" and aren't just arbitrary collections of heterogeneous features. If we write an adapter to DataProvider, do we need another library? Is there an SWT extension module to collect code which interoperates with this library? > > Is TableModel happy with SWT folks or does this display a Swing bias? Any > > heartburn with ResultSet, or is there perhaps a better JDBC-related > > alternative you would like to propose? > > > ResultSet is fine? But I think I need more understanding of what you are > trying to accomplish first. Well, I was thinking of exposing the coverage contents using "normal" java idioms. I'm not thinking of this for GeoAPI, mind you, but for the various implementations. It could also go the other way. A coverage could wrap a ResultSet (containing domain/range pairs). So, generic geospatial code using Coverage.evaluate(), Coverage.select(), etc. could actually operate on a remote data store. > > THis is probably enough for today. :) :) I'll go look at emails regarding Expression and come back when I'm less dumb. Bryce ------------------------------------------------------------------------- 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
