Monday, December 17, 2007

Navigating the G/Tech Metadata with GTI’s Metadata Explorer (GTMetaExp) – Part 1

GTI has gained considerable experience with Intergraph’s G/Technology metadata through the development of our export tools that take GIS data out of Oracle and into the GTViewer format (which can then be used with GTViewer, Pocket GTViewer, and/or GTWeb). GTI’s G/Tech Exporter is now in its fourth generation and offers better support and flexibility for quickly and accurately getting graphic and tabular data out of a G/Tech database. The current incarnation of GTI’s G/Tech Exporter provides a full GUI interface, provides dynamic style and label rule evaluation, and automatically extracts style and symbology information. The Exporter is a heavy user of the G/Tech Metadata when exporting the GIS data, so it was a small leap for GTI to reuse some of this technology in a tool other than the Exporter, and the GTI Metadata Explorer was born.

As many people who deal with G/Tech data know, Toad has been the tool of choice for navigating the G/Tech metadata. The G/Tech metadata contains all of the information describing the GIS and ranges from the list of features and their components, relationships between features, Display Legend info, to symbology. By using Toad’s Schema Browser or by executing home brewed SQL scripts, you can find anything you want to know in the metadata. And while I love Toad (I really do) and all it can do, and fully agree that this method of exploring the metadata is significantly better than what you could do with SQL*Plus or any of the G/Tech utilities, Toad doesn’t know anything about the G/Tech metadata or how the many tables interrelate. It should also be pointed out that Toad shouldn’t know these relationships because it is a database administration and SQL development tool, not a metadata viewer.

It is easy to illustrate the complexity of the metadata just by posing a simple question: “What are the components of a Pole feature?”

First, you need to find the Feature Number for a Pole Feature:

select *
from g3e_feature
where g3e_username='Pole';

Then use the feature number (208) to find the pole feature’s components:

select * from g3e_featurecomponent a, g3e_component b
where a.g3e_fno=208 and a.g3e_cno=b.g3e_cno
order by a.g3e_ordinal;

And you still have to wade through the entire list attributes for the joined table results to get the information you need. If you want to see all of the attributes for one of the tabular components, then SQL gets even more complicated.

With the GTI Metadata Explorer, you simply navigate from Feature to Attribute. To find information out about a Pole, just select it in the feature list:

Clicking on a feature will display all of its component information:

If you want to know the attributes for one of the feature’s tabular component, click on the tabular component in the list.

If you have an attribute associated with a value list, click on the attribute and to get a list of the values.

All together this process looks like the following:

The GTI Metadata Explorer does much more than navigate through the Feature/Component relationships. Other features include the:

Feature to Style functionality which allows the user to navigate from a Legend, to a Features, to the Style Rules, to the Style and Symbology. This feature will be discussed in detail in a later posting, but here is a screenshot of the information it can provide:

Another feature the explorer provides is a set of Validation routines. The correctness of certain aspects of the metadata can be verified.

  • Style Rule, Label Rule, and Label Format validation routines are provided to test the correctness of the expressions used in the metadata rules. It turns out that there are quite a few mistakes in these expressions that G/Tech does not catch and these validation routines can quickly identify them.
  • Other validation routines can detect Unreachable Rules. It is common to see in G/Tech data a list of rules for a feature where one or more rules have the same conditional expression. Obviously, something is wrong with these style rules because the first rule with the expression will always trigger the associated style and the duplicate(s) will never be reached.
  • Legend Validation will analyze a legend’s hierarchical structure and verify that there is a leaf node for legend level of the legend. It is not uncommon to see 3 levels of grouping, but no features at the lowest node.
  • Geometry Property Validation will search for obvious problems in a geometry table’s attributes. Whether these problems come from bulk data conversion when migrating from classic Framme data or from some other process, it is not uncommon to have poorly constructed geometry records in a G/Tech database. This validation is not technically testing metadata correctness since it is examining each geometry record in the database, but it is a useful test none the less.
More detailed information about the validation routines will be in a later posting.

One of the more interesting features of the GTI Metadata Explorer is the Summary Report feature. This report allows the user to select a set of features from a particular legend, then create a summary report for those features that will tell the number of times each style rule and label rule are used for the current data. This report is ideal for testing the integrity of both your data and metadata. For example, if you have no retired poles in your data, but the summary report show that there are 500,000 poles using the Retired Pole symbology, you know there is a problem that should be investigated. The report will also provide a quick and easy view of the usage of your style and label rules which is not something you can do by simply querying the database with Toad.

This posting just gives a taste of what the GTI Metadata Explorer can do. More postings will be added later describing the features in more detail. The Explorer is currently a beta application, but if you would like to try it, please contact me (, and I will get you started in the beta program.

No comments: