Chapter 9

WEBGEN: Web Services to Share Cartographic Generalization Tools

9.1. Introduction

This chapter describes WEBGEN, a framework offering cartographic generalization operations as Web processing services. Originally, WEBGEN was designed with the purpose of being a common research platform allowing people to share generalization algorithms, and contribute to more and more advanced experiments. Very soon, however, it became apparent that the architecture might also have benefits for other types of users, such as national mapping agencies (NMAs) and GIS providers. While the original version of WEBGEN used the SOAP protocol for service descriptions and communication mode, the following release was compatible with the Open Geospatial Consortium (OGC)'s Web Processing Services (WPS), which are widely supported by GIS. The latest version is available as open source.

9.2. Historical background

Cartographic generalization is the process that enables us to create a map readable at a given scale from often highly detailed geographical data (such as the data acquired by national mapping agencies). These data can only be represented as such at a very large scale. As soon as the scale is reduced, the objects on the map become too small to be read by the reader. Figure 9.1 shows this phenomenon in more detail. A map at a scale of 1:10 k quickly becomes unreadable if it is reduced. However, the map at a 1:50 k scale has a simplified content: the objects represented on it have been exaggerated and thus the map can be scaled down. Generalization is thus the process allowing the cartographer to simplify the map content to obtain a good compromise between the degree of detail and readability. There are other factors than scale involved in the choice of the objects to be exaggerated, aggregated, or eliminated. They depend on the needs of the target map user.

Figure 9.1. Scale reduction and generalization

The thematic content is dictated by the intended map purpose. The actual representation of content then depends not only on the scale at which the map must be displayed or printed, but also on the type of medium used to display the map, the purported map reader, and the reading context (day or night, for instance). The generalization process has an important cognitive aspect. The goal is not so much to create a map complying with strict specifications as much as to create a map that contains the information the user needs so he/she can interpret the map accurately.

Map generalization for a long time was a completely manual process. Its automation today represents a major challenge for national mapping agencies. It would help reduce map production costs considerably and open the door to on-demand map creation, generated for specific purposes. Research into the automation of this process has thus been carried out for more than 20 years (since the arrival of digital geographical data). The cognitive aspect linked to cartographic generalization, however, makes automation extremely demanding. Various solutions were suggested for different aspects of the process, using a great variety of often complex techniques. The International Cartographic Association (ICA) Commission on Generalization and Multiple Representation brings together a community of researchers and industrial actors working on the subject. This community published a book [MAC 07] that gathered together a series of articles covering the main aspects of the issues of automatic generalization. [RUA 02] offers a similar compendium in French.

Faced with such a complex problem, the research community realized in the past few years that it needed a common development platform. This would help come up with more complex and complete solutions, reusing what had already been accomplished, focusing on new aspects. A major part of the research in map generalization has been carried out within the context of academic doctoral dissertations, which invariably have a fixed duration. If these researchers have to develop their prototypes from scratch, they reach a certain ceiling which is hard to pass. Conversely, if they can take up the development made by their predecessors, the ceiling disappears. This is a slightly simplistic view of the matter, but it clearly illustrates the benefits which such a platform would bring to the research field.

For a few years now, there has been much progress in the fields of interoperability, distributed architectures, and especially in the standardization of formats for geographical information transfer, mostly thanks to the actions carried out by the OGC. This led a group of researchers to write the first article [EDW 03] as the technologies became available to build it. This study was presented during a workshop of the ICA Commission on Generalization and Multiple Representation in 2003. The subject has since then been presented and debated in all the workshops of this commission. Work started at the University of Zurich to build a distributed platform using Web service technology. WEBGEN, a prototype framework to deploy generalization operators as Web services, was thus born. WEBGEN, described in [NEU 05, NEU 08], enables us to embed automatic processes written in JAVA, for instance, in methods presenting a generic interface, to post them on a server, and to use them from a remote desktop. The platform allows the user to find available services and invoke them by providing them with control parameters as well as the data to be processed. The processing is carried out server side and the results are sent to the client. Additional testing was subsequently carried out at the research department of Ordnance Survey (the British national cartographic agency) to assess the interoperability of these services with a specific platform. We performed the tests with RADIUS CLARITY, a platform devoted to developing generalization processes, developed, and marketed by 1Spatial¹. The test consisted in checking that services could be called from RADIUS CLARITY, and also that processes native to the platform could be published as services, and therefore made available to other plateforms. It was demonstrated that it is relatively easy to request WEBGEN services from RADIUS CLARITY and vice versa to publish an algorithm depending on RADIUS CLARITY, and request it in the open source GIS JUMP². The results sparked the interest of part of the community and a workshop was organized in November 2007 in Southampton (at Ordnance Survey) to decide on the following steps to be taken to promote the use of such a platform. The GIS vendors present at this meeting requested that this platform be supported by an acknowledged standard.

The main argument was that these companies often wish to implement OGC standards. A platform built along such standards could thus be easily coupled to these GIS without requiring costly additional developments. The prospect of having a platform that could be used with the majority of GIS led to the decision to redevelop WEBGEN as an extension of the OGC's WPS standard. A more technical workshop took place in January 2008 in Zurich to define the new platform's specifications [FOE 10]. An implementation carried out at the University of Zurich and funded by Ordnance Survey then created a WEBGEN server along the new specifications, as well as a client for JUMP. Documentation was also produced to help adapting these clients and servers to proprietary platforms. The sources and documentation are available on the Web site of the ICA Commission on Generalization and Multiple Representation³.

The platform is now ready for use. A first exploitation phase is now required to understand how to use it and how to improve its functionalities.

9.3. Major functionalities

WEBGEN allows us to publish software tools devoted to generalization as Web services based on the OGC's WPS standard. Available functions are described in the following sections.

9.3.1. Uploading software tools

A WEBGEN server allows a developer to publish his/her software generalization tools online as Web services based on the OGC's WPS standard. There are two main constraints: the first is that the tool must read the data it needs and pass the result on in a format recognized by the WEBGEN server. In the WPS standard, vector data are transferred between the client and the server in the GML format. The current WEBGEN prototype can either pass this GML format data directly on to the algorithm or convert it into shapefile or into a native JAVA format (e.g. JAVA Topology Suite for JUMP). The second constraint is that the tool does not depend on a proprietary platform or on its internal functionalities (such as 1Spatial's RADIUS CLARITY or ESRI's ARCOBJECTS). This latter constraint can be removed by adapting the server to make it work with a specific proprietary platform. An experiment carried out at Ordnance Survey (GB) showed that it was possible to publish WEBGEN services depending on the RADIUS CLARITY platform.

The experiment went as follows. When a WEBGEN service was invoked on the server, it launched an executable file which carried out the following operations:

• – declare the environment variables required by the RADIUS CLARITY platform;
• – load the function libraries of the platform;
• – create an internal database in the platform, in our case, a database in the Gothic format;
• – translate the data passed to the service, in our case, translate GML data into the Gothic format;
• – load the objects into the database;
• – translate the required function parameters: in the test, it was a function creating a buffer around a given geometry; the only parameter was thus an integer representing the buffer width;
• – call the function: in the test, it was the buffer_create function, but we could create any type of function based on the function libraries in Gothic and call it in the same way;
• – translate the results from the Gothic format to the GML format to create the result sent back by the service.

The adaptation thus mainly concerned the translation of data from the format used by the WEBGEN server (JAVA Features, GML or shapefile) and the internal format used by the proprietary platform, and it had to be ensured that the server could execute the tool on this platform. It also had to be ensured that the license allowed this type of proprietary platform use.

9.3.2. Requesting a service

The tools published on the WEBGEN platform can be used by anyone who chooses one of the following access modes:

• – By looking up the service description and building his own http requests. This use is obviously the least satisfactory since it is completely manual and subject to many errors.
• – By using a programming client that facilitates the design of requests and the reception of responses. This client usually is a function library in JAVA, C, or any language used by the client platform.
• – By using a graphical client which is a plugin of a GIS platform. For now, there is only a single WEBGEN client available developed for the open source GIS JUMP. It is possible to adapt the client to other platforms and there is documentation to facilitate this process. A client prototype for 1Spatial's RADIUS CLARITY platform has actually been successfully developed at Ordnance Survey to test the ease with which the graphical client could be adapted to different platforms. Just like the server adaptation described above, the main modification is in the translation of the data from the GML format used by the standard WPS to the internal format used by the GIS platform.

9.3.3. Cataloging and discovering services

As part of the WPS standard, each server can provide on-demand the list of services it offers through the GetCapabilities request. However, a user might want to access services offered by different servers. Thus, the implementation of the WPS standard in the WEBGEN server was extended with its own service registry. In this registry, an organization can add a list of WPS servers with the services it is interested in and which are located elsewhere. The GetAllCapabilities request to this registry will provide the list of all the available services on its own server as well as on the other servers listed (see Figure 9.2). The idea behind this registry can in part be compared to the UDDI standard used with Web services based on the SOAP technology. However, since the OGC does not currently offer such a service registry for WPS, we have opted for this solution.

Figure 9.2. Registry use as a GetAllCapabilities request

9.4. Area of use

Different use modes have been envisioned for the platform to answer the needs of different types of users.

9.4.1. Usage

The platform was designed to allow two modes of use: the first is an interactive mode, useful to test and assess available services; the second is an automatic mode, which allows us to use available services to integrate them in more complex processes.

9.4.1.1. Interactive mode

The interactive mode allows the user to choose the service he/she would like to invoke, to select the data on which the service must be applied, and to input the parameter values requested by the service. To use this mode, a client with a graphical interface is required. The client is often an extension specific to a given platform (often a GIS which allows the visualization and manipulation of geographical data). The client accesses a register listing the servers offering WEBGEN services. It queries these servers to build a list of available services. Once the user has picked the service he/she wishes to use, the client reads the description of the service to learn about the expected parameters and builds an interface to allow the user to specify their values. The client also allows the user to choose the data (geographical objects) on which the service has to be applied. It must then translate these data in the format used by the platform into the standard format supported by WebGen. Once the service has returned a result, the client must translate it back into the data format supported by the platform.

Figure 9.3 shows the interface proposed by a WEBGEN client developed for the open source JUMP⁴ platform. It allows the user to specify the address of the server to be accessed. The list of available services on this server is then displayed (left side of the figure). When the user selects a specific service, the parameters required by the service are displayed in the right-hand side of the window. In this example, the BufferFeature service requires three input parameters: width (an integer), capstyle (an enumeration), and quadrants (an integer).

9.4.1.2. Automatic mode

The automatic mode allows the services to be accessed from a program. This enables the creation of complex processes by chaining requests to existing services. Such a process can itself be published as a service. This allows us to consider a hierarchy of services. Building a complete generalization system did not just require generalization operations, it also required spatial analysis functions. These functions help the global generalization process to identify geographical structures implicitly present in the data. These functions enrich the data by building an explicit representation of these structures which can then be used to guide the generalization process. We thus offer a hierarchy of three WEBGEN service layers:

• – The first layer, called support layer, essentially contains the lower level spatial analysis tools.
• – The second layer is made up of generalization operators. They are elementary generalization operators (simplification, aggregation, etc.) for which various classifications have been offered, see for instance [REG 07c]. They are especially useful to enrich data by measuring the intrinsic characteristics of geographical objects or by qualifying their relations (distances, similarities, etc.) with their neighborhood.
• – The third layer is made up of more complete processes which combine generalization operators to carry out more complete tasks, going as far as the complete generalization of a dataset.

This hierarchy makes the reuse of existing software tools easier, which helps the development of more and more complete and efficient tools. Figure 9.4 summarizes these three levels of services and their potential uses (interactive or automatic).

9.4.2. User types

We have identified three types of use for this platform.

9.4.2.1. Researchers

Researchers in automatic generalization (of which a great number are members of the ICA automatic generalization and multiple representation commission) should benefit from this platform in various ways:

• – assess existing tools and carry out benchmarking;
• – reuse exiting tools and concentrate only on developing more advanced new tools,
• – carry out research on how to engineer generalization functions by using existing and accessible services in a standardized manner,
• – carry out research into distributed and parallel processing, to improve performance (cloud computing);
• – obtain feedback (comments, assessments) on the tools developed and published;
• – promote the researcher's tools and thus their work and expertise.

Figure 9.3. WEBGEN client for the JUMP platform

Figure 9.4. Service hierarchy

There are already a few uses of the WEBGEN platform in research.

[NEU 08] experimented with the development of a support layer (the “support services” in Figure 9.3) to help develop more complex services. The creation of complex generalization processes (process service) based on the engineering of existing operators is presented in [NEU 09]. In this context, parallel processing techniques can be used to accelerate a process.

The parallel processing of generalization tasks requires either the domain or a function to break down [LAN 91]. Breaking down the domain means cutting up a task into independent units. For instance, the data can be partitioned into disjointed zones, which can be processed independently (by partitioning the space using a road network, for example). The functional breaking down divides a process into tasks, some of them have to be processed sequentially and some of them can be carried out simultaneously.

[NEU 09] offers a multiple instruction and multiple data stream approach based on the breaking down of data and instructions into independent tasks to process them in a parallel manner. The method ensures that there is no concurrent data access issue. This approach can use a system with multiple processors, or a cluster made of various systems connected by a nework (Cloud computing).

Both the domain and functional breaking down can be used in a Web service environment using a cluster of generalization service instances, as shown in Figure 9.5. The parallel processing service plays the role of master process, partitioning buildings, and creating an instance of the processing service (1) for each partition. Each instance of the service is an independent process, sending data and receiving results. For each instance of the processing service, a processing strategy is carried out. The latter is a mechanism that allows us to explore a set of potential solutions (such as hill climbing). For each cycle, all the available operators are applied in a parallel manner to the partition's current state (2). The results are then assessed with the help of special services assessing whether certain constraints have been satisfied. This assessment of the different results also happens in parallel (3). Once all the assessments are done, the best solution is kept and the process strategy goes on to the next cycle. The parallel computing thus happens at three different levels of the processing.

Figure 9.5. Parallel service requests

9.4.2.2. Cartographic institutions (Institut Géographique National – IGN and others)

Cartographic institutes could take advantage of the platform in two different contexts:

• – to design new production systems:
  • - to asses exiting tools by testing them on their own data;
  • - to test existing tool sequences to create and assess production system prototypes;
• – to develop a production system:
  • - using such an architecture to develop a production system allows the use of tools working in different environments. This offers great flexibility for combining the best tools available for each task without being held back by limited availability of tools in a specific system.

Along these lines, [REG 07a] and [REG 07b] propose a system architecture able to automatically derive, through generalization, on-demand maps. This system is based on the use of Web services to access in a standardized manner a rich library of generalization tools from various platforms. This idea was developed after a conclusive experiments on the integration of WEBGEN and RADIUS CLARITY, the platform Ordnance Survey uses for its research on automatic generalization.

9.4.2.3. GIS providers

GIS providers could use the platform in various ways:

• – assess the tools developed in research to choose which one to integrate in their systems. The fact they can test the tools provides them with a higher level of confidence and lowers the costs/risks linked with tool redeveloping;
• – identify the collaborators to develop their systems;
• – assess/compare their own tools versus other tools published as services;
• – carry out a virtual extension of their systems by developing an interface which allows the Web services to be called up from their systems;
• – provide generalization function as a paying service (pay per use, cloud computing). This would also allow small map designers to use efficient advanced production systems;
• – promote their own systems or some of their tools by publishing targeted demonstrations as services.

Some GIS providers have already turned toward the concept of Web services to develop their software. Inspired by the success of the initial WEBGEN research project, a joint research project between the University of Zurich and Axes System was established to link the AXPAND software to external generalization functionalities by using Web services. The article [PET 06] shows how generalization sequences can be built by chaining generalization Web services. [BOB 08] discusses the use of the Web service concept to build and maintain links between geographical objects. Finally, a test with the University of Hanover has shown how easy it was for their commercial software PUSH, which performs automatic displacement of cartographic objects [SES 99], to be published as a WEBGEN service. A trial version of this service, limited to 250 objects, is available online⁵.

This platform should allow all users to promote existing tools, reuse them, assess them, and thus have a better understanding of their strengths and weaknesses. It should also help collaboration between different types of users.

9.5. Architecture

WEBGEN is a platform built on a client-server architecture (see Figure 9.6). Its goal is to bring together in a virtual toolbox various tools useful to develop automatic generalization processes. It allows its users to access these tools in a standardized manner from various platforms, through the Web.

Figure 9.6. Client-server architecture

9.5.1. WEBGEN services access

WEBGEN is based on the OGC's WPS standard. WPS services are not the usual kind of Web service (like WMS, WFS) since they do not offer spatial data but processing capabilities, such as spatial algorithms. A WPS service can process data provided by the client (“upload”) or data accessible on a server (like a WFS server or a shapefile on a Web server). To use WPS services (and thus WebGen), a client has access to three functions:

• – getGapabilities: this method is implemented by the WPS server and provides the list of services offered by the server, with a short description.
• – describeProcess: this function is implemented by each service and provides a detailed description of the service as an XML format document, notably including the required parameters and their type.
  • – execute: this method is implemented by each service and causes the execution of the service.

  Figure 9.7 illustrates a typical exchange between a client and a server. The client starts by requesting the available services from the server. It then asks a specific service for a description of its parameters, and the data format required on input and output. It can then send the execution command to the desired service, with all the necessary parameters. Finally, the client gets the result of the execution in the predefined format.

  

  Figure 9.7. Client and WPS server exchanges

  9.5.2. A standard data model for generalization services

  The WPS service interface specifications offer great freedom in terms of data and parameters. The specifications do not impose any restrictions on the input or output data format. To facilitate the interoperability of these services, an extension like WEBGEN must restrain the formats used. It was first decided to only use GML to encode the data at input and output of the WEBGEN services. The question of offering a standard to describe structures specific to the generalization processes (for instance, graphs) was also raised. Using a standard model would allow us to standardize the service description and to make their automatic selection possible (automatic discovery of an appropriate service). An architecture for on-demand map creation was suggested in [REG 07a]. This architecture partly relies on the availability of generalization tools as services, described in a standardized manner.

  To use WEBGEN as a fully-fledged research platform, we must define a set of data formats and data models to improve the service interoperability as well as the compatibility between services and different clients. Moreover, we should plan on adding more complex data structures, such as graphs [NEU 08] and cartographic constraints [NEU 09] in the future. The classification proposed by [FOE 08] to extend the WPS standard provides a starting point. The following list provides an insight into the type of data which should be available on the research platform:

  • – literal data types (string, integer, floating point, boolean, date, and time);
  • – complex data types:
    • - geometries (encoded in GML 2): point, line, polygon, multipoint, multiline, multipolygons, and geometry collections;
    • - features (encoded in GML 2): collections of attributes (literal or complex), metadata (optional);
    • - collections of features (encoded in GML 2): collections of features with the same pattern, attributes (optional), and metadata (optional);
    • - list: list of literals or complex types;
    • - map: list of key-value pairs;
  • – more complex types to come: constraints [NEU 09], graphs [NEU 08], symbolization, and complex objects.

9.6. Associated communities

9.6.1. Distribution

The WEBGEN platform is mainly written in JAVA. The source code and literature are available as open source, licensed under GPL⁶.

9.6.2. Uses

WEBGEN has been used for research purposes at the University of Zurich and has been tested at Ordnance Survey to experiment on the integration of different generalization tools coming from different platforms in a single production system. Recently, tests have been carried out in the GIS Department of the University of Lund (Sweden). These are for now the only identified cases of the use of WEBGEN.

9.6.3. Contributors

WEBGEN'S original code was written by Moritz Neun at the University of Zurich during his doctorate. Moritz Wittensöldner ported WEBGEN toward OGC's WPS standard and wrote the documentation linked to it.

Various contributors took part in implementing the generalization services: Dirk Burghardt, Patrick Lüscher, Moritz Neun, Stefan Steiniger (all from the University of Zurich); Nicolas Regnauld (at Ordnance Survey); Stathis Perikleous (at Ordnance Survey, to publish an algorithm originally developed at the University of Edinburgh).

9.7. Conclusion and outlook

WEBGEN was designed to be a platform for generalization researchers, answering a need voiced by a large group of experts [EDW 03]. Since its original version, described in [NEU 05], the software was extended to be compatible with OGC's WPS standard and is now available as open source. Various studies [NEU 05, NEU 08, NEU 09] have shown that WebGen, a platform based on Web services for generalization, met the expectations and provided the originally targeted users (i.e. the researchers) the expected benefits. Moreover, there are certain national mapping agencies [REG 07a, REG 07b] and some cartographic software providers [PET 06, BOB 08] who found the service-oriented architecture concept attractive to build a generalization system. All the studies and projects have shown that the service-oriented architecture implemented in WEBGEN allows users to upload their own tools easily so that others can use them, and conversely allows them to easily use tools developed by other parties. In spite of the incredibly encouraging results reached in the three targeted user fields, WEBGEN is still not as widespread as the group of researchers who had originally suggested the idea thought it might be [EDW 03]. One possible explanation is the existence of other solutions also using a service-oriented architecture. For instance, the approach presented in [FOE 10] uses a combination of WPS and XML pattern translation to build automatic generalization processes. We believe, however, that XML pattern translation places considerable impediments on the sophistication and performance of the generalization tools which can be implemented.

Another (theoretical) reason for WEBGEN'S lack of market penetration might be that generalization researchers are not as interested as they initially said they were in the creation of a common and sustainable generalization tool development platform. In today's academic system, researchers are rather rewarded for short-term innovations and for publishing algorithms in journals, rather than undergoing the long-term effort of creating robust algorithms and distributing them to other researchers in an easy-to-use manner. As long as there is no (financial) incentive, researchers might accept making their “raw” source code available, however, with no documentation attached, and in various formats (often specific to a particular development platform); but they will rarely make the effort of publishing their algorithm as a service. This final stage requires an extra effort to develop the interface between the algorithm and the standard format used by the Web services. One solution could be to find extra funding to convert the code and write the documentation. However, given current priorities in academic research, this seems unlikely. Today, a more realistic solution would be that the members of the ICA Commission on Generalization and Multiple Representation sign a memorandum of understanding on the development of service-oriented generalization tools. [FOE 08] lays out the principle behind this approach.

Although the factors presented above have affected the distribution of WEBGEN, there are other factors which are controlled by the platform contributors. First of all, the use of the platform in its current state should be better promoted. Until now, the publicity effort was minimal. For instance, placing the software on a portal like SourceForge.net would certainly increase its visibility.

The WEBGEN services would also be easier to use if a standard data model existed to describe the services (see above). Such a data model would not only solve the issue of the syntactic description of the service interface (what parameters are required and how they must be represented), but also provide information on the capabilities and conditions of use of the service (what does the service do, what are the typical fields of use, and what are the limitations). Finally, the best way to promote WEBGEN is probably to keep on showing the value of the service-oriented approach for cartographic generalization through new studies. This could, for instance, include a continuation of the studies initiated by [NEU 05] and [NEU 09]: research on the use of the platform to dynamically chain services, within the field of on-demand map creation, as well as research on parallelization in order to accelerate the execution of complex processes.

9.8. Acknowledgments

The original version of WEBGEN was developed at the University of Zurich by Moritz Neun while he was working on his doctorate, funded by the Swiss National Science Foundation (SNF) through the DEGEN project (SNF no. 200020-101798). The extension to the original prototype, to make it compatible with the OGC's WPS standard, was funded by the Ordnance Survey (GB). We wish to express our gratitude toward the organizations which took part in the funding as well as toward the colleagues mentioned above who contributed their ideas and algorithms.

9.9. Bibliography

[BOB 08] BOBZIEN M., BURGHARDT D., NEUN M., WEIBEL R., “Multi-representation databases with explicitly modeled horizontal, vertical and update relations”, Cartography and Geographic Information Science, vol. 35, no. 1, pp. 3–16, 2008.

[EDW 03] EDWARDES A., BURGHARDT D., BOBZIEN M., HARRIE L., LETHO L., REICHENBACHER T., SESTER M., WEIBEL R., “Map generalisation technology: addressing the need for a common research platform”, 21st International Cartographic Conference, Durban, South Africa, 2003.

[FOE 08] FOERSTER T., BURGHARDT D., NEUN M., REGNAULD N., SWAN J., WEIBEL R., “Towards an interoperable web generalisation services framework – current work in progress”, Proceedings of the 11th ICA Workshop on Generalisation and Multiple Representation, Montpellier, France, 2008.

[FOE 10] FOERSTER T., LEHTO L., SARJAKOSKI T, SARJAKOSKI L.T., STOTER J., “Map generalization and schema transformation of geospatial data combined in a web service context”, Computers, Environment and Urban Systems, vol. 34, no. 1, pp. 79–88, 2010.

[LAN 91] LANGRAN G., “Generalization and parallel computation”, Map Generalization: Making Rules for Knowledge Representation, Longman, London, pp. 204–216, 1991.

[MAC 07] MACKANESS W.A., RUAS A., SARJAKOSKI L.T. (eds), Generalisation of Geographic Information: Cartographic Modelling and Applications, International Cartographic Association, Elsevier, 2007.

[NEU 05] NEUN M., BURGHARDT D., “Web services for an open generalisation research platform”, 8th ICA Workshop on Generalisation and Multiple Representation, A Coruña, Spain, 2005.

[NEU 08] NEUN M., BURGHARDT D., WEIBEL R., “Web service approaches for providing enriched data structures to generalisation operators”, International Journal of Geographical Information Science, vol. 22, no. 2, pp. 133–165, 2008.

[NEU 09] NEUN M., BURGHARDT D., WEIBEL R., “Automated processing for map generalization with web service”, GeoInformatica, vol. 13, no. 4, pp. 425–452, 2009.

[PET 06] PETZOLD I., BURGHARDT D., BOBZIEN M., “Workflow management and generalisation services”, 9th ICA Workshop on Generalisation and Multiple Representation, Portland, OR, USA, 2006.

[REG 07a] REGNAULD N., “A distributed system architecture to provide on-demand mapping”, Proceedings of the 23rd International Cartographic Conference, Moscow, Russia, 2007.

[REG 07b] REGNAULD N., “Evolving from automating existing map production systems to producing maps on demand automatically”, 10th ICA Workshop on Generalisation and Multiple Representation, Moscow, Russia, 2007.

[REG 07c] REGNAULD N., MCMASTER R., “A synoptic view of generalisation operators”, Generalisation of Geographic Information: Cartographic Modelling and Applications, Elsevier, Amsterdam, The Netherlands, pp. 37–66, 2007.

[RUA 02] RUAS A. (ed.), Généralisation et Représentation multiple, Traité IGAT, série Géomatique, Hermès-Lavoisier, Paris, 2002.

[SES 99] SESTER M., Automatische Generalisierung mittels Ausgleichun, No. 17, Mitteilungen des Bundesamtes für Kartographie und Geodäsie, Verlag des Bundesamtes für Kartographie und Geodäsie (BKG), Berlin, 1999.