Alesandro Cecconi and Martin Galanda
Department of Geography
University of Zurich

8057 Zurich
e-mail: (acecconi,mgalanda)
tel: ++41-1-6355131

Keywords: Web Mapping with SVG; Adaptive Zooming; Cartographic Generalization;


Beyond any doubt much of the current of the web mapping and web GIS applications lack cartographic quality. The reasons aren't only the technical limitations related to Internet delivery, but also the neglect of one of the main cartographic principles of digital mapping, namely adaptive zooming. Adaptive zooming describes the adjustment of a map, its contents and the symbolization to target scale in consequentlce of a zooming operation. The approach described in this paper propos1es the combination of two commonly known concepts: on the one hand levels of detail (LoD) for those object classes, that require high computational cost for the automated generalization process (e.g. buildings, road network); on the other hand an on-the-fly generalization for those object classes which can be generalized by less complex methods and algorithms (e.g. rivers, lakes). Realizing such interactive and dynamic concept for web mapping requires the use of vector based visualization tools. The data format best meeting the criteria is the W3C standard Scalable Vector Graphics (SVG). Thus, it has been used to implement the presented ideas in a prototype application for topographic web mapping based on the landscape model VECTOR25 of the Swiss Federal Office of Topography.

1 Introduction

Beyond any doubt much of the current of the web mapping and web GIS applications lack cartographic quality. The reasons aren't only the technical limitations related to Internet delivery, e.g. screen resolution, transmission speeds etc., but also the neglect of one of the main cartographic principles of digital mapping, namely adaptive zooming.

Adaptive zooming describes the adjustment of a map, its contents and the symbolization to target scale in consequentlce of a zooming operation (=scale change) (Brühlmeier 2000). In web mapping commonly the concept of levels of detail (LoD) is appliedso far that is, a certain sequence of pre-calculated maps that cover the mapped area at different scales are used to adapt to the target scale (see for instance the examples of or Such an approach presents three main drawbacks:

The ideal solution would be to use a single master database and to calculate every arbitrary desired scale on-demand by means of automated generalization (on-the-fly generalization). This approach is not ideal either because of the limited time available to react on a zoom request (a limit of 10 seconds is assumed) and the complexity of the generalization task with respect to available methods and algorithms. Therefore this paper proposes a combination of these two methods - LoD and on-the-fly generalization - to implement adaptive zooming in order to compromise between flexibility in scale and (re-)loading time.

The requirements for on-the-fly generalization are very stringent, because the maps must be generated in real-time, which makes the process extremely time-sensitive. Bernier et al. (2002) identify the following characteristics for the on-the-fly generalization:

Next to these characteristics other effects must be respected particularly in the context of the Internet. The performance plays a very important role . Through the generalization process the amount of data, which has to be transferred and displayed, can be optimized for the user's purpose according to scale and theme. Since most people need web maps only for a short time this flexibility is central. The user wishes to have their own defined map with their own preferences, where they can easily zoom in and out, pan, etc.

2 Generalization in web mapping

2.1 The LoD approach

A multiscale database (Cecconi and Weibel 2001, Devogele 1997) represents a special database where datasets from different pre-defined scales are stored. In such a database each feature class is stored at different scale levels (e.g. 1:25'000, 1:100'000, 1:200'000). These levels are commonly called levels of detail (LoD). The LoD are derived beforehand by means of interactive generalization of the base dataset. According to generalization there are two main advantages to using this approach. First, the generalization process is not time sensitive. Thus complex and computational expensive methods and algorithms can be used in the generalization, for instance optimization techniques (Bader 2001, Galanda 2001) or a multi-agent system (Barrault et al. 2001). Secondly the cartographer can interactively generalize situations, which are too complex for automated generalization with the help of generalization software. However, one disadvantage is keeping the database updated for all LoD. If the base dataset is changed (e.g. new buildings, new roads) all the updates must be propagated to the other LoD. Methods and algorithms for doing so automatically are still under research (Harrie 1999). Thus, the selection of the scales at which LoD are stored in a multiscale database has to be a compromise between the number of LoD and the optimal adaptation to arbitrary scales.

2.2 On-the-fly generalization

This approach creates a temporary visualization of a topological and consistent dataset for a selected scale at run-time. All accomplished transformations - both geometric and semantic - are derived directly from the base dataset, without creating a new one (Oosterom 1995). Thus, on-the-fly generalization is highly time critical and restricted to efficient and less complex generalization methods and algorithms. For the optimization and speeding up of the generalization process a precedent data analysis is undertaken. Geometric and semantic information is derived from the objects in the base dataset in advance in order to ensure efficient generalization and passable loading and re-calculation time, i.e. lower than 10 seconds. Various types of additional information such as area, additional data structures (e.g. topology) or geometric objects (e.g. inflection points of linear objects) are stored in the base dataset (data enrichment) - cf. section 3.5 for concrete examples.

2.3 Combining the methods

As neither the LoD approach nor that of on-the-fly generalization fulfills all the requirements to implement adaptive zooming in web mapping, we propose a combination of them in order to benefit from each of their advantages and minimize their drawbacks. Figure 1 illustrates the framework for adaptive zooming and web map generation based on this concept.

The principle of adaptive Zooming

Figure 1: Principle of adaptive zooming and web map generation based on LoD and on-the-fly generalization (Source: Cecconi and Galanda 2001)

Some feature classes are stored as LoD in a multiscale database, while others are generated in real-time from the base dataset. The created data are then combined into one map. The current allocation of the feature classes to the different approaches depends on the complexity of their generalization and the availability of appropriate methods for on-the-fly generalization. We hope that new, faster algorithms and methods for cartographic generalization, as well as better computational performance and higher data transmission capacity may allow more feature classes to be calculated on-the-fly in the future.

2.4 Generalization Operators

While generalization operators designate abstract transformations in the generalization process, algorithms put the geometric and semantic transformation of the dataset into execution. The basic operations of cartographic generalization are listed among others in Weibel and Dutton (1999) and McMaster and Shea (1992). In the following section we discuss only those generalization operators that seem to be especially qualified for on-the-fly generalization and therefore have been used in our prototype.

2.4.1 Selection/Elimination

The omission of 'less important' map objects is one of the main processes of map generalization. It is described by the generalization operator selection/elimination. This operator reduces the number of objects within the dataset, emphasizes the remaining objects and ensures their visual perceptibility at a reduced scale. Figure 2 shows an example of selecting building objects. Semantic information and geometric properties of objects indicating their 'importance' enable the straightforward implementation of this operator. For instance a church or hospital is kept rather than a simple house. The selection/elimination operator is applied to point, line and area (polygonal) features.

The selection operator

Figure 2: The generalization process selection used for the feature class buildings.

2.4.2 Simplification

The simplification operator reduces the granularity of linear objects (see figure 3) and the outlines of polygon objects. The simplification operator creates a simplified line using a subset of the original vertices. Points that are not necessary to represent the characteristics of the line or that describe detail no longer perceptible at the target scale will be rejected. Simplification can also be used for removing redundant points to retain a lower number of data points.

The simplification operator

Figure 3: Possible generalization of a river (line object) with the simplification operator.

2.5 Symbolization

The symbolization process sets the visual variables (e.g. size, color, etc.) for the representation of the dataset's objects according to their semantics and the target scale. How important an appropriate symbolization is to represent the different kinds of roads with a familiar color is showing Figure 4. The basic symbolization for every feature class is defined in advance and is then adjusted on-the-fly to the requirements imposed by the target scale (e.g. minimal line-width, minimal symbol size).

The symbolization process

Figure 4: The symbolization process gives the data the familiar appearance known by the user. (data: © Swiss Federal Office of Topography 2002 (JD22298))

2.6 Sequence of operators for on-the-fly generalization

Due to both the limited number of operators used here and their diverse character the most appropriate sequence of operators for on-the-fly generalization is obvious, namely first selection, then simplification and finally symbolization. That sequence is illustrated in Figure 5 using the example of a river object. Every time the user zooms the map is re-generated and respectively generalized from the base dataset for the requested scale.

A possible generalization process

Figure 5: Possible generalization process for a feature class (e.g. river).

For a river object thus means that first the objects' properties (e.g. connectivity, width, etc.) are analyzed and a decision is made whether to display the object or not at the target scale (selection/elimination). If it is considered to be part of the target map its geometry is simplified (simplification) and its graphical representation is defined (symbolization), both peocesses are highly dependent on by the target scale. Details on the generalization operators and their implementation according to the different feature classes is given in section 3.5.

3 Prototype implementation

3.1 SVG

In the last few years most maps on the web have been produced in raster format, since web browsers' ability to handle vector data is fairly new. With the introduction of vector graphics the cartographic quality and flexibility in theme and scale of web mapping applications has significantly improved.

Currently web browsers support two vector data formats that are of particular interest for web mapping. One is the quasi-standard format Macromedia Flash (SWF version 6.0), the other the open W3C standard Scalable Vector Graphics (SVG Specification 1.0). The following table 1 summarizes the characteristics and qualities of each data format from a cartographer's point of view - for a more detailed comparison refer to Neumann (2002).

Table 1: Webstandards used in the project and it's corresponding version numbers.
Data format type ascii binary
Plug-in required yes yes
Data protection (copyright) improvable moderate
Compatibility to W3C standards excellent bad
Real world coordinates yes no
Multimedia effects supported yes yes
Major applications Cartography, Geovisualization Multimedia

From our point of view, the main advantages of SVG compared to SWF lies in SVG's strength as open standard and the better adaptation of it to web cartography's requirements. The most important reasons for using SVG for web mapping in general and for its implementation in the proposed adaptive zooming approach are that SVG:

For a general discussion on the application of SVG for web mapping refer to Winter and Neumann (2000). For the technical implementation of the prototype presented here, SVG is combined with JavaScript that allows an interactive modification of the SVG document or single SVG objects via the DOM in real-time. This solution is acting purely on the client-side and is kept consciously simple as the main focus of this paper is set out the proposed method for adaptive zooming and its 'proof of concept'.

3.2 Data Source

For the prototype a test area in the region of Nyon (Switzerland) has been chosen. The vector data from VECTOR25 of the Swiss Federal Office of Topography was the original data source for our prototype. Its content and geometry is based on the National Map 1:25'000 of Switzerland. VECTOR25 consists of the eight thematic layers and includes a total of about 140 different kinds of cartographic objects. The following layers are included in the prototype either as LoD or as part of the base dataset for on-the-fly generalization (compare the last column in table 2):

Table 2: Comparison of the two common plug-in for displaying vector data through web browser.
Road network HighwayRoad 1st class - 3rd class LoD
Hydrography Rivers 1st - 3rd classLake on-the-fly
Buildings General buildings LoD
Land use Forest on-the-fly

In order to optimize our approach only one additional LoD has been selected, namely one equivalent to a paper map at 1:100'000. For the level of 1:100'000 no vector data is available of the Swiss Federal Office of Topography, but since it is required for our application, it has been digitized.

3.3 Creating SVG objects out of GIS objects

The data of VECTOR25 has been manipulated, structured and enriched in a Geographic Information System (GIS) in order to meet the requirements imposed by the proposed approach to adaptive zooming and the techniques used. All the base datasets of the prototype are stored in the GIS ArcInfo. The process of creating SVG objects out of GIS objects is fully automated by macros in ArcInfo and the programming language Perl.

3.3.1 Feature classes stored as LoD

Those object classes represented as LoD in the prototype are converted directly to SVG objects. First, the geometries of those objects are exported to a text-based format - cf. left-hand box in Figure 6 for an example of a building's geometry. Then, the generated file is interpreted by a Perl program and every object is translated into a SVG element - see the right box in Figure 6 for a building object represented by a SVG 'path' element. The semantics of the LoD objects is considered by combining all objects belonging to one LoD and one object class into one map layer with the help of the so-called 'g' element of SVG. Thus symbolization and visibility according to the target scale can be set per group/layer.

A GIS object's geometry to SVG

Figure 6: An example for the conversion of a GIS objects' geometry to an SVG graphic element.

In order to keep the size of the SVG file as small as possible all coordinates in x are reduced by the minimal x (here 505'000) and all in y are reduced by the minimal y (here 138'000). In addition all points of a SVG element- except the starting point - are stored relatively to the previous point. Due to different points of origin of the real world coordinate system and the user-defined coordinate system in SVG all the y coordinates are multiplied by a factor (-1). For a detailed discussion of both coordinate systems in SVG and the syntax of coordinates in SVG refer to the SVG specification 1.0 (W3C 2001).

3.3.2 Classes for on-the-fly generalization

The feature classes assigned to on-the-fly generalization are translated to different kinds of JavaScript objects, namely geometry objects representing polylines and thematic objects storing semantics. The reasons for doing thus are twofold, to optimally support the generalization process and to avoid duplication in the JavaScript code. While Figure 7 illustrates by example the conversion of a GIS object's geometry to a JavaScript geometry object the figure 8 shows the creation of a JavaScript thematic object out of an GIS's attribute table at run time SVG objects are created out of these objects according to the target scale - section 3.6 then discusses both the chosen technical solution and the map making process in more detail.

A GIS object's geometry to JavaScript

Figure 7: An example for the conversion of a GIS objects' geometries to geometry objects in JavaScript.

The conversion of the coordinates from the GIS objects' geometries to JavaScript geometry objects follows the same guidelines as described for LoD objects in the previous section. That is, coordinates are reduced by the minimal coordinate and (except the first one) stored relative to the previous point of the geometry. A geometry object has two properties, a sequential number and an array containing its coordinates, as well as several methods, for instance a simplification method implementing the Douglas-Peuker algorithm (Douglas and Peucker 1973) and a method for displaying the geometry as a SVG element. All the semantic information is stored in the thematic objects.

A GIS object's attributes to JavaScript

Figure 8: An example for the conversion of the GIS objects' attributes to properties of JavaScript objects.

Thematic objects (e.g. a river object or a forest object) are automatically generated out of the feature attribute tables of ArcInfo. On the one hand, all the attributes derived from the data analysis (compare section 2.2) are stored as object properties. On the other hand, every thematic object needs to accumulate those geometry objects representing its graphical appearance. While for linear thematic objects only the consecutive number of the respective geometry object is required polygonal objects must store an array of links to polylines (geometry objects) and their directions in order to enable their assembly to polygon geometries.

3.4 LoD Object Classes - Buildings and Road Network

As explained in section 3.2 two LoD - 1:25'000 and 1:100'000 - have been selected for the utilization in our prototype. Figure 9 illustrates the two scale levels, showing the feature classes building and road network. On the left side the scale of 1:25'000, on the right 1:100'000, display the difference of the information density between the two levels.

Buildings and road netweorks as LoD

Figure 9: A clipping of the object classes buildings and road network and their representation at the LoD 1:25'000 (left-hand figure) and 1:100'000 (right-hand figure) - figures not at scale. (data: © Swiss Federal Office of Topography 2002 (JD22298))

The threshold where the change from the LoD 1:25'000 to the LoD 1:100'000 or vice versa takes place is set by the zoom level of 75%. This value must be defined in advance and cannot be influenced by the user. A possible disadvantage of this approach can been seen well by the selected example. Changing from one zoom level to the other, the represented information changes abruptly and so could possibly confuse the user.

3.5 On-the-fly Object Classes

3.5.1 River

The data enrichment for the feature class river focused on the derivation of an indicator for the relevance of a specific river, in order to objectively base the selection/elimination operator. Adopting from the classification given in the VECTOR25 dataset and influenced by a Horton ordering of the river network (Thomson and Brooks 2000) an importance value was assigned to every river object. Additionally the extent (minimum and maximum coordinates in x and y) of every object was automatically derived from the base dataset. This information enables a processing of only those objects required for the extent of the target map.

With respect to the principle of on-the-fly generalization (cf. section 2.2) SVG elements representing river objects are created dynamically every time a zoom request induces the adaptation to a new target scale. While section 2.5 has already outlined by example the generalization process for a river object, Figure 10 shows the process's results according to specific zoom levels. Compared to the original situation (zoom level 100%) illustrated in the left-hand figure, the other two figures show generalized views of a section of the river network at zoom levels of 50% and 37.5%.


Figure 10: A section of the river feature class and its adaptation to the target zoom level of 100% (left-hand figure), 50 % (figure In the middle) and 37.5 % (right-hand figure) - figures not to scale. (data: © Swiss Federal Office of Topography 2002 (JD22298))

However, the figure 10 clarifies the way on-the-fly generalization enables adaptive zooming by modifying the content and symbolization of the base dataset: the importance value triggers the omission of objects, i.e. the smaller the zoom level the less river objects are included in the map - cf. Figure 10; the line geometries are simplified by the Douglas-Peucker algorithm and so the river's granularity is reduced at smaller scales; the line-width increases at smaller zoom levels to ensure good perceptibility.

3.5.2 Area objects: Forests and Lakes

Whether a forest or lake object is displayed at a specific zoom level depends, besides its extent, - compare the previous section - primarily on its area. That is, for every zoom level a minimal area value is calculated based on the minimal area defined at the zoom level 100% and the ratio of the current level to 100%. Only area objects with a greater area than the threshold are shown in the target map - compare the number of small polygons at the two different zoom levels in figure 11. Additionally, forest objects obviously bound to a river object are linked to the selection of that river. Thus, if the river is not displayed the forest object will not appear in the final map either. For instance, the forest polygon in the upper right of the left-hand image of figure 11 is not shown at a zoom level of 50% due its linkage to the river, although the polygon's area is significantly higher than the minimal area. The simplification operator is not applied to area objects in the current version of the prototype.

Forest and lakes

Figure 11: A section of the forest and river object classes illustrating the on-the-fly generalization of the forest polygons. The left figure shows the zoom level at 100% and the right one at 50% - figures not to scale. (data: © Swiss Federal Office of Topography 2002 (JD22298))

3.5.3 Labels and point symbols

The selection/elimination of the labels is again controlled by a so-called 'importance value' which was set manually with respect to the appearance of the labels in the National Maps of Switzerland 1:25'000, 1:100'000 to 1:200'000. The symbolization of a label depends on this value and the target zoom level (e.g. text height, stroke width). The label placement is performed through a fixed reference point and a label attribute that defines whether the label is placed to the right or left and above or below this position. Point symbols attached to a label are also positioned according to this reference point and selected together with the label.

Point symbols display additional thematic information that indicate campsites (cf. table 3), recreation areas, hotels, restaurants and tourist information. Besides the points, symbols attached to labels point symbols can also occur independently of any other map feature. Their selection is controlled by a manually set minimum scale attribute. Point symbols are created automatically, see table 3 for an example of a function for the automatic creation of a campsite symbol - based on a reference point and the target zoom level.

Table 3: A point symbol showing a campsite (left-hand) and the JavaScript code it is generated through (right-hand).

Campsite symbol

function drawCamp(x,y,sf,lay,m)
    symbRect(x,y,sf,"white",lay,m);  //create the background rectangle
    eval("s = svgdoc" + m +".createElement('polyline');");   //new polyline
    //x2=x AND (y1,y2,y3,y4)=y
    x0 = x + 6.5*sf;
    y0 = y - 7.5*sf;
    x1 = x + 1.5*sf;
    x3 = x + 10*sf;
    x4 = x + 8.5*sf;
    x5 = x + 3.5*sf; y5 = y - 7.5*sf;
    koord = ""+x0+","+y0+" "+x1+","+y+" "+x+","+y+" "+x3+","+y+"
            "+x4+","+y+" "+x5+","+y5;
    style = s.getStyle();
    style.setProperty("fill", "none");
    style.setProperty("stroke", "red");
    sw = (sf/6) * 5;   //set the stroke width with respect to the zoom level
    //add the polyline to the target layer
    eval(lay +"lay.appendChild(s);");

3.6 A review of the mapping process

The following section intends to give a review of the mapping process. The components explained separately so far are put in context and the process of adaptive zooming is explained briefly. The two left most boxes of figure 12 (GIS and data conversion) describe the preprocessing of data resulting from the input data to the mapping process (compare section 3.3).

The mapping process

Figure 12: An overview of the mapping process in the prototype. The abbreviations SVG and JS (JavaScript) in the lower right corner of the boxes indicate the technique the component is implemented with.

The mapping process that takes place in real-time is initialized by a zoom request, i.e. a map at a different zoom level (a new adaptation to a target scale) is needed. According to the proposed approach, outlined in section 2.3, a so-called multiscale module and an on-the-fly module are started. The first controls the visibility of the LoD layers according to the requested zoom level. The second re-generates all the SVG elements representing on-the-fly object classes from the base data - cf. section 3.5 - again with respect to the requested zoom level. The final result of the mapping process is the combination of the output of these two modules in a temporary map. Following the guidelines imposed by adaptive zooming, this map meets well the principles of cartographic visualization For instance, the appropriate density of map objects and the clearly perceptible symbolization.

3.7 The prototype

Maps play a prominent role in the communication of spatial data and information on the Internet. Most applications are path or route finding programs that work with LoD technology, for instance - which according to Peterson (2001) is the largest map publisher in the world with around 20'000'000 maps downloaded every day - or The focus of our work is how the outlined approaches in automated generalization can be merged with the LoD approach in order to allow more flexibility in the question of scale and thematic content for web mapping.

To allow the user to navigate in a familiar environment a Graphic User Interface (GUI), which was clear and easy to understand was developed. The application is best viewed on a screen size of a minimum of 1024 x 768 pixels. Most space has been reserved for the map and the legend display. At the bottom of the window, the zoom and pan functionality can be found. The user has the possibility to change between six different zoom levels and to scroll and pan in all directions, additionally, independent from these fixed steps, a user-defined map scale can be set. The value entered is equivalent to the proportions of the extent to the original viewport in %.

Since the zoom functionality needs a lot of computational performance, it is not very intelligent to re-calculate a new map for the whole extent of the area. Our approach permits distinguishing between objects from a LoD and objects created on-the-fly. Thereby those elements of a LoD need not to be transformed and are displayed for the whole area. For elements generated on-the-fly, only those in the current window region are taken into account. Scrolling the map requires a re-calculation of the whole displayed map. For future work it is desired to implement a similar technique as utilized for zooming for the scrolling functionality, where only the new added objects will be calculated and not the whole map.

The following figure illustrates the prototype and gives a first overview of the disposition of the basic essentials. For testing the application on the web a special site has been installed. (URL??)

Screenshot of the prototype

Figure 13: Screenshot of the prototype. (data: © Swiss Federal Office of Topography 2002 (JD22298))

4 Discussion and Outlook

4.1 Discussion of the proposed concept

By means of the developed prototype an improvement of the cartographic quality to existing products is noticeable. The displayed information is more or less exactly adapted to the scale selected by the user, which results in a clear, legible map for every level. The structure of the GUI allows a familiar handling and understanding of the implemented functionality. Using this product for data from other regions involves a simple process of the transformation of the data from a GIS into SVG and JavaScript. On the part of the on-the-fly generalization process different bottleneck must still be solved. One issue is the strong time dependency of web applications. . Another is maintaining the topological consistency between the objects stored in the different LoD and the objects created on-the-fly. Since data from different approaches will be merged, topological problems can occur and finally appear in the generated map.

As changes in the real world often occur, the LoD has to be updated regularly and adjusted to the new realities. This causes a lot of work because the new objects must be included or canceled in each level and the rest of the information adapted to the new circumstances. Since there is no possibility to do this process automatically - the full automatic generalization process is not yet so far developed - it requires of lot of time, human resources and ultimately money. A lot of mapping agencies know this problem and are willing to undertake the research on this topic. One possible solution for this updating problem can be to create all feature elements on-the-fly out of one base dataset. But this depends strongly on the development success of the automated generalization research and the increase of computational performance.

4.2 Evaluation of the technical solution

The main disadvantage of using SVG techniques - in the sense of propagation - is that a plug-in must be downloaded and installed. Since downloading a plug-in takes a few minutes and requires advanced computer skills not every user likes to do this procedure. The most used plug-in is the Adobe plug-in that is also distributed with the Adobe Acrobat Reader software. Neumann (2001) estimated the SVG's plug-in availability at about 10% and for the Macromedia Flash plug-in, which is get to be included in web browsers yet, at 90%.

For the evaluation of our prototype the time for the calculation and loading process of the displayed data is too high, an average zooming process currently lasts between 12 and 15 seconds particularly in the context of Internet use, a shorter re-loading time would assist the user in retrieving information.

As currently the complete base data is stored in JavaScript, the detailed information can be view and downloaded through the web browser. This leads to copyright issues with the data owner, i.e. national mapping agencies.

4.3 Potential of future work

The next step in the development of the prototype will be the integration of the application in server-side-technology. This means moving most of the functionality from the client (web browser) and implementing it on the server and at the same time storing the dataset in a real database. For the domain of the generalization better computational performance on the server can be utilized to speed up the on-the-fly generation process. The creation of more object classes through the on-the-fly approach could help to make the application more flexible and minimize topological problems originating from merging the data created by the two different approaches. For this step more progress in the automatic generalization research is necessary. Beyond any doubt further improvements are concernable for the on-the-fly generalization of the area objects, for instance the consideration of a minimal width criteria and the integration of additional generalization operators.

Other possible future work would be a better implementation of the scroll functionality (see section 3.7) by not re-calculating the whole map every time, but only the newly added objects. The positioning of the labels is not fully automated yet. Particularly near the border of the map there is no testing procedure, which analyze if the label has been cut off and so needs to be re-positioned. For this problem an automated solution must be developed and implemented.


This research is part of the project "GENDEM: Map Generalization for Thematic and On-demand Mapping in GIS" supported by the Swiss National Science Foundation under contract 20-59249.99.


Bader M. (2001): Energy Minimizing Methods for Feature Displacement in Map Generalization. PhD Thesis. Department of Geography, University of Zurich.

Barrault M., Regnauld N., Duchêne C., Haire K., Baeijs C., Demazeau Y., Hardy P., Mackaness W., Ruas A., and Weibel R. (2001): Integrating multi-agent, object-oriented and algorithmic techniques for improved automated map generalization. Proceedings 20th International Cartographic Conference, Beijing, China. pp 2110-2116

Bernier E., Weibel R., Bedard Y., and Cecconi A. (2002): Généralisation à la volée. In: Generalisation et représentation multiple, Ruas A. (ed). HERMES Science Europe Ltd,, Middlesex, UK.

Brühlmeier T. (2000): Interaktive Karten - Adaptives Zoomen mit Scalable Vector Graphics. MSc Thesis. Department of Geography, University of Zurich.

Cecconi A., and Galanda M. (2001): Multiskalierte Datenbanken und kartographische Generalisierung als Elemente guter Internetkartographie. In: Blaschke, Griesebner, Strobl: Angewandte Geographische Informationsverarbeitung 13, Beiträge zum AGIT-Symposium 2001, Verlag Wichmann. pp 78-83

Cecconi A., and Weibel R. (2001): Map Generalization for On-demand Mapping. In: GIM International, Magazine for Geomatics, 15 (5), May 2001, Lemmer, The Netherlands. pp 12-15

Devogele T., Trevisan J., and Raynal L. (1997): Building a Multi-Scale Database with Scale-Transition Database. In: Kraak M.J., and Molenaar M. (eds), Advances in GIS Research II, Taylor & Francis, London. pp 559-570

Douglas D.H., and Peucker T.K. (1973): Algorithms for the reduction of the number of points required to represent a digitized line or its character. The Canadian Cartographer, 10(2).

Galanda, M. (2001): Optimization techniques for polygon generalization. ICA-Workshop on Progress in Automated Map Generalization, Beijing (China).

Harrie L., and Hellström A.-K. (2000): A Prototype System for Propagating Updates between Cartographic Datasets. The Cartographic Journal 36(2). pp 133-140

McMaster R., and Shea, K.S. (1992): Generalization in Digital Cartography. Association of American Geographers, Washington.

Neumann A. (2002): Comparing .SWF (Shockwave Flash) and .SVG (Scalable Vector Graphics) file format specifications.

Oosterom van P. (1995): The GAP-tree, an approach to 'on the fly' map generalization of an area partitioning. In: Müller J.-C., Lagrange J.-P., Weibel R. (eds) GIS and Generalization. Methodology and Practice (= GISDATA 1). London, Bristol. Verlag Taylor&Francis. pp 120-132

Peterson M.P. (2001): The Development of Map Distributen through the Internet. Proceedings 20th International Cartographic Conference, Beijing, China. pp 2306-2312

Thomson R., and Brooks R. (2000): Efficient Generalisation and Abstraction of Network Data Using Perceptual Grouping. Proceedings of the 5th International Conference on GeoCompuation, Greenwich, UK.

Weibel R., and Dutton G. (1999): Generalizing Spatial Data and Dealing with Multiple Representations. In: Longley P., Goodchild M.F., Maguire D.J., and Rhind D.W. (eds), Geographical Information Systems: Principles, Techniques, Management and Applications, Second Edition. Cambridge, GeoInformation International. pp 125-155

Winter A., and Neumann A. (2000): Vector-based Web Cartography: Enabler SVG.

W3C (2001): Scalable Vector Graphics (SVG) 1.0 Specification.

Valid XHTML 1.0!