- ProcessingFeatureTypeInfo, ProcessingCoverageInfo, sub-interfaces of FeatureTypeInfo
If a process results in multiple outputs, how do you wire it to WMS/WFS?
So basically the FeatureType would have a metadata referring to the ProcessInfo, and potentially filling in some bits, like the input and the choice of output to be used.
Sure, sounds like a good idea.
Yep. I guess these would need validators just like sql views.
WFS cannot really do that, the structure of the feature type is described by DFT and has to stay fixed.
WMS uses attributes to validate filters and SLDs, but if ResourcePool is returning the feature type based on the current request parameters that should not pose a problem.
I see where you’re going. Uh, a bit painful to have to create the feature type, it’s hard to guess what a certain process will generate…
Maybe only allow chains of “streaming” processes to be used in this approach, so that you just get a feature collection with the proper
feature type, not even have to compute the features themselves.
A way to mark streaming processing would be useful also from the p.o.v. of deciding which processes to allow in the WPS configuration,
since non streaming ones are dangerous memory usage wise.
Looks good to me. What if I don’t want to chain processes, but just use a process as-is though? What happens
in that case?
E.g., I want to buffer all the features in a layer by a certain amount? Do I need a ProcessInfo in that case?
Cheers
Andrea
···
and CoverageInfo that have the notion of the process they are calling and that are able
to execute it, but besides that, they can be seen pretty much like normal resources
from the outside world
Interesting idea. One thing this would prevent would be a process that resulted in multiple outputs. But perhaps that is not all that big of a limitation. I’ll have to put more thought into this but from an WFS/WCS/WMS service integration standpoint this would certainly make things simpler. From a modelling standpoint I think the ProcessInfo approach might be nicer.
- do like SQL view and do not create a new resource at all, but just add the processing information
in the metadata view, and have the resource pool deal with it
I wonder if a hybrid approach would make sense. Basically adding ProcessInfo which contains everything we need to model the process execution. This is also nice because it gives WPS a dedicated resource in the catalog to work with. But for integration with the other services we use a metadata object, or whatever to reference the ProcessInfo object. And as you say the ResourcePool can handle it, invoking the process when need be to generate the coverage reader / feature source.
The SQL Views offer some other interesting direction, which is, view parameters: these processes
could get some of their inputs from the request directly, assuming of course that you also provide
some defaults to the param values so that the process can work even without the user providing
new values.
Yeah, this is exactly what i had in mind. However you define a process layer you can set it up with default values, any of which you can override on the fly in the request.
One concern about partial/parametric processes is that the structure of the output can change
depending on the inputs, for example, the feature type in output can contain certain attributes
depending on how the execution is parametrized.
Right, well currently for the most part we don’t maintain that much about the actual attribute list of the feature type right? Unless the attribute has been manually specified (which only happens with manual editing, or is a relic of an old configuration) we generally grab the attribute list dynamically.
So aside from making the resource pool smarter in terms of caching the attribute list for feature types backed by processes is there anything that will prevent us from handling a feature type whose attributes change dynamically?
And btw… in general, how do you compute the feature type generated by a process that
returns a FeatureCollection?
There is no way to get that besides running the process as far I know (which might take
a ton of time if the input is a large layer).
Right. This is sort of the same problem as computing bounds on a large table, if your table is massive you don’t want to auto calculate the bounds, and can specify it manually. Perhaps the same approach can be used here. We don’t calculate anything unless explicitly asked, and give the user a chance to configure all the things we need to publish the resource.
I would see it more naturally as a separate process factory that feeds off definitions that
we can store in the data directory, but not necessarily make layers.
Right. And I think this is the direction this feedback is going, to de-couple the two. So on the one side you configure your process chain, basically just specifying the new name for the process, the name of the process(es) involved, and perhaps allow for default values for some inputs.
And then on the other side configure a feature type or coverage, that points to the process chain, that can provide an additional set of inputs, ones specific to exactly that feature type.
