Is it possible to match the level of an element by its offset?
I have a workflow that adds a sphere around clashes. Now instead of searching each element ID to find the clashes I would like to show what level each clash sphere is on.
In the above workflow I would be looking to match the sphere elements with the level list at index 17.
If I have well understand your question, I would suggest you to extract the Location (Element.GetLocation) of the family Clash Sphere, then subtract the Z of the position with the “Offset from Host”. The result should be exactly the Elevation of the hosting level so you can easily create the comparison between sphere and levels.
I would suggest you to GroupByKey all the sphere, using the found value as key, and then make the equivalence to discover who is match with who.
extract a relevant Z value of each sphere, list all the elevations of your levels, and subtract the one from the other. The set of values that returns the smallest difference is the one corresponding to the closest level to that sphere.
there´s a couple cross products involved so it can get slow if you have a lot of elements or levels
Thank you! I am getting a error on the List.sortbykey… I tried to list.sort on the level elevations before the “-” node as well.The error says:
“Warning: Internal error, please report: Dereferencing a non-pointer.
Internal error, please report: Dereferencing a non-pointer.
List.SortByKey operation failed.
Number of items does not match the number of keys.”
your list structure for the lower flow is one deeper than in my example - either change the list@level for the sortByKey, or try flattening the list after your point.z node
The error is gone. How do I match my sphere to the level name now?
Since there are negative values, this is the only way I could get it to work:
Is there a better approach?
Why not just get Level of sphere using Element.Level custom node from clockwork package:
I tried that first and it resulted in nulls:
@Smaren this should solve for you:
Note: I just added shuffle for testing purpose. You can ignore Shuffle and follow the rest of the nodes.
No, extracting the absolute value of the height difference is of course correct - I forgot about it in my draft. It is also, by the way, what the Spring node does. So it´s still what you are doing, you are just not seeing it