Steepest Paths down a Topography with Aggregate Runoff
Tracing the steepest slopes over a topography has a common mapping exercise within Landscape Urbanism practices (and one which has been used productively by our students at EPFL). It makes for a good scripting exercise because there is really no good way to do it on the canvas alone (hoopsnake notwithstanding) and it demonstrates the power of iteration and simple loop controls.
Over the last few years I’ve written and rewritten a couple of different versions in Grasshopper for various purposes. Finally, while I decided to make a complete, robust definition while feeling my way around ghPython. The ability to create custom classes in python and to exchange them between Grasshopper script components allowed a more elegant solution to a couple of things I’d wanted to add in to the standard slope definition. Most significantly, I wanted to be able to add the ability to collapse traces into a single path when they grow too close and to insert new traces when they diverge too far from their neighbors. Creating a custom class of topoPoint with methods that hold hold the indices of the points before and after itself in the path (.src and .trgt) and storing them in a defaultdict(list) made it simpler to manage such irregular data.
Uphill Paths in Orange, Downhill Paths in Blue
In addition to options to compress or insert traces, the definition can also be run uphill from the lowest topoline or downhill from the highest. Either way, the definition will recongnize when a new curve should be entered into the search (for example, a secondary peak or a disconnected base). The script should also work on closed or open curve or a combination and should not require the curves to be oriented in the same direction. All these sorting are a little costly so be careful opening it on a vast topography or with too small a divison dimension at first.
UDATE: After investigating code optimisation for ghPython, it became clear that the ghpythonlib functions (.components and .parallel) are currently a liability for any complex or iterated functions. I’ve rewritten this code without using them and get (at least) a 4×-5× improvement in speed even on the first run (i.e. without taking into account the memory leakage that seems to occur as discussed in the link just above).
The download link now connects to this rewritten version.
Note that you need ghPython installed and that the stickyClass component must also be kept with the definition.