Processing of input data with a different number of categories

[RemeshevskiyValeriy]

Related issues: #47

[KolesovDmitry]

I Mixing of code levels and diffusion of responsibility

Try do not mix different levels of code too much. Currently, the interface (neuralnetworkwidget.py) knows too much about the internal structure of the algorithmic modules. See for example

• https://github.com/RemeshevskiyValeriy/qgis_molusce/blob/d8c99c6d527cc79b93d999283411c67dd5c8c4a6/src/molusce/neuralnetworkwidget.py#L159-L169 (similarly: https://github.com/RemeshevskiyValeriy/qgis_molusce/blob/d8c99c6d527cc79b93d999283411c67dd5c8c4a6/src/molusce/logisticregressionwidget.py#L98-L108)

Here the interface part analyzes how many categories are stored in the initial/final rasters and 'it knows' that these categories should be combined with each other. As a result, the processing logic is "spread out" across several modules.

Ideally, all the logic should be kept in one place, for example, by put the code into a separate function/method get_categories(init_raster, final_raster) and keep it there. Moreover, the function/method should be defined not in the interface part of the plugin, but in the algorithmic modules (in the same modude where the main analysis of the state rasters occurs (AreaAnalysis? CrossTabs? Sampler?))

A remark (this is already a matter of taste). In my opinion, there is no need to check whether the categories in the rasters are the same, since they are processed through set(). So it doesn't matter whether the cateogoriesa are the same or not; the answer will be the same. Checking for category equality saves computation time, but the gain is neglect. Eliminating the check simplifies the code, it became easy to read; this is a more important priority for me (but, as I said, this is a matter of taste; there is no fundamental difference here).

II Duplication of code

The same code is placed in several different locations, for example:

• https://github.com/RemeshevskiyValeriy/qgis_molusce/blob/ad35903b24e2aec3ac89c61ec18f84f36d0be8ea/src/molusce/algorithms/models/area_analysis/manager.py#L63-L66
• https://github.com/RemeshevskiyValeriy/qgis_molusce/blob/d8c99c6d527cc79b93d999283411c67dd5c8c4a6/src/molusce/algorithms/models/simulator/sim.py#L124-L126
• https://github.com/RemeshevskiyValeriy/qgis_molusce/blob/d8c99c6d527cc79b93d999283411c67dd5c8c4a6/src/molusce/algorithms/models/sampler/sampler.py#L85-L88
• https://github.com/RemeshevskiyValeriy/qgis_molusce/blob/d8c99c6d527cc79b93d999283411c67dd5c8c4a6/src/molusce/moluscedialog.py#L797-L807
• and the one from the previous remark.

(also may be others examples; I haven't looked at all of them)

I strongly recommend create a special function/method for calculating categories. Otherwise, if we decide to recalculate the categories using a new scheme, we will have to go through the code to catch errors — we will need to remember all the places where these categories are calculated and make corrections in all those places.