Hi,
I would like to add support for “raw” inputs for WPS processes, that is, processes
that have either inputs or outputs that are binary streams, and that do their own
parsing (e.g., let’s say we are wrapping some command line utility such as gdal_translate).
In terms of inputs we need:
- a way for the process to advertise the supported mime types (so that we can generate
the process description accordingly) - a way for the process to grab the raw data
- a way for the process to know in which mime type the raw data is in
Advertising wise, I would add a new item in the Parameter metadata map,
called MIME_TYPES, that would contain a static list of accepted mime types.
A process that needs to receive a raw input would then have a special argument type,
let’s call it RawBinary, that conveys both the data and the selected mime type:
interface RawBinary {
String getMimeType();
InputStream getInputStream();
}
GeoServer WPS would notice the special type, and feed the process with the
raw input.
For raw outputs the situation would be a bit more complicated, all the process
needs to do is to generate a InputStream that GeoServer can read from,
but we’d need to:
- advertise the list of supported output mime types
- pass down to the process the chosen mime type
I’d say that for this case in the Parameter we’d have two new entries,
MIME_TYPES just like for the inputs (list of supported output mime types in this case),
and the name of a input parameter (REQUESTED_OUTPUT_MIME)
that would be used by GeoServer to pass
down the chosen mime type (which of course would not be necessary in case there
is a single output mime type).
Java wise, given that all these things are quite WPS specific and not something
a generic non WPS process writer should be concerned with, my idea would be
for GeoServer to have custom extra annotations describing these parameter:
@DescribeRawResult(name = “result”, description = “Output raster”, mimeTypes = {“application/json”, “text/xml”}, selection = “outputMimeType”)
RawBinary execute( …
@anonymised.com(name = “data”, description = “Input features”, mimeTypes = {“application/json”, “text/xml”}) RawBinary myInput
…
String outputMimeType);
Alternatively, the existing java annotations could become open ended by having a KVP sub-annotation array in a meta field:
@DescribeResult(name = “result”, description = “Output raster”,
meta = {@KVP(key = “mimeTypes”, values = {“application/json”, “text/xml”}, @KVP(key = “selection”, value = “outputMimeType”)}
RawBinary execute( …
@DescribeParameter(name = “data”, description = “Input features”) ,
meta = {@KVP(key = “mimeTypes”, values = {“application/json”, “text/xml”}) RawBinary myInput
…
String outputMimeType);
Personally I somewhat prefer the first, as it’s more compact for the user, even if
Then there is the python scripting side, there we have it easier, since we are talking about bindings
that can be used only for WPS regardless, I guess we can just add some entries in the parameter description,
mimeTypes and mimeTypeSelection, and be done with it, what do you think?
I’m not sure if the streams should be wrapped into something more pythonic before passing them down
to Jython
Feedback welcomed!
Cheers
Andrea
–
==
Meet us at GEO Business 2014! in London! Visit http://goo.gl/fES3aK
for more information.
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
