Jody Garnett wrote: > And thus the parts start to come back together ... >> I think you have communicated your intention just fine... its just >> that from my point of view while this seems like a very noble and >> lofty goal i dont think its very practical. Anyways... my two cents. > I am in agreement with you; and if that is not our goal (as a project) > then I would like to leave the word "FeatureCollection" out of the picture. > We cant... I would rather stick the the mess we have today then watch as 1000's of lines of code break. > I do happen to think ISO19107 FeatureColletion will be valuable - but if > we do not have resources/mandate/will to implement this right now (or > ever) then I would like us to do exactly that ... not implement geoapi > FeatureCollection. >> Lets not even mention ISO19107... we should really be refusing to >> allow specs like this one to influence what our classes look like when >> there is absbolutley *no* mandate to do so. Just because some spec >> that nooone without years of modelling experience can understand says so. > And this is where we are in agreement ISO19107 has its place; and I > think it is a good abstraction that has suffered from a very bad > presentation (and reception). Mostly that is entirly the fault of the > ISO standards body not making their standards in a way we can read them > for free. >> If someone really wants an ISO19107 FeatureCollection and wants to pay >> for it then giddy up. Lets give them a module and all that jazz and >> let them play. If not I suggest we focus on the minimum of what is >> useful for geotools and easy to maintain. > A very sensible viewpoint; and one we have taken. Now that they have > proven the idea works (several times on branches and unsupported > modules) it is time to figure out how to take advantage. OK... so lets stop going back and forth and try to nail down somethign that works for everything.
1. Keep the thing named FeatureCollection This keeps client code sane 2. Make FeatureCollection (including geoapi) *not* implement Collection Allows us to come up with a single base class that makes it easier for implementors. This includes implementing the Feature methods in the api *once* in the base class so again implementors do not have to worry. 3. Have FeatureCollection contain "FeatureIterator iterator()", and "visit(FeatureVisitor,ProgressListener)" Gives us the best of both worlds and again saves our client code. So how does that sound for everyone? If ok lets update the proposal and call it a day. -Justin > > Cheers, > Jody > > !DSPAM:4007,46af6b2f234047082231907! > -- Justin Deoliveira The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
