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.
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.
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.
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.
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.
Optimizing the route reduces the estimated travel time to 16 minutes (almost half the original) and a travel distance of 6.9 miles.
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.
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.
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).
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.
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.
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.
Also, for more information, see Printing with Custom Overview Maps in GTViewer to see what else can be done with printing in GTViewer.
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.
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.
For the ends of a View are an ideal time to Fit.
Most queried need, by sun and laptop.
Version 5.0.x.11 of GTViewer is available.
- 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.
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.
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).
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.
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.
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.
- FIX - Shape With Hole Elements (Donuts) were not converted correctly. Internal polygons were not being closed.
- 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.
- 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.
- NEW - The Destination Dataset attributes are used to filter the attributes written to the output feature tables. Previously, all available attributes were written.
- 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.