|
|
Setting up dependencies with 3D spatial rules |
Spatial Dependencies
To access this dialog:
-
Using the Edit Dependency Rules panel, select the Spatial Base Rules tab.
Spatial Based Dependencies
This tab, part of the Edit Dependency Rules panel, is used to define rules where activity points are associated by 3D world coordinates. You define a filter to determine the design data to which the rule(s) will apply (this is defined independently for the activity before the dependency (the predecessor) and the activity after the dependency (the successor).
Once the two 'players' have been defined for a rule, you also need to define the type of relationship between them, e.g. is there an end-start relationship or a start-start (simultaneous activities) or another option. More of these are described below.
Where you wish to constrain dependency generation to a particular structure (or design element), you can do so by defining a Grouping attribute. This will ensure that dependencies are only created between activities representing data sharing a common attribute. For example, you may wish to generate development dependencies solely within the same LEVEL, or for the same orebody or stope.
You also need to define which activity in a group you want to find with the search criteria, and which end of the dependency to use as the search origin. After that, you set up your search rules (extent and alignment) and finally, determine which dependency layer will receive the dependency rules.
Each dependency is assigned a notional index Number, represented by the first table column. This identifier can be useful after dependency generation to filter your loaded data and visualize which design data is affected by which dependency.
|
Rule-based dependencies can be transferred between projects using the Import Dependency function. You can choose to import rule-based dependencies if you wish (disabled by default). |
Field Details
The Spatial Based Rules table contains the following fields:
Number: a read-only index number representing a dependency rule.
Grouping: to constrain dependency generation to a particular group of data structures, using Grouping. By default, [<no grouping>] will be applied, meaning dependencies will be generated between all activities falling within a given search Geometry. Selecting an attribute from the Grouping list will restrict dependency generation to allow activities to be linked only where data shares the same attribute value.
For example, selecting LEVEL will ensure that the spatial dependency rule will only created dependencies between activity points on the same level.
Essentially, applying a Grouping attribute will filter the data that is considered by the dependency generator.
From/To: this group of table columns defines the dependency predecessor or successor of the activity pair:
-
The predecessor (From) is the activity from which the dependency will be drawn.
-
The successor (To) is the activity to which the dependency will be drawn.
The tools available for both From and To items are identical.
Filter: define your design filters here. For example, you may have a filter that applies only to fixed cross-sectional data that has been defined as a decline ramp, and you wish to set up a strict end-start relationship with all activity points along the decline string. In this case, a filter that denotes the decline design data is useful, not only for the assignation of a design definition, but also in defining an automatic dependency rule. In this particular example, both From and To filters would reference the same filter.
This list will contain any system and previously-defined filters. You will also see the filters that have been created by Studio UG automatically, based on your existing design definitions; one filter is created for each definition.
|
|
The Filters drop-down list will contain any system and previously-defined filters. You will also see the filters that have been created by Studio UG automatically, based on your existing design definitions; one filter is created for each definition |
Group
Position: for the From
element, this denotes the position from which a geospatial search
will be performed (which should be considered when you are setting
up your search geometries).
Similarly, for the To element,
this is the position of the activity in the target group you want
to locate with the specified search criteria. You should consider
your inter-activity distances when determining the group position.
A Group Position can be:
-
-
Start – the search will only look for an activity that is the start point of a group
-
End – the search will only look for an activity that is the end point of a group
-
Mid – the search will only look for an activity that is the midpoint of a group
-
Any – any activity will satisfy the search criteria.
-
In summary, the Group Position is used for both From and To searches to indicate which activity in a group you wish to search for.
Link
Position: displays if there is an override in force for either
the predecessor or successor activity. The overrider defines which
activity in the group that is found you want to use as the predecessor.
Overrides are set up using the Edit Link Position tool,
which is displayed on clicking the ellipsis inside the Link
Position field. More...
In summary, the Link Position
allows you to determine an override, and can be used for both From and To
searches to indicate which activity in a group you wish to use to
be either the predecessor or successor.
The image below represents
an example of a simple spatial-based rule. The example shows a search
being performed using the To option as the search origin. The search
is being performed from the Start point of the “A” drive and it looks
for any activity on the “B” drive. The link is being created from
the End position (used as the overrider):
|
From |
To |
Search |
||||||
|
Filter |
Group Position |
Link Position |
Filter |
Group Position |
Link Position |
Origin |
Geometry |
Dependency Layer |
|
B |
Any |
End |
A |
Start |
Start |
To |
20m Sphere |
Default |
Search: this section determines how you search between activity points in order to automatically form dependencies between design data that
passes the specified filters.
Origin: choose which end of the dependency to use as the search origin. Bear in mind that each search will only create a single dependency so when there is more than one dependency required choosing the correct search origin is important. The two columns are mutually exclusive.
Geometry: choose which search shape and size will be used to generate dependencies between proximal activity points. This list contains any previously defined geometries, as generated using the Edit Search Geometries dialog.
From: make the predecessor the search origin.
To: make the successor the search origin.
Azimuth Alignment: determines how to align measure the azimuth in 3D space for constrained searches. The specified search geometry ellipse can either be oriented with respect to the world, or relative to the azimuth of the activity’s point. For example:
Dip Alignment: determines how to align measure the dip of your predefined geometry in 3D space for constrained searches. You can either choose [World] to specify an azimuth relative to North, and a Dip relative to Horizontal, or [Design] to specify an azimuth relative to North, and a dip relative to the activity’s point dip. For example:
-
Dependency Layer: select a dependency layer to associate with the current rule. More...
