2018-05-27 14:03 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001387OTB-wrappingGeneralpublic2017-04-27 15:45
Assigned Togpasero 
StatusclosedResolutionno change required 
PlatformLinuxOSUbuntu OS Version16.04.1
Summary0001387: otbWrapperListViewParameter Cannot find labels of vector file
DescriptionI have troubles using python wrappers within a libsvm classification on both the 5.10 binary on Ubuntu 16.04 and a source built of 5.10 on Manjaro Linux.
Wrappers that use otbWrapperListViewParameter.cxx
to find a field in a vector file fail, stating it cannot find the field with <label>:
itk::ERROR: ListViewParameter(<address>):Cannot find <label>

Specifically, I had troubles with "TrainImagesClassifier" and "ComputeConfusionMatrix".
I noticed in the Cookbook that these fields are indicated as lists,
so I thought maybe this has changed recently,
but changing the module to SetParameterStringList and the input type to list didn't work either:
Exception thrown in otbApplication Application_SetParameterStringList: <path_to_src>/otbWrapperListViewParameter.cxx:191:
itk::ERROR: ListViewParameter(<address>): Value <label> not found in the list of choices: .

Tried also different vector files, with the same response.

Moreover, using the command line tools with the same arguments works though!
Steps To ReproduceI attached a minimal shapefile which can be used to reproduce the error using the python snippet below:

import otbApplication
ComputeConfusionMatrix = otbApplication.Registry.CreateApplication("ComputeConfusionMatrix")
TagsNo tags attached.
Attached Files




gpasero (administrator)

Try to add the following line just before setting "ref.vector.field" :



m-haas (reporter)

As simple as that! I missed that change apparently. Thanks a lot!


gpasero (administrator)

In fact it is more a hack than the intended way of doing things. The behaviour of "ref.vector.field" has changed, it is now a choice list showing available fields, hence the necessity to call UpdateParameters() after setting the OGR file.

Question to other devs : do we have a way to hide this extra step ? I know that C++ and Python API should remain close to each other.


rashadkm (developer)

we can however rename/override the methods in swig.

I would find out if there is an performance overhead when calling this method with each call to Set*


gpasero (administrator)

Yes, technically that would be the solution. But on the other hand, we break the symmetry between C++ and Python API.

Maybe in the long term, we should treat this UpdateParameters() as a callback or an observer on the parameters (directly in the ApplicationEngine). If a parameter value is changed, then there is an automatic call to app->UpdateParameters().


julien (administrator)

In the mean time, I close this issue.

-Issue History
Date Modified Username Field Change
2017-04-19 19:06 m-haas New Issue
2017-04-19 19:06 m-haas File Added: otb-test.zip
2017-04-20 11:06 gpasero Note Added: 0004129
2017-04-20 11:06 gpasero Assigned To => gpasero
2017-04-20 11:06 gpasero Status new => feedback
2017-04-20 11:52 m-haas Note Added: 0004130
2017-04-20 11:52 m-haas Status feedback => assigned
2017-04-20 15:07 gpasero Note Added: 0004131
2017-04-25 09:51 rashadkm Note Added: 0004138
2017-04-25 14:50 gpasero Note Added: 0004140
2017-04-27 15:45 julien Note Added: 0004150
2017-04-27 15:45 julien Status assigned => closed
2017-04-27 15:45 julien Resolution open => no change required
+Issue History