Andrea Aime wrote: >> As someone who has implemented a feature collection before, I can say >> that time and effort is spent implementing methods that will rarely be >> called client code, only because they are part of the Collection >> contract. Bit of a chicken and egg scenario here, since we cannot use FeatureCollection's right now as first class entities in our schemas. If we do get into complicated models I expect FeatureCollection *will* be a feature, have an identity, contain members etc...
Need to talk to Rob who is the only person looking at using FeatureCollections right now for more then shuttling data around. > Hem... the OGC model say that a FeatureCollection is a Feature indeed, > then I ask you, what is the FeatureCollection identity? Surprise, it > does not have one. This is because we are mixing two different concepts: > * collection as part of an object model. This is stretched, but it may > be that we can somehow build an identity for it, thought I'm not > very convinced. Need to find a real example, there may be a use case in Gabriel's work on the wiki. > * collection as a query result. This has no identity at all, it's just > a transient thing that allows me to access the results. Point taken; and this is the same separation between the hard reality of I/O based data access, ease of use, and modeling. > As for attributes, what are the collection ones? Hmm.. we could say > it has a size, but again, this seems to me like forcing a cube into > a round hole. The OGC model defines a few, description, bounds (but not size), and it is open ended allowing you to provide other information as approprate for your domain. I am a little confused on this front as I can see providing nice summary data about the contents (OGC reference model says that the collection is only defined in terms of its contents != empty feature collection cannot exist), and a FeatureCollection's use in terms of modeling real world concerns. I understand that if a FeatureCollection represents something (even aggregation) the information is more correctly stored as part of the relationship, ie question, rather then feature collection attributes, ie result) > Does FeatureCollection hold a Feature? It holds a collection of them > for sure. I think it is more that a Feature Collection describes a group of Features, that may be associated together via a common relationship (ie in response to a query), or by hand (ie Fid Filter ), the reference model had an example with an airport or something. > Does a FeatureCollection hold a collection? Hmmm... FeatureCollection > as it is now is just a mediator, not a data holder.... I could handle that, we even have a good "name" for this bean property in the form of "members". > Yes, it could give you back an in memory based standard collection. My > point is, if you want the easiness of standard collections, you have > to be prepared to give up scalability. Not sure about that, I am happy to not give up scalability and make a collection that is beyond the ones people are used to from standard in memory use. We have a couple examples (other then ourselves) of projects making the trade off. But this is the subject for a different email thread. Jody ------------------------------------------------------------------------- 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
