On Wed, Jul 27, 2011 at 4:34 AM, Jody Garnett <[email protected]> wrote: > Hi Andrea: It seems my reply got gobbled by a bad email program. > > a long long time ago, in a svn revision far away, Lisasoft contributed > an aggregating WFS data store: > http://svn.osgeo.org/geotools/branches/2.4.x/modules/unsupported/aggregating-wfs/src/main/java/org/geotools/data/aggregating/ > > Did you want me try and round up a contact for you from our Adelaide office.
No need. The old code is of little use, it's really simple but hardly usable in a production setting. > - has a target schema (the first one in list) and can aggregate the others > with some leeway on schema differences (ignore extra attributes, > nullify missing ones, eventually accept case differences in attribute names) > > I imagine the use of Expression here (as with uDig "re-shape" operation > which allows you to transform from one feature type to another for simple > features). I think the same idea is in play for the Join proposal. Oh no, I will not got there, just make some simple case insensitive lookups in case the case sensitive one fails . But if someone wants to follow up and make it reshape the feature type via expression we can talk about it. Thought I would prefer to see that done in a separate "transforming" data store that only does that for a living. > - can tolerate some of the stores being unavailable > > Will you cache results in like a local H2 datastore or something? Or just > have less content when the datastore is MIA. Less content > - can get features in parallel from the sources and merge them in a single > response (this one has still the jury out, it might be done in a purely > sequential way too) > > See above about using a local H2 datastore as a "staging area". No, can't have caches, the content needs to be fresh. Again, we could a caching data store, but that would be another one. Trying to cram too much functionality into a single class is bad practice, bad for reuse and code understanding. > - assumes there are no feature duplicates around > > Could always make the feature id more interesting in order to avoid the > appearance of duplication. Ah, yeah, the ids will be rebuilt of course, in such a way that we know what the original store was in order to serve properly fid filters (so expect long ids). > Of course the code would be developed in unsupported and then eventually > migrated to supported status. > > +1 on the creation of an unsupported module (based on this email). What did > you want to call the module. gt-data-aggregate I was thinking just gt-aggregate, or gt-feature-aggregate (raster is data too) > Opinions? > > Sounds like a great bit of work; did you want the link to the udig "reshape > operation"? Or did you want me to back port it as a gt-process... The pie in the sky dream would be to have a data store/feature store wrapper that can do reshaping read/write. A process would be nice too, and easier to code. Cheers Andrea -- ------------------------------------------------------- Ing. Andrea Aime GeoSolutions S.A.S. Tech lead Via Poggio alle Viti 1187 55054 Massarosa (LU) Italy phone: +39 0584 962313 fax: +39 0584 962313 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.youtube.com/user/GeoSolutionsIT http://www.linkedin.com/in/andreaaime http://twitter.com/geowolf ------------------------------------------------------- ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
