Label Generation

Having set up a TAGR element and its associated autotagging rules, the Labels are generated by UPDATE TAGGING command:

UPDATE element_identifier TAGG

If element_identifier refers to a TAGR owned by a LAYE, then all Labels defined by the given Tag Rule are generated.

If element_identifier refers to a LAYE, then all Labels defined by all of the member Tag Rules of the Layer, plus those owned by the TRST referenced by the Layer’s TRSF attribute are generated.

If element_identifier refers to a VIEW, SHEE or DRWG then this is equivalent to giving an UPDATE TAGG command for each Layer beneath them in the hierarchy.

If element_identifier is omitted then the current element is assumed and one of the three previous conditions applies. Tag Rules are be updated by UPDATE ALL.

When a Tag Rule is updated for the first time a set of Labels is created and drawn which can then be modified if required. Refer to Modify and Copy Labels for further information. Each Label has its SORF (source reference) attribute set to refer back to the TAGR.

Labels are not be created for any element that is not drawn because

• It is not included in the VIEW’s Id List

• It falls outside the VIEW rectangle

• It is excluded by the action of a Section Plane

In the latter two cases, whether or not an element is excluded depends upon the position of the p-point to which the Label is to be attached. Note that Labels are created for elements that are not drawn because they are obscured by others. If these Labels are not required it is recommended that they are made invisible by setting LVIS FALSE. Deleting them causes replacements to be generated on the next UPDATE TAGG command.

If a LAYE element is LOCKed then none of its TAGRs are updated. An UPDATE ALL command still causes the annotation of that Layer to be updated. If a GLAB or SLAB, which needs to be modified or deleted, is LOCKed then it is UNLOCKed and the modification or deletion carried out.

When a Tag Rule is updated a second (or subsequent) time, existing Labels are not deleted and recreated from scratch unless the OVERWRITE option is used, for example,

UPDATE TAGG OVERWRITE (or UPDATE element_identifier TAGG OVERWRITE)

Using OVERWRITE destroys any modification of individual Labels that may have been done. Not using OVERWRITE causes existing Labels to be updated so as to reflect any changes that may have occurred in the Design database; new Labels are only created for those Design elements found without Labels with correctly set SORF attributes. Any existing Label (with a correctly set SORF attribute) on a Design element which no longer exists or which no longer meets the criteria of the Tag Rule is deleted.

The example illustrates the effect of updating a Tag Rule a second time (without OVERWRITE):

VIEW /VIEW1 has an Id List /LIST1 which calls up four Equipments, /VESS1, /VESS2, /VESS3 and /VESS4. /VIEW1/LAYE1 owns Tag Rule /TR1 which is defined as ‘TAG ALL EQUI’. The IDLN attribute of /TR1 is set to /*, for example, the whole of /LIST1 is to be scanned and all EQUIs tagged.

When /TR1 is updated for the first time four Labels are created in /VIEW1, one on each of /VESS1, /VESS2, /VESS3 and /VESS4. For the sake of convenience we shall refer to these Labels as /LAB1, /LAB2, /LAB3 and /LAB4, although the autotagging process does not actually give them names.

Design and Draw database changes are then made:

• /VESS1 - unaltered

• /VESS2 - moved by W2500

• /VESS3 - deleted

• /VESS4 - removed from /LIST1

• /VESS5 - added to /LIST1

When /TR1 is subsequently updated the Labels change:

• /LAB1 - updated, but no changes

• /LAB2 - updated, and moved to reflect new position of /VESS2

• /LAB3 - deleted

• /LAB4 - deleted

• /LAB5 - new Label, created on /VESS5