- Linkages are keys placed on the graphic elements to link them to tabular records in one or more tables.
- A Linkage can be made up of one or more 32-bit integer values.
- There are two basic Linkage Types: 1Key and 2 Key. While rarely used, there is also support for 3, 4, 5, and 6 keys systems as well as using 1 key and 2 key with repeat modes so that you can have 6 one key links or three 2 keys links on the same element.
- The Linkage Type is defined in the ASCII Data Info section in the .GTM file. Types 1 and 3 (genrally used for Framme, MGE, Shapefile, and GeoDatabase data) are 2 Key; types 2 and 4 (generally used with Smallworld and G/Technology data) are 1 Key.
- Linkages only take up space in an element if they are specified. So, if you are very concerned with the graphics file sizes, do not use linkages on elements you do not wish to link to tabular data. GTConv provides an option drop linkages on categories of data if you wish to reduce the file size.
- A Category is assigned a Data Id. The Data Id corresponds to one of the tabular datasets defined in the ASCII Data Info section. The dataset assigned to the Category determines how the linkage will be interpreted on the graphics elements (1 Key or 2 Key). More than one Category can use the same Data Id, but one category cannot use more than one ASCII Data Info section.
- With Framme data, the linkage is 2 Key. The two 32-bit integers used to create the Linkage are from the feature’s RB_PRMRY (gid) and RB_SCDNRY (ufid) values in the tabular data records. It is also possible to merge multiple Framme segments together and still maintain their data integrity by offsetting the GID values by segments (this is handled automatically by the GTData utilities).
- With Smallworld Data, the linkage is 1 Key. The 32-bit integer used to create the linkage is from the feature’s Object Id value found in the tabular data. However, the 2 Key system is now generally being used to add some additional flexibility.
- With MGE and MicroStation Data, the linkage is 2 Key. The two 32-bit integers used to create the Linkage are from the feature’s Entity Number and Mslink values. The Entity Number and Mslink values come from the element’s original MicroStation linkage. The Entity number corresponds to the table number (defined in the miscatalog table) and the Mslink value corresponds to the tabular records’ MSLINK attribute values. MGE data require two keys because the Mslink values are not guaranteed to be unique across multiple tables; the entity number ensures uniqueness across the records from all tables.
- With Shapefile data, the linkage is 2 Key. The two 32-bit integers used to create the Linkage are from the table number (unique number assigned to each table) and the tabular record’s row id. These Linkages work very similarly to the MGE Linkages; the differences are that the table number is contrived and the row id is an implicit mslink value.
- With G/Technology Data, the linkage is 1 Key. The 32-bit integer used to create the Linkage comes from the G3E_FID attribute on the tabular records. However, the 2 Key system is now generally being used to add some additional flexibility.
- It is possible to have up to three 2 Key Linkages or six 1 Key Linkages on a single Element. It is very rare than more than a single linkage would be needed; however, this functionality does exist to support unusual source data types.
- All records with a common linkage from the tabular data will be displayed when an element is reviewed. For example, if a feature has several records from different tables and/or several records from a single table associated with it, all of these records will be displayed when the element is reviewed as long as all of the records have the same key as the element.
- Examples of 1 Key and 2 Key Linkages are shown below:
- An element can have a Linkage and/or Embedded data.
- Embedded data is a text string embedded in the element itself. A Linkage is a Key embedded in the element that points to data somewhere else.
- Embedded data can be any string value; however, if it follows a simple format, GTViewer, GTVx, GTWeb, GTSketch, and Pocket GTViewer will interpret the information as a tabular record (just as if it were a Linkage pointing to an actual tabular record).
The format for the embedded data is as follows:
\t Table Name
\a Attribute Name
- The tabular record string can contain 1 or more table entries (\t).
- For every \a there must be a \v.
- All \a and \v pairs will correspond with the preceding \t.
- If the SessionGraphicsDataStructureFile entry is defined in the .GTM file, display priorities and alternates names will be applied to the formatted embedded data.
- The element structure supports multiple types of embedded data; however, only Type 1 is currently implemented and Type 1 is a basic Text String.
- The maximum size of a Type 1 Embedded Data string is 2 to the 32nd power (4,294,967,296) characters; however, the practical limit will be significantly smaller.
- Embedded data provides a very easy method for adding tabular data to session graphics. While this data cannot be processed as efficiently as relational data in a dedicated tabular record structure, it can quiet easily handle most data collection needs.
- Embedded data can be retrieved from elements via code with GTViewer, GTVx, GTRead, and PGTReportX. There are also GTData utilities that can dump out the data like GTFormatInfo which reads a .gtg file and output all of the embedded data according to supplied formatting templates. Safe Software’s FME is also able to read .gtg files and understands the table structure embedded in the elements.
- GTViewer can Export embedded data as comma separated value files (with no coding required) and can export the embedded data as XML. Both of these options are available from the Draw/Export/Export Data menu in GTViewer.
- Embedded Data can significantly increase the size of element. Too much embedded data can degrade performance on slower machines (such as the handhelds).
- Embedded data can be used in any Category; however, it is generally only used in Session Graphics Categories since it is more efficient to use linkages for large amounts of data.