Evening Victor (I started this message earlier in the day, and see that Justin
has now covered some of the same topics).
Great suggestions, however we will need to sort out a name. I often use code
examples in order to create something that reads well to developers. I also ask
that we hook these parameters up to a dynamic user interface, such as gt-swing
parameter wizard pages, in order to verify that they are expressive enough for
purpose.
RELATE
How to describe the nature of the relationship? Using strings below? Perhaps
best handled with ENUM.
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( RELATED, "distance", RELATIONSHIP, "requires"
) );
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( RELATED, "snapping", RELATIONSHIP,
"enable") );
GROUP
Groups seem straight forward, we already have the idea of "level" which has
been used to group parameters into different wizard pages (or mark them for
pragmatic use only).
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", RELATED,
"dem") );
--
Jody Garnett
On Monday, 24 September 2012 at 6:31 PM, Victor Olaya wrote:
> Hi all
>
> I would like to propose two simple modifications to the Parameter
> class, to enhance the semantics of geoprocesses. They both can be
> implemented as new hints, and made available through the
> DescribeParameter annotation
>
> - A hint describing dependence of one parameter to another. The most
> typical use for that would be to indicate the relation between a
> String parameter representign and attribute and a FeatureCollection.
> That would allow the 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.
> Some 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 explicitly described, the UI will let the user fill all
> parameters or none of them, instead of enforcing using only one of
> them.
>
> As you can see, it is a very simple thing, but I think that would add
> more 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.
>
> Regards
>
> Victor
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> GeoTools-Devel mailing list
> GeoTools-Devel@lists.sourceforge.net
> (mailto:GeoTools-Devel@lists.sourceforge.net)
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
