I’m hoping you can help me with the following situation;
I’m struggling with handling datatree manipulation. Right now I have to manually explode my tree to retrieve my desired result, but this, of course, is not the parametric way and will cause issues if the number of branches in my tree were to change.
I have a data tree containing Breps, representing dwellings in urban blocks. The data tree is ordered first by block, then by type. Now I also have a logic that categorises / groups certain types together. From these categories, I want to order and split the lists of breps within a certain category based on attractor points. Finally, I want to restore the original data tree logic, based solely on blocks and types.
This works, but I can’t make the jump from type logic to categorised type logic without exploding the data tree manually. I hope someone can show me a better way to approach this problem.
didn’t really check what’s going on inside those long copypasted branches of code, but thought that because your paths intrinsically carry informations, and you want to process (split tree) your original {A;B} paths depending solely on the {B} path (split mask), then let’s make B the main path by reversing those:
then if you want to re-apply colors to just those elements you filtered, because they still lie in the right {B;A} configuration that was given to the data tree, you can use something dirty & fast {[(VERY NOT grasshoppery)]} like this:
but better would probably be to rebuild a splitting-mask or partition those in a different way (in particular, that Flatten is terrible, but still…)
anyway, the main point is, if those paths carry info, then keep those with you
you can always go back {B;A} → {A;B} whenever you want to handle previews or extract different data
[edit] in the above I put the A;B → B;A path mapper at the beginning, but you could put it at the end as well, just after the long branch that filters data by the attractor points: nothing really changes, you just use 2 path mappers at the end instead of one at the start
Now my wish is to ‘merge’ the different subtype branches into their categories, following the panel above, then do the attractor point segment, finding the closest breps within the categories, and finally restoring the type-based tree structure so I can see exactly which types within the categories are closest.
Does that make sense? I feel the approach you posted works only on the type level not on the category level.
Thank you again for working this out together with me
if you need to work on Geometries, then you can extrapolate those from the model object, do your thing, and then put them back together at the end (like in case A)
if at a certain point you incour into filtering, for instance a cull pattern of some sort, you can apply the culling directly to the model object (like in case B)
the thing is, as now your info are embedded into model objects, the original data structure itself (that once was the one carrying all the info through the paths addresses) doesn’t really matter anymore, so you are free to reorganize stuff
of course, if for any reason you reorganize your geometry data alone, those changes have to be applied also to the model objects, they should always be sinchronized
Supercool, thank you very much. I was working with a completely seperate parallel data tree based on text. This is a more concise workflow. So thanks again for all the support and explanations!
(in particular, that Flatten is terrible, but still…)
