Fix listview parameter in TrainImagesClassifier

Summary

TrainImagesClassifier is a composite application chaining several learning applications. This applications has a listView parameter sample.vfn connected to a PolygonClassStatistics, a SampleSelection and a TrainVectorClassifier application.

The io.vd input vector data source of TrainImagesClassifier is connected to the vec input vector data of PolygonClassStatistics and when the parameters of TrainImagesClassifier the parameters of PolygonClassStatistics are also updated. This means the listView parameter is connected to the input vector data. The choice list is the available fields in io.vd and the selected item is the index of sample.vfn in this choice list.

It is important to note that sharing a ListView parameter is not sharing the string value given to the parameter (or stringList), the whole ListView is shared, i.e. the choice list and the selected item(s).

However the input vector of the TrainVectorClassifier application is not the same one, it is a temporary vector created by SampleExtraction and its fields are not the same. The selected item is never updated again, and index of the selected item is not necessarily the right one.

In most case it is not a problem (i.e. the selected item is still the right field). However in the case described on this forum post the field used for classification is not the right one, it is a field containing the class name and during training a stod exception is raised while attempting to convert the wrong field into an integer. I don't know why this specific case fails and the other don't (e.g. the tests).

This merge request is a fix for this bug. sample.vfn is not connected to the cfield of TrainImageClassifier. Instead cfield is initialized with the value given to sample.vfn, i.e. the actual field name.

Copyright

The copyright owner is CNES and has signed the ORFEO ToolBox Contributor License Agreement.

---

Check before merging:

• All discussions are resolved
• At least 2 👍 votes from core developers, no 👎 vote.
• The feature branch is (reasonably) up-to-date with the base branch
• Dashboard is green
• Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
• Optionally, run git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i on latest changes and commit

changed milestone to %7.1.0

added bug label

Thanks for the analysis ! Do we have some test to valide this bug fix ?

Now I understand why the dataset used in the forum post causes the bug while the datasets we use in test don't.

PolygonClassStatistics accepts class fields of type OGRInteger, OGRInteger64 and ORGString while TrainVectorClassifier accepts OGRInteger, OGRInteger64 , ORGString and OFTReal. The dataset used has a OFTReal field (SURF) that comes before the class field (CODE_ess of type OFTString).

PolygonClassStatistics ignores the OFTReal field and finds the class field as position 8 in the field list. This is stored in the list view. Then TrainVectorClassifier uses the list view with its own fields, but as the real field is not ignored, the field at position 8 is not the correct one.

There is no test for this yet. But we could add a dummy field of type OGRReal in the input vector of TrainImagesClassifier. This should make the test fail without the fix and pass with it.

added 1 commit

• f236ba0f - TEST: added a fiel of type OGRReal in VectorData_QB1_utm31n.sqlite to test merge request 699

Compare with previous version

added 1 commit

• 7e7cb3e2 - TEST: update baseline for bug of mr 699 (additional real field)

Compare with previous version

@ytanguy I added a field of type OGRReal to the input vector data of apTvClTrainSVMImagesClassifierQB1. With this modification the test would fail on develop or release-7.1 (I only tested it locally) but pass with the fix.

The bug on debian testing are not related to the MR.

mentioned in commit 803307c7

merged