Here are some further thoughts on this matter: https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/FeatureModel#GML_Feature_Collection
Given this, we care about a FC as a transfer object I think - maybe it should be nothing more than a handle on a virtual set of Features, than can be serialised if desired, and unmarshalled into another FC instance. My own experience suggests that FCs come into play when we want to serialise relationships between features of different types, and defining a specialised FC can provide serialisation strategies (which types to serialise first to make serialisation and parsing easiest - but I'm not convinced the answer to this is straightforward either) The parallel we have encountered is a time-series. We often create a time-series as a result from a query into sample space. This can be encapsulated as a single Observation (or derived type) feature, where the observation method is the time series extraction, by subsetting or resampling (oh oh - a coverage operation here!) Thus, a coverage is closely related to a FeatureCollection, so that a subset is a coverage. At this point my brain explodes, and I need practical implementation challenges to focus my wild staring eyes.. :-) Rob Jody Garnett wrote: > 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 > ------------------------------------------------------------------------- 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
