The latest version of GTData (version 8.0.0.4) contains four new utilities. If we count the recently released version 8.0.0.3, we can add a 5th new utility.
There are now some 55 different utilities provided with GTData. The latest additions may not be of immediate use to many of you, but I want to use this post to run through what they do. After all, knowing what tools you have may be as useful as having the tool in the first place.
GTRemoveAttr – this utility will take a GTViewer tabular data file (data.txt) and a list of table/attribute pairs and produce a new tabular data file with the specified attribute values obscured (replaced with asterisks). Some customers have asked for this functionality to simply the process of building alternate GTViewer datasets to give to contractor or other entities outside their company. While you may say, that you could just create an alternate .GTM file that specifies a data.tab with the attributes hidden, you would be right, but the GTRemoveAttr utility will physically remove the sensitive data out of the data.txt file making it the safest way to distribute the data (other than loading the data without the sensitive data in the first place).
GTPreset – this utility solves the difficult problem of keeping your Display Preset definitions (.gtp) in sync with changing data. With Style Definition based datasets like G/Tech, ESRI, Smallword, and any GTViewer data produced by FME, the continual addition of new Filter Ids as new style or features show up make it challenging to keep the Display Presets up-to-date. After all, the .GTP files have been created by taking a snapshot of the current display settings and exporting them to a file. The GTPreset utility takes a .GTM file and a Display Definition File and produces a new .GTP file on demand. This step can be added to the conversion process and will always keep the Display Presets current with the data. How this works is that the Display Definition file describes the state of the display settings for the Preset in a different way than with just Category and Filter ids, so that the more abstract description can be used to generate the preset instead of the snapshot of view settings. The Display Definition File uses the same notation as the Display Toggle Definition recently added to GTViewer's ToolBox functionality, so they can easily describe what you want the preset to be using GIS Feature/Component Numbers to set a feature on or off, or using more general concepts like everything in a particular category is set on or off. This approach was added to GTQuery a couple of years ago to solve this same problem when building queries that were dependent on a changing set of Filter ids. Now, the Presets can use the same technique to always stay in sync with the data.
GTGtx2Gtg – this utility allows you to perform a common task in GTViewer on the command-line (or in a script). Instead of opening up an Extract file (.gtx) in GTViewer, selecting Draw/Export/Export Graphics and specifying a file to create (.gtg), you can now use GTGtx2Gtg and specify a .gtx file as input and a .gtg file as output. The session category is then exported out as a new .gtg file. This process can be scripted and can easily process large numbers of .gtx files if necessary.
GTOrcl2Mdb – this utility creates an Access file (.mdb) from a SQL statement and an Oracle connection. There are certainly other ways to perform this task, but this utility provides a means of doing it quickly and easily and in-line with the other GTData utilities. Why would you need to use this process with GTViewer? There turns out to be a couple of problems already that it can solve. With the G/Tech Loader, it turns out that there is often data that is outside the reaches of the Oracle server hosting the G/Tech data such as Customer Information Records, Inspection records, etc. This tool actually uses an OLEDB connection, so it theoretically can pull data from OLEDB data sources other than Oracle, but it was originally intended to be used in conjunction with Oracle. The G/Tech Loader allows an Exported Table to be specified as a Join between a SQL query made to the G/Tech data and a SQL Query made to the Access file. A common key must be present to link the two together, but the end result is just another table the GTViewer data with attributes from both the G/Tech Data and the data in the .MDB file. The second use for this utility is to build an Access file for use with a GTViewer External Application. It is sometime easier to build an app using pure OLEDB in .NET to find application specific data, rather than going through GTViewer's query mechanisms. The Access file can also support multiple indexes, it can contain data from different sources other than the G/Tech database, etc.
GtOrcl2Txt – this utility is very similar to the GTOrcl2Mdb utility except that instead of creating a .MDB file, it outputs the query results to a text file. There are many uses for this utility too, but the primary reason for its creation was to create unique value list files for GTViewer External Applications. For example, if you want a list of unique circuit ids used in your data, this utility can easily make a .txt file that lists these values. The utility's scriptability makes an easy way to keep such lists up-to-date with the data.
No comments:
Post a Comment