You may have noticed that my emails have a rather theoretical, exploratory bent to them. :)
[EMAIL PROTECTED] wrote on 12/01/2006 12:54:54 PM: > Bryce L Nordgren wrote: > > 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. Copy that. "svn update geoapi/branches" successfully executed. > > 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. My concern is perhaps best expressed as follows: GML is XML schema, which is basically a data transport mechanism; so every last behavior was added by us. We have created a FeatureCollection which is wearing two hats. It's a Feature and it's a Collection. I believe better separation of concerns would be achieved if FeatureCollection were the _composition_ of a feature and a collection. FeatureCollection would still be a Feature _and_ a Collection, but this is implemented with composition. If we separated things in this way, we would be able to write advanced, spatially-aware collections (with a variety of spatial indices) which could then be composed with the GML Feature Collection or the WFS Feature Collection. Or, we could write new types of FeatureCollections as the needs arise; _without_ re-inventing all the nasty spatially aware Collections code. Secondly, and this is a question for any who care to chime in: is the Java Collections Framework (JCF) adequate to represent a spatially aware collection? It is based on the premise that all objects can be somehow distinguished in 1D (via a hash code or via Comparable interface). Spatially aware collections, capable of efficiently locating one item among many, would seem to require more than this. Basically: can we do a good job implementing spatially aware collections with the interfaces provided by JCF, or do we need to extend those interfaces? I think I'll ask this over on JTS-devel as well... It's something to think about if we are still at a crossroads. > > 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... My concern with "adding properties" directly to interfaces is that all implementations must explicitly ensure that those properties are advertised in the feature's schema. They must also provide a second means of accessing those properties (interface methods and the generic feature). It's not part of the feature until it's advertised as a feature property and accessible through the generic feature accessor methods. I suppose that as long as this is done, we could still realize the benefits of polymorphic code if we encourage people to write code against the generic feature interface instead of against the FeatureCollection interface. We just need to harp on this whenever we extend the feature interface with another interface: ALL IMPLEMENTORS MUST ENSURE THEY ADVERTISE ADDITIONAL PROPERTIES THRU THE GENERIC FEATURE MANIPULATION MECHANISM!! > > 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. Well it certainly looks like GML is evolving into an explicit encoding of 19109, and it looks like OGC/ISO recognize the difference between what is possible with XML Schema modeling and what is possible with OO modeling. It also looks like they're constraining the allowable GML expressions until it is possible to perform a bidirectional mapping between the two. I am far beyond arguing that any changes be made to the model at this point. I just wish I'd known about this last January. Most of the opacity of the current feature model (to me) is the hybrid mixture of XML Schema concepts with OO concepts. I think this will forever be my achilles heel, and I think it will be the first stumbling block encountered by new programmers. I would find it much more intuitive if the core model was "either" XML Schema or OO, and we defined translations between them. That sounds a lot like I'm arguing for change. Shut up Bryce. :) Bryce ------------------------------------------------------------------------- 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
