Andrea Aime ha scritto:
> Michael Bedward ha scritto:
>> Hi Andrea et al,
>>
>> Thanks for looking at ways to improve the process module !
>>
>> I'm happy with your comments about both VectorToRaster and RasterToVector.
>>
>> I would much prefer to have FeatureSource used rather than
>> FeatureColl
Michael Bedward ha scritto:
> Hi Andrea et al,
>
> Thanks for looking at ways to improve the process module !
>
> I'm happy with your comments about both VectorToRaster and RasterToVector.
>
> I would much prefer to have FeatureSource used rather than
> FeatureCollection unless that presents big
Hi Andrea et al,
Thanks for looking at ways to improve the process module !
I'm happy with your comments about both VectorToRaster and RasterToVector.
I would much prefer to have FeatureSource used rather than
FeatureCollection unless that presents big problems for others.
Michael
I am going to wait for Jim to answer that one; i can see the use for it if you
are writing a super specific process for a custom deployment (something like
fetch me the PDF reports for this county; and you pass in the county).
But here is the thing; in these cases the user has already defined a
Jody Garnett ha scritto:
> Only thing I would add is Geometry parameters.
Oh, and what about Feature parameters?
There is one example process that deals with the single
feature... having a hard time deciding whether it's just
a bad idea and feature collections should suffice, or
if there is an act
Jody Garnett ha scritto:
> Only thing I would add is Geometry parameters.
Oh right, roger that.
> 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 proce
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
Andrea Aime wrote:
> 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.
And I forgot to deal with multiplicity.
First off, if a parameter is marked as o
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 mea
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
10 matches
Mail list logo
