Add support for direct use of geographic data

[alex-s-gardner]

Add support for direct use of geographic data

[evetion]

Yeah, this is something we need. A weighting factor for the y/x could be provided, probably as a matrix of the same size as the dem?

[alex-s-gardner]

Ya, a row to column scaling would work. This could be a scalar (rectangular cells) or matrix the same size as the DEM (geographic).

[alex-s-gardner]

should we introduce slope components (x and y) as a new function (maybe slopexy) of do we add a kwarg to slope?

do we adopt the convention that slope across columns to be x_slope and slope across rows to be y_slope?

[evetion]

Hmm. I was thinking of passing a x/y ratio as an argument to most methods. It can be a single value, or a column, or a matrix. The value and columns should be converted to a matrix so it can be used in the calculation.

Ideally, we can automatically set these things, if we have a trait for geographic stuff in GeoInterface. Let me whip up a PoC.

[alex-s-gardner]

That sounds good to me and would be the use case for most users. For my workflows I will still need slope in x and slope in y, and curvature in x and curvature in y. I could back out slope x/y from slope and azimuth but I suspect it's faster just to compute them directly. But i think it will be strait forward to add those after the geographic stuff is implemented.

The idea of automating this sounds like a dream.

[evetion]

Feel free to make a new issue for separate x y slopes and curvature, as it is something we don't have now. Maybe you also have a reference for a preferred implementation?

[alex-s-gardner]

Will do... we could add a "dims" kwarg to slope