Resolving ExtractROI default behavior bug

Closes #1545 (closed)

This has to be done to integrate modification on UserValue behavior in PirvateDo(). Modified files are :

M       Modules/Applications/AppImageUtils/app/otbExtractROI.cxx
M       Modules/Wrappers/ApplicationEngine/include/otbWrapperApplication.h
M       Modules/Wrappers/ApplicationEngine/src/otbWrapperApplication.cxx
M       Modules/Wrappers/ApplicationEngine/include/otbWrapperNumericalParameter.h

New methods to get default value of numerical parameter has been implemented.

Nothing should have change about the application interface, except for GUI, start and size parameters are now disable if the mode is not standard.

A bug has been corrected in numerical parameter : when setting value out of allowed interval, the value is clamped.

Due to this latter modification a test has been modified :

M       Modules/Applications/AppOpticalCalibration/test/CMakeLists.txt

changed the description

added 1 commit

• 0839b910 - ENH: add getters for default float and int value

Compare with previous version

unmarked as a Work In Progress

changed the description

changed the description

added 5 commits

• 1b4d2e08 - REFAC: get rid of useless this
• 6adeaada - REFAC: do not set the value but the default value
• 503a3f88 - STYLE: Get rid of commented code
• 535f6038 - REFAC: cleaner code and better radius computation
• 59548426 - BUG: take min and max value into account : clamp when setting outside

Compare with previous version

Application ExtractROI seems to be fine but the modification in numerical parameter seems to have raise a new error in OpticalCalibration. Not sure of why nor how so if anyone as an idea...

failed test : apTvRaOpticalCalibration_UnknownSensor

Got it :

-in test : "-acqui.view.azim" "-77.0"

-in code :

SetMinimumParameterFloatValue("acqui.view.azim", 0.);
SetMaximumParameterFloatValue("acqui.view.azim", 360.);

As I do not know explicitly what was the purpose of this parameter I am not sure of what to do. It seems that the filter using this value does not care if it is between [0,360] or [-180,180]... Maybe we could get rid of the min and max values in the application.

I think that azimuth angle in Pléiades metadata can be negative. I've got to double check this. I'll let you know

added 2 commits

• 9f052720 - ENH: remove min and max value for param acqui.view.azim
• ea3519ba - BUG: keep old behavior for null size ROI

Compare with previous version

Ok. For the moment I removed the min and max as I made some test and results seem to be the same if you give different angle values with the same modulo 360.

changed the description

I've checked the 6S source code and also the documentation. As far as I understand the view azimuthal angle is indeed in degree with value between 0 and 360. I think that we should let the min/max check in the application and update the test with a positive value instead.

Reference:

• main.F in OTB56S module
• 6S documentation: http://6s.ltdri.org/pages/manual.html
• 6S Python binding documentation: http://py6s.readthedocs.io/en/latest/index.html

Another solution is to operate the translation in DoUpdateParameters(). It doesn't require any min/max.

What do you mean by translation?

Not sure we're talking about the same problem, what I wanted to say is that I think that negative azimuth angles have undefined behavior in 6S so we should check and forbid them in OpticalCalibration application

Both options are fine for me.

added 76 commits

• ea3519ba...01a00be6 - 75 commits from branch develop
• aff9ebb3 - MRG: Merge branch 'develop' into bug_ExtractROI

Compare with previous version

I am sorry I didn't find anything on such a limitation...

class User

Stores parameters for a user-defined geometry for 6S.

Attributes:

    solar_z – Solar zenith angle
    solar_a – Solar azimuth angle
    view_z – View zenith angle
    view_a – View azimuth angle
    day – The day the image was acquired in (1-31)
    month – The month the image was acquired in (0-12)

(6S Python binding documentation http://py6s.readthedocs.io/en/latest/params.html#geometries)

I did not read the whole documentation and I didn't find any limitation in main.F... If you have time to point something more precise it would be great!

But anyway, we can let the user choose any kind of angle and we can update it later modulo 360 (in DoUpdate() or DoExecute()) as Guillaume suggest it.

added 1 commit

• ce1e3e30 - BUG: change value of test and restor min/max val on param

Compare with previous version

changed the description