cannot enter useful values to r.param.scale curvature tolerance in wxPython GUI

[cmbarton]

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.

Michael

[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.

Michael

[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.

Hamish

[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.

Michael

[martinl]

In r42323 has been replaced FloatSpin by TextCtrl including float-point validator. Testing welcomed.

[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

[hamish]

... and does it accept 1e-7 style input?

[martinl]

Replying to 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

It checks if input is a numeric value.

[martinl]

Replying to hamish:

... and does it accept 1e-7 style input?

yes.

[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.

Hamish

[martinl]

Replying to 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.

[hamish]

Replying to 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.

regards,

[martinl]

Replying to hamish:

Replying to 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.

[martinl]

Seems to be fixed, closing the ticket.