This PR incorporates your proposed algorithm for the lake identification into the deltalakes class and its methods.
To try and avoid making classes.py wildly long, I created a new file lake_utils.py which contains lake-specific functions to match the general structure of the delta/rivers classes. Maybe it ought to go in a "lakes" subdirectory eventually...
Biggest caveat with this method is that dilation process to overlap the lake blobs with the adjacent nodes (now in thedeltalakes.compute_lakes() method). I found that lakes with over 1 connecting channel may need to be dilated more than once to connect to all the adjacent nodes, however it is hard to code that in since the algorithm doesn't know a priori how many connections each lake should end up with. The parameterized solution I have is to allow the user to optionally set both a minimum and maximum number of dilations when computing / defining the lake nodes.
The minimum number of dilations is to help cover the case where a lake is incompletely connected to its adjacent channels (so it has made 1 connection, but missed at least 1). The maximum dilations sets a ceiling when we try to increase the dilations for a lake with no connections to adjacent nodes.
Can't help but think there must be a better way to accomplish this... just haven't hatched upon it yet. For now this appears to work, although it requires some user inspection of the pruned network to ensure all of the lakes remain connected -- if not they may need to specify these dilation parameters.
This PR incorporates your proposed algorithm for the lake identification into the
deltalakes
class and its methods.To try and avoid making
classes.py
wildly long, I created a new filelake_utils.py
which contains lake-specific functions to match the general structure of the delta/rivers classes. Maybe it ought to go in a "lakes" subdirectory eventually...Biggest caveat with this method is that dilation process to overlap the lake blobs with the adjacent nodes (now in the
deltalakes.compute_lakes()
method). I found that lakes with over 1 connecting channel may need to be dilated more than once to connect to all the adjacent nodes, however it is hard to code that in since the algorithm doesn't know a priori how many connections each lake should end up with. The parameterized solution I have is to allow the user to optionally set both a minimum and maximum number of dilations when computing / defining the lake nodes.The minimum number of dilations is to help cover the case where a lake is incompletely connected to its adjacent channels (so it has made 1 connection, but missed at least 1). The maximum dilations sets a ceiling when we try to increase the dilations for a lake with no connections to adjacent nodes.
Can't help but think there must be a better way to accomplish this... just haven't hatched upon it yet. For now this appears to work, although it requires some user inspection of the pruned network to ensure all of the lakes remain connected -- if not they may need to specify these dilation parameters.