How is search meant to work?

falken10vdlfalken10vdl
in General

This is a followup of discussion https://community.osarch.org/discussion/3200/simple-operator-for-getting-element-values-formatting-from-selector-syntax
To not add noise to the parts of "Getting element values" & "Formatting", this is just to understand how the search mechanism in Bonsai (operators "add_filter_group" and "add_filter" for modules "search" and "csv") uses the IfcOpenshell Selector sytax "filtering-elements".
I am just testing in

os: Linux
blender_version: 4.5.3 LTS
bonsai_commit_hash: aeed371
bonsai_commit_date: 2025-11-04T19:24:22+05:00
originating_system: Bonsai 0.8.4-alpha251105-039b9d3

and it looks to me that the is an OR everywhere. Example:

Is this how it is supposed to work?
Within a "Search group" the filtering should not be done in cascade so AND between the filters? (in the example above AND between globalID "2KGgMzZDLE3OPiUP4282Ex" and "IfcWindow" which should be 0 results

Thanks!

Comments

  • falken10vdlfalken10vdl

    @brunopostle I have updated the suggestions so the class hierarchy (not the spatial decomposition) as you mentioned is printed before the element.
    For globalID the format is hierarchy_str (IfcClass): GlobalId
    Examples:

    MyBuilding < Level 1 < MyWall (IfcWall): 2a3b4c5d6e7f8g9h
MySite < MyBuilding (IfcBuilding): 1a2b3c4d5e6f7g8h
MyElement (IfcColumn): 9z8y7x6w5v4u3t2s
(IfcBeam): 0q9w8e7r6t5y4u3i (no hierarchy)

    For Parent the format is hierarchy_str (IfcClass)
    Examples:

    MyBuilding < Level 1 < MyWall (IfcWall)
MySite < MyBuilding (IfcBuilding)
MyElement (IfcColumn)

    Thanks!

  • brunopostlebrunopostle

    The selector syntax does the job, but yes it is a bit confusing that selections are cumulative, until you add a filter which reduces the selection.

    theoryshaw
  • sjb007sjb007

    @falken10vdl It's behaving weird for me too. I can reproduce your outcome if I use the same style search setup.
    If I change it to:

    Then the group with the two filters only selects doors that are marked to be demolished. i.e. the result looks like the two filters are AND'd, and it only selects the doors marked to be demolished.

    Figured it out! Some filters are "special", and select from all elements additively (Class and GlobalID), and others act on the result of the previous filter (all the others). If you look at the Filter table on the page you linked, the Type column shows this as Add and Filter.

    So it's not intuitive, but it is understandable once you wrap your head around the specifics.

  • falken10vdlfalken10vdl
    edited November 2025

    from: https://community.osarch.org/discussion/3200/simple-operator-for-getting-element-values-formatting-from-selector-syntax#latest

    @brunopostle said:
    @falken10vdl I was thinking of the IFC class structure. Classes such as IfcDoor and IfcWall are both members of a 'super class' IfcBuildingElement. If you do a selector query for IfcBuildingElement you will match all the physical components of the building - even though there are no instances of IfcBuildingElement in the model.

    Ok I think now I understand you better. I have updated the implementation as follows:

    Hierarchy Separators:

    • ">" Schema inheritance (type hierarchy) - flows from base class to derived class
      USED IN FILTER: Class
      Example: IfcRoot > IfcObject > IfcProduct > IfcWall

    • "<" Instance hierarchy (spatial/decomposition) - flows from parent to child
      USED IN FILTERS: Location, Type, Group, Parent, GlobalId
      Example: MySite < MyBuilding < Level 1 < MyWall

    Markers:

    • (superclass) = Indicates an abstract class in schema hierarchy
    • (IfcClassName) = Shows the IFC class of an element instance
    • : GlobalId = Separates the GlobalId from the element context (only shown if required to distinguish instances)

    Does it make sense?
    Cheers!

  • falken10vdlfalken10vdl
    edited November 2025

    @sjb007 Thanks for the clarification! and pointing to the behavior:

    So except for Class and GlobalId the other behave that Filter_groups are unioned (OR) and filters within a group are chained left to write (AND from left to right).
    For the case of GlobalId and Class we have the possibility to add/substract. Let me add an operator in that case to make this distinction apparent.
    Thanks!

  • sjb007sjb007

    Yeah... Although it gets even more complicated... Using the ! makes the class/globalid act like a filter in that it removes them from the group selection, but it only works if there are previous filters in the chain. It cannot be the first in the chain. Oh my! Soooo convoluted. Competing with regex's for the "Most likely to make your brain explode!" award.

  • falken10vdlfalken10vdl

    Indeed! :) I have added a toggle for Class/GlobalID that cycles between add/subtract/filter.
    Filter and Subtract is applied if there is already another filter previously that it is used as "elements" to chain.
    In the edit_filter_query I have tried to explain that behavior. The difference between add and filter is just this chaining, as the query is the same.
    See an example below:

    Cheers!

    sjb007walpa
  • falken10vdlfalken10vdl

    fyi. You can test https://github.com/IfcOpenShell/IfcOpenShell/pull/7315 in latest bonsaiPR: https://github.com/falken10vdl/bonsaiPR/releases/tag/v0.8.4-alpha251105
    Cheers!

  • sjb007sjb007

    Yup. Already had a play with it. Works well. One small usability niggle. The mode button (+ / - / Y) of the first filter has no impact which is as expected based on the selector syntax. Might be good if that is omitted or disabled for the first entry.

  • falken10vdlfalken10vdl

    cool! Yes, updated. If Class or GlobalId are first, we remove the entry (and it behaves as if an ADD was active)

    Thanks!

    sjb007
  • falken10vdlfalken10vdl

    I have added a remove search button so one does not need to go to the group panel to remove saved searches. Also updated the functionality to cope for the (+/-/Y) settings.

    Cheers!

    John
Sign In or Register to comment.