Hi!
Im trying to assign branches in the tree according to the culled list. Any ideas, how to organize those branches? I feel like Im missing out on something obvious. 
Thanks!
3. Attach minimal versions of all the relevant files
you can use Replace Paths to do that, the problem is that you have 2500 branches to assign, and the Cull Pattern outputs 2508 values: they need to be the same
1 Like
Rene, thanks for your input!
However, in this case, it does not do the job, as the final tree have different amount of items. And as far as I understand, the branches can not be renumbered, as the final items, must keep the relation to the branches for data to make sense.
1 Like
Got it - similar to Joseph at first I wasn’t sure what you meant by organizing the branches according to the culled list so I combined them?
I had done what Inno suggested and realized the same thing.
Cheers
Inno, that might be the right direction.
In the new GH file, I have fixed the data, so now it has the same amount of branches. However, the final result is not as expected, as according to data, the final tree should have 21 branches.
I actually figured that I probably need new tree structure to preserve all data. I have skeched it in picture below. The key is the branch which both trees are pointing to - thats where the tree is connected.
tree_structure.gh (1.2 MB)
Any idea how to deal with it is appreciated!
believe me or not… I really cannot understand what you are looking for
if it does not bother you, here is the image of the “important points” on the last definition you posted:
please describe what you are looking for, I would use terms like branch count, item count, like: “I would like data in E to have the very same branch count of D, and very same number of items per branch as in D” or something like that [sorry for the crosshair, I’m in the Finals <3 ]
Well… I do believe that its hard to understand from my explanation. Especially when im strugling to understand myself, what exact outcome is possible and workable.
I may have included a little too much data. Could be that data D and E would be enough.
Lets try once again:
Data E consists of 21 branches. Each of those branches have different number of paths (For example (0) have 76 paths, (1) have 253 paths etc.). In total, there are 2372 paths in 21 branches. Those paths are not in sequance.
Data D, has 2372 branches, each branch has 16 unique parameters, which should keep relation to its branch.
I would like to get the tree like data E (with 21 major branches), but the data would be assigned from data D, according to paths provided in data E. There are equal number of paths in data E and branches in data D, and they should match, except in data E its divided in 21 branches.
So for example, the first branch should be (also check the picture below):
(0:319)[16] (the 16 items in the list must have the same data as 319 branch in data D) then
(0:383)[16]
(0:398)[16]
(0:686)[16]
.
.
(0:10225)[16]
.
.
(1:13)[16]
(1:66)[16]
(1:84)[16]
.
.
First branch should have total 76 branches assigned, second - 253 branches assigned etc.
Sorry, in earlier post, I might have overcomplicated expected tree for no reason. Now I see that two branch levels should be enough.
Thanks a lot!
Hope you are winning!
this was super clear 
here is a McGiver version that uses text operations to write the different paths
tree_structure (1)_McGiver.gh (1.1 MB)
this is still McGiver-ish but at least uses gh components to handle paths:
tree_structure (1)_McGiver_2.gh (1.1 MB)
1 Like
So far it seems that it worked as expected!
Thank you so much! Spent so much time trying to figure it out…
Hi Inno,
I might have celebrated a bit too early.
It turned out, that even if the number of branches seems correct, the data assigned to each branch is incorrect.
I realized that with previous example it was not possible to test if correct items are asssigned, as all of items were the same all accross branches. but with the real data,all of these items are unique, and as mentioned earlier, their relation to the branch must be kept.
I have corrected the initial data by leaving first item on the list as in original data - and the first item on the list is ID.
Now, when that is done, you can see that (0;319) branch have assigned list with ID 4, while it should have list with ID 320:
tree_structure.gh (1.8 MB)
Any ideas how to sort them in correct way?
Thanks!
1 Like
[edit] for the record, the example in this post is wrong and here is why: Organize tree branches according to culled list - #17 by inno
I just had this thought while doing other things…
as far as I understand, the Renumber/Maintain option should not make any difference in the final output (B) because the “name” of those paths temporarily exists between A and B only to be replaced: all those paths (A) are fully intercepted and replaced by (B) whatever “Maintain/Renumber” option you activate
if you Maintain them, the full list of maintained paths will be replaced, and if you Renumber them, the full list of renumbered paths will be replaced anyway
tree_structure (1)_McGiver_3.gh (1.1 MB)
I can’t reproduce the error you wrote about in your earlier post, and swapping Renumber/Maintain does not create any difference in the final result in my GH (Version 8 SR3 (8.3.23346.14001, 2023-12-12)
[edit] here is a simplified example where it’s easier to follow the data flow, colors have always helped me visualize stuff
tree_structure (1)_McGiver_colors.gh (592.3 KB)
As far as I understand, the paths are changed, but in this case, its all about the sequence of the branches, and it makes all the difference.
Structure of tree in both cases are the same, but the lists that are assigned to each branch are not the same. As mentioned erlied, my initial data kad exactly the same list items in all branches, so it was impossible to check it the right list is assigned. In one of the scripts uploaded eralier, I have updated the initial data (by leaving first item of the list original - in original data its ID). So if you check with new data, you can see that lists assigned to each branch are not the same in thos two cases:
tree_structure (1)_McGiver_3.gh (1.3 MB)
1 Like
you are right!
my assumption above is wrong, but looks like it’s working only because the paths retrieved by the Tree Branch component are sorted in ascending order (I mean this one circled in blood)
the main point of the whole thing is in how the “Maintain/Renumber” works, and I got punched in the nose by the following:
“Maintain” just culls any branch that is not listed in the Path input, so the original tree structure is mantained, and that is the reason why the data was not retrieved in the right order