HQ exponential decay discrepancy

[dcdenu4]

James mentioned that there is a discrepancy in how exponential decay is handled between source and the UG.

What the source code is doing: exp(-dist / max_dist)
What the UG says it should be doing: exp(-(2.99 / max_dist) * dist)

This came up from natcap/pygeoprocessing#268 (comment).

[dcdenu4]

After talking with @phargogh about this I think it's worth having a chat with @lmandle and @newtpatrol to get a sense of what we expect the model to be doing for the decay of threats over distance. The UG currently describes threats being decayed according to a Euclidean distance transform, but the model is actually using Convolutions and a weighted distance decay kernel in implementation.

[dcdenu4]

After talking things over with the science team (Lisa, Stacie, Jade) we decided to switch to a simpler euclidean distance implementation and to update the User's Guide with why the 2.99 constant is being used. The convolution implementation has been around since InVEST 3.3.0 but not reflected in the User's Guide. When thinking about writing the convolution implementation into the User's Guide I could not convince myself or defend the approach as currently implemented. There could be a reason (or bug) for why the filtered threats produce non intuitive degradation and quality outputs. As far as the 2.99 constant, Lisa noted:

With the constant of 2.99, the impact of the threat is reduced by 95% (to 5%) at the specified max threat distance. So I suspect it's based on the traditional 95% cutoff that used in statistics. We could tweak this cutoff (e.g., 99% decay at max distance), if we wanted.
Otherwise, I was suggesting we spell this out explicitly in the User's Guide (i.e., that the impact of the thread is reduced to 5% at the specified max distance).

[emlys]

Looks like this was fixed in #1159.