Justin Deoliveira <[EMAIL PROTECTED]> wrote on 12/04/2006 05:31:13 PM:
> Bryce L Nordgren wrote: > > [EMAIL PROTECTED] wrote on 12/01/2006 12:54:54 > > PM: > > > >> Bryce L Nordgren wrote: > > My concern is perhaps best expressed as follows: > > > > GML is XML schema, which is basically a data transport mechanism; so every > > last behavior was added by us. We have created a FeatureCollection which > > is wearing two hats. It's a Feature and it's a Collection. I believe > > better separation of concerns would be achieved if FeatureCollection were > > the _composition_ of a feature and a collection. FeatureCollection would > > still be a Feature _and_ a Collection, but this is implemented with > > composition. > > > > If we separated things in this way, we would be able to write advanced, > > spatially-aware collections (with a variety of spatial indices) which could > > then be composed with the GML Feature Collection or the WFS Feature > > Collection. Or, we could write new types of FeatureCollections as the > > needs arise; _without_ re-inventing all the nasty spatially aware > > Collections code. > Ok, this makes more sense now. Thinking... I do like this approach. It > addresses two issues i had with trying to implement this api. The first > was that keeping the type of the feature collection, and the type of the > features in the collection separate without breaking my mind. My problem starts with trying to figure out "the type of the features in the collection" if the collection is mixed. I couldn't even tell you what that means. :) > The second was that is was a pain to try and reuse all the feature code > and the spatially aware collection code through subclassing at the same > time. We had to break out a feature "mixin" object, which just didn't > seem right. See below for idea. > > Secondly, and this is a question for any who care to chime in: is the Java > > Collections Framework (JCF) adequate to represent a spatially aware > > collection? It is based on the premise that all objects can be somehow > > distinguished in 1D (via a hash code or via Comparable interface). > > Spatially aware collections, capable of efficiently locating one item among > > many, would seem to require more than this. Basically: can we do a good > > job implementing spatially aware collections with the interfaces provided > > by JCF, or do we need to extend those interfaces? > Jody came up with an extension to the collection interface which > addressed some of our concerns. The biggest one being the closing of > iterators, as a spatial collection is usually sucking up some sort of > resource. I asked this question on JTS devel, and received the following answer from Martin Davis: >My thinking is that this is not a question of efficiency, but a question >of whether the semantics of the various collections reflects the typical >use cases for spatial functionality. The kinds of spatial queries that >are usually asked are: > >- range searches, based on an envelope >- proximity searches, relative to a point or envelope. > >The collections are intended for use with queries which involve testing >object equality or ordering. I don't think either of these is all that >useful for "spatial queries". To this, I would add that the 19123 coverage implementation requires both of these types of searches. For that matter, so does rendering. And serving up features from a WFS. And processing all features which lie within a defined area. And identifying the feature closest to a mouse click. Tell me if you find this reasonable: In GeoTools (not GeoAPI), we create a SpatioTemporalCollection interface as an extension of java.util.Collection<Feature>. Iterators and equality searches are inherited from the Java collections framework. SpatioTemporalCollection would add the two functions described above: range and proximity searches. I suggest we take the semantics of these searches from 19123. range searches: equivilent to Coverage.select(s:Geometry,t:TemporalPrimitive):Set<Feature> ; return a Set of all elements which "lie within" the provided spatio-temporal bounds proximity searches: equivilent to Coverage.find(p:DirectPosition, limit:Int=1):List<Feature> ; return a List of elements, no longer than "limit", ordered from closest to "p" to farthest from "p". The SpatioTemporalCollection must have some way to know which properties define the geometry of each feature. The closing of iterators should probably be moved or copied to this interface. If we add the visitor pattern, we add it here. To form the rest of the collection framework, the interfaces inherit both from the corresponding item in JCF and from SpatioTemporalCollection. It makes sense to define SpatioTemporalSet, SpatioTemporalMap, and SpatioTemporalList. We won't want to try the "SortedXXX" interfaces. FeatureCollection, then, is composed with SpatioTemporalCollection. FeatureCollection does not care about spatial searches, and doesn't do any of the work of maintaining a collection. It is mainly concerned with implementing the Feature interface and deriving the type of the component objects. It also adds any extra properties required by the context (appropriate for WFSFeatureCollection or GMLFeatureCollection). These operations will be horribly painful to implement. I think we should ensure that we only do it once. Hmm...This implies that FeatureCollection should either be moved from GeoAPI to GeoTools, or should be _just_ a data container. Unless, of course, we drop all of the SpatioTemporalCollection framework into GeoAPI, realizing that it's not based on any standard whatsoever. Bryce ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
