This paper builds on a body of European research on multiple resolution data bases (MRDBs), defining a conceptual framework for managing tasks in a multi-scale mapping project. The framework establishes a workload incorporating task difficulty, time to complete a task, required level of expertise, required resources, etc. Project managers must balance the workload among tasks with lower and higher complexity to produce a high quality cartographic product on time and within budget. We argue for increased emphasis on the role of symbol design, which often carries a lower workload than multi-scale mapping based primarily on geometry change. Countering expectations that combining symbol change with geometry change will increase workloads, we argue that in many cases, integration of the two can reduce workloads overall. To demonstrate our points, we describe two case studies drawn from a recent multi-scale mapping and database building project for Ada County, Idaho. We extend the concept of workload balancing, demonstrating that insertion of Level of Detail (LoD) datasets at intermediate scales can further reduce the workload. Previous work proposing LoDs has not reported empirical assessment, and we encourage small and large mapping organizations to contribute to such an effort.
Introduction
Despite the dream of generating cartographic base maps spanning all display scales by using a single detailed database, reference mapping frequently continues to be conducted using multiple databases pre-compiled at standardized resolutions. This procedure makes it more difficult to create map products at a series of scales that reflect consistent symbolization and generalization strategies. It also complicates production workflow (the sequence of tasks required to create a product) as well as production workload (the amount of labor, time, and skill). Moreover, supporting map products at display scales that differ from those suited to compiled database resolutions often requires deriving some layers at intermediate map scales, creating specialized in-house product databases, and maintaining multiple resolution cartographic databases. Changes in symbol design and elimination of feature types support mapping through a range of scales, and this paper is about planning for the interaction of these display changes with geometry changes for complete multi-scale mapping.
Final cartographic products often are designed for a specific print media or display scale. In contrast, data contributing to these products may have been compiled at a resolution commensurate with mapping across a wide range of scales. For example, national mapping agencies (NMAs) by convention compile data at resolutions (called “anchors” in this paper) suited to a series of standard mapping scales. NMA anchor data support a large proportion of mapping data used in many GIS applications. The availability of anchor compilations and of national map products varies from one NMA to another (Table 1).
Table 1
Examples of scales used by national mapping agencies, comparing resolutions of anchor databases and corresponding scales of derived topographic database and/or map products
Footprint
Anchor Compilations
Derived data and map products
Spain (Catalonia example)
5
5, 10, 25
50
50, 100
250
250
Denmark
10
10, 25, 50
100
100, 250, 1000
France
10
25, 50
50
100, 120, 250, 500, 1000
Germany
10
10, 25, 50, 100
250
250, 500
1000
1000
Great Britain
1.25, 2.5, 10
10, 25, 50, 250
Sweden
10
10, 50, 100, 250, 1000
Switzerland
25
25, 50, 100
200
200, 500, 1000
United States
24
24
100
100, 250
2000
2000
For simplicity, we are referring to the anchor data and derived products in terms of scale. Scale numbers are denominators of representative fractions in thousands (for example, ‘25’ indicates 1:25,000). The table (except the U.S. summary) is derived from Stoter’s 2005 summary [22].
Anzeige
The number of anchor compilations and the compilation resolutions reflect several considerations, and these will have differing impacts on an organization’s workload. One factor is the size of the geographic footprint to be mapped. Countries such as Great Britain produce anchor compilations no smaller than 1:10,000. Larger footprints, such as Germany, require a smallest anchor scale of 1:1,000,000. The U.S. Geological Survey (USGS) maps a very large geographic footprint and consequently produces topographic data anchors out to 1:2,000,000 [24].
Another factor affecting the choice of anchors relates to data production and maintenance policies and procedures in place at an agency [22]. For example, Great Britain’s Ordinance Survey maintains a single, variable resolution anchor database containing features compiled at 1:1,250; 1:2,500; and 1:10,000. Compilation resolution varies for urban and rural features, for example. In contrast, Switzerland’s national mapping agency, swisstopo, maintains two anchors with fixed resolution compiled at 1:25,000 and 1:200,000.
A third factor relates also to work practice, specifically to how database and map product updates are coordinated; and the various mapping agencies show great diversity. For example, the ICC national mapping agency in Catalonia, Spain maintains four anchor databases. One of these (1:25,000) is derived by generalizing another (1:5,000); however the two anchors are updated separately. In Denmark, the national mapping agency KMS updates its 1:10,000 anchor data every five years, and its 1:100,000 anchor data every six years. The USGS updates portions of all three anchors by focusing on fast-changing (urbanized) areas at all scales, rather than updating an entire anchor all at once. Map tiles in some areas of the country are updated every few years, while other updates occur every few decades. Over time, one should expect that anchors updated independently will begin to diverge in content, geometry and spatial relationships [22].
In this paper we will apply the term scale to map products and resolution to databases following conventions in database research [17]. Readers unfamiliar with cartographic terminology describing common generalization operations should refer to [13, 18, 19]. Cartographic symbol designs change for map products intended for smaller scales. The resolution or granularity of features in an anchor compilation is altered by data modeling and feature generalization to modify the amount of detail. The complexities of creating multiple scales of map products from a series of anchors compiled at diverse resolutions raises significant challenges to implement procedures that link feature representations across database versions. Another challenge is to maintain representational consistency across map products, in accord with standardized or semi-standardized graphical ontologies in use at federal, regional, and local mapping houses. It is also important to maintain database consistency during feature updates. Map and database maintenance and update operations present NMAs with a host of compelling problems for which there remains no single solution [18: p.24], and these problems can complicate workflows. As a consequence, multi-scale discussions have transformed into multi-resolution and multi-representation discussions. Multi-Representation Data Base (MRDB) is the emergent label applied to databases designed for multi-scale mapping [14, 18, 21]. Examples of MRDB projects include ATKIS [1] and GiMoDig [12] and are described for countries throughout Europe [2, 7, 23, 26].
Anzeige
Some MRDB strategies derive an intermediate-scale, product-specific database called a Digital Cartographic Model (DCM) [11] that contains a complete version of data, generalized for appropriate display at a specific mapping scale and containing cartographic symbology as well as feature descriptions and attribution.
Another MRDB strategy is nicknamed a “Level of Detail” database (LoD). These databases contain subsets of database layers, for example, hydrographic channels generalized as line features. LoDs are preprocessed to support mapping at intermediate resolutions when feature generalization requires intensive computation (e.g., derivation of contours), when a high degree of cartographic expertise is needed (e.g., label placement, feature displacement), or for features whose map appearance or database geometry is quite sensitive to scale change (e.g., terrain or hydrography). The LoD concept is discussed by several authors (e.g., [9, 10, 15, 16, 27]), and it was presaged by Timpf and Frank [25]. Neither DCMs nor LoDs may be as complete or as accurate as Digital Landscape Models (DLMs), which contain data as captured but do not carry cartographic symbology [14].
The LoD purpose is to speed mapping and reduce map production workloads through all map scales. An effective LoD should support products across a range of mapping scales, and the magnitude of the range will depend on the data domain (Table 2). For example, an LoD for terrain contours or for hydrography will likely span a smaller scale range than an LoD for transportation, simply because naturally occurring features tend to be more sensitive to scale change than roads and railroads which are built to standard engineering specifications.
Table 2
Relative magnitudes and usable scale ranges for a hypothetical set of LoD layers
Data domain
Largest to smallest scales
Magnitude of scale support
Usable scale range
Terrain and hydrography
1:30,000–1:60,000
~2x
30,000
1:250,000–1:500,000
250,000
1:1,000,000–1:2,000,000
1,000,000
Transportation and buildings
1:30,000–1:150,000
~4x-5x
120,000
Thematic layers (vegetation, soils)
1:30,000–1:300,000
~4x-10x
270,000
The scale support column summarizes the amount of change for which mapping in each domain holds up well. For example, human layers such as transportation and buildings can be reduced four or five times from their compilation scale and support readable mapping.
The automated production of a series of LoDs from national datasets facilitates varied new modes of representation. These new modalities include PDAs and other mobile devices, in-car navigation, and on-demand web mapping [5, 16, 19, 20]. Technical challenges thus become adaptive zooming, variable scale mapping, and on-demand or on-the-fly production of acceptable graphic displays, rather than high-precision printed maps.
This paper defines a model for managing tasks in a multi-scale mapping project. The framework establishes a workload incorporating task difficulty, time to complete a task, and required level of expertise. We argue that the attention paid to data modeling and generalization in a majority of published MRDB solutions neglects the fact that in many situations, mapping at multiple scales can proceed effectively using display changes either by themselves or in conjunction with generalization. From a workload standpoint, symbol modification is often less intensive than is modifying data geometry. Countering expectations that combining symbol change with geometry change will increase workloads, we argue that in many cases, integration of the two can reduce workloads overall. To demonstrate our points, we describe two case studies drawn from a recent multi-scale mapping and database building project for Ada County, Idaho. We extend the concept of workload balancing, demonstrating that insertion of LoD data at intermediate scales can further reduce the workload.
We agree with the widely held opinion that tasks involving manual intervention will customarily carry a higher workload than automation. Tasks also differ in level of difficulty. For the sake of argument, we assign three levels of difficulty to any (manual or automated) task. One can think of the levels based on several parameters, for example, length of time to complete the task; level of required skill to implement manually or to code for automated change; or the challenge to integrate the changes into an existing map product design. Project managers must balance the workload among tasks with lower or higher difficulty to produce a high quality product on time and within budget. This is at once a mix of prioritizing, optimizing, integrating, and minimizing. We utilize the term workload balancing to emphasize that each criterion in the mix must be balanced against the others, throughout the range of resolutions for which products must be produced.
Our paper demonstrates how to incorporate display change into workload balancing. We argue that symbol change can balance or reduce overall workloads for multi-resolution cartographic data modeling, and we have not seen this finding reported by other researchers to date. In the next section we propose a general model of workload balancing, discussing how changes to display and geometry interact across mapping scales. We justify our position using empiric examples from a recent project to create a database in support of multi-scale, multi-purpose mapping for Ada County, Idaho [3, 4]. To set a problem-centered context for our discussion, we begin with one of these examples.
Case study one: balancing display and geometry change
Decisions about modifying data from its anchor resolution (i.e., compiled resolution) to make maps at other scales can involve display and/or geometry changes, each of which impacts the production workload. The workload may consist of applying data modeling algorithms, simplifying coordinates, and other forms of geometry modification. The workload may also involve symbol redesign, application of different style sets, or hand-editing symbol shapes and styles.
Modifications to feature geometry may include:
Resampling geometry (e.g., DEM resampling for smoother relief shading)
Interpolating new isolines from a DEM (e.g., changing from a 3m to 20m contour interval)
Changing dimensionality (e.g., collapsing building footprints to point features)
Simplifying lines (e.g., reducing coordinates along an intricate coastline)
Summarizing many small features with a larger areal feature (e.g., aggregating many small ponds to create a ‘wetland area’ polygon)
Removing features below a size threshold from the database (e.g., islands less than one square mile in area are eliminated).
Modifications to feature display may include:
Changing colors for fills and lines to those over which type is readable
Increasing the spacing in a boundary dash pattern to reveal underlying roads
Changing marker symbols’ size, shape, hue, and lightness so they do not obstruct adjacent features
Adding line casings to allow labels to be placed inside road areas with no road fill color.
Removing polygon outlines on a small-scale map so lines do not obscure small polygon fills
Changing drawing order (e.g., moving boundaries below roads)
Replacing features with labels (e.g., positioning building names at building locations but not symbolizing buildings)
Eliminating classes of features (e.g., eliminate all local roads from the map by specifying no road symbol while the features remain in the database).
Figure 1a shows a small map layout derived from the Ada County Idaho database at 1:5K, and 1b shows an unedited reduction to 1:15K. The map area includes a portion of a housing development, two large buildings, small water bodies, and a stream. Features in Fig. 1b are reduced in size but line symbols are not. For example, the 3-point line weight used for roads remains at a width of 3 points in 1b.
Fig. 1
Map of a housing development at 5K a and reduced to 15K b
×
Figure 2 shows three 1:15K versions of Fig. 1b with different mapmaking solutions that preserve readability after reducing the scale of the map. Figure 2a shows adjustments to only display aspects of the map, Fig. 2b shows geometry changes, and 2c combines both geometry and scale changes. Example display changes are making lines thinner and removing outlines to reduce clutter. Geometry changes include collapsing areal features to lines, eliminating features based on size and local density (removing isolated buildings that are not part of a housing cluster), aggregating building clusters to an areal feature, displacing adjacent features, and simplifying shapes. The geometry changes in Fig. 2b include a small amount of design work because the housing area fill color was also set.
Fig. 2
Redesign of Fig. 1 map for 15K is shown with display changes only a, geometry changes b, and both display and geometry changes c. Specific changes are listed next to each map
×
Modifications may require increased levels of expertise, time, computing cycles, and thus cost; these are the consequences of scale change. Every change will require integration to sustain the visual hierarchy, and for some tasks, integration requirements may be intensive or extensive. In the case of feature displacement, shifting a feature in one layer may activate the need to adjust feature label positions, possibly for more than one feature layer. A resampled DEM may result in the need to regenerate contour lines, or displace transportation features.
Model of workload balancing
Our model assumes that data are produced at one or more specific compilation resolutions, anticipating the generation of varied general- or special-purpose products. The compiled data anchors the workload in the sense that it requires a minimum of work to create a product at the anchor’s mapping scale. The general form of this schematic is adapted from [8] (additionally reported in [7] and [9]), who used complexity on their vertical axis. We utilize the concept of workload instead of complexity, recognizing that workload tasks may differ for various modifications.
Our workload model distinguishes between workloads associated with modifying the display and the geometry. One could question whether display modification is possible in a commercial mapping house or national mapping agency where standardized legend designs are carefully regulated. Even where legend regulation is strict, scale changes often result in elimination of specific feature types and categories. An example is given of multi-scale mapping of transportation [26], where Dutch Topography Service spatial data codes (Tdn codes) for transportation features are tagged to specific mapping scales. As the scale is reduced, entire classes of features (paths, streets, secondary roads, and main roads) are successively dropped. This type of elimination modifies the display and not the database.
The workload balancing model is intended to guide project managers in planning staffing and resource needs, and project completion timeframes and horizons. To explain the model, we sketch generic workload curves with shapes that are not empirically verified. The conceptual model in Fig. 3 illustrates that mapmaking workloads increase for products generated at scales between anchor databases.
Fig. 3
Lines sketching the workload required for mapmaking through all scales using anchor databases compiled at selected resolutions
×
As with [9], units on both axes are ordinal. The horizontal axis represents the entire range of scales for which an organization creates map products. Squares represent anchor resolutions at which compiled databases are available. The vertical axis represents relative workload, including processing complexity, time, skill level, and tool sophistication (each increasing mapmaking cost). In this initial figure, we separate the workloads for modifying geometry (Fig. 3a) and for modifying the display (Fig. 3b).
Using these hypothetical curves, we argue that workload changes are asymmetrical between anchor compilations. Figure 3a demonstrates that mapmaking at scales near anchor database resolutions requires minimal adjustments to feature geometry. As map scales depart from the anchor data, the amount of adjustment increases, and the workload rises accordingly. Figure 3b demonstrates that a mapmaker may produce satisfactory map products at intervening scales by modifying map symbols only.
Workloads drop as map scale approaches any anchor compilation because databases are often used for mapmaking at scales larger than their intended resolution, but not much larger. The workload never drops to zero, even when mapping at an anchor scale: some generalization and/or symbol design will always take place. The dashed segments of the curve in 3b indicate that display change alone may not be sufficient to generate a satisfactory map at a map scale distant from anchor data at finer resolution, even with the possibility of drawing upon another anchor dataset at a coarser resolution.
A question that must be asked of the workload balancing concept (whether applied to geometry or display changes) is how to determine at what mapping scale to make changes. A recent project [3] demonstrates that such determination may be arrived at empirically. Mapping data compiled at USGS standard mapping scales were used to create reference maps for a range of scales (10K to 5M) crossing orders of magnitude with changes in map display using symbol modification and feature elimination.
When modifying both geometry and display to make maps at multiple scales, the workload for each category of change is reduced. We have sketched this workload reduction in Fig. 4, with hypothetical curves of similar shape but lower amplitude through the range of mapmaking scales. Figure 4a shows the amount of geometry modification (such as line simplification) is reduced when the display is also modified (such as by modifying line widths). Likewise, Fig. 4b shows that the amount of display modification is reduced when geometry is also adjusted. For example, road lines may need less adjustment in width if adjacent buildings are collapsed from areas to point features as scale decreases. Comparing Fig. 3 with Fig. 4, one sees that the display change curve is not dashed in Fig. 4b, to reflect that display changes through the whole scale range will be satisfactory when geometry is also adjusted.
Fig. 4
The workload amplitude may be reduced overall when display changes and geometry changes are applied in conjunction. a shows that fewer geometry changes are needed when display changes are also made during mapmaking at each scale. b shows that fewer display changes are needed when geometry changes are also made
×
The two workload curves from Fig. 4 are overlaid in Fig. 5a and integrated (summed) in Fig. 5b. In Fig. 5a, the peaks along the workload curve for geometry modification (thin black line) are more skewed than the curve for display modification (gray line) to suggest that as the intended production scale moves farther away from its finer resolution anchor compilation, geometry adjustments comprise a larger component of the workload. When both types of operations are involved at mapping scales adjacent to anchor resolutions, the proportions for display change and geometry are the same. For example, the workload required to generate a set of contours should be similar to the workload required to select and symbolize index contours.
Fig. 5
The thin line in 5a represents geometry changes and the gray line represents display changes (shown separately in Fig. 4). The line in 5b represents the total workload when modifying both geometry and display during mapmaking through all scales using existing databases. That is, the 5b line shows the sum of component workloads shown in 5a—the integrated workload
×
One would expect that the overall workload for display change combined with geometry change should be greater than the workload for either in isolation. We propose the paradox that this interaction is not borne out in practice. Instead, we argue that combining the two types of modification reduces workloads overall. In our model, the integrated workload is expected to be lower in amplitude than curves for either of these efforts on their own. Figure 6 overlays the curve from Fig. 5b on each individual workload curve shown in Fig. 3. We argue that when geometry and display changes are integrated, the two types of activity complement each other, in effect balancing the overall workload. For example, applying a thinner line weight or a smaller marker symbol size will in some cases obviate the need for feature displacement.
Fig. 6
The bold black line represents the integrated display and geometry workload. It is compared to the workloads for changing only geometry (line from Fig. 3a) or only display (line from 3b). The workload for geometry-only modification exceeds the integrated workload midway between scales and is less than the display/geometry workload near product scales a. The display-only workload always equals or exceeds the integrated workload b
×
Neither the display or geometry modifications described by the curves in the above figures include label placement. Map labeling is a time-consuming aspect of cartography. We propose that most labeling could be completed with a single fine-resolution database of place names and that workload decreases at smaller mapping scales (Fig. 7). Fewer types of features would be labeled, though more of each may be present within the map extent. More overlap between labels may also need to be resolved at smaller scales.
Fig. 7
Workload for labeling is reduced at smaller scales because fewer labels for fewer feature classes are usually involved. Databases of feature names for large-scale mapping may supply labels for a wide range of scales (represented by a single square on the horizontal scale axis). The labeling workload is not included in the workloads discussed in previous figures
×
Comparing workload magnitudes for case study one
The tasks listed in Fig. 2 vary in the amount of work required to carry them out and may be generally classed as easy, moderately difficult, and difficult. For example, changing a display by making a color change is easy, but adjusting colors and lines to produce the desired visual hierarchy among a set of new symbols is more difficult. Processing that changes the geometry of the data is of varying difficulty to use and some geometry changes require hand editing given current tool capabilities. For example, simplifying the angular shapes of buildings within one layer is easier than displacing streams to improve vertical integration between the hydrography and road layers. To ease comparison of mapmaking difficulty, we assign approximate units of difficulty to the tasks used to construct maps shown in Fig. 2. Easy tasks require one unit of work, where units are relative and approximate aggregates of the time, expertise, and processing demands of a task. Moderately difficult tasks are assigned two units of work and difficult tasks are assigned three. These workload units allow very rough summaries of mapmaking workloads.
Summary totals in Table 3 provide a sense of the workload reduction offered by mapmaking that combines display and geometry change. Display changes in Fig. 2a total to 10 workload units, and the geometry changes for 2b also total to 10 units. In contrast, the combination of display and geometry changes in Fig. 2c total to 6 workload units. All three design solutions are viable but the last one is less work because it has the most balanced workload.
Table 3
Workload comparison for display and geometry change
One might argue that modeling a different set of weights could result in a different workload estimation, and this is of course absolutely correct. Project managers will establish weighting strategies based on the types of products they generate, at specified mapping scales, depending on staffing levels and expertise and on the time available to complete production. In some situations, a manager may be short on staff but have a longer production timeline. In other projects, the purchase of a specialized type of equipment may be balanced against outsourcing one or more project tasks; and decoupling the tasks in terms of time, expertise, or processing needs can further refine the workload balancing model. This paper does not intend to standardize relative weights for specific display or geometry modifications, rather to demonstrate how the workload balancing model can systematically guide managers in deciding whether to modify display, geometry, or both.
Case study two: using an LoD in workload balancing
An example from the hydrography layer of the Ada County data demonstrates multiple changes to geometry and how an LoD might fit into the work of preparing a map at a smaller scale. Figure 8a shows a segment of the hydrography at 1:5K and Fig. 8b shows the generalization of the 1:5K data suited to preparing a map at 1:24K. Small text notes within Fig. 8a highlight example changes to the geometry made in producing Fig. 8b. Two nearby lines are merged into one representative line, a small island is eliminated from the database because of its size, a narrow pond is collapsed to a line, inlet details on a large island are simplified, and an island is displaced from the river edge.
Fig.8
Hydrography data is shown at three scales, 1:5K, 1:24K, and 1:40K. a presents original data at 1:5K. b is the LoD at 1:24K, created from the 1:5K data. c shows further simplification and aggregation of features from the 1:24K LoD for production of a map at 1:40K
×
The 1:24K LoD shown in Fig. 8b can support mapmaking for a range of scales with display changes alone. The LoD can also be generalized incrementally to support mapping at still smaller scales that require further change in geometry for readable maps. To demonstrate, further generalization of the 1:24K LoD is shown in Fig. 8c for mapmaking at 1:40K. For example, incremental generalization step from the 1:24K data to 1:40K mapping shows additional aggregation of adjacent small ponds into larger areas and simplification of lines throughout the map. Less work in geometry change is required to make the next map with the LoD already available. An LoD requires initial work to produce but, if it is well placed within the range of scales between anchor data resolutions, it allows additional geometric processing of low workload when making multiple maps of varied scales. Figure 9 shows the original 5K data at 1:40K to emphasize the overall amount of change these two generalization steps have produced.
Fig. 9
The 1:5K data shown at 1:40K with no geometry change. Compare this map to Fig. 8c to see the many changes to the database with incremental generalization. The white square outlines the area shown in Fig. 8a
×
Continued modeling of workload balance
LoDs are shown within our schematic scale/workload diagram in Fig. 10 using open squares between the existing databases (black squares). An LoD effectively provides an additional anchor database, possibly storing a subset of original data. The workload dips at LoD resolutions and the amplitude of the entire curve is reduced. One benefit of adding preprocessed LoDs to a mapmaking workflow would be reducing effort to levels that can be managed by a mapmaking group.
Fig. 10
LoDs store preprocessed geometry changes for intermediate scales between existing database resolutions. The preprocessing they offer reduces the workload for mapmaking at scales distant from initial anchor databases, reducing the workload for selected scale products. (For simplicity of explanation, the same reduction is shown between all LoDs though this benefit may vary through the scale range.)
×
For example, a small cartography company may not own high-end computers or sophisticated processing extensions to software, they may not know how to implement some geometric processing functions, or they may not have the time to iterate on parameter settings to optimize to a suitable generalization of the database. The mapmakers may not have permissions to change a database used for mapmaking, or they may not know how to use editing tools to customize a product at a particular map scale. They may also choose to hire a consultant to complete processing for which they do not have time or in-house skills, and this increases mapmaking costs (one aspect of workload). These are example limitations that affect real-world cartography. These limitations are summarized with the horizontal dashed line midway up the workload axis. The addition of LoDs damps down the cartographic production workload below this hypothetical threshold of skill and processing.
For the multi-scale mapping project with Ada County data ([4, 6]) we built draft-version LoDs for hydrography to suit mapping at scales of 20K and 80K. These LoDs replaced the original anchor data when maps reached the limits of readability during redesign using display changes only. We applied a limited set of operators, eliminating small disconnected stream segments, eliminating small ponds and islands, identifying complete centerline paths for braided stream channels, replacing thin stream channel polygons with linear features, simplifying linear features and polygon outlines, and correcting stream network connections.
We consider our LoDs as draft versions, since our generalization workflow did not include data modeling refinements such as amalgamating proximal polygons, resolving spatial conflicts by displacement, or re-establishing logical stream order sequences. Our intention was to demonstrate that geometry changes could extend the limits of readability while reducing overall workloads for map production at smaller scales. Insertion of the draft LoDs at the problematic mapping scales introduced coordinate geometry with an appropriate level of detail, thus obviating the need to further fine-tune line weights, color choices, and symbol outlines to reduce or obscure the visual noise of overly fine details in the anchor version. This effort balanced the symbol modification workload, facilitating the design of hydrographic symbols holding a logical degree of visual prominence in the figure-ground hierarchy.
We generalize results of our LoD exercise in Fig. 11. The figure shows workloads for mapmaking at two scales, a large-scale example (Y) and a smaller-scale example (Z). In U.S. mapping, these scales may differ by orders of magnitude. The X and Y examples are represented by vertical gray lines intersecting the workload curves, and they do not coincide with an anchor database resolution or a derived LoD. Working from LoD resolutions, however, reduces the workload (Fig. 11d) when compared to mapmaking by modifying geometry alone (10a), display characteristics alone (10b), or both (10c).
Fig. 11
Relative workloads for mapmaking at two scales (Y and Z) are highlighted. Example Y requires large changes in geometry alone a or larger changes in display alone b using the finer-resolution database for map production. Combining both display and geometry change reduces the overall workload c. Example Z, at a smaller scale, is positioned where workloads are very high for mapmaking with geometry change alone a and cannot be solved by display change alone (dashed line in b). Working from an LoD at a nearby resolution reduces the workload for both examples d
×
Discussion and concluding comments
This paper makes the case for anticipating and balancing workloads for multi-scale reference base mapping. It extends European research on cartographic workloads by incorporating changes to the map display (such as symbol redesign or modification) with changes to feature geometry that take place in both model generalization and in map generalization. The paper demonstrates two case studies that isolate workloads for display modification from workloads for changes to feature geometry. We propose that display change and geometry change should in practice complement each other, and reduce rather than amplify overall workloads.
To reflect geographic processes in multi-scale mapping, each change carries with it some ‘consequence’ for the mapmaking workload. Changes to feature geometry often require more effort (i.e., carry higher consequences) than changes to symbology. A worst-case scenario might interleave two data sets compiled at disparate scales, such as collating roads from a federal data source with on-ramps and clover-leaf ramps compiled from a state or local databases. In this scenario, the workflow might require a datum shift or projection change, reducing coordinate density, correcting conflation error among the data sources, matching discordant attribute domains, and all this prior to symbolization—clearly a significant consequence for cartographic workload. The cartographer’s goal is to modify the view on the data while preserving geographic logic and validity and producing a map product of suitable quality. In short, the ‘consequences’ of scale change will vary with the map purpose, map audience, modality of use, and available anchor databases.
We point to several gaps in the current work, specifically to tasks in cartographic production workload that are not addressed by our conceptual framework. First is the issue of automation. There is general agreement that the extent to which one can automate display and geometry modification is likely proportional to reducing work, overall. One must of course account for the time required to adopt an existing automation solution, in the form of training staff to utilize new software or in the form of changing production sequences. If automated solutions are developed in-house, this may incur a one-time workload increase, which must be balanced against the number of times such a solution will be invoked for any subsequent product development.
A second gap in our work relates to data updates, which should be incorporated into an operating workload balancing model particularly when such updates are frequent or numerous. Attribute updates have implications for display modifications, while feature updates are likely to mandate geometry changes. Introducing new products into an agency’s product portfolio could mandate creation of new LoDs or additional anchor compilations, creating major impacts on a workload balancing model. In fact, the framework we propose here could be used to study new product feasibility, to justify staffing additions or addition of new expertise into the labor pool. We do not discuss these implications in our present work, but encourage others to address them and report on their experiences.
A third aspect which is not incorporated into the models, but should be, relates to the workload associated with maintaining LoD versions of one or more data domains. It is obvious that adding data layers will increase database management workloads, and in the case of LoDs, the added data is slightly or wholly redundant, when it takes the form of simplified versions of anchor data. The manager’s decision will have to balance work required to establish unique identifiers, to link between multiple representations, and/or to propagate changes consistently through a database. These additions to the overall workload can be significant, changing not only the overall amount of work, but the shape of workload curves, at or near the scales where LoDs are derived (Fig. 10).
These three gaps (automation, updates and LoD maintenance workloads) do not diminish the utility of the workload balancing model described in this paper. Our work provides a proof-of-concept for the proposal by Swiss cartographers to create Level of Detail databases (LoDs) that contain subsets of data layers generalized to intermediate scales. Researchers [9] propose use of a small number of LoDs to obviate the need for computationally intensive scale-changing operations. In fact, the gaps underscore the need to minimize the number of LoDs generated and maintained in any very large database. For example, maintaining an additional one to three LoD feature versions inside a fully-operational database (consisting perhaps of 15 to 20 feature layers within 10 to 12 data domains) is trivial. The workload “cost” of updates and maintenance in this case is likely far less than the cost of generating intermediate-scale versions on the fly. As the number of LoDs increases, however, maintenance costs will begin to outweigh the benefits of pre-computed versions. Project managers must balance these considerations as they decide which strategy to adopt.
Our second case study and our draft LoD exercise demonstrates a further benefit of LoDs, namely to extend the range of mapping scales which are accessible from a given anchor resolution. Accessibility in this context refers to the range of scales within which a given data set can be suitably symbolized to produce a readable map.
In the Ada County project, for example, we found that 1:5,000 hydrographic data could be symbolized appropriately for mapping scales ranging from the anchor down to 1:20,000. At smaller scales, hydrographic details began to coalesce and the maps lost graphic clarity; these smaller scales were inaccessible from the anchor without applying some form of geometry change (simplification, elimination, displacement, or aggregation). We produced an LoD containing the data representation resulting from geometry changes. Substituting the LoD for the 1:5,000 anchor hydrography, the map legibility improved. We found that symbol change alone could support further scale reduction as well. We conclude that production of an LoD for 1:20,000 extended the range of accessible scales for the Ada County database.
Another benefit of creating LoDs is the reduction of expertise required to complete a particular design at a particular mapping scale. By simplifying tasks required to generate a smaller scale map, a project manager can reduce the level of cartographic expertise needed by staff. A historical example of such expertise can be summarized by recalling that prior to the advent of computer generated hillshading, many map production agencies employed one or a few airbrushing experts who generated hillshades manually, often creating hillshade artwork for areas much larger than any single map project might necessitate. Photographic negatives of these were stored and cropped as necessary to suit individual maps. (Possibly this is a good example of an analog LoD.) At present, development of refined algorithms has simplified workloads to the point where the level of expertise required to produce a hillshade layer has been reduced dramatically. Hillshades are commonly created using commercial off-the-shelf software for each individual map product; and anyone on the cartographic staff can handle the work with only a small amount of training.
We acknowledge that the creation of an LoD requires time, computer processing, and cartographic skill, each of which is a factor in assessing workloads. It is important to keep in mind that the point in producing the LoD is to expend those resources once, in order to reduce workloads for subsequent mapping products. In the MRDB context, updates are then automatically propagated to only the changed portions of LoDs as well as to anchor databases at resolutions suited to smaller scale mapping. Obviously, it makes little sense to create an LoD for a single map product. A project manager may consider outsourcing or subcontracting data production tasks that exceed in-house time, processing, or skill levels.
The workload balancing concept described in this paper has not been empirically tested, with the exception of the LoD exercise. Our findings from that exercise demonstrate that geometry change can reduce workloads for symbol change, and that inserting LoDs at critical mapping scales can extend the usable range of a topographic data base for mapping. Our research team does not handle the volume of mapping projects needed to undertake a systematic empirical evaluation, although many small and large mapping organizations do handle sufficient projects to do so. We encourage such an effort and look forward to suggestions that could refine the workload balancing framework which we propose.
Acknowledgments
The authors gratefully acknowledge funding by ESRI (Professional Services Agreements 2003B6345 and 2003B6346, 2003B6347, and 2006B2964). Charlie Frye and Aileen Buckley at ESRI supported the project with planning, discussion, and data files. We also acknowledge database editing and building by Kiyoshi Yamashita, a graduate research assistant at University of Colorado.
Open Access
This article is distributed under the terms of the Creative Commons Attribution Noncommercial License which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited.
Open AccessThis is an open access article distributed under the terms of the Creative Commons Attribution Noncommercial License (https://creativecommons.org/licenses/by-nc/2.0), which permits any noncommercial use, distribution, and reproduction in any medium, provided the original author(s) and source are credited.
