Confluence and Jira are so awesome: can drop a topic for a season, then pick it up again right where you left off.
This is a pondering email to generate responses which guide my further thinking. 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? Can someone tell me if coverages would break existing feature code? My concern is with how coverages expose data. 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? 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. 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. 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? 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. THis is probably enough for today. :) 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
