Thanks for looking at it Justin, my bad forgetting that we had swapped these over to a class rather than an interface. The joys of java having two type systems.
Sorry it took me a while to respond - here are my notes/questions/research:
Q: Is it possible to make a fake CoverageInfo around a chained GridCoverage?
Prevent defining the same process twice when defining processes in GeoServer. You could fill in the getGridCoverage(ProgressListener listener, Hints hints) method etc…
This would not help geotools at all, but would prevent you having to introduce CoverageSupplier interfaces.
So this is a quick/clean alternative if you want it. Not great due to the number of CoverageInfo methods.
Q: Do you need to define Supplier / CoverageSupplier at the GeoTools level?
Yep, alternative is wrapper CoverageInfo as described above.
Approach is similar to the Provider interfaces/classes out of uDig:
uDig API is largely the same as you propose, takes some effort to account for blocking, parameters, and so on not sure if you want to consider such things at the moment.
Q: Can we use Property to smuggle extra data in here to avoid duplicating similar data structures?
Not really, even though api is not stable it is entrenched.
Compare:
Parameter is already used to document Map<String,Object> (i.e. key/value) parameters for both datastore factories, functions, and processes.
The kicker here is that we want a more capable data structure to pass values into a processes, similar to have feature model works with Attribute values (each has a getUserData map).
May be worth
Q: Can we use Supplier to get a handle on some of the magic book keeping GeoServer does?
GeoServer tracks resources consumed during process execution using thread locals, in addition to being complex, it is rather opaque to developers writing processes.
We may indeed be able to, so a process defined as taking a supplier …
public static Supplier floor( Supplier dem, Polygon area, ProgressListener progress ) …
Would give a process a chance to register any resources (say file) that needs to be cleaned in the returned metadata map.
Aside: Although Supplier seems to be more complicated then our quick annotations allow for, may be better to keep it for hand created processes.
Q: We already have resource wrappers in GeoServer can we combine forces with Supplier ?
See:
I see no reason why these could not implement Supplier allowing GeoServer to smoothly hand the objects over to a process. Currently they are all kept behind the scenes, used to stage data prior to calling the process.
···
On 1 September 2015 at 06:33, Justin Deoliveira <jdeolive@anonymised.com> wrote:
Hey guys,
I took another look at this trying to implement what Jody suggested… and I don’t think it will quite work with a wrapper or a proxy. Reason being that most raster processes actually take GridCoverage2D rather than GridCoverage. I think trying to wrap that class will be a bit messy and proxying a class would require a CGLIB dependency… all in all getting to be a bit hairy. Staying along the same line though I think introducing a new interface in GeoTools, something named CoverageSupplier (modelled after guava/java8 supplier interface) would work. Basic idea would look like:
interface CoverageSupplier extends Supplier;
With that it would be easy enough for GeoServer to plug in an implementation that provides access to the catalog metadata when it is around. Although I am not sure how to do this and make the process GeoServer agnostic… another class or interface I guess to represent all of that same metadata… maybe just a simple map structure would do:
interface CoverageSupplier extends Supplier {
Map<String,Object> metadata();
}
This would give me what I need in a general way. If folks think that is a good idea I can continue down that path (and btw I would want to add the equivalent supplier interface for FeatureCollection). If not though I think I may just fall back to my original approach which is to be able to declare an input directly on CoverageInfo.
Thanks!
-Justin
–
Jody Garnett
On Wed, Aug 26, 2015 at 12:23 PM, Jody Garnett <jody.garnett@anonymised.com> wrote:
Sorry if my example was not clear,
The answer is that a GridCoverage would be sent in, and you could do and instance of check to access to a ResourceInfo if needed.
String name name( GridCoverage coverage ){
if( coverage instanceof AccessInfo ){
ResourceInfo info = ((AccessInfo)coverage).toInfo();
return info.getName();
}
return “unnamed”;
}
–
Jody Garnett
On 26 August 2015 at 09:52, Justin Deoliveira <jdeolive@anonymised.com> wrote:
On Wed, Aug 26, 2015 at 10:28 AM, Jody Garnett <jody.garnett@anonymised.com…> wrote:
I would make a new interface that allows access to the ResourceInfo …
interface AccessInfo {
ResoruceInfo toInfo();
}
And then wrap the GridCoverage in a proxy that also supports a AccesInfo:
class GridCoveageWrapper implements GridCoverage, AccessInfo {
GridCoveage delegate;
ResourceInfo info;
…
}
Or similar, if I was smarter I would make it as a DynamicProxy so I could clean apply InfoWrapper around any parameter … since you are a smart guy I bet you could make that work 
Sorry but what does this buy me over the approach I thought of? The CoverageInfo already provides access to the grid coverage… so this seems like just adding a superfluous interface?
Jody
–
Jody Garnett
On 26 August 2015 at 08:51, Justin Deoliveira <jdeolive@anonymised.com> wrote:
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:Identifierinput</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