Label Generation

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

UPDATE element_identifier TAGG

If element_identifier refers to a TAGR owned by a LAYE, then all Labels defined by the given Tag Rule will be 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 will be 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 will apply. Tag Rules will also be updated by UPDATE ALL.

When a Tag Rule is updated for the first time a set of Labels will be created and drawn which can then be edited if required - see Label Editing and Copying. Each Label will have its SORF (source reference) attribute set to refer back to the TAGR.

Labels will 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 will be 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 will only cause replacements to be generated on the next UPDATE TAGG command.

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

When a Tag Rule is updated a second (or subsequent) time, existing Labels will not be deleted and recreated from scratch unless the OVERWRITE option is used, that means,

UPDATE TAGG OVERWRITE (or UPDATE element_identifier TAGG OVERWRITE)

Using OVERWRITE will destroy any editing of individual Labels that may have been done. Not using OVERWRITE will cause existing Labels to be updated so as to reflect any changes that may have occurred in the Design database; new Labels will only be 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 (see above) will be deleted.

The following 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 simply defined as ‘TAG ALL EQUI’. The IDLN attribute of /TR1 is set to /*, that means, 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 would not actually give them names.

The following Design and Draft 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 as follows:

• /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