Why didn’t I just leave GNE as it was? I actually thought the previous version of GNE was pretty good. It edited networks quite nicely and did a fine job of displaying and printing network data. But I was irritated with the old GNE because of its use of DOS “8.3” file names. Unfortunately, it was impossible to upgrade the filenames with Borland Pascal, the compiler I had been using. It was necessary to find a different compiler. Delphi 3 seemed the natural choice. It used the same dialect of Pascal, and I had previously used it to update QRS II. To my dismay, I could not salvage any of the visual aspects of GNE. GNE had something like 60 different dialog boxes, many buttons, an extensive main menu, and the Sketch Pad. Just getting back to what I had before would be a huge undertaking.
I couldn’t face the chore unless I could somehow make it fun. I started listing all the requests for new features I had heard from users and started listing all the features of Delphi 3 that might lead to something interesting. Delphi 3 had obvious features that could be immediately helpful: hints, a good implementation of a multidocument interface (MDI), and tool bars. That got me started. As I worked with the partially finished code I slowly discovered other, less obvious, ways that Delphi 3 could make GNE even better. By the end of last summer I hadn’t yet exhausted everything in Delphi 3 and Delphi 4 was available, but it was time to freeze the DTA file format and start beta testing.
I have published three papers about GNE and in the last one I made two rash statements about GNE’s internal data structure: that it can be as versatile as a GIS and that it can support rather advanced network algorithms. While these statements may be theoretically true, neither had been demonstrated in a tangible way. Therefore, I decided to improve upon GNE’s GIS-like capabilities by adding link shape points and a variety of background graphics. In addition, I implemented the mark shortest path feature to demonstrate how path building could be quickly accomplished. The whole path building algorithm, which does a variety of tasks, occupies only about 90 lines of code. It also executes quickly, considering that the distance criterion for links is evaluated from a text expression on the fly.
I personally have had the most fun with “views”. The concept of a view had its origin in MDI. MDI is the part of Windows API that allows several active “child” windows to be contained within a single “parent” window. Lots of popular software products use it. I originally wanted GNE to just be able to display more than one network simultaneously, but the networks would be entirely independent of each other. Networks could exchange small amounts of data through the clipboard, but that was it. Observing users at work, I noticed that their real desire was to display different characteristics of the same network, a task easily accomplished with the old GNE. However, with the old GNE, multiple networks could become inconsistent with each other as editing operations progressed. Thus, I needed some method for two different Sketch Pads to display the same network data but in different ways.
The key to making this all work was pointers. If you are familiar with programming you remember that a pointer is a memory address of a data structure. Network data are stored in just three data structures (nodes and links together, system attributes, delete stack) and the application schema is stored in just three data structures (node definition, link definition, system definition). Thus, everything really important about a network is stored in structures that can be referred to by just six pointers (only 24 bytes).
Each Sketch Pad is a separate object. This object contains all the mechanics of editing and display, a main menu, scroll bars, all the things that affect the look of the network, Extract/Update specifications, a Calculate program, a few other things, and the six pointers to the network. When the user creates a view of an existing network, GNE first creates a new Sketch Pad and initializes all of its properties to match the original network, but GNE does not copy the network data. Rather it sets the Sketch Pad’s data structure pointers to the values of their respective pointers on the original network. Both Sketch Pads (the original and the view) think that they exclusively own the same network data, and each has the power to change the data without permission.
There are many obvious implications of this arrangement and many less obvious implications. Among the obvious implications is the ability to edit the network on one view while seeing the results on another view. Less obvious implications relate to some of the items on the Tools menu. For example, it would be possible to create an Extract specification on one view and an Update specification on another view – thereby allowing the network to exchange data with itself. It would be possible to create two separate Calculate programs that work together in some fashion. It would be possible to create different sets of link width expressions on three views, one to display widths, another to display labels as functions of link attributes, and a third to be a measure of link distance in a shortest path building. The possibilities are limitless.
Finally, it is possible to have one view underlay another (and another, and another … ). By underlaying views users can create displays that would be impossible from a single Sketch Pad. For example, a user could place as many as eight distinct labels on a single node or link. Or the number of JPEG or metafile images could be expanded indefinitely.
I would encourage you to try out the views. If you currently own GNE 6.0, you can immediately use views to improve your networks and increase your productivity. If you do not own GNE 6.0, you should download the demo editions of it and QRS II 5.1 from this web site.