Filtering nodes by node ID or 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.
NodeIdNodeCollection contains a list of nodes identified by their CDF IDs.
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.
SinglePropertyFilterNodeCollection is similar to PropertyFilterNodeCollection, but differs in that
it only matches on a single node property and is able to match on a list of values. This is useful
to e.g. provide a list of node names or source system IDs.
Note that if a node is in one of the collections discussed in this page, 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.
Highlight nodes identified by IDs
If Node IDs are known, NodeIdNodeCollection can be used to style the nodes (and the children):
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 and combining 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. In the following example, a single system is isolated
and all pipe support for the system is hidden.