Thanks Justin; I will update the proposal. And indeed it is a "day" (although it felt like a week).
No rush on this one I presume? You are not going to be back into the thick of things until your GeoServer release goes out; and Andrea has a date with Query hints (more of a showdown at dawn, guns drawn with coffins ready). Jody > 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! >> > > ------------------------------------------------------------------------- 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
