Creating Intersections for your source GIS

The recent posting on Intersection Creation from street segment data brought up another question from a user. Can you take the generated intersection features back to the source GIS? This is a very interesting question since GTIntersect and GTInterGtg were designed to generate the intersections for GTViewer’s use. Originally, the answer was no. While you could export the intersections to a DGN or Shapefiles or use FME to export the data to any other format, only the graphics would have been exported since the data was stored in a GTViewer tabular database. In the next version of GTData, GTIntersect and GTInterGtg have the ability to embed the tabular data on the intersection symbols, thus the export to Shapefiles or a .GTG conversion with FME will be able to export the tabular information as well as the graphics. GTData provides a variety of geoprocessing tools like the intersection generation utilities and more processes like this one will be discussed in future blog entries to help further enrich you source GIS data as well as the data used with GTViewer and its family of products.

Below, a few approaches to getting you intersection information back to your source GIS will be discuss.

If you want to take your generated intersections back to an ESRI system, the process will be like this:

1. Generate your intersections as before with GTIntersect or GTInterGtg, only add the EmbedData=1 option to the parameter file.
2. Import the Intersection .GTG file you create as Session Graphics in GTViewer (Draw/Import/Import GTViewer Graphics).
3. Export the Session Category data as a Shapefile (Draw/Export/Export As Shapefile)
4. You will get 3 files created in the specified Export Path: Inter_point.dbf, Inter_point.shp, Inter_point.shx
5. Use the generated files to update your ESRI system.

And alternative approach here would be to just use the GT2Shape utility (part of GTData) to directly convert the intersection .gtg file to shapefiles. This method would avoid using GTViewer and importing and exporting.

The process is a little different if you are using FME:

1. Generate your intersections as before with GTIntersect or GTInterGtg, only add the EmbedData=1 option to the parameter file.
2. In FME, select GTI_GTViewer as the source data type, then pick any format you want as the destination data type.
3. Then run the translation in FME.

The FME process is very straightforward and very flexible as to the type of output you want. It could convert to Geodatabase, Shapefiles, MapInfo, Smallworld, etc.; however, you must have FME and any required components to use this approach.

Generating Labels for Streets and other Linear Features

The last posting on creating Intersections for Street Segments is closely related to another topic that deserves a posting of its own. Typically, TIGER data (used to make intersection in the previous post) is just the linear graphics for the streets segment with no labeling. To make the street segments data usable, it needs to have labels. Labeling data automatically is not a trivial task, but GTData includes two utilities for generating labels for any linear data from associated its attribute values. This linear data is usually street segments, but it can be anything from Gas Mains to Primary Conductors.

A typical street network may look like the following. When zoomed out past a certain point, labels do not really matter as they probably won’t be readable anyway:



As you zoom in, Labels can be used to make the streets identifiable as shown below. However, labeling every street at this level can quickly clutter up the view and some mechanism must be used to filter out some of the labels.



When zooming in closer, all streets segments can be labeled as shown below:



The GTIntersect utility used to create intersections from Shapefiles (see previous post) has a special mode for creating labels. It can be used to generate the labels seen in the above screenshots. Another utility, called GTLabelGtg is also provided to give the equivalent functionality only using .GTG files (GTViewer’s native graphics file format) instead of Shapefiles as its source data.

The labeling utilities both have two modes of operation. They can generate labels of a fixed size and only create the label if there is enough space to fit the label on the street segments. This mode is ideal for producing labels when zoomed out where many of the labels need to be filtered out or they will cause visual clutter. The second mode uses variable sized labels that will be scaled to fit in the space available on the street segment. In this mode, a maximum size is specified, but a label will be generated for every street segment and will be scaled down if it does not fit in the available space. This mode is ideal for generating labels for close up viewing. The screenshot below shows better details of how the variable scaling will appear in more extreme circumstances:



While the GTData utilities provides an excellent means of generating labels for street data (as well as other linear data), it is not the only approach available. Safe Software’s FME can also be used to generate street labels with the Labeller tool.



In this example, the Concatenator was used to make a string that included the Street Direction, Street Name, and Street Type. This new string was then used as the source attribute for the Labeller. The Labeller provides a variety of settings for specifying the label size and overlap prevention. More complex implementation of labeling could also be implemented with FME, but this Labeller is the simplest way to get labels on the page. The following screenshot show the same set of data with the labels produces by FME:




Labeling of streets may only be necessary if you are using TIGER data or something similar that does not have the man hours invested in it to contain aesthetically placed labels. While the automated labeling approaches offered by GTData and FME do not provide as “pretty” of a result human place labels, it does fill in a gap that is essential for having usable data. Also, keep in mind, that street labels are not the only thing labeling can be used for. Any attribute or combination of attributes on linear data can be used for creating labels, so you could place pressure and size information along a gas main, phase or circuit id along a conductor. Be creative.

Intersection Queries without Intersection Data

A common query that users like to use is an Intersection Query. For example, find me Main Street and 4th Ave or Jordan Ln. and Holmes Ave. An Intersection Query is sometimes more useful than an Address Query because you do not have to be as precise to get relatively close to what you are looking for. Also, it is often easier to remember an intersection than an addresses, and it is also easy to identify intersections just by looking for the closest street signs. Interestingly, many data sets to not model intersections as a feature, so creating an explicit intersection query may not be something supported by your GIS data. GTData has provided some utilities for some time to specifically create street intersection features from a street segment data and provide the ability to locate by intersection in GTViewer, GTVx, Pocket GTViewer, and GTWeb even if the source GIS data does not support this type of query in its native environment.

The Intersection feature building utilities in GTData were implemented because several customers wanted to use TIGER Line data to provide landbase information in their data. This data is available (free of charge) in many different formats and from many different sources, such as the U.S. Census Bureau (http://www.census.gov/geo/www/tiger/index.html) or ESRI (http://esri.com/data/download/census2000_tigerline/index.html). While this free data does provides a street segment network, it does not provide intersection features, so while an address can be located using GTViewer’s Geocoding Address Query, an Intersection query was not directly supported. To solve this problem, the GTIntersect utility was added to GTData to generate intersection features (points with associated street names) directly from Shapefile data. This utility looks at all of the street segments and performs geoprocessing to check for any intersecting segments and any place where street segments meet. The end result is a new intersection category for GTViewer and associated tabular data. The tabular data can be used to generate an intersection query with GTQuery.

The success of the GTIntersect utility with the TIGER data was too good to limit it to Shapefile data. Perhaps it was a little shorted-sighted to build the utility to work with Shapefiles when there is other data that could benefit from it as well. So, the GTInterGtg was implemented to take care of this oversight. The GTInterGtg utility is also part of GTData and is equivalent to the GTIntersect utility except that it works against .GTG files (GTViewer’s native graphics format) instead of Shapefiles. This change opens intersection building up to any data that can be converted to the GTViewer format.

To illustrate how the intersection query works, the following screenshots step through the process of locating an intersection in GTViewer.

The Find Intersection Query asks for 2 streets in the screenshot below. This query could also ask for a city and/or state as well. The order that the streets are entered does not matter as the Intersection query automatically checks the values both ways when processing the query:



The intersection being queried was Jordan Ln and Holmes Ave, but the only first few letters were entered for each of the street names.. The Query Results below show all of the matches:



Picking the intersection in the list will locate on that spot in the map in GTViewer:



The Intersection Query can also be used to find all streets that intersect with a specific street by just entering one street in the query dialog:






While the ability to generate intersection may not be of interest to those who already have intersection features in their GIS data, it can be very useful to those who do not have this information. GTData provides 2 ways to produce intersection features to solve this problem, so if you want to try building intersections from your street networks, the tools are available.

Using the LineGeneralizer in FME to reduce the number of points in a Polygon

GTViewer and Pocket GTViewer both set an artificially low maximum number of points that can be used in certain elements. These element types include:

• Line String Elements
• Shape Elements
• Shape With Holes Elements
• Complex Line String Elements
• Complex Shape Elements
• Complex Shape With Holes Elements.

The maximum point count is kept low to force the use of smaller elements to improve display performance and to reduce the amount of memory resources required to render the element. Pocket GTViewer runs on devices with severely limited resources and strict attention must be paid to this hardware limitation if high performance is to be maintained on the handheld platforms. The desktop version of GTViewer is forced to comply with this low maximum too because one data set is desired for use between the desktop and the handheld platforms, plus what runs faster on the handheld will also run faster on the desktop.

Currently, the maximum number of points is set to 12,000 and is sometimes too low to accommodate certain elements. Some polygons may contain 50,000 or more points for seemingly trivial features. There are various ways to deal with this problem when converting data for GTViewer. The GTShapeConv utility can decompose one of these elements into a group of elements with fewer points and this is generally the ideal solution, but it becomes a problem when you do this with large polygons. The polygon element will be broken down into a group of independent line strings that together will look like the polygon. The problem with this solution is that the converted element is no longer a polygon and can’t be filled.

If you are using Safe Software’s FME to convert your data to the GTViewer format, a clever transformer called the LineGenerlizer can be used to thin out the number of points in a linestring or polygon. By simply placing this transformer between your source and destination and configuring its parameters, the number of points in the elements will be reduced and fit into the elements without breaking them up.





A variety of parameters are available to generalize the element. I will leave it up to the user to look at the FME documentation for more details. However, I will discuss how to determine if you have satisfactorily adjusted the parameters enough to get all of the large polygons small enough to fit in to the maximum allowed number of points. When you run FME to convert your data, you will get warning messages like the following for elements that contained more than the maximum allowed points:

Shape with Holes contains more than the maximum number of points (20094, Max: 12000). Converted as a group of linestrings.
Shape with Holes contains more than the maximum number of points (12374, Max: 12000). Converted as a group of linestrings.
Shape with Holes contains more than the maximum number of points (24081, Max: 12000). Converted as a group of linestrings.

For generalizations using the Douglas algorithm, you can increase the generalization tolerance until you no longer get these warnings.

Not only will this process reduce the number of points in the elements enough to generate the appropriate elements, the reduction in points further improves performance, reduces the overall data size, and you probably will not be able to tell the points were removed in the first place.

GTViewer 5.0.x.12 is Available

Version 5.0.x.12 of GTViewer is available.

-----------------------
05.00.00.12 - 03/15/06
-----------------------
- FIX - With Session Links, if you browse to file that is at the same level as the .GTM file and the relative path mode is used, the first character of the detail
filenames get removed after the path is adjusted.

- NEW - Filter Threshold section added to Element tab in Attribute Info Dialog.

- NEW - Data Id now added to element attributes on Element tab in Attribute Info Dialog.

- FIX - The Text property for Text elements on the Element tab in the Attribute Info Dialog was display negative numbers for single character text as the character id for values over 127.

- FIX - Saving Character to .GTS session files with ASCII values greater than 127 would get their character value inverted.

- FIX - The Print to Scale dialog was not showing the units on the Scale Selection.

- CHG - For DGN Exports, groups of text elements are no longer converted as orphaned cells. Text Node element are now used instead of orphaned cells when all internal group elements are text elements.

- FIX - ElementGetPointList was not returning values for Type 114 Shape With Holes elements.

- NEW - New Methods:

long ElementGetPartCount(long id);

How to Make Your Toolbar Buttons Larger in GTViewer

Some time ago, a feature was added to optionally increase the size of the toolbar buttons in GTViewer. Originally, this feature was intended to make it easier to select the buttons when using Tablet PC or any other laptop with a stylus or pen. The buttons are only slightly larger, but the size difference does make selecting the individual buttons much easier since the target area is larger.

The screenshots below illustrate the different sizes of the buttons; the top uses the regular sized buttons and the bottom uses the larger buttons. The Zoom command is activated in both screenshots and can be used to more easily compare the size difference:



With the lackluster success of Tablet PC in the marketplace, this option was never integrated into the user interface, but it can still be used by setting a registry entry. Find the HKEY_CURRENT_USER folder, then Software, then Graphics Technologies Inc, and finally GTViewer. Under GTViewer there will be a Settings folder.



Add an entry to this folder called BigButton Flag. Make it a String value and then set it to 1 (setting it to 0 will be the regular sized buttons):



Run GTViewer and you should see the larger buttons.

You can also create a .reg file like the one shown below and run it:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Graphic Technologies Inc\GTViewer\Settings]
"BigButtonFlag"="1"

GTSmartClient - Press Release

Today, GTI announces a new product called GTSmartClient:

Press Release - GIS Cafe

Press Release - Directions Magazine

Street Navigation and Routing in GTViewer using MapPoint

Street Navigation and Routing capabilities are common tasks required by many GTViewer users. In its simplest definition, Street Navigation is determining a list of directions to get from Point A to Point B where Points A and B are street addresses (such as 123 Main St., Anytown, AL). Directions are presented as a list of turns and distances to travel to get you from the starting address to the destination. Street Routing is a step of above Street Navigation, while the two tasks are similar, Street Routing takes a list of addresses and finds the best order to visit each address providing the optimal (or near optimal) list of directions that minimize the distance and time required to visit all addresses.

While most GIS data does provide extensive landbase information (roads edges, street center-lines, etc.), this data generally does not provide enough information to perform viable Street Navigation or Street Routing. Many datasets even have well connected street centerline data, but do not contain one-way street information, road class, construction information, or any number of other attributes that could affect navigation decisions. So, the question arises, do you want to try to use your GIS’s landbase information even though it does not contain sufficient information to perform usable navigation and routing, or do you look to a 3rd party source of data to help? More and more users are turning to 3rd party data to solve this problem. Detailed street data that contains enough information to provide navigation and routing is very difficult to create and even more difficult to maintain. However, 3rd party data is available for these specific tasks. Microsoft’s MapPoint application is one such source of this data and is the topic of today’s blog posting. MapPoint provides good street data, good routing tools, and can be easily integrated into other applications (in this case, GTViewer).

MapPoint provides an extensive API for accessing its functionality. Similarly, GTViewer provides a similar style of API for extending its own functionality and integrating it with other applications. By creating an external application for GTViewer, the MapPoint functionality can be embedded into GTViewer and the MapPoint functionality becomes accessible inside GTViewer. One might ask the question, why bother integrating this functionality into GTViewer when MapPoint itself provides a user-friendly interface for performing Street Navigation and Routing (plus much more). An overwhelming opinion on this matter is that users do not want to switch to a different application to do this, user do not want to be trained on another application, and MapPoint’s many features that are not applicable may be confusing to the user. Also, running MapPoint as a separate application forgoes the tight integration you can achieve by embedding MapPoint inside GTViewer, such as clicking on a feature in GTViewer’s view to obtain an address for MapPoint to use, or clicking on an address in MapPoint and locate on it in GTViewer.

A Street Routing application is now available for GTViewer. This application integrates MapPoint with GTViewer to provide Street Navigation and Street Routing to GTViewer users. With the Street Routing application installed, you can select it from the Query menu in GTViewer and get the following dialog:



The Street Routing dialog provides three 3 methods for entering an address. The first, Find Place or Address, allows the user to key in a complete address, such as 123 Main St. Anytown, Alabama. Pressing the Find button will then search the MapPoint database for any matching address and present them to the user. The second method, Find Address, allows the user to enter the address components (Street Name, City, State, Zip Code). Pressing the Find button will search the MapPoint database and present any matching addresses:






The third method is the Get Address from Map option which allows an address to be acquired directly from a feature in GTViewer. Pressing this button activates a mode in GTViewer that allows the user to select features with addresses (the feature list must be configured in advance along with the table and fields that contain the address information). Once a feature containing an address is selected in GTViewer, the address information is sent directly to the Street Routing application.

Select and Address in GTViewer:






If the selected address is found, it is located in the MapPoint view and automatically added to the Route.



To perform Street Navigation, you need at least two addresses in the Route List. Any address in the Matching Addresses list can be added to the Route List (by double-clicking or pressing the Add button). The Delete button can also be used to remove any selected address from the Route List. The first address in the Route list is always the starting point and the last item in the list is the destination. You can have any number of items in the Route List. The Move Up and Move Down buttons can be used to reorder the items in the Route List while the Clear Route button will reset the list.

The Compute Route button is enabled when 2 or more items appear in the Route List. Pressing this button will cause MapPoint to generate a directions list to navigate from the starting address, through any intermediate addresses (waypoints), to the destination address.

In the following example, 4 addresses appear in the Route List:



A closer view of the graphical representation of the directions is shown below. The numbered squares correspond to the items in the Route List:



The Directions List provides summary information of the trip along with a detailed turn-by-turn description of how to get from the starting address, through the waypoints, to the destination address:



If a Route List has 4 or more addresses, you also have the option to Optimize the route. The Starting Address and Destination Address will stay the same, but any waypoints will be ordered such that you have the best route for the given address list.

In the trivial example shown above, Optimize still reduces the distance and driving time by change the order of the waypoints:





For more complex routes that cover a larger distance, the optimization can make a dramatic reduction in both time and distance. Optimizing a route is a non-trival problem that MapPoint handles automatically.

A more complex route is show below with a estimated travel time of 30 minutes and a distance of 13.4 miles:



Original Route List


Optimizing the route reduces the estimated travel time to 16 minutes (almost half the original) and a travel distance of 6.9 miles.


Optimized Route List


The Street Routing app has a few other features as well. Clicking on any address in the Route List will locate on that item in both the MapPoint view and in GTViewer. There is also an Import and Export capability for the Routes. So, if you have a file that contains a list of addresses (this file can be created in various ways from manually typing in a list with notepad or from an outage system’s output), press the Import Route button, select the file, then optimized and create a direction list. You can also export any Route list to a file with the Export Route button.

All GTViewer users do not need Street Navigation and Street Routing capabilities, so the additional cost of MapPoint is not justified; however, there are always times when this functionality is crucial to your operation, such as when visiting crews are helping with storm damage and are unfamiliar with the area. Using an application dedicated to Street Navigation and Routing, like MapPoint, is generally a better solution than trying to force your existing GIS’s landbase data to work at a crippled or inadequate level. By integrating MapPoint with GTViewer you get the best of both worlds.

Printing to Scale vs. Standard Printing in GTViewer

GTViewer and GTVx both provide sophisticated printing functionality. Most users have probably used the Standard Print command many times, but they may not be familiar with the Print to Scale command. This blog entry will discuss the differences between standard printing and printing to scale and show how they are different from one another.

The Standard Print command (File/Print or the printer icon on the toolbar) has two options for determining what information will be printed: the Default mode and the Full Page mode. The Default mode will print only what is contained in the Active View, while the Full Page mode will contain what is in the active view plus whatever else can be included to fill up the printable area on the paper. Since the Active View is generally not the same proportions as the printable area on the paper, there will usually be wasted space on the print; Full Page mode simply utilizes all of this wasted space while still including the information in the Active View.


Standard Print – Only what is in the Active View (default mode)


Standard – Active View plus additional area to fill page (Full Page mode)


While all Standard Prints have a scale, this value is just the computed scale required to fit the desired information on the printed page. The Print to Scale command provides the user with the ability to specify exactly what scale features will have when they come out on paper. For example, you might specify that the scale is 1 in = 50 ft (or 1 inch on the print will represent 50 feet in the real world). A scale might also be a ratio like 1:10000 (or 1 unit on the paper represents 10000 of those units in the real world).

By selecting the File/Print to Scale command in GTViewer, you get the following Print to Scale Dialog:

Using the Default Scales (based on the data’s minor and major units):


Using Custom Scales (defined as Ratios in the .GTM file):


From the Print to Scale dialog, you specify both the Scale you want and the Paper Orientation (Portrait or Landscape). A default Scale selection is provided (the first 7 scale options) and these scales can be configured in the .GTM file (two versions are shown above). The 8th scale option is a custom scale and allows the user to key in any scale value.

After selecting the scale and orientation, press okay and you are returned to the Active View with a “Cookie-Cutter” attached to the cursor. The Cookie-Cutter is a rectangle that can be moved around the view; all data inside the rectangle will be printed at the specified scale.

Cookie-Cutter:


Print to Scale – 1 in = 100 ft / Portrait

The Cookie-Cutter provides an easy way to see select the exact area you want to print at the selected scale. Also, with the Cookie-Cutter active, the user can also use a variety of key commands to change the scale and/or orientation and to see a print preview.


Key Commands for Cookie-Cutter:

• L – Set to Landscape Orientation
• P – Set to Portrait Orientation
• + (plus) or . (period) – Set to next larger scale
• - (minus) or , (comma) – Set to next smaller scale
• Esc – Cancel Print to Scale Mode
• Shift-P – Print Preview

Once the Cookie-Cutter contains the area you want to print, click the mouse button and you will be taken to the regular Print Dialog.

More Examples are shown below:

Print to Scale – 1 in = 200 ft / Portrait

Print to Scale – 1 in = 500 ft / Landscape



Also, for more information, see Printing with Custom Overview Maps in GTViewer to see what else can be done with printing in GTViewer.

How do I Zoom thee? Let me count the ways...

Okay, I am a day late for my Valentine's Day title, but here it is anyway. :)

I like to add blog postings on topics that not only show the features of the GTViewer product family, but I also like share answers to commonly asked questions that I get from days to day from the users base.

Today’s topic is about all of the different was to zoom in and out of your data. This list has grown over the years because everyone seems to have a different way they want to zoom, so here goes:

• The obvious number one option is the Zoom command on the toolbar or View/Zoom. The Zoom command allows the user to zoom out by dragging the cursor up and right and to zoom in by dragging the cursor down and right. The zoom command also provides previous view functionality (drag up and left) and and Center View with a click (which can also be used to pan and will be described in a future blog posting "How do I Pan thee? Let me count the ways...".
  
• The number two option is the Attribute Info command? What? Yes, the Attribute Info command. The Attribute Info command uses the same gestures as the Zoom command except the click with no drag will review a feature (under the click) instead of a Center View on the click.
  
• The number three option (and my personal favorite) is the Mouse Wheel. Roll the mouse wheel away from you, and the view zooms out. Roll the mouse wheel toward you, and the view zooms in. It does not matter which mode you are in except for Magnify where the mouse wheel changes the size of the magnify box (for this case use the keyboard----see option 5 and 6 below).
  
• Hold the boat! Option 3 sounds like the deal for you and could potentially be your favorite Zooming method, but the logic seems all backwards to you. You may want to roll the mouse wheel away to zoom in and vice versa. Well, that is okay (wrong, ha ha, but okay), you just have to change the direction of the zoom for the mouse wheel under Options/Settings/Mouse Wheel Increment. Making the increment negative will reverse the direction of the zoom. You can also change how much it zooms here too as its name implies.
  
• The next option is for the keyboard fans out there. The '+' and '-' keys on the top of the keyboard and on the number pad both provide zoom in and zoom out functionality in any mode. Again, a ways to zoom in and out without changing modes (see previous 2 options for more methods that don’t change the mode).
  
• Ack!!! My computer doesn't have a Plus and Minus Key!!!! And I want to use the keyboard! I don’t have a mouse and that pad thingee is too difficult to use!!! (This is me mocking myself; I am not making fun of any users out there). Most laptops actually do have the plus and minus keys, but it takes a function key or some additional key to get to it to work (thus defeating the ease of use option and usually making it a two-handed job). So I agree, the plus and minus keys are not the best choice for laptops (and GTViewer is supposed to be a mobile application isn't it???). There is a nice alternate solution here, the Comma ',' and Period '.' keys can also be used to zoom in and out. They share with the '<' and '>' keys, which makes the key functionality easier to remember, but they work if the shift is pressed or not.
  
• This is probably enough for the zoom list, but there are yet even more ways to zoom in and out. The Fit will zoom all the way out. The Magify mode will zoom in to the magnified zoom level if you double click the mouse (very nice feature if you haven’t tried it). And last but not least, the Good Ol' Locate XY will let you set the zoom level to whatever you want. O, I guess I forgot that Queries will zoom into a predefined zoom level too. I am sure there are more, but I won’t go any farther.
  

How do I Zoom thee? Let me count the ways...

I zoom thee to the depth and breadth and height

My data can reach, when feeling out of sight

For the ends of a View are an ideal time to Fit.

I zoom thee to the level of everyday's

Most queried need, by sun and laptop.


Thanks Elizabeth Barrett Browning

GTViewer 5.0.x.11 is Available

Version 5.0.x.11 of GTViewer is available.

-----------------------
05.00.00.11 - 02/15/06
-----------------------

- NEW - Addition Logging information for the Data Extraction process.

- FIX - The Extract Process was suffering problems when source files are very large .gtx files using Non-Graphic Framme Keys.

- CHG - The Coordinate Readout Pane in the status bar was widened.

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.

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.

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.

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.