Tree sorting, by curve, then by type

[Mark_Keukens]

Hello everybody,

I’ve been struggling quite hard with this tree structure. (having a flu does not help).

I have a plot with 6 groups of each 4 curves, with tree structure {Group; Curve} i.e. {5;3} to which I assign geometry by type (A,B,C,D etc.). The distibution is semirandomized output from a python script. My goal is to organize the types and their corresponding planes by ways of {Group; Curve; Type}

I’ve come to a solution, but its not very parametric as it relies on explode tree and pathmapper.

If I were to change the number of types this would break the script and require manual fixing, that is not an option for this script was, which has the goal of running through many iterations for optimization purposes.

More about the script and the different methods I’ve tried so far:

I have a plot with 6 groups of each 4 curves, with tree structure {Group; Curve} i.e. {5;3} to which I assign geometry by type (A,B,C,D etc.).

Now I’m dividing these curves by a semirandom distribution of Types A,B,C & D which I get from a Python script. These types represent geometric bocks, each with their own grid width. I’m using K/V search to get the corresponding sequence of gridsizes and then partitioning the list of types and grids to produce a list of planes per curve.

These are still grouped in the {Group; Curve} i.e. {5;3} tree format, with different list lengths depending on the number of planes.

So far so good, only the next step is sorting the planes by type so I can use orient to place the proper geometry on the proper plane. I do this by means of the member index component.

However leaves me with a tree with 4 branches each branch representing a type (A,B,C,D)

My wish however is to attain a tree structure that is organized as such {group;crv;type} i.e. {5;3;2}.

Each branch would contain just one Type i.e. B, on a specific curve within a specific group.

I’ve tried a multitude of ways to attain this tree structure, trying to work within one member index component, grafting, flattening, I’ve tree exploding the tree, quadrupling the tree and splitting the member index per type. I’ve tried splitting up the original indexes by curve and using that to create domains, which I then cross referenced with the indices of the assorted types. That finally did the trick.

However as said, it’s not a dynamic, parametric solution yet. Help and insights will be greatly appreciated! Please have a look at the script and let me know your thoughts.

forumquestion_tree sorting.gh (367.6 KB)

[Eef_Weenink]

I have read it two times and don’t understand want you want to achieve.
I understand it is about working with the datasets to get what you need. (Not the geometry itself).
You use a couple of plugins so not possible to run your script here.

request:

• Please make a smaller version (if possible) without plugins.
• try to describe in logical steps what you want to happen. (most of the time this is very helpfull in finding the solution yourself).

Regards, Eef

[Mark_Keukens]

Thank you Eef, that’s fair. I’ll repost a more succinct version of the question and the script here shortly.

[inno]

you can use something like this to create a new layer of branches (0 or 1 or 2 or 3) that represent the letters (A, B, C, D) into something like {group;crv;type}

just note, for instance, as in the branch {0;0} they are all type C (type C is represented by number 2), so everything in branch {0;0} is moved to branch {0;0;2}

different story for instance in branch {0;1} which has 12 elements and has no B type (so only 0, 2, 3) and its elements get branched into {0;1;0}, {0;1;2}, {0;1;3}

just keep in mind this branching has no way back, it’s not “retro-compatible” (so this is a sort of “destructive” intervention, with a brand new data-tree starting point in the time line)
→ this happens because stuff is now branched by type: you can’t trim tree anymore and compare to previous versions of that same data-tree because you would end up with the right elements in each branch but in a (most probably) wrong sorting order

forumquestion_tree sorting_inno.gh (30.5 KB)

[Volker_Rakow]

@Mark_Keukens

My wish however is to attain a tree structure that is organized as such {group;crv;type} i.e. {5;3;2}.

Each branch would contain just one Type i.e. B, on a specific curve within a specific group.

Well, clearly, if you want each branch to contain just one type, then your tree hierarchy cannot be {group;crv;type}, but rather must be {type; group; curve} or {type; curve; group}…

[inno]

once you have {group;crv;type} you can Replace Paths into {type;group;crv} like:

the main point -to my eyes- is data “backtrackability” is anyway lost

forumquestion_tree sorting_inno2.gh (28.1 KB)

[Volker_Rakow]

I mean… sort of? You can always backtrack the method you used to get where you started?

I feel like I should clarify. I understand what you are saying, but to be able to use graft and trim in the way we are accustomed is the reason that I recommended that the data structured {type; group; curve} from the get go; so that the data is serialized, not just sequenced. Also, wouldn’t a method that inserts nulls into tree also solve this problem?

[Mark_Keukens]

Thank you Inno, that’s fantastic, it does work very well for my purposes which is mainly to be able to track different amounts of types per group/ curve.

I verified that it works, I don’t think the “missing” branches are a problem, pretty easy to append those later.

forumquestion_tree sorting v2.gh (62.9 KB)

[Mark_Keukens]

Just wondering if the same method can be used to gather all the types within a group or curve? i.e. merging the innermost or middle branches to find type totals per curve, per group and then for the whole plot?

manual method would be something like this.

The most important is to be able to extract data per group level (highest path index)

[inno]

yes, you can for sure always backtrack the method to transform data structure back into an earlier-structure version

my point was more about being very careful on adding branching where the path itself carries some intrinsic properties/meaning, because that alters the data itself to the point where the data tree is not trimmable anymore, as you are literally re-sequencing the data into something else (as you have also correctly stated)

for what is worth, the way I got used to handle data trees, I would keep the initial data tree “as it is” (meaning just {a;b} paths) and keep a parallel data tree with very same {a;b} structure containing just the corresponding ABCD letters

if you want to create some filters, do those for the ABCD tree, then apply them to the original one, but do not alter the original one through branching by properties (unless you are in the case that OP just well explained, where he just wants to make some sort of counts on the ABCD types, then probably that tree will be forgotten forever )

---

to answer @Mark_Keukens last question, you don’t really need to touch the original {group;crv} data-tree to get those info, as you already have all the required data in the other ABCD tree

here you have your planes (on the left) but on the right you have all the data you need to make any sort of count, just use the data tree with ABDC info

here to get ABCD count by {group;crv}:

here the same by {group} alone:

and here the grand ABCD total:

you don’t need to embed these properties into the tree containing the planes to extract data, as you have a dedicated tree with just these and the correct data structure

forumquestion_tree sorting_inno3.gh (28.1 KB)

[Mark_Keukens]

Hi Eef, I uploaded a more compact version of the script in response to Inno’s solution

[Mark_Keukens]

Wow Inno, that’s amazing, thank you so much for your help and explanations! I learned a lot today!

[Volker_Rakow]

@inno

for what is worth, the way I got used to handle data trees, I would keep the initial data tree “as it is” (meaning just {a;b} paths) and keep a parallel data tree with very same {a;b} structure containing just the corresponding ABCD letters

That is exactly the way I am currently learning to deal with Data Trees.

[Mark_Keukens]

@inno

for what is worth, the way I got used to handle data trees, I would keep the initial data tree “as it is” (meaning just {a;b} paths) and keep a parallel data tree with very same {a;b} structure containing just the corresponding ABCD letters

This is very valuable advice indeed! Saving this post

[Volker_Rakow]

forumquestion_tree sorting_vr_01.gh (403.2 KB)

plus letter sorting:
forumquestion_tree sorting_vr_02.gh (396.2 KB)

[Mark_Keukens]

wow that’s a super clean definition , thank you Volker!

If I can just pick your brains for a bit more;
I combined yours and Inno’s scripts and did a trial where different types share the same grid size. I saw you used the grid sizes as keys in the K/V search.

Three questions arose:

1. I assumed that using duplicate grids would force me to use the types as keys again, but this doesnt seems to be case (which still puzzles me a little).

2. I also noticed I’m not always directly getting an output from member index which matches the original tree as was the case in Inno’s script. Luckily I could put the newly learned tricks from that script - (de)construct path - to fix the structure. Just wondering here what could cause the tree structure to be different then expected.

3. I’m planning to do some geometry manipulation (clash detection with other geometry etc.), in this case I would need to apply the filters attained from the geometry tree to the distr/crv tree, correct? Like @inno mentioned here:

@inno

for what is worth, the way I got used to handle data trees, I would keep the initial data tree “as it is” (meaning just {a;b} paths) and keep a parallel data tree with very same {a;b} structure containing just the corresponding ABCD letters

if you want to create some filters, do those for the ABCD tree, then apply them to the original one, but do not alter the original one through branching by properties

and would you call this technique “parallel trees” ?

forumquestion_tree sorting_vr_02_mke.gh (52.6 KB)

Thank you again,

Best regards,

Mark

[inno]

@Mark_Keukens

and would you call this technique “parallel trees” ?

I don’t know if it has its own name
once you have even many different data trees with very same structure, each of which carry some kind of info (in this case one of those trees carrying some particular property was the ABCD type data-tree) instead of creating a brand new tree that embeds these additional property into the original one, you can interrogate the ABCD tree directly to get a particular filtering
(for instance in the following example the question is “which members are type C?”)
and as last step you can apply that filtering mask to the original data tree

you create the filter one one, then apply the filter to the other:

that can be useful in case you need for instance to isolate just some elements from the main tree

---

but let’s say for instance you want to give preview colors to your Geometries depending on the their type, in that case you don’t need to isolate each type on a separate tree (also, if you have like 150 different types what are you gonna do? 150 copy-paste? and if you have 1500 different types?)
in that case you just take advantage of having a separate tree that carries the “type” info, and can use that to generate a new tree where a different color is assigned to each type, then use it as color preview, like:

forumquestion_tree sorting_inno4.gh (30.3 KB)

this way you don’t touch/reorganize/restructure the original data you are working with, but just leverage on its tree-structure
we could write a whole book on how to best structure data-trees for a particular task, but that’s a much different topic

[Mark_Keukens]

Haha I thought I read that name “parallel trees” somewhere. Anyway, whatever the name is, this technique is awesome and extremely useful. Thanks for showing these different examples in which it can be useful! I’ll add a parametric way to assign colors, then its a super scalable script!

[Volker_Rakow]

@Mark_Keukens

I assumed that using duplicate grids would force me to use the types as keys again, but this doesnt seems to be case (which still puzzles me a little).

It does. Look closer:

You cannot Match Text against the grid spacings as keys because these are numbers:

@Mark_Keukens

I also noticed I’m not always directly getting an output from member index which matches the original tree as was the case in Inno’s script. Luckily I could put the newly learned tricks from that script - (de)construct path - to fix the structure. Just wondering here what could cause the tree structure to be different then expected.

That’s because my script doesn’t do anything to change the data structure beyond how you had formulated it in your opening post:

so using Member Index on it will deliver the same results.

Your attempted manipulation of Inno’s script btw doesn’t do anything at the moment:

other than add a depth of hierarchy to the beginning of the tree.

@Mark_Keukens

I’m planning to do some geometry manipulation (clash detection with other geometry etc.), in this case I would need to apply the filters attained from the geometry tree to the distr/crv tree, correct? Like @inno mentioned here:

I have already prepared for that by the end of the script, though you may want to make the changes for “duplicate grids” as you have:

Grid spacings, placed geometry, type distribution all have the same data structure; by which is meant the data trees have the same number of branches, the same list length to the each of the branches, and elements between the different data trees are related by the same path and list indices. The hierarchization of the branch path labels are wholly irrelevant i.e. {0;1;8} or {2;9}, it doesn’t matter as long as the two associated paths have the same path index i.e. their serialized whole number renumbering is the same.

Changes for “duplicate grid”: forumquestion_tree sorting_vr_03.gh (44.7 KB)