# SUBSYSTEM OVERVIEW

IGES Mapping (IMAP) Subsystem

The IMAP subsystem provides mapping functions for manipulating entities in the IGES interface. The mappings available in the IMAP subsystem are described in the imap_mappings manual page.

# MAPPING ATTRIBUTES

Attributes are usually mapped from an application dispatcher. The recommended approach is to map attributes after committing an entity with map_CommitEntity. IGES attributes have a hierarchical nature and are tracked with an EAM (Entity Attribute Manager) stack. It is best to apply the EAM stack to the original entity first and then map attributes from the IGES_ATTR structure that is returned to the target entities. The following code demonstrates how attributes can be applied.

       {
          .
          .
          map_CommitEntity (MAP_NOOPT, db_ptr, info, &new_db_ptr);
          mda_LockEntity (MDA_NOOPT, new_db_ptr, &new_ent);
          orig_db_ptr = mda_GetOrigDbptr (MDA_NOOPT, new_ent);
          mda_LockEntity (MDA_NOOPT, orig_db_ptr, &orig_ent);
          iges_attr = (IGES_ATTR *) eam_GetAppliedAttr (EAM_NOOPT,
                                    info->stack, orig_ent);

          /* Map attributes from iges_attr to target entity */
          .
          .
       }

The sample program, itoi.c, further demonstrates this concept within its application dispatcher.

Additional Guidelines

Other caveats that should be observed when mapping attributes to target entities in an IGES model follow:

1)

Explosion of IGES subfigure entities having an integrated scale factor can result in a matrix in the IGES_ATTR struct with embedded scaling. Since scaled matrices are illegal in IGES, it is necessary to factor the scaling out of the matrix and apply it directly to the entity being committed. Refer to the itoi.c sample program for details.

2)

IGES conics (104:*) and circular arcs (100:0) are special case target entities that require a slight addition to the attribute mapping process discussed above. The possibility exists for these entities to be oriented with a referenced matrix. It is thus necessary (after committing) to concatenate the matrix with the matrix determined after applying attributes to the original entity. This is also demonstrated in the application dispatcher of the itoi.c sample program.

# COMMITTING AN IGES ENTITY

Although the process of committing an IGES entity is generally the same process used for committing any entity, special conditions can exist which cause unsatisfactory results. Particularly, if committing an IGES entity having pointer references from its DE, ASSOCS, or PROPS fields, all entities referenced will be recursively copied as well. Since the information in these fields is essentially useless at entity committal time, it is sometimes wise to temporarily default these fields before committing and then restore them when finished. Thus if a call to map_CommitEntity results in copying the entity passed to it, unnecessary DE, ASSOCS, and PROPS pointer references will not be copied along. This is really only necessary when mapping between two IGES models. For a source code example, examine the sample program, itoi.c.