Filtering nodes by node properties
3D nodes may have associated attribute/property data. Reveal allows for filtering based on
these properties, allowing queries such as "all pipes", "nodes within module P600" or "nodes
with status S5". Combinations are also possible by using UnionNodeCollection and IntersectionNodeCollection.
PropertyFilterNodeCollection is used to query nodes based on node properties. It's possible to specify
multiple criterias which will be combined using AND - i.e. all criterias must be met for a node
to match. To emulate OR, use UnionNodeCollection.
Note that if a node is in a PropertyFilterNodeCollection all of its children will also be
in the set.
The test model used in the documentation site is lacking good node properties and the quality of the examples shown is therefor restricted as a result of this. To best utilize the filtering APIs we recommend providing a rich 3D models with a good set of high-quality attributes associated with the nodes.
Show all pipes
If nodes in the 3D model has an attribute 'PDMS.Type', PropertyFilterNodeCollection can be used to
retrieve nodes of a certain type. In the following example, only pipes are accepted:
Partitioning requests
For filters that match a lot of nodes, paritioned requests
might increase the performance radically by fetching result from the server in parallel.
To partition requests, provide the number of partitions using the requestPartitions-option
to the PropertyFilterNodeCollection-constructor:
To compare speed-up, set requestPartitions to 1.
Combining filters
Often one would want to match multiple criterias of the same type. Lets say we want to find all mechanical equipment with purpose 'STU'. We can either execute this as a single query, or as two seperate queries.
When doing this as a single query, no IntersectionNodeCollection is necessary and the code is quite compact:
Combining two separate queries requires the use of IntersectionNodeCollection:
The two approaches has their pros and cons. Often it will be faster to combine the filters into a single query as this will reduce the result set returned from the server. However, if the different combinations will be configured run-time (e.g. the user will want to show 'ARCH'-nodes within the 'STU'-purpose) it might be better to use two separate queries and combine the results. Also, the latter approach also allows for more complex types of filters.
Matching nodes with a list of values
There might be situations where an application has a long list of identifiers of nodes to show
or style. In this case, SinglePropertyFilterNodeCollection might be useful. This class will match
one node property towards many values - e.g. a node identifier towards a list of IDs. This node set
supports thousands of IDs - PropertyFilterNodeCollection only supports one matching value.
Inverting filters
Often it is interesting to invert results from filters to find elements that does not match the query. This
can be done using InvertedNodeCollection.