Hi Andrea, I am reading with interest this email, since I am nowadays extracting all the JGrass processing power into a library that implements for every module also the geotools process api. My choice in the lib has been to rely on FeatureCollection and GridCoverage2D, so I understand what you mean. Without the subcollection methods I would be dead in some cases.
So I would be +1 to keep them and rely on FC and GC2D. Ciao Andrea On Fri, Jun 11, 2010 at 3:09 PM, Andrea Aime <[email protected]> wrote: > Hi, > this week I've tried to make some of the processes in gt-process > run in GeoServer, as they presented some decent variety in input > and outputs. I succeded with some of them and found out a few > issues in the processes that the attached patch fixes. > > The patch however does not contain only fixes but also some changes > in the parameters. > The problem I've found working on these processes is that they tend > to have a large variety of input and output types, which makes it > harder to deal with them from the p.o.v. of a fully automated > client such as GeoServer is. > > In general, to allow a client to describe and handle all the inputs > and output of the processes there has to be some agreement on what > data types are supported and how to handle multiplicity. > > For example, the VectorToRaster has a java.awt.Dimension parameter. > I don't believe it's something that should be part of the interface > of a process interested in being used by a automated system, as > it uses a rendering related class, and the same information can > be easily expressed by using two doubles instead (which is the > change I did in the patch). > > It would be nice to have a short list of types that it's safe to > use in the in/out of a process that wants to be supported by > an automated client (which could also be uDig, maybe with a generic > GUI builder that uses the information in the input/output map > to build the GUI to configure and run a process). > > What I have in mind so far are all the primitive wrappers, dates, > strings, feature collection, grid coverage 2d, and referenced > envelopes. Do you think the short list should contain something else? > > Another general question that came to mind was if processes should > operate against feature collections or against feature sources. > The issue with using collections is that it's harder to query them, > in that light, removing the subcollection methods from the > FeatureCollection would make coding efficient processes quite hard. > Think of a process that needs to perform a vector overlay between > two polygon layers, you scan one layer and look for polygons > in the other layer that intersect it, in that case it's important > to be able to rely on query methods. > So moving forward I see two options: > - the processes stop using feature collection and start using > FeatureSource instead > - the processes use collection but we keep the sub-collection > query methods in the collection interface > > I was thinking more or less the same about coverages, instead of > using GridCoverage2D we could trade coverage readers. > However for coverages in theory we're playing with a set of > JAI operations that get chained so, always in theory, trading > coverage should be effective and more familiar to the programmer. > > Opinions? > > Cheers > Andrea > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Geotools-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
