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)
Q: Visitor pattern and Event firing disappeared. Are they staying disappeared?
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.
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.
!!!!!!!
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? :)
------------------------------------------------------------------------- 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
