Friday, March 31, 2006

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.


Tuesday, March 28, 2006

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.

Friday, March 24, 2006

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.

Wednesday, March 22, 2006

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.

Wednesday, March 15, 2006

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);

Wednesday, March 08, 2006

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