Evening Victor:
In the interest of getting this discussion to converge I have gathered the code
examples here:
- http://docs.codehaus.org/display/GEOTOOLS/Parameter+Interaction
--
Jody Garnett
--
Got visibility?
Most
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 describe
On Wed, Sep 26, 2012 at 5:28 PM, Victor Olaya 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 wa
> Sounds great to me. I guess it's better to use an enum, instead of
> string, but the syntax of those examples is perfect from my point of
> view
Well I want to see it run first, to make sure we are on the right track.
> hmmm, I do not understand this one. The GROUP parameter I was
> proposing
>
> 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
On Wed, Sep 26, 2012 at 3:22 PM, Victor Olaya wrote:
> > RELATE
> >
> > How to describe the nature of the relationship? Using strings below?
> Perhaps
> > best handled with ENUM.
> >
> > Parameter SNAPPING = new Parameter("snapping",
> > Boolean.class, "Enable Snapping", "True to enable snapping,
> RELATE
>
> How to describe the nature of the relationship? Using strings below? Perhaps
> best handled with ENUM.
>
> Parameter SNAPPING = new Parameter("snapping",
> Boolean.class, "Enable Snapping", "True to enable snapping, requires use of
> 'distance' parameter", true, 1, 1, new KVP( RELATED,
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 the
>
> One advantage to hard-coding the relationship is that it gives better
> type-checking and IDE support. Are there likely to be more than a few
> different relationships that need to be expressed?
I just can think of a band index from a raster layer (talking from
what I have seen in GRASS proce
On Mon, Sep 24, 2012 at 8:24 AM, Victor Olaya wrote:
>
> >>
> > I wonder if calling this a "relationship" rather than a dependency makes
> > more sense. What sort of other information will the
> relationship/dependency
> > relay? Like for instance, in this could be good to create the
> relationsh
> Just to be clear the new stuff would be part of the Parameter class directly
> right? and available to all process implementors, not just ones using the
> annotation based stuff?
Yes, I think that if it goes in the Parameter class it will be
available to all processes. In fact, I think there are
I think this would be great to have, anything that increase
the expressiveness available to the process author is a step up.
Just to be clear the new stuff would be part of the Parameter class
directly right? and available to all process implementors, not just ones
using the annotation based stuff
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
typ
13 matches
Mail list logo
