cost/distance accumulation surfaces?

[rafaqz]

I'm wondering where these would go - its certainly something you could use Stencils.jl for, and kind of fits with the other algs here?

I mean something like:
https://pro.arcgis.com/en/pro-app/latest/tool-reference/spatial-analyst/distance-accumulation.htm

I have an alg somewhere I need to use in a production model, but probably it shouldn't go in the model code, so maybe it can live here?

[evetion]

They go here https://deltares.github.io/Geomorphometry.jl/dev/usage#Cost-distance

[evetion]

Note that the Eastman method shouldn't be used. Eikonal method (extension on Eikonal.jl) is the best by far, but is shifted by half a cell (ideally we should resample it).

[rafaqz]

Ah of course. Somehow I found the name and arguments of spread a little hard to follow.

Mostly I need something that is fast but also low/zero-allocation to run in inner loops on a cluster. Eikonal is calling fill quite a bit, would be nice to pass those arrays in but there isn't even a constructor for FastSweeping that lets you not allocate.

My idea was a non allocating alg

[evetion]

Hmm, not sure if there are non alloc algorithms. Feel free to edit the current ones, split them to have in place operations for at least the output.

[rafaqz]

Yes having a user facing spread! would help a lot. But there are also some internal buffers it would be nice to reuse, similar to how you can reuse a sparse factorization for multiple rhs vectors, we could reuse the grid setup/memory etc for multiple target positions. So first run some initialisation step that returns a bundle of workspaces and precalculations (if there is anything generic to calculate for all positions) and the output array and then then call spread! that would run on that memory:

x = init(Eikonal(), friction; kw...)
spread!(x, positions)

My use case is calculating the cost distance to all of the positions for maybe a quarter of the positions in the matrix.

[evetion]

My use case is calculating the cost distance to all of the positions for maybe a quarter of the positions in the matrix.

Why do you need that? I wonder if just knowing the closest initial point would be enough? That's easier and much faster.

[rafaqz]

I need the indices along the path from essentially every pixel to every other pixel - for ecological connectivity.

(And yes there should be optimisations... The paths to a neighbouring pixel will be almost identical. But it may not be practical to reuse that information)

[rafaqz]

Eikonal method (extension on Eikonal.jl) is the best by far, but is shifted by half a cell (ideally we should resample it).

I've just been looking at this, how do you imagine resampling it? is it the minimum of the four corners or the mean?