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

Decide and Implement new Centerline Strategy #382

Closed
1 task
joewheaton opened this issue Aug 20, 2021 · 6 comments
Closed
1 task

Decide and Implement new Centerline Strategy #382

joewheaton opened this issue Aug 20, 2021 · 6 comments
Assignees
Labels
pkg:VBET VBET python package

Comments

@joewheaton
Copy link
Contributor

In #381 we tried to bring back centerlines, but with decisions to leave rasterized edges, we have way more vertices and this was blowing up the centerline tool. Six steps forward one step back ;). @philipbaileynar, @KellyMWhitehead and @joewheaton need a new strategy.

  • @KellyMWhitehead since you're seeing what's going on here, please share your ideas for a strategy that might work.

Once we have it, let's spell it out up here by editing this post. I will put my thoughts below.

@joewheaton joewheaton added the pkg:VBET VBET python package label Aug 20, 2021
@joewheaton
Copy link
Contributor Author

A few ideas... Assuming that what is breaking our centerline method right now is the number of vertices and using Theisen polygons, I'm wondering if we try something staying in Raster first. Feel free to shoot this down... what if:

  1. We produced a binary raster where 1 is outside the 0.68 thresholded valley bottom and 0 (false) is inside.
  2. We calculated a Euclidian distance from 1's (outside), and then similar to @philipbaileynar old RBT thalweg tool, we do a least cost-path tracing down trying to connect dots to the next highest (i.e. furthest away from edge) cells?
  3. We could then attempt to smooth and simplify the resulting line so it doesn't have so many vertices?

Or...
I don't know how the "smoothing" works, but I know it is computationally expensive. What if we are only doing it temporarily for purposes of getting a centerline on the 0.68? What parameters on that operation are there, what seems to cost the most?

@joewheaton
Copy link
Contributor Author

@lauren-herbine and @shelbysawyer feel free to make suggestions if you have them. Otherwise mentioning you for FYI

@joewheaton
Copy link
Contributor Author

Just found this old post from Duncan, that is quite helpful for our CL strategy discussions: Riverscapes/ConfinementTool#39

@joewheaton
Copy link
Contributor Author

@philipbaileynar can you ask @KellyMWhitehead to try the Euclidian Distance thing and see where that gets us? I believe that because step 1 will be to produce a binary raster that is outside all valley bottoms, it should overcome some of the lateral partitioning of valley bottoms that are getting split apart in bigger valley bottoms when they should be lumped together.

@philipbaileynar
Copy link
Contributor

Someone should experiment with Euclidean distance by hand before we write any code. Could even be model builder.

@MattReimer MattReimer modified the milestones: Week 3 - Sept, Someday Oct 7, 2022
@joewheaton
Copy link
Contributor Author

This is now complete with 0.7 onwards.

@MattReimer MattReimer removed this from the Someday milestone Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pkg:VBET VBET python package
Projects
None yet
Development

No branches or pull requests

3 participants