Monday, July 31, 2006
Tuesday, July 25, 2006
When a GTViewer dataset is created, a Session Category is generally defined in the data (in the .GTM file). A session category is similar to any of the other Categories in the GTViewer data, except that it does not have a predefined graphics file (.gtg) or a predefined spatial index (.gtn). Instead, the Session Category points to the user’s session which can be a GTViewer Session File (.GTS) file or the embedded session in an extract file (.GTX). Session Graphics can also be exported as a GTViewer graphics file (.GTG), Shapefiles, .DGN files, or XML.
While Session Graphics may appear somewhat straightforward, there are many features they provide that might not be readily apparent. A session graphics element supports both Keys (linkages) and embedded data (for more information on the differences between keys and embedded data, see Linkages and Embedded Data).
The basics for Session Graphics are the same in all of the GTViewer Family of products: GTViewer, GTVx, Pocket GTViewer, GTWeb, and the Pocket GTViewer Control. There exists a set of properties that define many of the characteristics of session graphic elements. This set of properties consists of FilterId, ColorId, StyleId, Weight, and ExtendedStyle; and these properties use a current state concept. When one of these properties is set to a value, all session graphics elements created subsequently will use this property’s value; until it is changed to another value. So if you set the current ColorId to 3, then add a line, a circle, and a text element; all of these elements will use color id 3.
Filter Id and Session Graphics
Filter Id is an important property that is sometimes not fully understood. Filter ids are used for several different things, and this is probably why they are sometimes confusing. Filter Ids are a way to group common elements; they can be thought of as layers or levels and each GTViewer category can (currently) have 500 unique filter ids. The Filter Definition files (.flt files defined in the category sections of the .GTM file) specify a name and several properties for each Filter Id (such as min and max display thresholds and selectability).
Filter Ids are used by several important mechanisms in GTViewer, such as Display Control and Style Rules. Display Control (or the Display Filter, which is the origin of the term filter id) determines which elements are displayed either by turning an entire category on or off, or by turning individual filter ids within a category on or off. The grouping of common features provided by the filter ids provides a logical and effective method for controlling the display.
Style Rules are another feature that uses Filter Ids. Style Rules map a style definition to a particular filter id in a particular category. Once mapped, all elements in the category with the filter id have the mapped style definition applied to them before rendering. Some data uses style rules for all symbology, some data uses instance-based symbology with no style rules, and some data uses a mixture of style rules and instance-based symbology. For more information on Style Rules, see The Dynamic Display.
Adding Embedded Data to Session Graphics Elements
Unlike the element characteristics specified with the current state properties like FilterId, color id, style id, and weight; Embedded Data and Keys, use an only-for-the-next-element concept. So if you set Embedded Data to a value, the data will be embedded on the next session graphics element added, but then will be reset. So, if you set the Embedded Data to a value, place a line, and then place a circle; only the line will have embedded data.
Embedded Data can be any text string you want to store on the element; however, if you use the t-a-v format, the embedded data will automatically be processed like a database record. The t-a-v format is very simple:
You specify a one or more records by starting with \t followed by the table name. Then for each attribute/value pair, add \a followed by the attribute name, and \v following by the attribute value. You can repeat the \a\v pairs for as many attributes as you need. If you need to represent more than one record, simply add another \t entry followed by a set of \a\v pairs. For example:
Embedded Data is a very power tool for collecting attribute data along with graphics and can be processed in many ways. GTRead can read this information, and so can the automation layer in GTViewer and GTVx. GTViewer can export just embedded data (by table) as wells as export XML containing the both geometry and tabular information (including the embedded data). There is also a GTData tool called GTFormatInfo that can read a .GTG or .GTX file and export the embedded data in a user-specified format (like SQL Updates, CSV files, etc.). \tPole\aPole_Number\v1234\aHeight\v45\aClass\v1 Table: Pole Attr 1: Pole_Number=1234 Attr 2: Height=45 Attr 3: Class=1
Attr 1: Pole_Number=1234
Attr 2: Height=45
Attr 3: Class=1
Adding Keys to Session Graphics Elements Keys are simply one or two 32 bit integer values embedded into the Session Graphics element. When an element is reviewed (with Attribute Info or through programmatic means), the keys on the element are retrieved and then the database associated with the element’s category is queried to find any tabular information with the same keys. This process can return one or more records from one or more different tables. For example, a Pole might have a Pole Table, a Work Order Table, and a Common Table; and the Work Order Table may have multiple records for the same pole. Setting Keys works the same way as Embedded Data; setting the keys to a value only applies to the next element added. A Session Category can use any of the existing database information associated with the GIS data; however, there turns out to be a more important use for keys in the Session Category. Keys are an easy way to manage the elements in the Session Category. If you assign a Session Category element a unique key, then you can manage that element with that key. It can be deleted, edited, or reviewed using this key (none of which may require the GIS database as keys normally do). Group Elements Group Elements are special elements that contain more than one element (sub-elements), but are treated as a single element. The group concept is generally simple, but it can seem complicated when Embedded Data and Keys are thrown in to the mix. A Group element contains one or more sub-elements; each sub element can have it own color id , weight, style id, and extended style; but filter id, embedded data, and keys are only allowed on the Group element itself. Nested Groups are not allowed (meaning you can add a group element as a sub-element in another group element).
Adding Keys to Session Graphics Elements
Keys are simply one or two 32 bit integer values embedded into the Session Graphics element. When an element is reviewed (with Attribute Info or through programmatic means), the keys on the element are retrieved and then the database associated with the element’s category is queried to find any tabular information with the same keys. This process can return one or more records from one or more different tables. For example, a Pole might have a Pole Table, a Work Order Table, and a Common Table; and the Work Order Table may have multiple records for the same pole.
Setting Keys works the same way as Embedded Data; setting the keys to a value only applies to the next element added.
A Session Category can use any of the existing database information associated with the GIS data; however, there turns out to be a more important use for keys in the Session Category. Keys are an easy way to manage the elements in the Session Category. If you assign a Session Category element a unique key, then you can manage that element with that key. It can be deleted, edited, or reviewed using this key (none of which may require the GIS database as keys normally do).
Group Elements are special elements that contain more than one element (sub-elements), but are treated as a single element. The group concept is generally simple, but it can seem complicated when Embedded Data and Keys are thrown in to the mix. A Group element contains one or more sub-elements; each sub element can have it own color id , weight, style id, and extended style; but filter id, embedded data, and keys are only allowed on the Group element itself. Nested Groups are not allowed (meaning you can add a group element as a sub-element in another group element).
Thursday, July 13, 2006
Version 188.8.131.52 of GTData is available.
- FIX - GTUpdateGtg - Deleted elements in the update file were still being processed.
- CHG - GTUpdateGtg - If a delete item was defined with no filter, then any additional deletes for this item with a filter id will be ignored.
- FIX - GTShapeConv - The RangeFile was not being created for category seciton that had only regular shape element (not shape with hole, shapes that were over the maximum points, etc.).
- FIX - GTQuery - The Connectivity Query (Type 29) did not allow a FixedGid entry.
- FIX - GTQuery, GTExtract, GTPack - modified to support new modules for working with large .GTX files.
- NEW - GTTextQuery - MinCharacter entry added to specify minimum required number of character before text will be loaded.
- NEW - GTGetRecords - The Column entry can now support a list of columns (pipe delimited). The output will be a single value for column whose value is the result of appending all of the values in the specified columns together (with a space inserted between populated values).
- FIX - GTConv - Problem with shared cell definition with arcs.
- FIX - GTInterGtg - Was incorrectly reporting unfound Additional Attributes. If a defined AdditionalAttrName entry used an invalid attribute, it report the wrong attribute as being the undefined one.
- FIX - GTLabelGtg, GTIntersect - Characters in text with ids above 127 would sometimes cause problems.
- NEW - GTFormatInfo - HeaderFile and FooterFile entries are now optional.
- NEW - GTFormatInfo - TableFilter entry added to allow records to be filtered by table name.
- NEW - GTFormatInfo - Filter entry added to allow records to be processed or ignored depending on an attribute value appearing or not appearing in the Filter List. The FilterOmitFlag was also added.
- NEW - GTFormatInfo - Two new tokens are now supported: <%KEY1%> and <%KEY2%>
- NEW - GTTile1 - Now supports an Offset entry to allow files to be shifted independently according to their the embedded data.
- FIX - GTInterGtg - Did not tell the version in the output.
- FIX - GTQuery - Problems with prompt values greater than 255 character (the max limit). Will now provide a warning message and give a location of the record.
- FIX - GTShapeDbfConv - Fields with Pipes (|) are now cleaned to prevent problems with Tabular data export format.
- NEW - GTFormatInfo - Verbose mode added.
- NEW - GTInterGtg - now supports a AdditionalAttributesFromBothFeatures flag. If set to 1, Additional Attribute will be retrieved from both features creating the intersection.
- NEW - GTLabelGtg - now supports Mode=3 to define more than one label per element. The labels are fixed in size, and are controled with SpaceBetween and SpaceFromEnd entries using system unit values.
- NEW - GTRemap2 - Added to support remaping by element key.
Monday, July 10, 2006
Pocket GTViewer version 5.0.x.15 is now available.
05.00.00.15 - 07/10/06
- FIX - Symbol to Text conversion (for edited symbols) did not account for the style scale if the height and length multipliers were default values.
- NEW - Info Exchange interface now supports LoadAddProp.
- NEW - Entries in the Additional Properties section of the .GTM file can now be split into multiple line (to overcome the 255 character limit). The Attribute value must be
- NEW - SetState instruction will now accept a blank to clear the state value.
- NEW - ~PROMPT is now included in the exchange info to pass the last prompt message to the external application.
- NEW - ActivateCapture now supports "Feature".
- NEW - ActivateCapture now supports a RESEND_PREVIOUS option which will send the previous element information along with the current mode information.
- NEW - Hi-Res Toolbar images has been provided.
- NEW - Customizable toolbars have been added. Up to 5 customizable toolbar can now be defined in the .GTM file or addprop.ini.
Thursday, July 06, 2006
With version 5.0.x.15 of Pocket GTViewer, there are two major changes to the toolbar. First, new images have been provided specifically for Hi-Res devices. The standard toolbar images worked, but they became very small on a Hi-Res Device. The second major change is the support for up to 5 custom toolbars. These custom toolbar are defined in your .GTM file in the [Additional Properties] section or in an AddProp.ini file. The toolbar entries simply specify the Command to perform and an Image to use for each button on the toolbar. A few new commands have been added to facilitate this new feature even more. The Next Toolbar command can be used to jump to the next custom toolbar (you can have up to 5). So, if you put a button on your toolbar and associate it with the Next Toolbar command, you can scroll through up to 5 different toolbars; then it wraps around to the beginning. Currently, there are 55 different images to choose from for 40 different Commands (which mostly correspond to the menu items).
Let’s look at an example. The following screenshot shows a toolbar similar to the standard:
There are a few differences here from the traditional toolbar in Pocket GTViewer. The first icon looks like the Zoom command, but it is has been assigned to the Attribute Info command. The Zoom and Attribute Info commands on the toolbar were a little redundant anyway, so this is a way to customize the toolbar to get the most usability. The last button on the toolbar (three right facing arrow heads) has been assigned to the Next Toolbar command and pressing it will take you to the next toolbar as seen below:
The second toolbar still contains the Attribute Info/Zoom command at the beginning (since it is useful for all toolbars), but it contains all of the Drawing commands instead of the general list of commands. The second toolbar also contains the Next Toolbar command. The third custom toolbar is show below:
This toolbar contains all of the GPS commands, plus the Attribute Info/Zoom and a Fit. A special command has also been added to immediately start or stop GPS tracking without going through the normal GPS Tracking dialog. Pressing the Next Toolbar from the third custom toolbar will take you back to the first custom toolbar (since there were no other toolbars defined).
The customizable toolbars can also be used to make you external applications more recognizable. For example, the GT/Field icons (from the Desktop version of GT/Field) can be used instead of the Yellow and Blue Stars:
Another benefit of the customizable toolbars is the ability to add more than 8 buttons. You may wonder why this is important since only 8 buttons will fit on a screen. That is a good point, but with Landscape mode and differently shaped screens provided by newer devices, it is possible to fit more buttons on certain devices.
Wednesday, July 05, 2006
First, let’s look at what the ExternalApp entry contains and see why it can grow beyond the 255 character limit.
App Name is the name that appears in the Applications list dialog in Pocket GTViewer.
Mode is the mode number specifying how to launch the external app (immediately, when a feature is selected, when a point is selected, with a GPS point, etc.).
External App Path is the path on the device to the external application.
Parameters specify any parameters for the external app. This parameter can be used to specify an eMbedded VB file when vbload.exe is used as the external app.
Filter specifies a list of comma delimited
Msg is the Prompt message you see in Pocket GTViewer when a feature, point, line, gps point, etc. is being captured. Once the capture is made, the external app is launched. The Msg value only applies to certain modes. For example, Launch Immediately does not use a prompt. If there is no prompt, the value should be set to
The App Name is generally not very long and the mode is at most 2 characters. The Path to the external app can be several characters depending on the depth of the path; however, the %mainapppath% and %programpath% tokens can reduce the size some (as well as make the location generic). Parameters is rarely used with the growing popularity of .NET development (and the shrinking popularity of eMbedded VB). That leaves filter and msg.
If your external app deals with broad filters where you can include all filters in a category (like 2:*, 3:*, 999:*), then your filter string does not get very long. However, if you have many categories with many features and your external application needs to filter out specific components of a lengthy list of features, the filter string can easily grow to a size greater than 255 characters. GT/Field is a good example of an External App that can have a very lengthy filter if you use it to edit a large number of existing features (and can’t simply say all filters in a category).
Msg will never be too many characters because if it is too big, it won’t fit on the device’s screen. However, if you user 25 characters for your prompt, that is just fewer characters you can use for a filter.
With version 5.0.x.15+ of Pocket GTViewer, the problem of long ExternalApp entry is solved with a new entry for the Additional Properties section:
Any line in the [Additional Properties] section (as well as the addprop.ini) can now be split. Simply split the line and make a new entry called
An entry can be split as many times as you need as long as you do not have blank lines between the main entry and the continuation entries.