Addressing multiple-scale output requirements

Addressing multiple-scale output requirements

Gary S. Miller
Director - Project Implementation,Analytical Surveys, Inc.
741 N. Grand Avenue, Waukesha, WI 53186

M. Todd Rhodes
Project Implementation Analyst, Analytical Surveys, Inc.
741 N. Grand Avenue, Waukesha, WI 53186

Introduction
As geospatial information systems have spread throughout the enterprise, an increasingly diverse user community has been born. These users have come to recognize the power of spatially integrated information. Concurrent with an expansion of needs associated with user community growth, the established user community has also increased its demands on geospatial systems. Much emphasis has been placed on supporting these expanded needs with more open data architecture, more standard computing platforms, friendlier user interfaces, and more robust application functionality. These GIS enhancements have positively and substantially addressed many system requirements.

The required ability of these systems to create a broadened range of optimized map displays and products is a similarly important requirement. It is, however, a requirement that cannot be addressed solely through software enhancement.

"The Map is only a Report"
Those of us who've been around the industry for a while have welcomed the expansion in users and user demands. Many GIS professionals have also preached that the most important components of the systems are the data and the applications. Statements like "the map is only a report", and "don't worry about the map, it's the data that's important" have been heard by most of us and spoken by some.

While those statements may be true, it's also true that a great deal of what GIS brings to the table is its ability to present information in map-form. Map displays and outputs can be quickly understood and communicated. The new user community has not simply been impressed by the power of spatial computing, they have also been captivated by the power of spatial information presentation.

The plane truth is that the ability to create clear, precise, appropriate, and aesthetically pleasing map displays and products is among the most fundamental of the attributes which separate a GIS from many other computing environments, but it does not come without some effort. In order to further understand this effort, let's ask a few questions.

GIS has the ability to generate map displays and products. Why should we dedicate any further thought to it?

Optimized map displays and products don't just happen. We design and develop GIS databases and applications to supply them.

This sounds like much ado about nothing. GIS and CADD systems have had the ability to create varying displays for years. Don't today's systems come with all the necessary abilities to take care of this detail?

Yes they do, if we understand our requirements and properly use the technology.

What do we need to understand?

For starters, scale and size dependencies, map display, and product use.

Scale and Size Dependencies
Design of symbology and annotation sizing is a component of all GIS physical data modeling efforts. A fundamental starting point in this process is considering the minimum readable size and also the maximum reasonable size for a given scale. This consideration needs to be applied to both symbology and annotation. Annotation sizing is somewhat easier to express, but the readability and reasonability limits are essentially the same for both annotation and symbology. Basically, assuming a "normal" reading environment, a minimum readable annotation (paper) size may be approximately .06" (1.5mm). Also assuming a "normal" reading environment, a maximum reasonable annotation size may be approximately .16" (4.0mm). Within some GIS environments, annotation size is expressed in paper unit sizes as described above, while in others it is specified in ground units. The table below presents the range of paper sizes above, in ground units at several common scales.

Table 1: Annotation Size Ranges

As you can see in the table above, it's relatively easy to select an annotation size that is appropriate for use at two scales where one scale is 2x, or even 2.5x the other. It is however, essentially impossible to select an annotation size that is appropriate for two scales where one is 4x the other. For instance, 12' annotation falls within the readable and reasonable limits for both 1":100' and 1":200' scales. There is no size, however, that is both readable and reasonable at 1"100' and 1":400'.

Given, this assessment of annotation size ranges, it is possible to specify a single annotation size for use at two scales, where one is double the other, but in cases where one scale is in excess of 2.5x the other, two separate annotation sizes will probably be required. Guidelines for symbology sizing are essentially the same as those described above for annotation.

Issues and Implications
Now that we've established some of the basics of scale and size dependencies, we can more comprehensively examine the full range of output product issues. For each output map product, the following items must be considered:

Use
Scale and Size
Content
Emphasis
Relative/Cartographic Positioning
Annotation Positioning
Annotation Frequency

Use
The most fundamental questions to be answered for each output product deal with their use.

Who will use the map product? Why will they use the map product? How will the map product be used? How often will the map product be used? Under what conditions will the map product be used?

Scale and Sizes
The output product scale and size, which together define the area covered by a map, will affect many other considerations and must be determined early.

Content
It is important to keep in mind that not all data is required on each map display or product. For example, a circuit map might not require the display of secondary facilities or services, and might require display of pole symbols, but not pole annotation. Or, it may require the display of pole symbols and a subset of the "standard" pole annotation.

Emphasis
Just as some data may be excluded from a map product, certain data may be most important to the use of a map product. It may be appropriate to take steps to emphasize certain data on a given map product. Steps of this nature might include using exaggerated size, color, shading, or a heavier "line weight" for some features.

Relative/Cartographic Positioning
During its design, much consideration is usually given to the positional accuracy of a GIS database. In the case of a utility GIS, this is true for both the planimetric and infrastructure data. What is sometimes not thoroughly understood are the implications that symbol size has on feature placement. For instance, the size of a pole or pad symbol is likely to be reflected in the distance those features are placed from other GIS features. The "re-sizing" of symbology for use on a different map product will often expose this problem. Depending upon the importance of optimized positioning at multiple scales, more complex feature symbology designs may be required.

Annotation Placement
Annotation placement is subject to similar scale optimization. That is, once re-sized, annotation which was appropriately placed at one scale, often appears too close or too distant from its associated feature, or may overstrike other features or annotation.

Annotation Frequency
Linear and polygonal feature annotation frequency is another specification issue which is output scale and size dependent. While point features generally have one occurrence of annotation per feature, map size and scale often impact the placement specifications for linear and polygonal feature annotation. The result of this dependency is that annotation placement optimized for one product, may be too often or too scarcely present on another product.

The Software Takes care of IT
Each of the leading GIS software products feature various mechanisms that address some of the issues described above. None, however, fully address the issues above in a purely automated manner.

For instance, the automated or semi-automated re-sizing of symbology and annotation is supported by nearly every system. Symbology positioning and annotation positioning and frequency modification, however, is not perfectly supported by any system. Similarly, every GIS software system allows for adjustment of content and emphasis for various displays and products, but no implementation of the software will achieve optimum results without first defining what the optimized results are.

The simple truth is that the relevant mechanisms within the software environments act as both tools and constraints that must be considered in the design of the physical data model.

Analysis of "Multi-Scale" Requirements
The only way to assure that multiple scale requirements are met by a geospatial system implementation is to include certain relevant issues within the requirements analysis and logical data model design prior to initiating the physical database design process. The first step in this process is the consideration of the support of map displays and products as system requirements in the same way that the support of applications and interfaces are considered as system requirements. This means that just as individual applications and interfaces must be identified as part of a requirements analysis effort, important map displays and products must be individually identified.

As with applications and interfaces, the examination of needs of the relevant user group must be accomplished first. As stated earlier, the relevant questions are who, why, how, when, and under what conditions will the map display or product be used.

Once these questions have been answered, a list of map displays and products can be developed. For each of map display and product, a scale and size must then be determined. Following that effort, the content of the map display and product must be considered. This process is most effectively done at a feature-by-feature, component-by-component level.

The use of a matrix where, features and components form the left column and map displays and products (with scale and size noted) form the top row. The intersecting cells of the matrix can then be used to note whether a particular feature component is required for each map display or product. In the case of symbols, initially noting simply whether it is required as a YES or NO may be sufficient. For annotation, however, it may be necessary to note the specific content requirement for each annotation string. For linear features, it may also be necessary to note the required or desired frequency of the annotation. A sample matrix is presented below as table 2.

Table 2: Component Display Requirement Matrix

The resultant matrix concisely presents the display requirements of each map product. The guidelines for symbology and annotation readability and reasonability, can then be applied to determine what specifications are appropriate for each feature component on each product. Some compromise of optimal specifications for each display or product may be appropriate at this time. Once this process is completed, a practical test of the displays and products is the next logical step. This can typically be accomplished within a CADD environment without benefit of full GIS functionality. The process for accomplishing this is to digitize a typical map area graphically differentiating between components to the same degree that the GIS would differentiate between components.

"Normal" CADD functionality can then be used to simulate the map displays and products required by the GIS. This process might involve changing display and plot scale, copying and resizing symbology and annotation, and editing certain annotation. Care must be taken to accomplish this effort without inadvertent symbol or annotation repositioning. The resultant displays and products can then be examined to determine to what extent they meet user requirements. This examination may point to requirements that were overlooked in the initial analysis or specifications that are unsuitable. In these situations, some modification to the display and product requirement matrix, and the sample displays and products may be merited Once the matrix and the samples have been edited, they will be extremely helpful in the physical data modeling effort and in the further development of specifications.

Conclusion
The ability to create optimized map displays and outputs is a critical requirement for an enterprise-wide geospatial system. This requirement may be more complex than it appears at first glance. The GIS software available today provides the basic ability to support multiple displays and products. Particularly, when it comes to varying scales, the best use of those abilities requires a detailed analysis of the relevant requirements. In order to avoid substantial additional cost and effort, this analysis must be accomplished prior to the physical database design, development, and construction.