Bryce L Nordgren wrote: > 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. > And that is exactly the feedback Martin gave me :-P Nice when people agree. >> 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. > I wonder w/ respect to Coverage extending Feature if they are just advertising a few attributes (such as bounds?) > 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. > Interesting, okay that can work for me. > 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. > I have been thinking about that (and you can see the work occurring on the various Pojo datastores), however I am also attracted to the earlier suggestion of defining "Mix-ins" where an an operation is defined against a set of specific attributes (captured with Java interface or data structure?) and then we can make a wrapper for each feature that has the correct attributes; this would separate the definition of operation code from the identification of types where the operation can be used.
This would all be under the covers of the feature model; in much the same way as the recent XPath support is under the covers of the Filter implementation. From the point of view of end-users the features would show up with some operations at the end of the day. >> 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 following page should be sufficient (the long and short of it is that expression is starting to work against features, featuretypes and pojos - with xpath support): - http://docs.codehaus.org/display/GEOTOOLS/Expression+Improvements For my own interest I need to understand how RasterSymbolizer uses Expression to suck out real values in order to produce a visual. >> 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. > So use a Map as a representative sample is the only way to bridge - or recognize that Coverage is a different thing and identify superset of the java collections classes (may wish to talk with the jscience people here)... > 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? > I was speaking more in terms of writing Adapters as a nice way of letting you program coverage as is - and then making adapters to connect the result to various UI widgets as needed. Bryce have you looked at GeoAPI Feature Model recently? We have Complex (the supertype of Feature) and is very similar to your ISO Record. Mostly we are breaking appart due to problems with ISO use of Name (and TypeName literally being the super of Record or some madness). >> 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. > I see so rather then use Complex (or GeoAPI Record) you would back yourself onto another dynamic type system - namely JDBC ResultSet (and ResultSetMetadata) or the different table models. > I'll go look at emails regarding Expression and come back when I'm less > dumb. > Well if you want have a look at RasterSymbolizer (the point of contact between coverage and expression) and then we can have a nice IRC chat. 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
