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 .

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 of GTViewer is available.

----------------------- - 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 is Available

Version of GTVx is available.

----------------------- - 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:

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

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


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 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 and the data they can provide, visit their web site for more information:

Thursday, October 06, 2005

GTViewer's Highlight By Phase Application

The next several posting will cover various applications that use GTViewer as an application development platform. The last application discussed was the Upstream/Downstream Trace and it showed how a sophisticated GIS application can be implemented. This posting will cover another application that is much simpler in its design, but is still very useful. The Highlight By Phase app really does not do anything different from what you can already do with GTViewer and its built-in Thematic Queries; however, this app streamlines the use of several Thematic queries at once and minimizes the user’s input to get a standardized set of results.

The Highlight By Phase app allows the users to highlight electrical features that have a particular phase attribute. The standard app allows the user to select A, B, C, or Multiple. If A is selected, all features with the phase attribute set to A will be highlighted in Red. If B is selected, all features with the phase attribute set to B will be highlighted in Blue; and if C is selected, they will be highlighted in Green. A forth option allows features with more than one phase to be highlighted in Orange. By pressing the Highlight button, the Emphasize Session Graphics mode is engaged (to gray out all of the features), and the selected Phases are highlighted in the appropriate colors. The Highlight By Phase app only applies to features that are in the current view; however, there is no limit as to how many features you can include in the view, other than the more features, the longer it will take to process. Fortunately, GTViewer can process highlighting very fast and a very large number of features can be processed in this manner.

Sample Output using Emphasize Session Graphics Mode:

Sample Output with a Raster Backdrop:

To fully appreciate how valuable this simple little app can be, let us compare it to what would be done with Thematic Queries. A Thematic Query in GTViewer highlights a set of features with common attribute values, such as all wooden poles, all conductors with a particular circuit id, or all electrical features with a specific phase attribute. The Thematic Query is generic; the users fill in the prompts like a standard query to select the features to highlight, then the user selects how the highlighted items will appear (color, weight, etc.). The Highlight By Phase app is really just performing 4 Thematic Queries at once (A, B, C, Multiple) with a preset color scheme.

Just like with the Upstream/Downstream Trace, once results are obtained, the user can do various things with them. The results can be Printed as shown below:

The results can be converted to Redlines with the Tools/Highlighted Elements to Session command. Once converted to Redlines, the results can be shared with other users, manipulated, or exported as a DGN file or XML.

The Highlight By Phase app’s logic can be applied to many tasks other than phase highlighting. It can contain a list of predefined Thematic queries for any discipline, it can contain more preset Thematic Queries to choose from, and it can base its feature select on much more complicated criteria than a single attribute.

Tuesday, October 04, 2005

GTViewer's Upstream/Downstream Trace Application - Part 2

Part 2. See Part 1 for the beginning of this post.

Everything presented so far about the Upstream/Downstream Trace is pretty standard as for as Tracing applications go. The next part discussed is what sets GTViewer apart from other development platforms. The Modify Status button at the bottom of the dialog allows the user to change the Open/Close status of any switchable device. Changing the status will affect how the trace operates (since a trace will not go through an open device). By default, all switchable features use the status from the GIS data. If you press the Modify Status button, you can then select a switchable device in the view and change it open/close status. When a switchable feature is selected, you will get the following dialog:

This dialog tells you the type of feature you selected and shows the current status. If you change the status and press Save, the new status will be used the next time the data is traced. A modified feature will be shown in Red to indicate that it has been changed.

The next several screenshot will show how switching devices will change the trace results. The first screenshot show the Trace with no modifications made. The Magenta conductor is the starting feature and some of the Blue downstream features are shown.

If we zoom in to the center of the previous screenshot, there are 3 fuses:

I will open each switch one at a time and show the different trace results after each opening. In the screenshot below, the middle fuse is opened:

In the screenshot below, the middle and left fuses are opened:

In the screenshot below, all three fuses are opened:

The above example is just a simple demonstration of what can be done by modifying the feature status.

There are many things that can be done with Trace results that are just part of GTViewer’s standard functionality. Trace results can be printed:

The Feature Counting mechanism works on Trace results just like it does on any other feature. For example, the below screenshots show the Count summary and a Count Details report for Conductors. The Count in this instance only applied to the trace results and not all of the other features in the data.

Trace results can also be converted to Session Graphics (or Redlines) with the Tools/Highlighted Elements to Session command in GTViewer. Once converted to Redlines, the Trace results can be shared with others, converted to other formats (such as .DGN files or anything FME can generate). Also, once converted to redlines, the Trace Results can be manipulated like any other redline.

The Upstream/Downstream Trace application is a simple app, but it shows how sophisticated an application built on top of GTViewer can be. The Next few posts will cover other applications built on top of GTViewer to show in even more detail what can be done.