Only thing I would add is Geometry parameters. There is a common way to package up geometry provided by the WPS implementations like 52N. It is basically a small schema that allows a single geometry element to be passed in or out of a process.
Jim will know more. Jody On 11/06/2010, at 11:19 PM, andrea antonello wrote: > 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 <aa...@opengeo.org> 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 >> Geotools-devel@lists.sourceforge.net >> 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 > Geotools-devel@lists.sourceforge.net > 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
