Hi folks,
I have a scenario where I want to write a GeoServer WPS process that takes
in raster input but then passes the raster off to another service to do the
actual processing. The other service takes the path to the raster as it's
input. So my problem is that it seems the established way to write a raster
process is to take a GridCoverage object as input, and from what I can tell
there is no easy way to get the original source of the coverage (which
makes sense). So right now to pull this off the grid coverage is written
out to a temporary geotiff file which is then passed off. I would like to
avoid this copy step and work on the original file directly if possible.
So I guess my first question is if folks have done anything like this and
if so how they approached it. If not I was thinking of the following
solution:
Rather than declare my input of type GridCoverage, declare it of type
CoverageInfo. From there I can get to the store and then to the file
backing it. I am also aware that a grid coverage could potentially come
from a non-file source. For these cases I still plan to keep the "copy to
geotiff" in place as a fallback.
Now I could just have my process take a string as input, interpret that as
a layer name, and then look it up in the catalog. But I was thinking adding
a bit of infrastructure for it (like what's there for accepting
GridCoverage and FeatureCollection) could be of general use. Also with that
approach I lose some niceties like a dropdown of layer names in the request
builder.
I sketched out an implementation of this and the approach I took was to
encode the input as a reference along the same lines as internal WFS/WCS
calls are made. In XML it looks like this:
<wps:Input>
<ows:Identifier>input</ows:Identifier>
<wps:Reference xlink:href="http://geoserver/catalog/topp:states"/>
</wps:Input>
With that it required a PPIO and an InputProvider and then it worked like a
charm.
Looking for feedback for this one. If folks think this is worth while I
will happily prep a pull request. Although I know it's close to feature
freeze time which is fine. Happy to wait.
Thanks!
-Justin
------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
