[EMAIL PROTECTED] wrote: >>> I would like to see this as a single discrete object: with the list I >>> made above (FeatureType, Features, Summary) boiled down to a single >>> class. >>> >> Hum, FeatureType does not seem to be boiled down effectively, the >> FeatureType of a FeatureCollection simply does not make sense to me? >> I think I would expect getFeatureType returned the feature type of >> features contained in the collection, but that's not what happens (because >> the current implementation says FeatureCollection IsA Feature, something I >> don't believe it's right despite what OGC may say). >> > > It's been awhile since I fired up my brain to think about this, but when I > last did my thought was that getFeatureType on a FeatureCollection should > return a schema with a 'choice' of unlimited multiplicity of the > featureTypes of the features in the collection. If the feature model can > represent choice and multiplicities then it should be able to return this. > > Actually, its simply a sequence of generic Feature properties then multipe gml:FeaturePropertyType (or substitutable specialisations).
> And then for a MultiFeatureCollection (the implementation that can handle > more than one feature - ie from memory datastore and the like, or the > result of multiple queries) we should additionally have a > getCollectionTypes method or some such, which returns an array of the > possible featureTypes. And perhaps a TypedFeatureCollection with a > getCollectionType() method that just returns the single allowed > featureType, and will reject other attempts to add it. > > > But I'm not sure that's necessarily the way to go, it's just what I > thought at the time when we were trying to get it to implement Collection > and Feature and be backwards compatible. > > 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. > > best regards, > > Chris > > ------------------------------------------------------------------------- > 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 > ------------------------------------------------------------------------- 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
