The GRC has developed a consistent series of digital data layers for implementation of this digital mapping program. The data is gathered from a variety of sources, including TIGER line files, MHTD existing layers, USGS 15 minute quadrangles, as well as additional information digitized by GRC staff members. Over 20 different layers comprise a final map. These include county, civil, park, and urban boundaries, road networks and their corresponding shields, hydrology, railroads, the Public Land Survey System, cultural features, and bridges.
This project, in order to meet the needs of MHTD, created a user interface, through the use of Arc Macro Language (AML). An extensive menu system allowed the user to create, edit, update, and plot county highway maps, utilizing the multi-layering of the database to meet the system's demands. The interface is divided between two options: county map creation, and county map edit/update.
The first menu that the user sees is an inventory of the digital layers. As this is an Arcplot session, the user is allowed to display any or all of the available layers, as well as perform particular functions such as panning and zooming, even though a map composition is not yet created. If a final map is desired for output, the next option is to move to the plot menu.
The plot menu is designed to move the display into a map composition, and allow the user to put all the finishing touches on the map. After being prompted for the size and the scale of the map, a new menu appears. This menu gives the user the option of displaying the title, subtitle, map maker, scale bars, distance markers, legend, north arrow, key locator map, and the revision box. The option is also given to use map composition tools to fine tune the product.
Output for these maps was originally produced on a Calcomp plotter at both the GRC and MHTD. Future maps are to be plotted on a HP 750 Designjet, with the possibility of postscript files.
The county map creation, in the future, will allow MHTD to create and define custom maps. This would include combining two or more counties to make a regional map. Another probable option would be the ability to drop different coverages onto these maps.
The first menu lets the user choose which coverage to use as the edit coverage, and which ones to use as backcoverages. After the choices are made, the master edit menu is displayed. From this menu, one can perform almost any arcedit function, with the most employed being in button format. Commands involving selecting, attributing, and adding are among the most prevalent.
This menu includes a few noteworthy options. One such option is the ability the user has to 'hide' or 'show' what is going to be on the final map. By doing this, the features are attributed so that they will appear only if the user desires. This is useful because the standard county map, while complete, cannot possibly contain each layer without causing a large amount of clutter. Examples of this include locations where many roads or railroads overlap one another, or locations where the PLSS lines are not actually shown on the final map. By using the hide option, certain features can be hidden from view for the final plot, but still remain intact in the database. This option includes the ability to hide arcs, labels, and annotation.
Another useful feature is the ability to view arcs and labels symbolized, as they would appear in Arcplot. While this is included in the normal functionality of Arcedit, additional AML programs were constructed to allow the user to zoom and pan, keeping the scale of the symbols. This becomes particularly useful when placing and rotating cultural features and road shields, so that they appear as they would on the final map.
When does the product functionality stop and the preference of the user begin? In the interest of making a menu functional, the user needs to be comfortable with the options that are available. What the project calls for, and what the user wants,can be two different agendas. In designing a menu, it must be both functionable from a programming standpoint and easy to navigate for the end user.
Does product performance matter? It is a foregone conclusion of programming that a given segment of code be robust. That is, it must be both efficient and somewhat crash-proof. As with any program, these menus should not crash, and if they do, the reason can be established. Efficiency, on the other hand, may be an issue. Since the overall code in an AML program pales in comparison to ArcInfo and the operating system code, the performance of the AML rarely does become an issue. Delays more often than not occur because of system constraints, or other ARC functions which are called from within the AML.
Who benefits from this interface, and its databases? While the project called for a specific product, other uses can be inferred from this design. The databases are now documented as a small part in the Missouri Spatial Data Information Service (MSDIS), located in the GRC. These coverages are made available over the internet in digital format. Furthermore, the AML's and menus, as with any other, are now part of the GRC's library of useful items. Part of the benefit of AML is the ability to take written code, and implement it for your own menus. An AML does not be wholly original. Using code that is already written can be a time-saving and efficient means in writing new AML routines and menus.