Monday, September 12, 2005

The Data Monitor comes to GTViewer 5.0

GTViewer 5.0 includes the Data Monitor functionality provided in GTVx. For more information on the Data Monitor see the previous Blog posting: The Data Monitor in GTVx.

The Data Monitor provides a powerful set of tools for displaying geographically oriented data that is of a temporary nature. One might compare the Data Monitor items to Redlines (or session graphics), but the Data Monitor items are more for conveying information to the user at the moment rather that providing a mechanism for sharing and storing data. Lighting Strikes, Vehicle Tracking, and Outage Management are the example I provided in the previous posting.

The Data Monitor has been withheld from GTViewer in the past because it usually requires more coding than typical External Apps, and if you are going to be doing that much customization, GTVx is usually a better solution. However, the Data Monitor turns out to be very useful in very simple applications just as a means of presenting information to the user. For example, an application might read a file of ticket information and show the tickets at their geographical locations with all of their corresponding data as tooltips. Currently, the Data Monitor in GTViewer and GTVx are identical providing the same set of methods and events. The Data Monitor consists of around 50 methods to create, modify, and delete items. Five events are provided to know when items are clicked, double-clicked, and when tooltips are displayed and hidden.

The Data Monitor has been a very powerful too in GTVx for several years. Now, this power is part of GTViewer as well.

2 comments:

Larry Cosgrove said...

If I understand the Data Monitor correctly then the DM Items are held in memory as opposed to being written into the .gts file or anywhere else. If that is so, then what are the memory metrics? Is there anyway to determine how much memory each DM Item requires? At what point (how many displayed items) might it become impractical to use DM items as opposed to session graphics?

GTViewer - Joey Rogers said...

The DM (Data Monitor) items and SG (Session Graphic or Redline) items are very similar in many ways. Actually, both are held in memory while a session is active. One big difference is that the SG items also contain a spatial index (just like all other categories). SG items are no different from any other Category except they are in memory and the lock preventing the items from being modified is removed. Memory requirements for DM and SG items are very similar. The DM Bitmap item is roughly equivalent to an SG Symbol (this is because the bitmap image is loaded into memory just once and then rendered at each bitmap item’s location). Where the biggest difference in performance between DM and SG items will be seen is where the items are updated frequently, especially a large number of the items. For example, if we take the Vehicle Tracking example, every item may move at every update interval (and could be as often as every second). While you can move an SG item, it is a much more complicated process since not only the item itself is moved, but the spatial index is updated as well. Updating the spatial index for a few items is trivial, but updating hundreds or thousands every second will take a significant amount of processing that is not required by the DM. The same is true for deletions; when SG items are deleted, the spatial index must be updated as well. On the other hand, the SG category provides a much wider range of element types than can be placed, the items can be interactively or programmatically created and manipulated, the SG elements can do anything any other category’s elements’ support (style rules, rotation, scaling), the SG elements can be exported to other formats, shared as a .gtg file, and the SG elements are automatically stored and retrieved by the session. The DM items are really intended to be session based, their source information is external to the GTViewer data, they are not manipulated interactively (although they can be selected and deselected which could be used to delete them or move them and they could be placed using a point capture event), they provide tooltips, and they fire events when clicked, double-clicks, or hovered over with the cursor. They are short-lived (at most for the length of the session), they are not stored and retrieved automatically (because they are coming from some other data source anyway), and they meant for the display (however, they can also be printed).