Hello All,
I need a lisp that creates the main stream of thalweg by polylines (basin - watershed) as the example below:
Someone to help?
(I need) LISP - binary tree join polilines a watershed
It seems extraordinarily challenging to imagine a way that a routine could determine a route that goes "all the way through" [however that would be defined], from all those itty bitty pieces. But even if it could, it seems utterly impossible for it to be able to choose between your white route and, for example, some of these yellow alternatives:
I would not assume that whatever possible continuous route happens to be the longest is necessarily the "main" stream -- one that's a little shorter than some others could easily be carrying more flow. Largest tributary area? You'd have to have all the contours, too, because you can't assume the break point is equidistant between stream routes. But I don't work in Civil Engineering, so what do I know?
Looking a little more closely, I see that some of them are 3D Polylines, with Z-coordinate differences, and those are all along the white route? But they follow it from the downstream end only about a third of the way along. Beyond that point they're all 2D, flat on the XY plane. If the solution involved Joining, and comparing resulting lengths, the 3D ones would need to be Flattened, anyway -- their ends don't all meet in 3 Dimensions. But what a process -- say you start with the discharge end, and find the Polylines that meet it at one end, Join one of them and check the length, and Join the other and check the length. Right away the total length from Joining the "right" one is shorter than the total length from Joining the "wrong" one, so comparing adding single ones isn't going to work. You'd have to continue Joining all possible combinations of subsequent connected ones, until dead ends are reached, then back off and check a different next connected one, or some such process. There are more than 2500 Polylines, and it's hard to imagine the number of permutations that would need to be checked....
Kent Cooper, AIA 
It's hard to imagine how something like an AutoLisp routine could solve something like this except by going through the countless permutations of Joining every possible combination of 3DPolylines, and comparing resulting lengths [assuming that's really a viable basis for choosing the "main" route, about which I have my doubts]. But even if one were to try that, right away, coming in at the downstream end, the very first place where that end-most Polyline has a choice to make between which of two others to Join to, the ends of the three of them are all at different Z coordinates, so they can't be Joined. Other meeting points I looked at [just a few] did appear to have common Z coordinates, but there are over 2700 Polylines, and I wouldn't assume the only mis-alignment is at that one first spot I looked at.
The whole thing is way beyond my ability to imagine any AutoLisp-based solution. One's brain can see pretty quickly what the longer combinations are -- maybe a very few need to be tried and compared to determine the longest, if that's the criterion -- because it can easily ignore the vast majority of the Polylines that obviously aren't contributing to that. AutoLisp would have no way to determine which can be ignored except by slogging through all of them to see whether they lead anywhere.
Kent Cooper, AIA
@ActivistInvestor wrote:
Calculating the length of a series of interconnected polylines doesn't require them to be joined. Typically in processes like this, the length of each polyline would be one of the things that would be cached in memory, and the operation itself would be entirely memory-based, without directly involving any polylines at all.
Sure, once you know which ones are interconnected. Wouldn't you first have to compare both endpoints of every Polyline to both endpoints of every other one, in order to determine which could form possible stream routes? I imagine only by doing that could you determine which combinations of lengths of unjoined ones to add together to test lengths of possible routes. Let's see -- 2700+ Polylines times 2 ends raised to the power of..... I suppose it could be partially limited if they're in 3D, by comparing the higher-Z-coordinate end of every one to the lower-Z-coordinate end of every other, since that's where any flow-direction-relevant connections would be.
Kent Cooper, AIA
@Kent1Cooper - that's why I tend to go for hybrid solutions in cases like this. Use the computer for the stuff it's good at, use the human for the stuff they're good at, so when the tool is being run by the end user it's both fast and reliable.
The actual processing time *can* be brought down a bit but that requires some "data gymnastics" to preprocess the data into logical chunks, much like prepping points for triangulation. And a whole lotta list functions. 
----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.