Message-ID: <430750100.46664.1414742657271.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_46663_613975705.1414742657270" ------=_Part_46663_613975705.1414742657270 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This page is a follow up to geotools-devel discussion asking the= important question: How to represent parameters that are expected to captu= re an interaction?
I would like to propose two simple modifications to the Parameter = class, to enhance the semantics of geoprocesses. They both can be implement= ed as new hints, and made available through the DescribeParameter annotatio= n
- A hint describing dependence of one parameter to another. The most typ= ical use for that would be to indicate the relation between a String parame= ter representign and attribute and a FeatureCollection. That would allow th= e user interface to make it easier for the user to select the field, as it = could be taken from the list of available ones for the selected FC
- A hint describing the group of optional one a parameter belongs to. So= me processes have a set of 2 or 3 parameters, from which just one has to be= used (see the ContourProcess for example). If these grouping is not explic= itly described, the UI will let the user fill all parameters or none of the= m, instead of enforcing using only one of them.
As you can see, it is a very simple thing, but I think that would add mo= re robustness to the process semantics. Adapting existing processes to this= change is trivial and should take little time to do.
Looking forward to knowing your opinion on this.
Here are the code examples.
This example is interesting as both DISSOLVE and ATTRIBUTE "l= ook up" in their group for the parameter providing a "schema"= ;. Attribute allows more than one attribute to be defined, using the same T= ransform Definition thing as the transform process.