Edited: 9/13/2023
The Problem with Filtering
In the first post of this thread, I laid out some techniques for how to filter content based on a data type’s attribute or user text value. It worked, but with one major flaw.
The Filter Content component had an input, called Key, which let you define what attribute or user text key that you wanted to use during the filtering operation. Because this was set on the Filter Content component itself, it meant that you could only ever use a single key during the filtering operation.
So, if you wanted to filter the incoming content for floors whose (Area > 2,250) and (Area < 2,500) sf, for example, you’d be fine. But, if you wanted to create more complex rules where you wanted to filter for (Area > 2,250) and (Area < 2,500) and (Use Type = Office) then you’d have to use two separate Filtering Content components because you’re using two unique “Keys” (ie. Area and Use Type).
You can probably imagine that this would soon become untenable as filtering conditions become more elaborate or bespoke.
Complex Filtering
The solution to the problem above is to remove the “Key” input from the Filtering Content component and move it upstream into each of the various Filtering Rule components. In this way, you can define both the “Key” and the “Condition” that you want to filter for in the same component. You can then combine those various filters together using any of the logical operators (ie. AND, OR, NOT, INTERSECTION, and UNION) to form complex filtering rules.
For example, let’s say we wanted to filter all of the floor plates in the original example for the following condition: (Area > 2,250) and (Area < 2,500) and (Use Type = Office)
First, we would create a new filtering rule using the Greater Than Filter. We can right-click on the “Key” input and select User Text from the drop-down combo box and then Area from the tree view control. Lastly, we can create a numeric slider (set to 2,250) and connect that to the value. This filter (when connected to the Filter Content component) will then check all incoming objects to see if they have a User Text key called “Area”. If it does, it retrieves that value and checks it against the defined condition (ie. Area > 2,250).
Now, if you used the any of the Filtering components prior to today, you may have noticed a subtle change other than the placement of the “Key” input. Prior to today, you used to have to right-click on the component and specify whether you wanted to use By User Text Key or By Attribute. This selection would prefilter the set of values that were visible in the “Key” input.
Now, you no longer need to do this. Instead, you simply need to select the appropriate value from the drop-down list that appears in the combo box when you right-click on the “Key” input.
If for example, you wanted to filter objects by their Layer Name, you would first select the Model Object item in the combo box. Then in the tree view control, you would expand the Layer root node and finally select the Name child node.
Putting it Together
Now that we know how to create the filtering conditions, we can combine them using any of the logical operators (if you want to filter objects using more than one rule). In the example above, we wanted to check for the following: (Area > 2,250) and (Area < 2,500) and (Use Type = Office). You’ll notice that each of the conditions (the stuff in parenthesis) are combined using the keyword and. This means that all three conditions need to be true in order for the content to be passed through the Filtering Content component.
There is a component called Logical AND Filter which combines two rules together… however, we have three conditions. To combine more than two rules together using a logical AND condition, we can use the Filter Intersection component which returns true only if all input filters evaluate to true.
Once we have created the Intersection filter, we can pass that to the Filter Content component and it will evaluate all three of the defined conditions and filter the content accordingly. The final definition should look something like this.
We realize that this is not an insignificant change and that you may need to rework existing definitions in order to accommodate this. However, we do think this is a much more powerful solution for being able to create complex filtering conditions in order to manage your data effectively.
As always, we rely on your feedback. Please let us know if you have any questions or concerns about how to effectively filter content in your definitions.
