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.