[EMAIL PROTECTED] wrote on 01/02/2007 09:32:28 AM:
> As for the debate in general, I do think you can get a lot of the > advantages of people's familiarity with the Collection API by just coding > it to be similar, without necessarily completely implementing its > interface. And we can do the same with feature/featureCollections - I > like the idea of having some of the same convenience methods, like > getBounds. But it may be stretching to insist that they really are the > same thing. Though our feature model should be rich enough that we could > express things that way if we really wanted. > > But I'm not going to be able to keep up with the debate, but I think it's > a timely one to have. I tried to describe the current feature collection framework in GT w.r.t. GML/Java Collections Framework/and coverages. Section 2.1.3 of the 19123 Primer. http://docs.codehaus.org/download/attachments/31212/ISO19123+Primer.pdf As I was writing this, I suggested to Justin: > 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. If you can figure out how to search the GT-devel archives, the thread topic is "FeatureCollection questions" and took place around the beginning of 12/2006. That's pretty much the only useful(?) thing I have to contribute design wise. Note that collections as specified above would be useful for implementing coverages, for identifying features on a map, for in-memory queries ("nearest-to-a-point"), etc. 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
