Mastering map scale: balancing workloads using display and geometry change in multi-scale mapping
- First Online:
- 1.4k Downloads
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.
KeywordsMulti-scale mapping Multi-resolution database MRDB Generalization Cartography Map design Workload Level of detail database LoD
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.
Examples of scales used by national mapping agencies, comparing resolutions of anchor databases and corresponding scales of derived topographic database and/or map products
Derived data and map products
Spain (Catalonia example)
5, 10, 25
10, 25, 50
100, 250, 1000
100, 120, 250, 500, 1000
10, 25, 50, 100
1.25, 2.5, 10
10, 25, 50, 250
10, 50, 100, 250, 1000
25, 50, 100
200, 500, 1000
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 .
Another factor affecting the choice of anchors relates to data production and maintenance policies and procedures in place at an agency . 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 .
In this paper we will apply the term scale to map products and resolution to databases following conventions in database research . 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  and GiMoDig  and are described for countries throughout Europe [2, 7, 23, 26].
Some MRDB strategies derive an intermediate-scale, product-specific database called a Digital Cartographic Model (DCM)  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 . 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 .
Relative magnitudes and usable scale ranges for a hypothetical set of LoD layers
Largest to smallest scales
Magnitude of scale support
Usable scale range
Terrain and hydrography
Transportation and buildings
Thematic layers (vegetation, soils)
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.
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).
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).
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  (additionally reported in  and ), 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 , 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.
As with , 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  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.
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.
Workload comparison for display and geometry change
Display changes in Fig. 2a:
thinner road line
road color change
no road casing
select buildings on size (do not display smaller buildings)
no building outline
no stream outline
stream color change
design correct visual hierarchy
Geometry changes in Fig. 2b:
collapse stream to centerline
eliminate buildings on local density (remove small isolated buildings)
construct hull around dense area of buildings
displace road from stream
simplify largest buildings
Both geometry and display changes in Fig. 2c:
select buildings by size
displace road from stream
simplify all building shapes
no building outline
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
Continued modeling of workload balance
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.
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  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.
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.
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.