Friday, April 28, 2006

The Reference Point GPS Feature in Pocket GTViewer

Even though it has been part of Pocket GTViewer since version 3.0.x.20, one of the lesser known features of Pocket GTViewer is the Reference Point. The Reference Point provides a very simple function; it allows you to place a fixed point in your map view and a special arrow on the GPS indicator will always point toward the Reference Point.

The Reference Point is found under Menu/Options/Reference Point and presents a dialog like the following:




The Reference Point dialog provides 2 ways to place a Reference Point in your map. The Place Button allows you to interactively place the Reference Point by tapping a point in the map view. The At GPS Point button (which is only enabled when the GPS is tracking) will place the reference point at the current GPS position. Two more options are available to provide more information while the GPS is tracking with a Reference Point. Show Path will draw a dashed line between the GPS indicator and the reference point. This line is sometimes more informative than just an arrow pointing in the direction of the Reference Point. The Show Info option will cause the Distance and Bearing from the GPS Indicator to the Reference Point to both display at the top of the map view. The following screenshots show the Reference Point with the Show Path and Show Info options enabled as well as the Decaying GPS trail. The GPS indicator will use a Blue Arrow head to point to the Reference Point while a Red Arrow head indicators the current heading.










The following screenshot show the Reference Point arrow on the GPS indicator without the Path:



There are also several other options available for the Reference Point. In the .GTM file, you can add several entries to the Additional Properties section to control certain aspects of the Reference Point.

RPCol can be used to specify the color for the Reference Point. The default is Blue. Color is specified as a RGB component color value.

RPStyle can be used to specify the line style id used for the line connecting the GPS Reference Point to the GPS cursor. The value can be 0 to 7. The default is 2 (dashed).

RPWeight can be used to specify the weight of the line connecting the GPS Reference Point to the GPS cursor. The value can be 0 to 15. The default is 2.

RPPos can be used to specify the location of the default position of the Reference Point, such as your home office, etc.

RPProp is can be used to specify the default options (Show Path and Show Info).

The Reference Point can also be controlled via the Developer’s Framework and the Reference Points current location is always available to external applications.

Tuesday, April 25, 2006

GTViewer 5.0.x.17 is Available



Version 5.0.x.17 of GTViewer is available.

-----------------------
05.00.00.17 - 04/25/06
-----------------------

- NEW - Log File message has been added for Query locates when a category id is not valid.


- FIX - The Style Manager's import style definition's ignore if already exists option was not working. It was not ignoring style definitions that did not already exists.

- NEW - Location based details can now overlap existing geographic data. All categories except the detail categories will now be automatically turned off when a detail is located.

- NEW - Queries to items in Detail files will automatically turn off all categories except the detail categories when the features is located.

Thursday, April 20, 2006

Ten Sail Consulting Smallworld Symposium




April 26-27 in Tampa immediately following GITA's Annual Conference.

Symposium - Program of Events

Keynote Abstract - The Role of Mobile GIS in the Wake of Hurricanes Katrina and Rita at Entergy
Robert "skip" Dearie, Entergy Corporation
In 2005 New Orleans experienced one of the worst natural disasters in the history of the United States – the severe flooding that occurred in the wake of Hurricane Katrina. Within a month, Hurricane Rita struck other portions of Entergy’s service territory, resulting in more widespread outages and flooding. With Entergy’s corporate headquarters shut down and many of Entergy’s regional offices out of power for a significant period of time, Entergy’s mobile GIS system was the only source of network information for many restoration crews from all over the United States. This presentation discusses the severity of the damage caused by Hurricanes Katrina and Rita and the vital role that Entergy’s mobile GIS played in the restoration effort


Panel Discussion - Going Mobile
Matt Shellenberger (AEP), Jon Taylor (JEA), John Wakefield (Washington Gas), Ron York (Duke Energy)
Ten Sails Consulting and a panel of expert mobile GIS technology users discuss current system capabilities and real-world implementation experiences with systems from GTi, GSIWorks, MapFrame, and Tensing. This session will include short presentations from the panel members followed by an interactive "open mic" session to answer questions from the audience.

Thursday, April 06, 2006

Sessions 103 - the Evolution Continues

As with most of the really nice features in GTViewer, their inspiration came from customer requests. The session management in GTViewer has continued to evolve over the life of the product and with the latest enhancement (requested by a customer), an even better approach can now be taken with session management. There have been two posting on Sessions in the last few months. Sessions 101 discussed the basics of session management and Sessions 102 discussed a new feature. This posting, Sessions 103, is a further extension to the new feature discussed in the Sessions 102.

The ExternalSessionsOnly flag (in the Additional Properties section of the .GTM file) was added in GTViewer 5.0.x.10. When set to 1, it prevented any user from accessing the internal session of a .GTX file. While using external sessions with a .GTX file was not new, there was previously nothing to prevent a user from using it, and the default file opening mechanism was geared to run in the internal session mode. Thus, this one flag ensured that no internal sessions would be used. Remember that there is nothing wrong with using the internal session in a .GTX file in single user mode, but multiple users sharing the same .gtx file must use external sessions. Also, keeping the session separate from the .gtx file means that the .gtx file can be replace without worrying about exporting any redlines from the .gtx before updating it.

While the ExternalSessionsOnly=1 setting streamlined session management in GTViewer and prevented users from intentionally or accidentally using the internal session in a .gtx file, it still left some of the session management responsibilities up to the users. If the user opened a .gtx file, did some work, then existed; GTViewer would ask for a location to save the session. Then it was the user’s responsibility to use the session he or she created the next time around.

It turns out that a common workflow is to have users always use the same session, even if the parent .gtx file is updated. So, having the users specify the name and location of the session file and remember to use the session file they created instead of the .gtx file is a unit of work that can now be eliminated by using ExternalSessionsOnly=2. This new option will default the name of the session file to be the same name as the .GTX file (except for the .gts extension) in the same directory. If a user opens a .gtx file with this ExternalSessionsOnly set to 2, GTViewer will first check to see if a session of the same name exists. If the session does exist, it will be opened instead of the .gtx file. If the session file does not exist, the name of the session file is automatically assigned the same name and path as the .gtx file (only with a .gts extension) and will be saved when the .gtx file is exited or explicitly saved. Thus, the session management responsibilities can now be removed from your users completely if your workflow fits within these confines. There are many users who keep several different sessions for a single .gtx file and this option is not appropriate for those users (the ExternalSessionsOnly=1 might be a more flexible option for them).

The ExternalSessionsOnly=2 option will also work with .GTM files. There is not internal session in a .GTM file, but the automatic naming of the session and checking to see if a session of the same name exists and opening it instead of the .GTM file can still be useful for removing session management responsibilities.

GTViewer 5.0.x.16 is Available



Version 5.0.x.16 of GTViewer is available.

-----------------------
05.00.00.16 - 04/06/06
-----------------------

- FIX - The Address Query was not zooming to the desired Query Zoom for specific address values.

- NEW - ExternalSessionsOnly entry in the Additional Properties section can now be set to 2 which creates a default session when opening a .gtx or .gtm file to be a file of the same name (only with a .GTS extension). If this mode is used in a .gtx or .gtm, opening the .gtx or .gtm will first check for the existence of the .gts of the same name and open it first.

- NEW - The Print to Scale command will now zoom out automatically if the cookie-cutter is larger than the view. This automatic operation prevents the need to manually zoom out when the cookie-cutter is too large to fit in the current view.

Wednesday, April 05, 2006

GTVx 5.0.x.6 is Available



Version 5.0.x.6 of GTVx is available.

-----------------------
05.00.00.06 - 04/05/06
-----------------------

- FIX - When showing more than one Preview image in the Attribute Info Dialog, tabbing between the preview images did not update the image unless you tabbed to a different type of tab.

- CHG - If a group element has an invalid complex flag, it will now draw as a regular group.

- NEW - CountFeatureSummary and CountFeatureDetails now support Shape with Holes Element as the the selected polygon.

- CHG - Selected element used with CountFeatureSummary and CountFeatureDetails is not reset after the methods are run.

- NEW - Feature Counting now supports Shape with Holes elements, closed linestrings, and groups with connected sub-elements as the selected polygon.

- FIX - CountFeatureSummary sometimes returned a bogus length for point features when the length should always be 0.

- FIX - Locate Address now behaves the same as it does in GTViewer. If a fit of the feature is less than the query's zoom level, it will use the query zoom level.

- NEW - ExternalSessionsOnly entry in the Additional Properties section can now be set to 2 which creates a default session when opening a .gtx or .gtm file to be a file of the same name (only with a .GTS extension). If this mode is used in a .gtx or .gtm, opening the .gtx or .gtm will first check for the existence of the .gts of the same name and open it first.

-----------------------
05.00.00.05 - 03/15/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.

- FIX - Right Mouse Feature selection (for Attribute Info) was not filtering out features whose category was turned off by thresholds.

- FIX - Saving Character to .GTS session files with 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.

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

- NEW - New Methods:

long ElementGetPartCount(long id);

Sunday, April 02, 2006

Using Wildcards in Queries

The GTViewer family of products (GTViewer, Pocket GTViewer, GTVx, and GTWeb) has always provided support for Wildcards (*) in queries. Wildcards allow you to only enter part of the value you are searching far and give you more flexibility when performing a query.

By default, all queries perform a “Begins With” search. If you enter the first part of a value you are searching for, the query will return all records that begin with the value you entered. There are, however, several modes you can use when searching: Begins With, Ends With, Contains, and Exact Match. To illustrate these different search modes, each mode will be described below.

Let us say you are looking for records with the value: 123456789

You could enter just 1234 in the query prompt. Since a “Begins With” search is the default, you do not have to add the Wildcard at the end of the prompt value, but 1234* is the equivalent search string and both it and 1234 will return all records whose values begin with 1234 such as 123456789, 123400000, 12345555, 1234, etc.

You can also perform an “Ends With” search by placing the wildcard at the beginning, such as *6789 which will return 123456789 but also all records that end with 6789 such as 0006789, 111116789, 6789, etc.

The “Contains” search is a combination of the “Begins With” and the “Ends With” search modes. This mode is specified by placing a Wildcard at the beginning and end of the prompt value. So, if you specify *456*, you will get all records that contain 456 in their value such as 123456789, 111456111, 456, 456789, 123456, etc.

Lastly, the “Exact Match” search method is a way to get around the default "Begins With" search if that is not what you want. By specifying a tick mark at the beginning and end of a prompt value, such as '123456789', you will only get records returned that have a value of 123456789.

To summarize these modes, the following list shows how to specify the different search modes. The xxxx is the text you enter for the prompt:

xxxx automatically does a begins with
xxxx* begins with (same as default)
*xxxx ends with
*xxxx* contains
'xxxx' exact match

GTViewer 5.0.x.15 is Available



Version 5.0.x.15 of GTViewer is available.

-----------------------
05.00.00.15 - 03/29/06
-----------------------

- FIX - When showing more than one Preview image in the Attribute Info Dialog, tabbing between the preview images did not update the image unless you tabbed to a different type of tab.

- CHG - If a group element has an invalid complex flag, it will now draw as a regular group.

- NEW - Feature Counting now supports Shape with Holes elements, closed linestrings, and groups with connected sub-elements as the selected polygon.


-----------------------
05.00.00.14 - 03/20/06
-----------------------

- FIX - Minor fix to Attribute Info on very large .gtx files. It would sometimes say that the index file could not be opened (with the .gtx file as the index file).

- FIX - Hyperlink items would sometimes not be correctly identified if the filename had numbers in it.


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

Tuesday, February 28, 2006

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.

Friday, February 24, 2006

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.