Hi Bryce, I will do my best to answer your questions :).
Bryce L Nordgren wrote: > FeatureCollection appears to be one of the items being overhauled as > part of the feature model effort. It's a toughie because it's a mix of > GML, the Java Collections Framework, and user needs. I realize you're > not done yet, but could I pick your brains about where you're headed? > I'm trying to tease out commonalities with Coverage, or at least a > relationship between the two. > > Q: FeatureList disappeared in gt/spike/complex. Is this intentional? > The GML natural language definition of a FeatureCollection is a "list" > and it is specified as a sequence. It would seem that FeatureList is > more necessary than FeatureCollection, especially since GML inspired its > existence. (Observation: In 2.2, FeatureList does not inherit from > List<Feature>, but probably should) > It is definitely intended to come back. I am not sure where you are looking at interfaces, but if you want a better idea of what the new model will look it you probably want to look at the interfaces that are part of the geoapi project. > Q: Visitor pattern and Event firing disappeared. Are they staying > disappeared? > The current geoapi interfaces don't have these. I believe there was a request to add visitor back in. And events make sense. In my opinion they should be there. > Q: When specifying a feature's schema, are all geometries considered the > same? (e.g., Can I say that field "location" is of type > org.opengis.geometry.Geometry, or do I have to name a particular > geometry like point, curve, surface, or solid?) In essense, does the > feature model type system permit substitution of a child for a parent. > Definitely, there is nothing that says that the type of an attribute has to be tightly bound to an instance of it, I think the only restriction is that they are related through some inheritance hierarchy. > Q: GML says that "a feature collection is a feature", but is there any > benefit at all to making this true with interface inheritance? Why not > provide an implementation class for Feature which sports a single > attribute of type List<Feature>? That's the literal definition in GML's > XML Schema (accounting for XML Schema types being more like macro > substitutions than Classes). You then have the benefit of polymorphic > code: anything written to operate on a feature collection could be > immediately applied to any feature containing a list of other features. > (e.g., boundary calculation, centroid calculation, etc.) Making a > separate interface encourages people to write code against the > FeatureCollection interface instead of against List<Feature>, > Set<Feature> or Collection<Feature>. Boo hiss. Your encoding rule to > GML would then be to emit a FeatureCollection whenever Collection, Set, > or List<Feature> is encountered in a schema. I suspect this would also > be true if FeatureCollection was a separate interface. You make a good point, and the feature model chooses the GML approach. The benefit of which is to be able to attach additional properties to the collection itself. A "gml feature collection" attaches the bounds property for example, A "wfs feature collection" attaches "numberOfFeatures", "timeStamp", etc... > > !!!!!!! > > Whoa! I just found Annex E&F of the GML 3.1 spec!! These address > mapping back and forth between properly expressed GML and the 19109 > model. As I recall, Jody and I were mainly wrangling over these > issues. My main disappointment is that the feature model is polluted > with constructs from XML Schema (Descriptors!), which is awkward because > 19109 is object oriented, and XML Schema is...well I don't know what it > is, but it's not object oriented. > > But there's a standard mapping! A GML document is considered to be > valid input to the mapping if it meets GML Conformance class B and obeys > some additional rules (Annex F). Basically, conformance class B says > that the GML Schema corresponding to the document must abide by the > rules for making a GML schema (defined in Clause 23). Are we planning > on incorporating Clause 23 into the GML parser? > > I _so_ get the feeling that our arguments over feature model are > reinventing the wheel. Someone else is already thinking this through in > far more detail than we ever will. Did you all know about this and just > didn't tell me? :) I didn't, but Jody has been following this more then I. > !DSPAM:1004,45707fa1170452207481331! > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > > !DSPAM:1004,45707fa1170452207481331! > > > ------------------------------------------------------------------------ > > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > !DSPAM:1004,45707fa1170452207481331! -- 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
