otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2019-08-09T12:15:13Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1952Crash with the decision tree classifier in OpenCV 3.4.1 and K-fold cross-vali...2019-08-09T12:15:13ZCédric TraizetCrash with the decision tree classifier in OpenCV 3.4.1 and K-fold cross-validations > 1### Description
when training a decision tree classifier in OpenCV 3.4.1 and K-fold cross-validations > 1 (`classifier.dt.f > 1`), the application crash with the error message
```
2019-08-01 10:24:30 (FATAL) TrainVectorClassifier: Cau...### Description
when training a decision tree classifier in OpenCV 3.4.1 and K-fold cross-validations > 1 (`classifier.dt.f > 1`), the application crash with the error message
```
2019-08-01 10:24:30 (FATAL) TrainVectorClassifier: Caught std::exception during application execution: OpenCV(3.4.1) /Datas/Code/OTB/SuperBuild/OPENCV/build/modules/ml/precomp.hpp:157: error: (-213) tree pruning using cross-validation is not implemented.Set CVFolds to 1 in function setCVFolds
```
Apparently, this bug is already known and "fixed" when defining the `classifier.dt.f` parameter in `otbTrainDecisionTree.hxx:78`
``` cpp
//CVFolds
AddParameter(ParameterType_Int, "classifier.dt.f", "K-fold cross-validations");
#ifdef OTB_OPENCV_3
// disable cross validation by default (crash in opencv 3.2)
SetParameterInt("classifier.dt.f",0);
#else
SetParameterInt("classifier.dt.f",10);
#endif
SetParameterDescription("classifier.dt.f",
"If cv_folds > 1, then it prunes a tree with K-fold cross-validation where K "
"is equal to cv_folds.");
```
The default value of the parameter has been set to 0, so it doesn't crash if the parameter is not set, but maybe we should just remove the parameter when using open cv3 if it makes the application crash.
### Configuration information
Superbuild (opencv 3.4.1)7.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1946Deploy job and CookBook2020-02-07T16:11:00ZAntoine RegimbeauDeploy job and CookBookAs of today the deploy job is updating the cookbook to the server as an archive. It needs to untar it so that we can update the link https://www.orfeo-toolbox.org/CookBook-develop to the latest version.As of today the deploy job is updating the cookbook to the server as an archive. It needs to untar it so that we can update the link https://www.orfeo-toolbox.org/CookBook-develop to the latest version.7.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1933Prepare shark 4.x situation for 7.0 release2019-08-06T14:40:30ZVictor PoughonPrepare shark 4.x situation for 7.0 release* Check shark 4.x availability in debian* Check shark 4.x availability in debian7.0.0Guillaume PaseroGuillaume Paserohttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1916type assertion in OGRFieldWrapper GetValue()2019-07-08T07:56:52ZCédric Traizettype assertion in OGRFieldWrapper GetValue()The `GetValue<T>()` method of `otbOGRFieldWrapper` returns the value of the field by calling the ogr method associated with type T, for example, if T=int, it will call `ogr::GetFieldAsInteger`.
There is an assertion that compares the ...The `GetValue<T>()` method of `otbOGRFieldWrapper` returns the value of the field by calling the ogr method associated with type T, for example, if T=int, it will call `ogr::GetFieldAsInteger`.
There is an assertion that compares the type of the field object from wchich the method is called to the required type (l454 of otbOGRFieldWrapper.hxx):
``` cpp
assert(m_Definition.GetType() == Kind::value && "OGR field type mismatches the type of requested field value");
```
This means that, if otb is compiled with assertion, `GetValue<int>()` can only be called on integer fields, `GetValue<string>()` can only be called on string fields and so on.
The `GetValue<T>()` method of otbOGRFieldWrapper returns the value of the field by calling the ogr method associated with type T, for example, if T=int, it will call ogr::GetFieldAsInteger.
There is an assertion that compares the type of the field object from wchich the method is called to the required type (l454 of otbOGRFieldWrapper.hxx):
I don't think this is the expected behavior of such a function, as ogr's GetFieldAsXXX can do conversions, for example calling `atoi` to convert string to int if GetFieldAsInt is called on a string field.
This method is used for example in the classification vector applications to fetch the fields and values of the input vector data. The input field can be a string (possible fields are defined in the DoExecute of the applications), but the assertion will fail as the class field is an integer.
There are a few tests failing because of this issue if the otb is compiled in debug mode (which does not happen or CI nor Dashboard if I'm correct). If we want to keep this assertion, we should replace GetValue<T> by GetFieldAsXXX in classification applications.7.0.0Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1907"External libraries used in OTB" table is missing from nightly doc2019-07-23T09:25:53ZVictor Poughon"External libraries used in OTB" table is missing from nightly docIn the documentation, in the section "Compiling OTB from source" there is a table called "External libraries used in OTB". It appears in my local build but not in the nightly build: https://www.orfeo-toolbox.org/packages/nightly/latest/C...In the documentation, in the section "Compiling OTB from source" there is a table called "External libraries used in OTB". It appears in my local build but not in the nightly build: https://www.orfeo-toolbox.org/packages/nightly/latest/CookBook-6.7/CompilingOTBFromSource.html7.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1904Improve BandMathX documentation2019-09-13T09:51:29ZCédric TraizetImprove BandMathX documentationThe documentation of BandMathX in the Cookbook is a bit confusing:
- There is the [application documentation](https://www.orfeo-toolbox.org/packages/nightly/latest/CookBook-6.7/Applications/app_BandMathX.html): the documentation is quit...The documentation of BandMathX in the Cookbook is a bit confusing:
- There is the [application documentation](https://www.orfeo-toolbox.org/packages/nightly/latest/CookBook-6.7/Applications/app_BandMathX.html): the documentation is quite long but non exhaustive.
- There is the `About BandMathX` C++ API section. It contains information on the BandMathX syntax and C++ example. It contains a lot of details on advanced use of BandMathX, and describes additional functionalities beside `MuParserX`. This section comes from the Software Guide migration.
- Document bit manipulation as it should be used with the `int` operator
Most users of `BandMathX` are using the application, and will never open the C++ API section. I think the documentation should be refactored as follow:
- All the syntax related information should go in BandMathX's documentation.
- The `About BandMathX` C++ API section should be removed, and the C++ part should be moved to the examples (or not, there is already an example for the BandMathX filter).
- We could add an example of the BandMathX application in this [recipe](https://www.orfeo-toolbox.org/CookBook-develop/recipes/improc.html), to point out the differences with `BandMath`7.0.0Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1815ExtractROI 'mode fit' generates wrong clip when the reference extent exceeds ...2019-05-28T09:29:50ZSébastien PeilletExtractROI 'mode fit' generates wrong clip when the reference extent exceeds the input raster extent### Description
ExtractROI application generates wrong clip in fit mode (vect or im reference) when the reference exceeds input raster extent.
It's due to the conversion of physical point to index point. Point that is outside input ras...### Description
ExtractROI application generates wrong clip in fit mode (vect or im reference) when the reference exceeds input raster extent.
It's due to the conversion of physical point to index point. Point that is outside input raster extent can be converted into negative index value (cf. [otbExtractROI.cxx](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/blob/develop/Modules/Applications/AppImageUtils/app/otbExtractROI.cxx#L770) )
| before ExtractRoi | after ExtractRoi | corrected ExtractRoi |
| ------ | ------ | ------ |
| <img src="http://open.geoexmachina.fr/img/article/before.png" width="200"/> | <img src="http://open.geoexmachina.fr/img/article/after.png" width="200" /> | <img src="http://open.geoexmachina.fr/img/article/correction.png" width="200"/> |
I fixed the problem by replacing negative index with 0 (cf. [fix](https://gitlab.orfeo-toolbox.org/SebastienPeillet/otb/commit/c9acde4464af34c9ff0e66b60d1e230da2a261a0) )
### Steps to reproduce
create a vector layer that exceeds your raster
use cmd:
> otbcli_ExtractROI -in input.tif -mode fit -mode.fit.vect vect.shp -out output.tif
### Configuration information
Ubuntu 16.04, OTB 6.6.1, build with [iota2](https://framagit.org/inglada/iota2) method7.0.0