Cool ideas!! Comments inline. Bryce L Nordgren wrote: > > 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. > A couple of thoughts...
Often the attributes on the "Feature" part of the FeatureCollection are derived from the contents of the collection. For instance, in a GMLFeatureCollection, there is a "boundedBy" property on the feature, which corresponds to the bounds of the all the features in the collection. So... what does the api look like for keeping these things synced up? I imagine the Collection part we come up with will have some sort of event notification? Is it up to the person creating the collection to add a listener which keeps things in sync. Also, in geotools land, an important design principle has been that we want to promote data store implementors to write custom feature collections. For instance, for a jdbc based datastore, we want the collection to be closely wrapped around a "Result Set" for performance reasons. Which still seems consistent with this new FeatureCollection. The implementor will now have just have to extend the "Collection" part, providing a custom iterator of sorts. So yeah ... i am liking this design. I also like that it is very non-intrusive toward geoapi, most of the details are geotools implementation. What does Jody think of all this? He is really the mastermind behind the current FeatureCollection design, I am interested to hear what he has to say. -Justin > Bryce > > > !DSPAM:1004,4575e00c8031995013331! > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
