Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for direct use of geographic data #33

Open
alex-s-gardner opened this issue Jan 2, 2024 · 7 comments
Open

Add support for direct use of geographic data #33

alex-s-gardner opened this issue Jan 2, 2024 · 7 comments

Comments

@alex-s-gardner
Copy link
Contributor

I'd like to calculate slope and curvature from a geographic DEM (raster dimensions are in degrees). I'd like to do this without retrojecting the DEM. I think the only way to do this is to calculate component values (slope/curvature along lat/lon) then to scale each component by the local meters per degree lat/lon. Given this, would it make sense to add an option to relevant functions to return component values?

@evetion
Copy link
Member

evetion commented Jan 2, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Member

evetion commented Feb 3, 2024

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
Copy link
Contributor Author

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
Copy link
Member

evetion commented Feb 3, 2024

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
Copy link
Contributor Author

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

@alex-s-gardner alex-s-gardner changed the title x/y lat/lon component values Add support for direct use of geographic data Feb 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants