Wednesday, February 08, 2006

The Dynamic Display in GTViewer

Since the GTViewer Data format was designed to support data from different GIS sources (ESRI, Smallworld, Intergraph, etc.), it has always provided a variety of tools to manage the view in a dynamic fashion. For some GIS data, like Smallworld, it is common place for feature symbology to be dynamic and change as the view scale changes; however, for CAD based systems like FRAMME, the symbolgy is instance based and does not readily support dynamic styles. From GTViewer’s perspective, the source of the GIS data is irrelevant, so the dynamic style concept it uses with Smallworld can also be used with FRAMME data or any other GIS data source giving the user a much richer viewing experience. GTViewer provides two mechanisms to support Dynamic Display capabilities: Dynamic Style Rules and Display Threshold. These two approaches will be discussed in detail below.

In GTViewer, Dynamic Style Rules provide for different symbology (color, linestyles, weight, symbol characters, scale, etc.) as the view scale (zoom level) changes. Features viewed from far out can use one symbology while using a different symbology when viewed close up. The Dynamic Style Rules associate a named Style Definition with a particular feature for a particular zoom level range; there can be any number of Style Rules applied to feature as long as the zoom level ranges do not overlap (so only one style rule is in effect for a feature at any given zoom level). For example, a simple Dynamic Style Rule may define something like the following:

For Zoom Levels 0 to 2500, use Style Definition: Switch – Large
  • ColorValue=2550255
  • Scale=5.0

For Zoom Levels 2500 to Max, use Style Definition: Switch – Small

  • ColorValue=127640
  • Scale=1.0

The screenshot below shows the “Switch – Large” style rule in action. It causes the switch features (the Circled “S”) to be displayed much larger and in a brighter color (magenta) so that the features can be easily identified from far out. This sample data is from FRAMME which could not support this ease-of-viewing functionality. The Style Definition can be used to change the feature in a more dramatic way, such as changing the symbol character, rotating, offsetting, or any other number of characteristics (see the Style Manager for more info).

When zoomed in closer to the features, a different style rule is used with the switches:



Filter and Category Display Thresholds are also nice features for creating Dynamic View characteristics. Generally, Display Thresholds are used to boost performance by reducing the number elements drawn for each view update; however, Display Thresholds have a very nice side-effect of decluttering a view automatically as the user zooms in or out. Category Display Thresholds define a maximum and minimum zoom level for each Category of data in GTViewer. The Category will only be rendered when the view’s zoom level is within the Category’s Display Threshold range. So, if a category contains features that are only useful (or clearly visible) when the view is zoomed into, then it is always a good idea to set a maximum Category Display Threshold that will turn the Category off when zoomed out past a certain level. This idea is carried one step farther with Filter Display Thresholds. Each Feature Component in a Category has its own independent minimum and maximum Display Filter Threshold. A Filter Display Threshold is always superseded by its parent Category Display Threshold; however, if your Category contains a large display range, then Filter Display Thresholds can make a substantial difference in the usability of the data.

The following screenshot shows data with all features turned on as it would be in the original GIS:



The next screenshot uses Filter Display Thresholds to turn off all features that clutter the view or are not big enough to be of use. This example goes to the extreme by turning off most features to make a point, but as the user moves in closer, more features can be turned on automatically:



Both Dynamic Style Rules and Display Thresholds can be used in GTViewer to ensure that the users have the most usable view of the GIS data without any effort on their part. The users do not have to concern themselves with turning on and off features to get an unclutter view of the data and the symbology can automatically adjust to be provide the most useful display. The Dynamic Display characteristics are common to some GIS systems and GTViewer will carry these characteristics forward; however, the viewing requirement for mobile users or for specific applications may have different needs than the original GIS system, so alternate Dynamic Display characteristics can be provided on a user-class basis. Also, for GIS systems that never supported dynamic display characteristics in the first place, these features can provide an even richer viewing experience making the data more useful and the users more productive.

Wednesday, February 01, 2006

Update Available for the GTViewer Reader/Writer in FME



The latest FME Beta (build 2561 and later) from Safe Software includes an update to the GTViewer FME Reader/Writer Modules. This update includes several fixes and some minor new features. List of all updates below.

GTI will continue to improve the GTViewer Reader/Writer modules for FME as they have proven to be a very powerful means of getting data into and out of the GTViewer format. Through the use of FME, GTViewer, Pocket GTViewer, GTVx, and GTWeb can be used with any of the data formats FME Supports.


-----------
01.00.00.10 - 01/11/06
-----------

- FIX - Shape With Hole Elements (Donuts) were not converted correctly. Internal polygons were not being closed.

-----------
01.00.00.09 - 11/01/05
-----------

- FIX - If no tabular attributes are present on a feature, then no database record is written. Previously, an empty record with key information was written.

- NEW - IndexGraphics entry in the GtiParameters.txt. If set to 0, the .gtg files will not be generated.

-----------
01.00.00.08 - 10/12/05
-----------

- NEW - The gtiParameters.txt directive file was added. It currently supports the EmbeddedAttribute entry which will automatically embed an attribute on a converted element element. This embedded information can be used for various things, such as tiling the data that was not originally tiled. It is also the same as setting the gti_embeddedData to the source attribute and the gti_embeddedDataType to 1 for all destination datasets.

-----------
01.00.00.07 - 10/5/05
-----------

- NEW - The Destination Dataset attributes are used to filter the attributes written to the output feature tables. Previously, all available attributes were written.

-----------
01.00.00.06 - 10/4/05
-----------

- FIX - The \xd\xa character was filtered out of attribute values, but \xd and \xa were not filtered out individually. This caused a problem with the table merge at the end of the conversion since there were blank lines in the temporary files.

- FIX - Preloaded .TAB files were using the feature name as the temporary table names. This was a problem fixed in an earlier version by placing a ~ in front of the temporary name, but it wasn't added to name for preloaded table information. This is only a problem if the feature name and the dataset name are the same.

Friday, January 27, 2006

GTViewer version 5.0.x.10 is Available



Version 5.0.x.10 of GTViewer is available.

-----------------------
05.00.00.10 - 01/27/06
-----------------------

- FIX - The RasterFileList file was not trimming the filenames in the list and would not correctly identify the raster type if the filename had spaces at the end.

- NEW - ExternalSessionsOnly flag can be set in the Additional Properties section of a .GTM file to allow GTViewer and GTVx to only use .GTS session files with .GTX files and not use the internal session in the .GTX file.

- CHG - The New Session Dialog's Browse button will default to showing both .GTM files and .GTX files by default instead of just .GTM files.

- NEW - Save As now supports Extract files (.GTX) and will create a .GTS session file of the current session. The new session file will be external to the .GTX.

- NEW - Session Modified Indicator on the Status bar. The asterisk in the 3rd pane on the status bar indicates that the current session has been modified and the session will need to be saved. The session is modified by changing the view, display filters, or redlines.

- FIX - Right Mouse Feature selection (for Attribute Info) was not filtering out features whose category was turned off by thresholds.


Thursday, January 26, 2006

Justification Codes for Text and Symbols

The GTViewer data format supports justified display for both Text and Symbol elements. This functionality is sometime confusing because of the number of codes used to specify the justification instructions. This posting will help clarify these different codes.

  • 0 – Default (Bottom Left)
  • 1 to 99 – Ignored, same as default (Bottom Left)
  • 100 – Bottom/Left
  • 101 – Center/Left
  • 102 – Top/Left
  • 103 – Bottom/Center
  • 104 – Center/Center
  • 105 – Top/Center
  • 106 – Bottom/Right
  • 107 – Center/Right
  • 108 – Top/Right
  • 163 – Bottom/Left
  • 165 – Bottom/Center
  • 167 – Bottom/Right
  • 171 – Base/Left
  • 173 – Base/Center
  • 175 – Base/Right
  • 181 – Center/Left
  • 183 – Center/Center
  • 185 – Center/Right
  • 201 – Top/Center
  • 203 - Top/Center
  • 205 – Top/Right
The following diagram will show how codes 100 through 108 will affect a text element. The Red Circle is the Origin for the text element when draw for each of the justification codes:

The codes 163 through 205 are similar to the 100 through 108 series. The difference is that these value correspond to the Smallworld justification codes (plus 150). There is also the addition of the Base Line justifications (171,172,173) that adjust the origin to 1/3 from the bottom of the text box.

For Text Elements, the justification can be specified as part of the element or as a Style Rule. For Symbol Elements, the justification is always specified with a style rule.

Tuesday, January 24, 2006

Thursday, January 19, 2006

The Mysterious addprop.ini File

Most people are unaware of the addprop.ini file and how it can be used with GTViewer, GTVx, and Pocket GTViewer. The addprop.ini file is a feature originally intended for development and debugging, but it has found many uses in the real world. The .GTM file ends with a section called [Additional Properties]. This section can contain a variety of different entries (usually items that do not fit in other sections). You can look at the GTVConfig.doc to see a complete list of entries supported by the [Additional Properties] section, but here is a quick list:

Measure Charactistics

  • MeasureFactor
  • MeasurePrecision
  • MeasureUnitLabel
  • LatLongFlag
  • MeasureDegreeFactor

Menu Hiding

  • LocateXYMenu
  • EditPasscode

View Restrictions

  • MinZoomLevel

Default Symbol Definition

  • DefaultSymbolCharId
  • DefaultSymbolFont
  • DefaultSymbolMode
  • DefaultSymbolLengthMult
  • DefaultSymbolJustification
  • DefaultSymbolScale

Timeout Properties

  • ApplicationTimeout
  • ApplicationInactivityTimeout

Reference Point Properties

  • RPCol
  • RPStyle
  • RPWeight
  • RPPos
  • RPProp

Non-Category Raster File Definition

  • Raster
  • RasterPC

Session Link Definitions

  • SessionLink

GPS Indicator Properties

  • GPSIndicatorSize
  • GPSIndicatorWeight
  • GPSIndicatorColor
  • GPSHeadingColor
  • GPSRefHeadingColor

External App Definitions for Pocket GTViewer

  • ExternalApp
  • DefaultApp
  • AutoStartApp
  • ResetExternalApps
  • ExtAppFiles
  • AllowClearAll

Some of these entries apply only to the desktop versions (GTViewer and GTVx), some apply only to the handheld version (Pocket GTViewer), and some apply to all platforms.

Since Pocket GTViewer only reads Extract Files (.GTX), the entries that are specific to this platform (such as ExternalApp) cannot be changed. Originally, if you wanted to change one of these entries, you had to modify the .GTM file and re-extract the data to create a new .GTX file with the updated entries. While this procedure was a little effort, it was possible. On the support side here at GTI, if a user sent a .GTX file to illustrate a problem he or she was experiencing, there was not a way to modify the settings to see if they just needed to make a minor change to these entries. So, the addprop.ini file was introduced to provide a mechanism for changing the entries in the [Additional Properties] section in a .GTX file. If a file called addprop.ini is found in the same directory as the product (PGTViewer.exe) or in the same directory as the .GTX file being viewed, the contents of the addprop.ini file were appended to the [Additional Properties] section when the .GTX file is opened. If an addprop.ini file exists both with the .GTX file and with the product, the one with the .GTX file is always used first. So, the addprop.ini file can be used to easily modify these settings.

Another problem the addprop.ini file addresses is when a user has a set of .GTX files that were generated in the past, but now the user wants to take advantage of a new feature added to Pocket GTViewer or use a feature that was not previously being used (such as ExternalApp). The addprop.ini once again can be used to supplement the [Additional Properties] section without modifying any of the .gtx files.

The use of the addprop.ini file has grown beyond its original intended use. Many users use the addprop.ini file to manage all of their external applications and never include this information in their .GTM file.

Some of the entries in the [Additional Properties] section are now specifically for the addprop.ini file, such as ResetExternalApps. This entry will clear any ExternalApp settings that were already defined in the .GTX file and new entries can then be provided in the addprop.ini file.

Since the addprop.ini worked so well for Pocket GTViewer, the same functionality was added to GTViewer and GTVx.

Sessions 102 - New Feature

In a recent posting (Sessions 101), the many different aspects of sessions were reviewed. One key item it discussed was creating a session file (.GTS) from an Extract File (.GTX) instead of a .GTM file. Traditionally, the session for an Extract file (.GTX) has been stored internally (in the .GTX file along with the data), to keep the dataset and the session in a single file. Many users expressed the desired to keep their data as single Extract file to simplify data management, so the Session File (.GTS) was extended to work with a .GTX file as well as a .GTM file. With this change, multiple users could have their own session (or multiple session) with a single Extract File (.GTX file). This feature has worked very well with one exception; it is sometimes confusing to a user that they need to create a session from a .GTX file (with File/New) rather than just open it with File/Open (which will open the internal session). With the latest version of GTViewer (version 5.0.x.10) and GTVx (version 5.0.x.5), a new feature was added to make the process of using .GTS session files with a .GTX file easier and less confusing.

In the .GTM file (remember that a .GTX file is made from a .GTM file), you can add a new entry to the [Additional Properties] section called ExternalSessionsOnly. If this entry is set to 1, the internal session in a .GTX file will not be accessible to GTViewer or GTVx. If this option is set, there can be no mistake of opening a .GTX with it internal session instead of creating an external session. If the user opens a .GTX with File/New, it will simply create a new session and when the user exists, it will ask if they want to save it (just like it does when a .GTM file is opened).

Tuesday, January 10, 2006

GTData 5.0.0.2 is Available



Version 5.0.0.2 of GTData is available. This version includes 3 new utilities:
  • GT2Shape will convert a .GTG file to a setup of Shapefiles.
  • GTThesh will adjust the maximum display thresholds in a filter file (.flt) based on the average size of the graphics associated with each individual filter id.
  • GTCleanFlt will reset the custom setting in a filter file (.flt).
-----------
05.00.00.02 - 01/10/06
-----------

- NEW - GTPack, GTExtract - now display an error message when using invalid or corrupt query files (.qry).

- NEW - GTThresh, GTCleanFlt, GT2Shape - New utilities have been added.

- NEW - GTShapeConv - Will now use a .shx file is present.

- FIX - GTShapeConv - Actual Range was not correctly displaying the range for certain elements types.

- CHG - GTShapeConv - Polygons now default to Shape Elements and Polylines now default to line or linestring elements. The ShapeFlag=0 will force polygons to lines and ShapeFlag=1 will force linesstrings to shape element (closing if necessary).

- NEW - GTShapeConv - TextFlag will now work with Polygon and Polyline types. The first point is used as the text origin.

- NEW - GTShapeConv - Will now assume the DbfFilename entry is the same as the ShapeFilename entry with .dbf instead of .shx.

- NEW - GTShapeDbfConv - Will now format Float type to be regular number (no scientific notation) and Date types according to the machines current locale.

GTI's 10 Year Aniversary

GTI is celebrating its 10 year aniversary.

Press Release


Monday, January 09, 2006

GTVx 5.0.x.4 is Available



Version 5.0.0.4 of GTVx is available.

-----------------------
05.00.00.04 - 01/09/06
-----------------------

- FIX - The Query Locate was not considering style rules that might alter the location of the element (such as a long piece of text that is center or right justified).

- NEW - The OptionalFlag has been added the Category sections of the .GTM file.

- FIX - The ExportSessionGraphics and ExportSessionGraphicsEx methods now will verify that an existing file is deleted before a new file is written. On Novell servers, the delete happens after the writting of the new file.~


GTViewer 5.0.x.9 is Available



Version 5.0.0.9 of GTViewer is available.

-----------------------
05.00.00.09 - 01/09/06
-----------------------

- FIX - The tabs on the GPS Info dialog did not show the correct text from the resource file.

- FIX - The Query Locate was not considering style rules that might alter the location of the element (such as a long piece of text that is center or right justified).

- NEW - The OptionalFlag has been added the Category sections of the .GTM file.

- FIX - The ExportSessionGraphics and ExportSessionGraphicsEx methods now will verify that an existing file is deleted before a new file is written. On Novell servers, the delete happens after the writting of the new file.

- NEW - New Doc Object Methods:
  • boolean ActivateInfoDialog(long mode, long categoryId, long offset);
  • boolean GetAttributeData(long mode, long dataId, VARIANT* linkageList, long linkageCount, VARIANT* attrList, VARIANT* valueList, long* count);

Thursday, December 22, 2005

Happy Holidays - Looking Forward to 2006

The Holiday season and end of the year activities has slowed down the routine postings, but rest assured, the regular postings will resume in January.

There are many exciting things GTI has in store for 2006:

Pocket GTViewer 5.0 will be release early in the year. This version of Pocket GTViewer will contain a significant amount of new functionality, plus support for Windows Mobile 5.0.

GTViewer will provide an import and export capability via Safe’s FME Enablement. This functionality will allow redlines to be imported and exported in GTViewer to and from any FME support format as long as FME is installed on the same machine as GTViewer.

A new product called GT/Field will allow users to create data collection and inspection apps for GTViewer and Pocket GTViewer using a GUI interface (no coding or development required).

Thursday, December 08, 2005

Automated Vehicle Location in GTViewer using APRS

Years ago when the Global Positioning System (GPS) was just beginning to make its impact on GIS, I would opine that, “GPS was a solution in search of a problem.” Obviously, today GPS is the solution to many GIS and non-GIS problems and is used daily in hundreds of different applications. And since I consider myself a knowledgeable person in the GIS industry, I thought I already knew about all of them. But recently while making arrangements to create a sample dataset for a potential client, I was surprised to learn something new about the use of the Global Positioning System (GPS).

Apparently, there is widespread use of GPS within the amateur or ham radio community which includes businesses, utilities, and municipalities. My understanding is that ham radios can be a more reliable form of communications than other radio-based systems- especially under emergency conditions.

Briefly stated, vehicles with ham radios and certain GPS devices can transmit data such as their GPS coordinates, estimated speed, bearing, and more. This is accomplished through the Automatic Position Reporting System (APRS). APRS is a system developed by Bob Bruninga which uses amateur radio to transmit position reports, weather reports, and messages between users. This data are received and eventually collated and stored within a central database. This database is available and accessible through the internet. Vehicles transmitting this data are displayed as icons with their call signs next to them on web-based, interactive maps. If you are interested in APRS and want to know more about it, please visit http://web.usna.navy.mil/~bruninga/aprs.html .

If you are looking for a specific vehicle and you know its call sign, you can enter the call sign and the vehicle’s position will be automatically generated and displayed for you on a map on the web site. This intrigued me and I wondered if I could develop an application which would query the database, receive the data, and display the location and data on a map within GTViewer. The result was a small, customized .ocx application I wrote that works within the standard GTViewer product as an external application. Using the Data Monitor toolkit functionality within GTViewer was straightforward and a lot of fun.

The results of my application as you can see are simple but as you might imagine you could get carried away and practically create your own Automatic Vehicle Location system.

As these screenshots illustrate, you don’t necessarily need the power of GTVx to create customized and functional applications. Many of them could be designed simply as external applications using your own data and GTViewer right out of the box!











Wednesday, December 07, 2005

GTViewer 5.0.x.8 is Available



Version 5.0.0.8 of GTViewer is available.

-----------------------
05.00.00.08 - 12/08/05
-----------------------
- CHG - Evaluation Timeout extended.
- FIX - Overview Map did not display elements whose priority was not 1.
- FIX - Style Manager did not like Filter Id greater than the max (500).
It will now semi-ignore them.
- FIX - Label in View Extents was Xhigh Ylow when it should have said Xhigh Yhigh.

- FIX - The Smallworld Justification codes were conflicting with the Microstation codes, so the Smallworld justification values are shifted by 150 so that they do not overlap.
- NEW - Shapefile Export has been added under Draw/Export.
- FIX - Fit Session Graphics was not adjusting for deleted redline elements.
- NEW - New Methods:


Doc Object:
boolean SetIndicatorRefHeadingDisplay(long mode);

boolean SetIndicatorRefHeading(double bearing);
boolean GetGpsInfo(VARIANT* attrList, VARIANT* valueList, long* count);
boolean SetIndicatorDisplay(boolean value);
boolean SetIndicatorPosition(long mode, double x, double y);
boolean GetIndicatorPosition(long mode, double* x, double* y);
boolean GetIndicatorDisplay();
boolean SetIndicatorHeadingDisplay(long mode);
boolean SetIndicatorHeading(double bearing);
boolean DeleteSessionGraphicByKey(long key1, long key2);
double GetElementLength(long categoryId, long offset);
long GetAddElementRedrawMode();
boolean SetAddElementRedrawMode(long value);

App Object:
long GetAppHandle();
boolean GetSize(long* xSize, long* ySize);
boolean GetPosition(long* x, long* y);

View Object:
long GetViewHandle();

boolean SetAddElementRedrawMode(long value);
boolean IsIndicatorInView();
boolean GetSize(long* xSize, long* ySize);
boolean GetPosition(long mode, long* x, long* y);

Dialog Object:
boolean SetPosition(long x, long y);

long GetDialogHandle();
boolean GetPosition(long mode, long* x, long* y);

Friday, December 02, 2005

Sessions 101 and New versus Open in GTViewer and GTVx

GTViewer and GTVx both offer the same two dialogs for New and Open and there is sometimes confusion about what the difference between these two commands. The differences are minor, but there are some differences. This blog posting will try to clarify these two commands and explain how a Session relates to them.

GTViewer and GTVx are session based. When you are viewing your GIS data, you are always in a session. The session information is separate from the GIS data in that it contains only the user-specific information such as the current view extents, display filter settings, and redlines. The GIS data is generally represented by a .GTM file (unextracted GTViewer data), and the session it uses is a .GTS file. A single .GTM file can have any number of sessions created against it, and these sessions can all be open simultaneously by one or more users.

This separation between the GIS data and the session info is straightforward until you consider an Extract File (.GTX) which contains both the GIS data and the session information in a single file. The .GTX file was initially designed to be single-user since its primary purpose was to provide data for Pocket GTViewer (a single-user environment). However, user affinity for managing their data with a single, self-contained .GTX file on the desktop guided product development to support simultaneous users each with their own session from a single .GTX file. By extending the .GTS session file to support .GTX files as well as .GTM files, multi-user support is provided for both .GTM and .GTX files. For more info, see: Unextracted versus Extracted Data, Creating Extract Files

This convoluted introduction to sessions is the key to understanding the difference between New and Open.

  • You will always be in a session if you are viewing GIS data from a .GTM file or a .GTX file.
    If you are using a .GTX file in single-user mode, the session information is embedded in the .GTX file (along with the GIS data, but only the session information is modifiable by the user).
  • If you use File/Open to open a .GTX file, the embedded session is used.
  • If you use File/Open to open a .GTM file, a new session is created using the .GTM file as the source. When you exit the session, you will be asked if you want to save the session. The session will be saved as a .GTS file.
  • If you use File/New and specify a .GTX file, a new session is created. When you exit the session, you will be asked if you want to save the session as a .GTS file.
  • If you use File/New and specify a .GTM file, a new session is created. When you exit the session, you will be asked if you want to save it or not.
  • With a .GTM file, File/Open and File/New are identical.
  • Double-clicking a file in the File Exploring is identical to File/Open.
  • Select a file from the Most Recently Used (MRU) list under the File menu is identical to using File/Open.
  • The File/Open command does provide a fancier dialog for creating a session. A history of the last ten source files is listed along with their descriptions (from inside the .GTM or .GTX files). You can select a file in the history list to create a session from or you can browse for a source file. (The Browse button will also take the path typed into the prompt as a starting point to speed along browsing)

The difference between File/New and File/Open are really pretty trivial; however, know the differences between the two command can help you get even more use out of your data, especially if you are wanting to share a .GTX file amongst multiple users. I have noticed from observing users that the File/New command is sometimes never used. There is nothing wrong with this approach, but the File/Open’s history list is sometimes very useful if you deal with several different datasets.

Creating sessions from .GTW and .GTG files is also supported, but this will be another blog posting at a later date.

See Also: Sessions 102

Thursday, December 01, 2005

GTVx 5.0.0.3 is Available



Version 5.0.0.3 of GTVx is available.

-----------------------
05.00.00.03 - 12/01/05
-----------------------

- FIX - If a font character contains a single polygon stroke, it could appear to dissappear at certain zoom levels (when the polygon points all end up at the same point). If this condition occures, the points of the characters polygon are spread so that they are not all in the same spot.

- NEW - New properties for SetDataProperty and new entries for Additional Properties section of GTM file:
  • GPSIndicatorColor
  • GPSHeadingColor
  • GPSRefHeadingColor
  • GPSIndicatorWeight
  • GPSIndicatorSize
- NEW - New Methods:
  • boolean SetIndicatorRefHeadingDisplay(long mode);
  • boolean SetIndicatorRefHeading(double bearing);


Tuesday, November 29, 2005

Wednesday, November 23, 2005

Geolocating Address Query in GTViewer and Pocket GTViewer

With the release of GTViewer 5.0, a new type of Query was added to set of available Locate Queries. GTViewer already supports long list of query types including a Standard Locate Query, a Thematic Query, a Street Intersection Query, a Locate By Coordinate, and a Locate By Lat/Long; Pocket GTViewer supports a similar list of query types. The Geolocating Address Query was added in GTViewer 5.0 and has recently been added to Pocket GTViewer. This new query type is specifically for street segment data containing High/Low address ranges for the left and right sides of the street segment. Given a specific address number and a street name, the query will determine what segment contains that address and will interpolate the spot where it is located.

The new Query looks like any other when run. The Street Number will be assumed to be a numeric value, but the Street name, City, and State can be left blank or wildcarded (begins with, contains, or ends with).



The results are a little different than a normal query because it shows all segments segment that match address being searched:



Another difference is what happens when you locate on a specific street segment. The whole segment is highlighted. Also, the location of the address number being searched for is interpolated, and a circle is drawn at the interpolated spot:



The new Address Query in GTViewer and Pocket GTViewer is very useful if your street data supports address ranges. The interpolated point for the address is not always accurate, but it will usually get you pretty close to the desired location.

Friday, November 18, 2005

Associating Tabular Only Components with a Feature in FME

Depending on the complexity of your GIS data, you may or may not need to integrate complex data relationships into the GTViewer data you create. Safe Software’s FME is a very powerful tool for converting data to the GTViewer format, but there are many subtleties in the workspace design process that may not be readily obvious; one of them being the association of tabular only components to a feature with geometry.

This posting will touch on how you can relate non-graphic components (database records that are not associated with a specific geometry) to another feature that does have geometry. A good example of this scenario is data that contains Pole and Pole Attachment features. A Pole will have a record and geometry. A Pole Attachment will usually not have geometry and will be associated to an existing Pole. Also, there may be many Pole Attachments associated with a single Pole.

Let’s look at how the Pole feature is converted first with FME:



There are several ways to accomplish this task, but for simplicity, I have explicitly specified what the gti_key1 and gti_key2 properties are in the output. Normally, if these keys are not specified, FME will automatically populate them with appropriate values. Key1 will be a number associated with the feature, and Key2 will be a unique value for the individual feature. In this example, however, we want to make sure that we can associate the Pole Attachment records to the Pole, so the ObjectId is specified as Key2. Object Id is also the key field between the Pole Attachment and the Pole records in this example. Key1 is just explicitly set to a value so that we will know what it is for both the Pole and Pole Attachment records.

In this example, the source data is an ESRI geodatabase and Pole Attachments have a geometry point at the same location as the pole; however, we are just going to associate the tabular component to the pole and not have a graphic.

The Pole Attachement record has a POLE_OBJECTID attribute that tells which pole it is associated with. By assigning the POLE_OBJECTID to gti_key2 and setting gti_key1 to the same key1 value we used for the Poles, the records for the Pole Attachment will be associated with the Poles. The gti_type attribute is then set to gti_data to indicate that it will only have data and no geometry will be written for the feature.



To fully understand what this association means to GTViewer, the screenshots of an Attribute Info dialog below for a Pole should give a better illustration of why this process is useful:





By simply reviewing a Pole in GTViewer, you get both the Pole record and all associated Pole Attachment records. In this example, there are 2 Pole Attachments for the selected pole.

Thursday, November 10, 2005

Tips on using the GTShapeConv Utility

There are several approaches for converting Shapefiles to GTI's GTViewer format. Safe Software’s FME can be used, the GTData utility GTShapeConv can be used, and soon GTViewer will be able to import shapefiles directly (to match its direct shapefile export functionality). This posting contains a brief review of some of the commonly used items with GTShapeConv that may not be obvious from the documentation.

GTShapeConv is one of the many utilities provided with GTData. This particular utility is a command-line tool that accepts a parameter file as input. The parameter file contains a section for each shapefile you will be converting and can include multiple sections that use the same shapefile only with different filters and/or symbology settings.

There are 2 types of sections in the parameter file: Main and Category. The main section is the [GTShapeConv] section and is always first. This section contains the coordinate factor conversion entries and any global entries. A global entry is a default value that will be used by the category section; so instead of repeating an entry with the same value in each category section, the global entry can be defined once in the main section and will be the default if the entry is not defined in a category section.

The category section will create a GTViewer category (.gtg file) from a specified shapefile. It is important to recognize a few characteristics of the category section when defining your GTViewer categories. A category section is specified with [Category #] where # is the category number. A category number can be used more than once in the parameter file. All of the data converted for these sections with a common category id will be added to the same .GTG file. This ability allows multiple shapefiles to be merged into one GTViewer category.

A category section also supports a FilterValue entry as well as an OmitValue entry. The FilterValue entry specifies a criteria for elements that you want to keep and the OmitValue specifies a criteria for elements that you want to omit. These entries are repeatable and both specify an attribute name and a value. By keeping or omitting specific elements in the shapefile, you can split a shapefile into multiple categories or change characteristics of elements within a single category by changing the symbology or filter id of the converted elements related to that section. The FilterValue and OmitValue also have a special mode where you can use a wildcard to perform begins with, contains, or ends with matches. The OrFlag entry is also available to allow multiple FixedValues to be ORed instead of ANDed together when specifying multiple entries all using the same attribute.

In the past, most shapefile parameter files specified all of the symbology used by the converted elements. Now, with GTViewer’s Style Manager, it is much easier and more flexible to just assign all of the different style groups a particular Filter Id and use the Style Manager to define the styles. You may also prefer defining some of the symbology in the parameter file and the rest with the style manager.

The HoleFlag entry is an item that should be set for each conversion (probably as a global entry). The entry can be set to 3 values:
  • 0 – use original method of shape elements and linestrings (default).
  • 1 – use Shape with Holes elements for all Shape elements in Shapefile.
  • 2 – use Shape with Holes elements only for Shape elements with more than one part.

The default is unfortunately the worst option to use, but support for Shape with Hole elements was not available in early versions of GTViewer, so 0 has remained the default to assure backward compatibility. Mode 1 can be used which converts all polygon type elements as Shape With Hole Elements; however, Mode 2 is probably the best choice because it will use the simpler Shape element when a polygon only has one part (and no internal holes or disconnected parts). Mode 2 will also reduce the size of the converted file if there are many elements than can be simple Shape elements and a Shape element is more performant than a Shape with Hole element (especially with Pocket GTViewer).

The TableNum and KeyAttribute entries define the linkage between the graphic and tabular data. The TableNum value will become Key1 on the element and the KeyAttribute will become Key2 on the element. TableNum is a number, but KeyAttribute can either be an attribute from the data or which uses the row id of the record.

While there are alternative now to using GTShapeConv, it will always remain an important part of GTData because of its speed, flexibility, and ease of use.

Friday, October 28, 2005

GTViewer Customer Takes Speaker Award at EGUG

Greg Broussard received one of three Speaker Awards at ESRI’s 2005 Electric & Gas User Group Meeting. He described how Jackson Electric Membership Cooperative (JEMC) extends the value of their ESRI ArcGIS core through integration with applications on GTViewer.

Located in Georgia, northeast of Atlanta in a high growth corridor, JEMC is the largest electric cooperative in the United States in energy sales and the second largest in customers with over 190,000.

Mr. Broussard, Director of Engineering Services, spoke about how 233 employees of JEMC used GTViewer in combination with ArcGIS to improve mowing and trimming, transformer load calculations, and other operations.

EGUG Speaker Awards are given to speakers who are rated most highly by the people attending their presentations.

Thursday, October 27, 2005

The Data Monitor comes to Pocket GTViewer

The GTI Data Monitor is now included in the soon to be released Pocket GTViewer 5.0. The “Mini” Data Monitor found in Pocket GTViewer is a subset of the Data Monitors found in GTViewer and GTVx; however, it provides specific functionality that works best in the device environment while respecting the limited resources and performance of today’s Windows CE devices (Pocket PC/Windows Mobile/CE.NET).

For those not familiar with the GTI Data Monitor, see the previous posting on what it has been used for on the desktop. In short, the Data Monitor provides an efficient mechanism for quickly showing data that is not necessarily part of the GIS data and is temporary in nature or changes frequently. While session graphics (redlines) can usually be used to display the same information as the Data Monitor, redlines are meant to be stored and shared and the overhead associated with these characteristics makes them more resource demanding when dealing with a large number of constantly changing items. The idea behind the Data Monitor was the need for a tool to efficiently track a large number of trucks with GPS receivers in real-time. Hundreds of trucks, all of which could be in motion, required a dynamic framework more efficient than what redlines alone could provide. As it turns out, the Data Monitor is just as useful for information other than vehicle locations, such as lightning strikes, ticket locations, and many others.

The “Mini” Data Monitor found in Pocket GTViewer is a scaled down version of what is found in GTViewer and GTVx, but it provides the essential qualities that make the Data Monitor useful. In the example below, each Red star is a ticket location loaded from a file containing a list of ticket information:



Zooming in closer shows a more detailed landbase (from the GIS data) and dynamic labels on the Data Monitor items:



Data Monitor symbols can have their display size be zoom-independent as they are in the above two screenshots (always the same size regardless of the zoom level) or they can be scale-dependent and get larger as you zoom in to them.

The screenshots below show how items can be changed. An item’s symbol, rotation, size, color, label, and geographic position can all be changed with minimal overhead:






Just like the desktop Data Monitors, data can be associated with an item. Using the tap-and-hold gesture on one of the items, an Attribute Info dialog will appear showing detailed information:






The addition of the Data Monitor to Pocket GTViewer 5.0 expands the possibilities for application development. The Data Monitor provides a dynamic means of utilizing data that is not necessarily from your GIS. Pocket GTViewer has long been a powerful platform for GIS application development, and with the Data Monitor it is even better.

Tuesday, October 25, 2005

Using Visual Studio .NET to Develop Applications for Pocket GTViewer

The current version of Pocket GTViewer provides specific support for developing applications with Visual Studio .NET. While there has never been anything preventing the use of Visual Studio .NET as a development platform with Pocket GTViewer, GTI did not provide any samples or tools to help accelerate the process. The .NET Interface for Pocket GTViewer is now available and provides .NET class to handle all of the communications between your application and Pocket GTViewer. A sample Pole Inspection application is also provided as a demo.

Previously, eMbedded VB and eMbedded VC++ were the platforms of choice; however, this was because Visual Studio .NET was not available or required learning a new environment/platform. Other platforms such as NS Basic were also used. Visual Studio .NET 2003 and the soon to be released Visual Studio .NET 2005 provide a much better tool for developing Pocket PC/Windows Mobile apps. While simple applications could be implemented with eMbedded VB, it was sometimes painful to use if applications required more sophistication. This does not; however, mean that eMbedded VB could not be used to create successful applications for Pocket GTViewer (and many users proved this repeatedly). eMbedded VB with its many flaws did have its benefits too, such as being free and also being similar Visual Basic. eMbedded VC++ is also a free development tool and does not suffer from the limitations found in eMbedded VB; however, many users did not know or want to know C++ well enough to develop with it.

With Visual Studio .NET, you can use the language of your choice (VB.NET or C#.NET) to create a “Smart Device Application” project. Unlike eMbedded Visual Studio which was separate from the desktop Visual Studio, Visual Studio .NET provides embedded development and desktop development in the same environment using different project types to separate the two. Probably the best feature Visual Studio .NET provides for developing Pocket GTViewer applications is its Window Forms environment (a huge leap in functionality and ease of use compared to eMbedded VB or eMbedded C++). Since most Pocket GTViewer applications are forms based and may contain many forms for collecting data, etc., the Window Forms environment is a nice feature to have at your disposal.

So, if you have been wanting to try developing applications for Pocket GTViewer and were intimidated by eMbedded VB and eMbedded VC++, try Visual Studio .NET. Unfortunately, it is not free like the other tools, but it does provide significant improvements and ease of use. If you have already been developing applications for Pocket GTViewer with eMbedded VB or eMbedded VC++, now may be the time to try Visual Studio .NET.

COGNET GIS Develops Software to Improve Lightning-Strike Response Time

Look at this Press Release from COGNET about something they have done with GTVx:

http://www.gisuser.com/content/view/7196/

Wednesday, October 19, 2005

The GTThresh Utility

The GTThresh utility will be included in the next version of GTData, and it is currently available on request. This tool can be used to automatically set the Maximum Display Thresholds for each filter id in a filter (.flt) file. Previously, this task has always been a manual effort and has also been one of the more neglected tasks when configuring data. Setting the maximum display thresholds is also one of the best ways to improve display performance in GTViewer and even more so in Pocket GTViewer.

The GTThresh utility takes a .GTG and a .FLT file as inputs. It will scan through the .GTG file looking to see the maximum size of each element for each filter id used in the file. It then goes through the .FLT file and adjusts the maximum display threshold values (the zoom level at which the elements using that filter id will be automatically turned off). A sensitivity value is provided to specify how quickly filter ids should be turned off. This value is a little arbitrary, but the default is 5, and it means that as soon as the biggest element is smaller than 5 pixels, that zoom level will be the new threshold. The default value of 5 may be a little conservative, and I have been using 10 for most datasets lately.

The GTThresh utility assumes a few things, such as that all items using the same filter id are generally the same size. If you have all point features and one long line, then the threshold will get set for the largest element (the line) and will not be a good max value. However, this generally is not the case and future version of GTThresh may employ some form of averaging to get around anomalies like this one. For Text elements, only the height is considered so that long text string are not artificially inflating the maximum size when they can not be read anyway from a distance. If a .FLT file has a value already set for the maximum display threshold that is smaller than the computed one, it will not adjust the value. You can also specify a maximum value and if a computed value is greater than the maximum, it will be set to 0 (no maximum).

The GTThresh is not perfect. I still believe that a person can visually do a better job given enough time and effort. However, since so many users are skipping the task of setting the maximum display thresholds altogether and letting their display performance suffer, GTThresh can be a tremendous help to data configuration. If you have already set your maximum display thresholds, it may be of some use to run GTThresh anyway just to see if there were any you have missed.

GTThresh is still a new utility, but testing has shown that it can set maximum display values to a good default and even if you have to adjust them manually, it is much better and easier to tweak a few than to set all of them. This utility has been so successful in its testing, that its functionality is going to be implemented into the GTViewer FME Writer so that it will produce .FLT files that are already set to good defaults.

Thursday, October 13, 2005

GTViewer's Outage Analysis Application

The GTViewer Outage Analysis Application is one of the more interesting applications built on top of GTViewer. This posting will cover some of the functionality it offers to give a good idea of just what kind of power the GTViewer and its family of products can provide. As mention before, GTViewer is far more than a viewer and applications like Outage Analysis illustrate why.

The GTViewer Outage Analysis Application provides several different facets of functionality that all work together to provide the best tool for analyzing outage information. There are three major parts to the application:
  • Upstream/Downstream Search
  • Batch Outage Analysis
  • Interactive Outage Analysis

The Upstream/Downstream Search is identical to the functionality found in the GTViewer Upstream/Downstream Trace application. The user can select a conductor segment to start from and the electric network is traced to determine all of the upstream items (along the path to the breaker) and all of the downstream items (along the path away from the breaker). The user can also interactively modify the open status of switches and fuses to dynamically reconfigure the electric network and immediately see what impact it has on the network. The Outage Analysis will also respect these modified devices giving the user a great deal of control over the data.

The Batch Outage Analysis functionality reads data from an external source that reports outages. This information could come from a call center, a SCADA, or any other source of outage information. The outage information can be read in continuously to provide real-time, update-to-date outage information. The Batch Outage Analysis and the Interactive Outage Analysis modes both provide the same form of analysis, the only difference is that the outage information either comes from an external source (in batch mode) or from the user (in interactive mode). The rest of this posting will demonstrate the Outage Analysis Application by using the Interactive mode, but keep in mind that the Batch mode does the same processing just on a much larger scale at a faster rate.

The Outage Analysis Console is shown below. This console contains a lot of controls and panes, but it is designed to provide all of the tools needed for outage analysis in one small area:


This particular implementation of the Outage Analysis application is a dedicated application utilizing GTVx. While it can be an application runing inside of GTViewer (just like all of the other applications discussed in previous few blog entries), this implementation caters to a user performing mostly Outage Analysis. GTViewer and GTVx provide equivalent functionality; however, GTVx provides more control over the application layout as seen below:

To get a good idea of what the GTViewer Outage Analysis Application does, I am going to go through the process of interactively selecting outages and showing the results. Remember, the Batch Mode is also available for processing a large number of outage calls at once. The Interactive Mode allows a user to select outage locations and immediately see the results of the outage analysis.

For the first example, two customers are specified as having an outage:

  • 3019 Hampton Cove Way
  • 3021 Hampton Cove Way

The Outage Analysis Application takes the two customers and performs the necessary analysis to determine what the probable cause of the outage is based on the available information. Both of these customers share a common service transformer which has been determined to be the probable cause. In the screenshot below, the outage calls are shown with Magenta circles, the probable cause is shown in Cyan, and all potentially affect customers are highlighted in Red. The Lightning Bolt symbol indicates the location of the potential problem. The lightning bolt symbol and outage symbols are also Data Monitor Items which will be discussed later.

The Outage Console also shows information about the current analysis. The top line in the screenshot below tells the Circuit the device is on and the type of facility identified as the potential problem. The bottom pane shows a list of all customers that would be affected if this device is the failure point. Clicking on one of the customers will locate on that particular address in the view.

The first example was pretty trivial since both customer were connected to a common transformer. To demonstrate the capabilities of the Outage Analysis application, we have to continue adding outage calls and see how it responds. In the next screenshot, another call is added at:

  • 3027 Hampton Cove Way (supplied by a different transformer)

The analysis performs the necessary traces to determine the probable failure is fuse #105 located upstream of all three outage calls. The screenshot also shows all of the conductor affect in Orange.



The Outage Console now shows 22 customers that would be out if the identified device has failed.

By adding one more outage call at:

  • 3025 Agusta Trace (upstream of fuse #105)

The Outage Analysis app again traces the network to find a potential device that would affect all four addresses if it had failed.

In this example, a Fuse near the substation is identified as the potential failure point which would affect 154 customers if it has failed. Again, the circuit affected is shown in Orange.

The above example shows only one circuit outage; however, this application is designed around the GT/Trace component and performs the tracing it needs for its analysis very quickly and give this application a great deal of scalability. When multiple outages are present with many customer calls, the Data Monitor makes it easy to see what is going on in the entire system. Data Monitor items are used for both the outage location and customer call, and a Data Monitor item’s tooltip is displayed when the cursor hovers over the item to show detailed information as shown below:

This posting just grazes the surface of what the GTViewer Outage Analysis Application does, but hopefully it gives an idea of the complexity applications written on top of GTViewer or GTVx can provide.

GTViewer's Loop Makeup Application

Loop Makeup is a task performed on telephone networks to identify various characteristics of a line as it goes back to the CO (central office). Loop Makeup reports are used for a variety of decision making tasks such as qualifying a customer for DSL service, finding bridge taps, determining loading, etc. By providing this detailed information in the field or in the office, GTViewer’s Loop Makeup Application improves productivity and gets the right information to the right people, when it is needed.

The Loop Makeup Application is shown below:



When activated, the Loop Makeup Application waits for the user to select a starting feature. The feature can be a terminal, a cable, etc. Since a feature generally has more than one pair of wires running through it, the user is presented with a list of all Cable Id and Pair ranges for the selected feature. The user then picks a Cable Id alone or a Cable Id and Pair Count to create a loop makeup report for and the network trace begins. By utilizing the GT/Trace component, the telephone network is traced very quickly from the selected feature back to the CO. As the trace progresses, the data for the report is accumulated and several options are made available to the user, such as Trace by Cable Id or Trace By Cable Id and Pair Count with a specified pair count value. The user can also specify to Include Bridge Taps and to Create a Loop Makeup Report file.

The Results pane in the Loop Makeup app shows each feature traversed on the way back to the CO. These features can be in the regular geographic view and/or in a detail drawing since the trace goes through all connected feature and usually there are some in detail drawings. Clicking on one of the items in the results will locate on that item in the view.

The Cable Summation pane shows a summary list of lengths for each cable type/gauge pair. A list of Bridge Taps is also provided if the Include Bridge Taps options were selected.

Both the Trace Results and Summary Information can be copied to the Windows clipboard with the Copy Results to Clipboard and Copy Summary to Clipboard buttons. These results can be pasted in to Excel or any other application.

If the Create a Loop Makeup Report option was selected, a formatted file is written to disk with all of the Loop Makeup information included. This report looks like the following screenshot; however, its appearance can be customized.



The Loop Makeup results are also shown graphics in the geographic view by highlighting the path taken back to the CO. Unlike network tracing seen with Gas and Electric models, it is not obvious which path a pair takes just by looking at map. A cable can contain hundreds of pairs and a pair can jump around through different cables, so a visual path drawn on the map can be more valuable than it might first appear:



The GTViewer Loop Makeup Application is an excellent example of a complex GIS task GTViewer can provide users in the field as well as users in the office.

GTViewer's Gas Valve Isolation Application


The Gas Valve Isolation Application has always been used as demonstration of GTViewer’s Network Tracing capabilities. This application allows the user to select a piece of gas main (where a leak has occurred), then the application traces the gas network in all directions looking for valves that would need to be closed to isolate the leak from the rest of the network. Also, the application determines which customers will be affected by closing the valve.

Early versions of this application simply searched for the valves that bounded the leak. While this was a flashy demo, it did not look beyond the immediate bounding valves to see if the network on the other side dead-ends (in which case, the valve doesn’t need to be closed and the customers on the other side of the valve also need to be included in the affected list). The current version of the Gas Valve Isolation Application does check the network on the other side of the bounding value until it finds a source; thus, a more useful result is provided.

The screenshot below shows the Gas Valve Isolation Application:



Once activated, the application waits for the users to select a gas main segment to start the analysis from. Once selected, the network is traced (using the GT/Trace components). The user can optionally fit the trace results while the trace runs (using the Fit while Tracing option); this option causes the trace to run slower, but shows exactly how the trace is progressing. The Gas Valve Isolation Application looks not only for valves that must be closed to isolate the leak, but it also gathers a list of all customers who will be affected by the isolation. The customer list is shown at the top of the form (by address) and the valve list is shown at the bottom. Clicking on either a customer or a valve will locate on that item in the view. The trace results are persistent, so locating on the customer or valve does not clear the results. The Fit Results button will always take you back to the overall view of the results. A Copy Customer Window button is provided to copy the list of customers to the Windows clipboard. These results can then be pasted in Excel or any other application. A Copy Valve Window is also provided to copy the Valve results to the Windows clipboard.

Another feature of the Gas Valve Isolation Application is that it takes into account that a user’s data might not model the source for the gas network. In this case, you can set a limit as to how far it should trace until it assumes that a source is at the other end. The Limit options allow the user to set various lengths or the Next Valve.

The screenshot below shows the isolated main in Red and the Green traces back to the source. The two valves that need to be closed in this example are pointed to with the Magenta Arrows. The Arrows are also Data Monitor items and show additional information as a tooltip when the cursor hovers over them.



The Gas Valve Isolation Application has evolved from a flashy demo to show off GTViewer’s tracing to a very useful analysis tool capable of proving important information in the field and on demand. It also shows off one more example of GTViewer’s success as a GIS application development platform.

Wednesday, October 12, 2005

Import Shape Files

Sometimes you want to import a shape file into your GTViewer session. Here's handy tool I wrote for a client and would like to share with the GTViewer development community at large. (We have lots of tools in GTData to help you bring entire shape file datasets into the format used by GTViewer, but this one lets you bring in just one, while you are in a session.)

Usage is pretty simple. You pull down the Query menu, select the app, and then browse to the shape file, and press the button.

Two items are hard coded, and you are welcome to change them for your app. One is the category number. My client did not have a category 10, so I used 10. This is only for temporary use, so even if you have a category 10, it ought not to matter. The other item is the coordinate factors that make the shape file come into GTViewer at the right position relative to the rest of the data. You may need to adjust these.

As usual, you will need to add the application to the .gtm file in the [External Applications] section.

Sample code can be downloaded from http://www.gti-us.com/Blog/ImportShape.zip

Let me know how it works for you, and feel free to send me your improvements!

Charlie charles.marlin@gti-us.com

Tuesday, October 11, 2005

GTViewer's Lightning Strike Application

The Lightning Strike Application for GTViewer shows current lightning strike data over your facility and landbase data. This application is not only a good illustration of using GTViewer as a GIS development platform, but it also shows off the capabilities the GTI Data Monitor with a real world application. The Data Monitor is a part of GTViewer that can display a large number of temporary items on top of your GIS data. These items may update their position frequently (as when showing Truck or Crew locations) or may have a limited lifetime (as with lighting strikes). The lightning strike information is only valuable for a short time period. Once the strike has aged, the information is no longer of value and can be discarded. Data Monitor items are not permanent features like Redlines and while this application could be implement by drawing redlines at the lighting strike locations, the Data Monitor is more efficient and provides more features than redlines can for this type of information.

The Lightning Strike application is very simple. It reads data from a lightning strike data source and then updates the data monitor items. Lightning Strike items are symbolized based on their age. Once the strikes have reached a certain age, they are automatically deleted. The lightning strike data can be updated at regular intervals to show a current view of the storm condition and provide additional support for critical decision making.

The examples shown below cover for a very large area (most of North America), while a real application would be for a much smaller area. The first screenshot shows a bird’s eye view of the United States. The colored dots represent the Lightning Strike Data Monitor items covering a 2 hour period.



If we zoom in to a specific area of the map where the lightning strikes are concentrated, we can get a better view of the storm pattern. The color of the lightning strike is determined by its age. White is less than 30 minutes; Yellow is less than 50 minutes; Red is less than 70 minutes; Orange is less than 90 minutes; Brown is less then 110 minutes, and Blue is greater than 110 minutes.



Zooming in again shows more detail. The Data Monitor items change from a dot to a lighting bolt symbol:




The next screenshot illustrates how the Data Monitor’s tooltip feature can be used to display information about each individual strike. By hovering the cursor over one of the strike locations, the tooltip is displayed automatically:




The Lightning Strike application involves more than simply running the Data Monitor. The Lighting Strike data must be acquired from somewhere. Some electric utilities have their own equipment for monitoring lightning strikes, but there are also services that provide this information for a monthly fee. For this application, the lightning strike data was provided by WeatherTAP.com. They can provide current lighting strike data via the internet for a minimum area of 50 x 50 miles. Cost is based on a per user basis and on the size of the area being monitored. Detailed information (as shown in the tooltip above) is extra.
The Lighting Strike application is a good example of how the Data Monitor can be used in a practical example. This application also contains a pattern that can be used for a variety of tasks other than monitoring lightning strikes. This pattern is: load data from a source (a file, the internet, etc.), then create data monitor items from the data. Already, the Lightning Strike app’s pattern has been applied to other applications for showing work ticket locations, and another for Siren locations.

For more information on WeatherTAP.com and the data they can provide, visit their web site for more information: