Bryce L Nordgren wrote: > Confluence and Jira are so awesome: can drop a topic for a season, then > pick it up again right where you left off. > Hiya Bryce :-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. 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... > 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).
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. > 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 ... > 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. > 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. > The quadrilateral gridded data coverage has a number of specialized > possibilities. Adaptors to and from java.awt.image.Raster and TableModel > (cells return data values of a single numeric band) spring to mind > immediately. > Aside: GridCoverage is deprecated on GeoAPI trunk; but no alternative is provided (!) If we do not have a replacement can we remove the deprecation please. > THis is probably enough for today. :) > Cheers, Jody ------------------------------------------------------------------------- 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
