GispoCoding / eis_toolkit

Python library for mineral prospectivity mapping
https://eis-he.eu/
European Union Public License 1.2
26 stars 8 forks source link

Zeros not handled in WofE generalized cumulative weights calculation #297

Closed em-t closed 8 months ago

em-t commented 9 months ago

I was testing WofE with a certain set of data that requires the 'ascending' option and noticed a situation during _generalized_weights_cumulative, where a value within a log evaluation can end up being zero. The weights calculation proceeds to the end with no error, but the following warnings are raised:

weights_of_evidence.py:230: RuntimeWarning: divide by zero encountered in log
  class_1_w_gen = np.log(class_1_point_count / total_deposits) - np.log(

weights_of_evidence.py:233: RuntimeWarning: divide by zero encountered in scalar divide
  clas_1_s_wpls_gen = np.sqrt((1 / class_1_point_count) + (1 / (class_1_count - class_1_point_count)))

The variable class_1_point_count was indeed zero at this point, causing the warning. In the result, the generalized weights for the rows belonging to that class end up as -inf/inf. This should probably be handled in some way?

I compared the weights calculation using the same data to what ArcSDM (an ArcGIS plugin) outputs, and while I can't vouch for the correctness of that, it results in some non-infinite values for the rows in generalized class 1. So, it's somehow handling the situation differently.

EIS Toolkit:

dstworms_ascending_eis

ArcSDM:

dstworms_ascending_ardsdm

Data:

Evidence raster: rc_dstworms_copy.tif Training points: Orogenic_Au_training.shp

wofe_data.zip

nmaarnio commented 9 months ago

Thanks for the report! If you would like to try to solve this issue yourself, go ahead! I think aiming for the same behaviour as ArcSDM sounds good. If you don't want to dive deeper into this issue, let's wait for @chudasama-bijal to return and comment this.

chudasama-bijal commented 9 months ago

The generalized weights calculations should handle the zeros in the same way as these are handled by the weights calculation functions. I suppose those adjustments have not been applied to the weights generalization functions, and hence we are having this issue. Please check.