#1070: cannot enter useful values to r.param.scale curvature tolerance in wxPython
GUI
---------------------------+------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: wxGUI | Version: unspecified
Keywords: r.param.scale | Platform: All
Cpu: All |
---------------------------+------------------------------------------------
The s_tol (slope tolerance) and c_tol (curvature tolerance) arguments are
not well documented for r.param.scale, but turn out to be of great
importance in achieving useful results of terrain classification. s_tol
values are in degrees but c_tol is in unitless curvature values. Useful
values range between 0.0000 and 0.0006 according to the documentation.
For some reason, the GUI only allows values to 3 decimal places (0.000) in
the s_tol and c_tol fields. This means that it is impossible to enter any
values between 0.0000 and 0.0010 even though these are exactly the values
that need to be entered. Of course you can enter these from the command
line, but this bug cripples use of this module for many users.
I don't know where the decimal place is specified in the code--in the
interface description in the C code, or somewhere in the wxPython
interface parser code.
#1070: cannot enter useful values to r.param.scale curvature tolerance in wxPython
GUI
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: r.param.scale
Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by cmbarton):
The problem is the use of floating point spin controls for numeric entry.
You must set the number of significant digits to use this. I don't see
that such spin controls make it any easier for users to enter numbers in a
field than simply typing what is needed. And the number of significant
digits can vary quite a bit among different modules.
IMHO, we should remove this control from the interface unless it actually
is helpful somewhere.
#1070: cannot enter useful values to r.param.scale curvature tolerance in wxPython
GUI
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: r.param.scale
Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by hamish):
I agree that spin controls, while nice for integers, don't really have a
place for floating point entries, as the programmer would have to bulk-
choose granularity/step size & one size does not fit all
{modules|users|tasks}. For integers we know the minimum step size will be
1.
#1070: cannot enter useful values to r.param.scale curvature tolerance in wxPython
GUI
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: r.param.scale
Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by cmbarton):
You are right about integers vs. floating point here. Thinking about it,
and the go round with UTM zones awhile back, I'm coming to the conclusion
that spin controls are most appropriate where a user needs to move through
a lot of related values quickly, seeing the result of each value as it
spins by. The best example would be where spinning would shift a display
in some dimension. In cases where different values need to be entered only
occasionally--to set a value and run a module as in this case--then simply
typing a value is quicker.
#1070: cannot enter useful values to r.param.scale curvature tolerance in wxPython
GUI
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: martinl
Type: defect | Status: assigned
Priority: normal | Milestone: 6.5.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: r.param.scale
Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by cmbarton):
Thanks. I'll try to recompile and test as soon as I can.
By floating point validator, do you mean a validator that checks to see if
a numeric value has been entered or one that enforces a set number of
significant digits? For floating point entries, I hope that we could enter
2 and be OK, and not have to enter 2.0. Also, the significant number of
digits that are relevant will vary from module to module
#1070: cannot enter useful values to r.param.scale curvature tolerance in wxPython
GUI
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: martinl
Type: defect | Status: assigned
Priority: normal | Milestone: 6.5.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: r.param.scale
Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by martinl):
Replying to [comment:5 cmbarton]:
> Thanks. I'll try to recompile and test as soon as I can.
>
> By floating point validator, do you mean a validator that checks to see
if a numeric value has been entered or one that enforces a set number of
significant digits? For floating point entries, I hope that we could enter
2 and be OK, and not have to enter 2.0. Also, the significant number of
digits that are relevant will vary from module to module
#1070: cannot enter useful values to r.param.scale curvature tolerance in wxPython
GUI
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: martinl
Type: defect | Status: assigned
Priority: normal | Milestone: 6.5.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: r.param.scale
Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by martinl):
Replying to [comment:9 hamish]:
> how about nan,inf? that's not relevant to r.param.scale, but it is for
`r.null setnull=` and `d.rast vallist=` when you need to debug+repair a FP
map.
The validator allows you to enter whatever you want, it's just indicate
that input is not float. Extra allowed strings could be handled by
redesigned {{{Option}}} structure in GRASS 7.
#1070: cannot enter useful values to r.param.scale curvature tolerance in wxPython
GUI
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: martinl
Type: defect | Status: assigned
Priority: normal | Milestone: 6.5.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: r.param.scale
Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by hamish):
Replying to [comment:10 martinl]:
> The validator allows you to enter whatever you want, it's just
> indicate that input is not float. Extra allowed strings could be
> handled by redesigned {{{Option}}} structure in GRASS 7.
I ask out of curiosity because nan,inf are valid IEEE floating point
values, but most validators don't remember to include them and that can
get you stuck. If they don't work it's a bug in the validator, we
shouldn't have to work around it ourselves.
#1070: cannot enter useful values to r.param.scale curvature tolerance in wxPython
GUI
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: martinl
Type: defect | Status: assigned
Priority: normal | Milestone: 6.5.0
Component: wxGUI | Version: unspecified
Resolution: | Keywords: r.param.scale
Platform: All | Cpu: All
-----------------------+----------------------------------------------------
Comment (by martinl):
Replying to [comment:11 hamish]:
> Replying to [comment:10 martinl]:
> > The validator allows you to enter whatever you want, it's just
> > indicate that input is not float. Extra allowed strings could be
> > handled by redesigned {{{Option}}} structure in GRASS 7.
>
> I ask out of curiosity because nan,inf are valid IEEE floating point
values, but most validators don't remember to include them and that can
get you stuck. If they don't work it's a bug in the validator, we
shouldn't have to work around it ourselves.
Python's float() understands nan or inf, so there is nothing to fix.