Hi Adrian, On Wednesday 26 March 2008 12:21:36 pm Adrian Custer wrote: > Hey all, > > Working my way through the new feature model, there is a lot of overlap > between the old effort and the new. It's unclear how much of this is > work-in-progress, how much is not-yet-deprecated cruft, and how much is > purely my confusion. completely understandable. Lets see if I can help bring some light, Jody/Justin correct me where I'm wrong.
Feature: ogt.feature (gt-main) should be clear and have no reference to the old geotools feature model whatsoever. Yet, it should be considered work in progress except for SimpleFeature/Type, which are the only ones widely used. FeatureImpl, ComplexAttributeImpl, AssociationImpl were ported for the sake of completeness but would need a serious assessment (I found what seems to be a mistake in FeatureImpl.setDefaultGeometryProperty for example) > > I hope we could clean some of this up and add explanations to the > documentation to help the next person trying to sort out featureNew. > > Notation used below: > oog is org.opengis > ogt is org.geotools > > > FeatureCollection and events: > ---------------------------- > oog.feature has: > FeatureCollection > DataFeatureCollection > FeatureEvent > FeatureListener > > ogt.feature (in gt-api) has: > FeatureCollection > CollectionEvent > CollectionListener > > > Is oog.feature.FeatureCollection currently unused, with > ogt.feature.FeatureCollection used instead? Is this work-in-progress? Is > the geotools version really a SimplefeatureCollection but not renamed to > avoid impacting user code? FeatureCollection: oog.featurecollection is not used, and is not gonna be used. Say oog.FeatureCollection plays the same role for the geoapi data access api (org.opengis.feature.FeatureStore) the geotools FeatureCollection plays for the gt data access api. Yet the geotools FeatureCollection is waiting for a change proposal from Justin to make it really simple, getting rid of java.util.Collection and the like. > > Is oog.feature.DataFeatureCollection an old idea since it is not used > anywhere in geotools? If we want to keep it, could its name be changed > to something more descriptive liked ExternalFC or BackedFC or > PeripheralFC? Why are the listener methods here and not in directly in > the parent FeatureCollection (also,see next)? you mean the geoapi DataFC right? I've no idea. If it were for me I would delete it (or rather remove from geoapi release) together with the data access api in there. > > There are several very similar event and listener classes: > oog.feature.FeatureEvent and oog.feature.FeatureListener > ogt.feature.CollectionEvent and ogt.feature.CollectionListener > ogt.data.FeatureEvent and ogt.data.FeatureListener > Could we rename the GeoAPI interfaces are to be kept, can we rename them > to FeatureCollection[Event/Listener] to clarify what they are for (also, > see previous)? Can we simplify the overlap between these classes in any > way? Could we add some javadoc explaining the difference between these? something else I would remove from geoapi. Basically, we decided to use the geoapi feature model but found during the geotools lifetime that a geoapi data-access api were first introduced by some private company helping set up geoapi and never was good enough for geotools or we never had the intention to get tied to geoapi interfaces for geotools (guess gt changes faster than geoapi allows) > > > Gt API Name, NameImpl: > --------------------- > These are essentially identical with the latter having been edited more > recently. Can we change the former to extend the latter and deprecate it > or simply remove it? that's a surprise to me. I though we only had NameImpl.... seems like a mistake to me and we should just remove one of them (Name). > > > Gt API filter: > ------------- > Most of the classes in ogt.filter in the gt-api module seem to be > deprecated but this appears to not have been done systematically so, for > example, Expression is deprecated but not ExpressionType which it > extends. So what's going on? That's a (huge) technical debt of the library (and thus of us) <http://docs.codehaus.org/display/GEOTOOLS/Technical+Debt>. The change to geoapi filter was supposed to fully happen for 2.4, I tried and did some of the move to geoapi filter, others did the same, but we got stuck on some datastores being really difficult to port and lack of spare time. > > enough for now since as I dig, I'm getting more confused. keep asking, or we get all confused or we get something in clear Gabriel > > --adrian > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplac >e _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > !DSPAM:4045,47ea31d864701849620573! ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
