Re: [Geotools-devel] Modification to Parameter class for geoprocesses

[Jody G. <jod...@gm...>]

I a considering combing the two ideas:  

a) Use GROUP to "indicate" the parameters in the same group work together
b) Use INTERACTION to indicate how they interact, if not interaction is specified then the parameter considered the subject or topic of the group (and is thus "enabled", or described by "metadata", or whatever)

Here is what that looks like …

DEM Metadata
===========

Parameter<File> DEM = new Parameter<File>("dem", File.class, "DEM File", "File to import",
    true, 1, 1, new KVP( GROUP, "elevation") );
Parameter<File> METADATA = new Parameter<File>("metadata", File.class, "Metadata", "DEM Metadata",
    false, 0, 1, new KVP( GROUP, "elevation", INTERACTION, "metadata") );


Exclusive
=======

Parameter<Double> interval= new Parameter<Double>("interval", Double.class, "Interval ",
   "Interval between contour values (ignored if levels parameter is supplied)",
   false, 1, 1, new KVP( GROUP, "contours", INTERACTION, "exclusive") );
Parameter<Double[]> levels= new Parameter<Double[]>("levels", Double[].class, "Fixed contour elevations",
   "Values of levels at which to generate contours",
   false, 1, null, new KVP( GROUP, "contours", INTERACTION, "exclusive") );


Enable
=====

Parameter<Boolean> SNAPPING = new Parameter<Boolean>("snapping", Boolean.class, "Enable Snapping",
   "True to enable snapping, requires use of 'distance' parameter",
   true, 1, 1, new KVP( GROUP ="snap", INTERACTION, "enable" ) );
Parameter<Double> DISTANCE = new Parameter<Double>("distance", Double.class, "Snapping Distance",
   "Snapping distance used, required when 'snapping' parameter is True.",
  false, 0, 1, new KVP( GROUP = "snap" ) );


Attributes
=======

Parameter<FeatureCollection> FEATURES = new Parameter<FeatureCollection>("features", FeatureCollection.class, "Features",
   "Features being disolved",
   true, 1, 1, new KVP( GROUP ="dissolve", INTERACTION, "schema" ) );
Parameter<String> DISSOLVE = new Parameter<String>("dissolve", String.class, "Dissolve Attribute",
   "Attribute used to form groups when dissolving",
   true, 0, 1, new KVP( GROUP = "dissolve" ) );


Parameter<TransformDefinition> ATTRIBUTE = new Parameter<TransformDefinition>("attribute", TransformDefinition.class, "Attribute",
   "Attribute defined using an aggregate function (sum, min, max, first, average)",
   false, 0, Integer.MAX_INTEGER, new KVP( GROUP = "dissolve" ) );


This example is interesting as both DISSOLVE and ATTRIBUTE "look up" in their group for the parameter providing a "schema". Attribute allows more than one attribute to be defined, using the same Transform Definition thing as the transform process.

--  
Jody Garnett


On Thursday, 27 September 2012 at 2:56 PM, Andrea Aime wrote:

> On Wed, Sep 26, 2012 at 5:28 PM, Victor Olaya <vo...@op... (mailto:vo...@op...)> wrote:
> > >
> > > Could we have more than one relationship? How do we handle it?
> >  
> > You mean one parameter related to many other ones? That could be
> > useful, but I guess it risks making it difficult to handle, since
> > probably additional information was needed to fully describe that more
> > complex relation. Can you put an example of a case where that could be
> > used? To be honest, I just proposed this improvement for the
> > "attribute-from-vector-layer" case,  
>  
> I see what you mean. I guess the usage of a generic name such as  
> RELATED is probably too much then, as there might be many types of
> relationships, like validation ones, max > min for example, or an  
> enumerated value whose possible values actually depend on a choice
> of another attribute (e.g., a process that can take both rater and vector
> input and that has an attribute name which makes sense only if the
> input is vector).  
>  
> I'm wondering if something more specific would be better suited if we're
> not after a tool to describe general relationships.
> Something like KVP("FEATURE_ATTRIBUTE", "th ueSourceCollection")
> for example.
>  
> If we go for RELATED instead maybe the value could be a Relation empty
> base class, which has a FeatureAttribute subclass, and other subclasses could
> be created if we want to describe other kinds of relationships:
> KVP("RELATED", Collections.asList(new FeatureAttribute("theSourceCollection")))
>  
> (the above also takes into account that we might have more than one relationship   
> by using a list, maybe the convention could be relaxed and accept either a Relation
> or a list of Relation as a possible value, I guess that could be documented)
>  
> Just my 2 cents  
>  
> Cheers
> Andrea
>   
>  
> --  
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it 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
>  
> -------------------------------------------------------