Towards Open Geo-Visualization Services

Stefan F. Keller

Center for integrated Geo-Information Systems
University of Applied Sciences Rapperswil, CH-8640 Rapperswil
fax +0041 055 222 44 00,,

Keywords: Geo-Information, Visualization, Web Services, Interoperability,
Model-based Method, Standards, SVG, UML, XML Schema, INTERLIS


Driven by the new information and communication technologies (ICT), geo-information services are more and more gaining attention in research, industry and administration. But how these services are designed is still an open debate. A common goal is to produce a cartographic product portrayed either on screen or printed on paper, with new properties, like interaction. Solutions to common goals are summarized in five theses about geo-visualization services.

In a background chapter, we will present an ICT Framework based on open standards. This will lead us "towards open geo-visualization services". "Model-based" means the application of data modeling with UML and the usage of system-neutral and platform-independent interface services with INTERLIS. XML-encoding rules automatically specify data structures and application programming interfaces can automatically be derived both from application schemas.

In a feasibility study we exemplify how extendable the model-based method and this ICT framework is: By adding a single software component to existing INTERLIS-based tools it was relatively easy to generate SVG documents. The results are being evaluated and experiences reported.

Finally, in the outlook, criteria on future standards are presented and ideas on a common model-based web service model are collected. Quite some questions will remain to be solved - but users don't have to wait for standards: The model-based method is ready including tools; this will make it easier to adopt new trends, whatever they are.

Introduction: The Challenge about Users Acceptance!

The main promise of geo-information technology is the ability to capture, maintain, analyze, or simply to visualize some spatially related data (geodata) in order to answer a given question or task.

The common goal is that these tasks can be fast accomplished by geo-information software that is mainly running locally or remote as a technical service. All this should be easy to use and easy to configure... something that is a challenge to software engineers! Driven by users who ask for new Information and Communication Technologies (ICT), like the Internet or mobile devices, these technical services are becoming more and more available.

In our vision, which we try to explain and exemplify here, we are seeking for base information technologies, which have a strong background, which are generic, which are time tested, simple and able to adopt new trends. Note, that we are heading not only geo-information technologies but also more general to information technologies. These technologies serve as a tool for communication, specification and implementation of (spatial) "data infrastructures" as well as for the realization of the newest spatially related software components, which are offered in a competitive innovative market.

Given this goal the most urgent problem to resolve is interoperability of data and of processes. This is something, which is not only a challenge to software engineers. In fact, the end users are those who are in a position to accept or ignore standards and to whom we have to explain what "good" standards are. This means that a challenge takes place about standard acceptance of the users. The influence of this challenge to the quality criteria of standards is an issue we have to leave open here. Thus, this paper not only is a technical paper but serves perhaps also as a help to technically knowledgeable users for choosing the "right" standards.

Design of an ICT framework - A Vision

The essential question is: What are the basic building blocks of a well-understood ICT framework for connecting businesses and enabling geo-information access via the web? What are the criteria for "good" standards, which could contribute to such a framework?

Let's take geo-visualization as an example to explain an ICT framework, because it is one of the most "visible" geo-information services: It is about the production of - or the access to - a cartographic product with a given quality portrayed either on screen ("web mapping") or printed on paper.

Five Theses about Geo-Visualization Services

For explaining the needs of geo-visualization services as part of the vision of an ICT framework we collected five theses with accompanying solution proposals:

The solution cannot be an even faster deployment of all new solutions from vendors or standards from consortia as these often typically are proprietary or specific and do not fulfill the five criteria of "Open Standards".

Solution: Re-use existing self-describing base data and process it with interoperable self-describing services.

This will naturally lead to a more sophisticated data and software architecture.

Solution: One solution may be multi-resolution databases which can propagate changes coming from base data and are able manage manual changes on derived data (automated functions prevent from storing derived data).

The mix of content and presentation information in graphic data restricts the possibilities of flexible production, of personalization and customization to new media (thesis 1). New demands, like interaction, animation or 3D, will expose even more the inherent limitations of the traditional graphics based approach on which many actual web-mapping projects are built upon.

Solution: The clear separation of content and presentation data is the only way to open up the possibilities of map production. This has been already known for quite a long time by the so-called "view-principle" (often also labeled as "multi-channel output")

Exchange and integration of heterogeneous (geo-)data has become one of the biggest bottlenecks in re-using geodata.

Solution: Geodata modeling with a well-known data (self-)description language combined with well-known encoding rules - the so-called "model-based method" [1] - is probably the only possible way of overcoming this problem. The model-based method delivers even more benefits as we will see [9].

Remember that this old requirement from users is no yet reality - neither in geo-information community nor in ICT in general. Though it is and will be possible to realize some application interfaces for specific platforms [2] there remain important limitations. Therefore not only geodata but also (geo-information) services should be model-based.

Solution: What is needed is a common agreed "Common Model-based Web Service Model". The key idea of such a model is first to utilize the existing universal data description language and second to describe the semantics of a service in a well-known structure. In order to find such a "well-known service description" (a service metadata schema) a consensus process should be taken which includes not only industry but also the users who define and get finally the value out of a service.

Structure of the Paper

Before we present our approach to geo-visualization we want to give in the next chapter a background. This background consists of considerations on the nature of geodata and the role of SVG, a model of the geo-visualization process and our definition of what a model-based web service is.

Then, we present a feasibility study, which is based on tools, which are related to our so-called model-based method. In the "Evaluation" chapter achievements are presented and discussed.

Finally, in the last chapter we take a broad outlook. This chapter consists of five theses about future geo-visualization services, criteria about open standards, which will lead us to a common model-based web services model.

Background: Interoperability of Data and Processes

Because of the special nature of geodata interoperability of data and processes in geo-information technology is more difficult to achieve than perhaps in mainstream information technology: this type of data involves structured attributes of a special type and is closely related to the real world. Therefore geodata has many constraints, has complex data structures, and needs to be managed potentially in large amounts and most important: geodata involves potentially complicated processes beginning

Besides this, geodata has to be treated like any other data, namely consisting simply of objects with properties whereas some - or perhaps even none - properties are of a special basic type of a non-graphically related geometry. There is an important difference between geodata and graphic (CAD) data: geodata is simply a data object which can be visualized in many ways, or in other words, geodata can be graphically presented or portrayed as graphic data. Whereas a graphic data object has a mandatory geometry attribute associated with at least one graphic style. From a pure data structure perspective, graphic data as opposite to geodata in fact has a fixed data schema each class having associated a "default style", which consists of four types of objects: a point, polyline, area and a text labeling class.

Often, if one takes a look at so-called "geo-spatial data", one realizes that in fact this is graphic data (CAD data), not geodata.

Usage of Scalable Vector Graphics (SVG)

What is the usage of Scalable Vector Graphics (SVG) in these processes? Up to now, SVG has been mainly used in the following ways (see also [12]):

  1. As an encoding format for static graphic layout and presentation of vector data (page layout description language)
  2. As an encoding format for animated presentation of 2D data (animation language)
  3. As an encoding format for user-initiated events and definition of responses (interactive graphics)
  4. As an encoding format for graphic symbols; that means as a sort of "meta-graphics" for (cartographic) vector graphics
  5. As a transfer, exchange, archiving format of vector data (spatial transfer format)

Its use as a spatial transfer format (case 5) is a by-product of the first four usages; this is clearly not recommended for geodata in our sense but only for derivated graphic data for example for disseminating "pre-configured" graphics to known users. Using SVG as a format for editing geodata seems to us of very limited use, such as "red-lining".

Using XSLT for transformation of geodata encoded in XML to SVG is useful for some specific cases. But taking a closer look at XSLT it becomes clear that this is limited to specific cases, because it is both simple on the query (complex joins?) as well as from the preprocessing part (lacking functional language for analysis and geometry processing).

Using SVG for symbology seems to be promising, but here - on the other hand - the possibilities of SVG are too great for a simple integration in geographic information systems: At least some SVG syntax elements would have to be excluded, like e.g. animation (SMIL) and scripting (ECMAScript).

We will utilize SVG here mainly for the portrayal of geodata (case 1). But due to our generic approach SVG can also be considered for all other cases. We will discuss this later on in the evaluation and outlook.

A Conceptual Model of the Geo-Visualization Process

The basic graphic presentation process is defined in figure 1. This abstract schema indicates roughly the data flow and the dependencies (dashed) starting with non-graphic geodata until it gets visualized on the graphic display as graphic objects. This is sometimes also called "the map styling model".

Process and data flow from geodata to graphic data

Figure 1: Graphic descriptions, on one hand built upon data and views, on the other upon graphic (process and data flow) [7] [11].

This conceptual model is a result of ten years experience in implementing software and maintaining large amounts of geodata [7] [11]. We clearly understand graphic data as output or intermediate data. One of the important features of separating content from its presentation is, that the graphic presentation can be chosen freely according to the communication purpose. In other words, there is not a one-to-one relationship between data and graphics - as this is implied by many web-mapping projects - but this is a one-to-many relationship. Any change in the data except either in the base data or in the standardized graphic description (a sort of legend and plotting configuration file) will lead to data sets which are hard to update.

Model-based Web Services

Slightly changed from a definition from ISO 19119 [3] a service "is a collection of operations, accessible through an interface". That allows to remotely call an application which returns information of value to an initial user. Note, that this is a different definition of service in the user (client or consumer) point of view. For users, "service" means a business activity. In the remainder of this paper we refer to the technical meaning of "service".

A Web service in the technical sense is "An interface that describes a collection of operations that are network accessible through standardized XML messaging." [4]. "Behind" the interface there is an "encapsulated" application, which is self-describing and behaves as a software component in a possible processing sequence. This application (or service) can be published, located, and invoked across the Internet.

A "geo-visualization service" is a specialized web service, which delivers a graphic presentation (a map) based on a remote request. With "geo-visualization" we mean the graphic presentation (or portrayal) of geo-referenced, non-symbolized data (called "geodata"). In contrast to graphic data, non-symbolized geodata is completely separated from graphic information like style (i.e. color). Non-symbolized data is modeled typically in an object-oriented way according to the inherent structure and behavior of real world phenomena.

We chose "open" because these services consist of software components, which contain explicitly documented program interfaces based on freely available "open standards". Open also indicates new business opportunities. But what is "model-based" in this context?

The Model-based Method

"Model-based" stands for data, service interfaces and services (applications) that are first described in an application schema by using a precise well-known description language, such as the Unified Modeling Language (UML). The resulting structured documents (so-called metadata!) are the means to "self-containing, self-describing" applications as mentioned above.

What about using UML for these self-containing descriptions where first users and software engineers can make a sense about what the service offers and second, just as a by-product, formats or application program interfaces can be generated automatically? Encoding rules could automatically take data structures, like eXtensible Markup Language (XML), and allow that application programming interfaces can automatically be derived both from the existing application models.

Unfortunately, standard UML, being the language of choice for conceptual schemas, is not enough for a precise common understanding both from the precision of what it covers as well as from what aspects it covers: First, UML lacks common defined basic data types as well as related encoding rules for the mapping and generation to a format description or an application interface description. Second, UML also lacks specialized spatial constraints, a query and as well a mapping language. XML Schema comes closer to this goal, as it is a textual a structure description language including some basic data types, but it lacks above mentioned properties needed for self-describing web services, especially for geo-visualization services.

Here INTERLIS [7] comes into play. The INTERLIS specification was specified and established as a de-jure standard in Switzerland before UML became the international language of choice. What makes INTERLIS so appealing is, that it not only covers all aspects of an UML structure diagram but also fills the gap for the lacking aspects. And very important: being a textual language it serves as a central data and application documentation as well as an open exchange format across geoinformation processing tools.

Note that an XML encoding can be used in two possible ways:

Again, with data we mean either (spatial) objects, or data for data catalogues or service descriptions. But what UML together with INTERLIS really deliver, is a precise structure (metadata) description. This is at least an underestimated component in the design of an ICT framework. It is also a fundamental misunderstanding, that automatic encoding is only a matter of a file format not of interest for "services".

The value of such precisely defined data structures comes into play when we try to define interfaces for web services. With the model-based method, applications will span many platforms and be open to changing standards (and markets!). Model-based web services can start by implementing base geodata dissemination and can be implemented step-wise up to completely modular and freely collected components.

Although this approach follows international standards (like the ISO 19100 [3] series or the "model-driven architecture", see [5] and though data modeling is well established in database technology, researchers and users in cartography only recently began to exploit this method. What "model-based" really means is being explained more in-depth in another paper of this conference [1] and elsewhere [10].

A Feasibility Study

In a recent feasibility study a software component for geo-visualization has been realized in order to produce new cartographic products such as those for web mapping and those targeted towards output to a hard copy. The broader goal of the feasibility study was to demonstrate the potentials of our generic ICT framework.

Feasibility Study Design

The software component takes INTERLIS base geodata (or almost any other format) and generates SVG output according to a standardized description either for the geodata as well for its graphic portrayal. As an added value, the inclusion of simple interactivity should be demonstrated, by integrating hyperlinks. The graphic SVG outcome includes colored styles or symbols, which in turn are also managed in the interoperable INTERLIS/XML protocol format.

Both, input data of and output data from of this components can be seen an object stream coming from a data service and sinking into a graphic service. All this is processed under the control of a "geo-visualization service". In our case, the geo-visualization service consists of three interfaces (data service, portrayal service and graphic mapping and rendering service). The sub-components inside this geo-visualization service are not yet services on their own but these are also candidate services with fully documented interfaces.

In figure 1 the geo-visualization includes the following indicated sub-components: Views (query processing), Graphic Definition (mapping to symbols/signatures/styles) and part of the Graphic renderer (in our case, the actual rendering is being done by SVG viewer software).

All services communicate through interfaces as shown in figure 2, where they are indicated with two black bars.

Self-describing services

Figure 2: "Self-describing" services (software components) that communicate through interfaces where both - interfaces and the purpose of the data and services - are described and generated using a universal data structure description language.

With the publication of the SVG specification there exists a promising graphic vector output format, which is a good match to our open standard criteria mentioned at the end of this report.

These are prerequisites used in the specific context of this feasibility study:

Table 1 shows the standards used in the feasibility study. XHTML and the Portable Document Format (PDF) have been used for software documentation.

Because of the existence of several tools which can process INTERLIS and which can display SVG, the actual software component that remained to be realized, was a sub-component for generating SVG output from objects passed by a an application programming interface (API) of an existing conversion system and data delivery service.

Table 1: Standards used in the feasibility study.
Standard Version Status URL
UML 1.4 stable
INTERLIS 1.1 and 2.2 stable
XML Schema 1.4 stable?
XML 1.0 stable
SVG 1.1 stable?
HTML, XHTML 1.1 stable?
PDF 1.4 stable


The used component is a highly configurable file conversion system with an INTERLIS-based software library. The library is called "INTERLIS conversion system" by InfoGrips [8]. The name of this sub-component is "SVG writer module". The resulting module can be plugged into the INTERLIS conversion system. The sub-component can be found on the right part of figure 2, indicated as "Output module".

This system in turn can be used as a sub-component to a base geodata viewer, delivery and integration service. The vendor who offers the ICS library calls this web application "GeoShop" [8].

The SVG writer module was realized in C by a couple of computer science students. This prototype is freely available under BSD license at

The realization of the SVG writer module took about a week to finish including users and programmers documentation. The implementation phase was so short because of the many existing tools and the main work was to code the sub-component against the programming interface of the software library.


For the continuing tests of the SVG writer module two data sets have been taken from land surveyors base data (all uncompressed extended ASCII):

Several SVG documents ("plots") have been generated. An SVG document could be produced from both test data sets.

The SVG documents have been visualized with the following software:

See figure 3 for an example.

Map from the first test geodata set

Figure 3: Map from the first test geodata set [click here or into figure to see SVG document].


The main goal of the feasibility study could be easily reached: The two generated SVG documents could be produced from the two test data sets. They have been successfully validated against the SVG structure (DTD). Any data set in any format supported by the INTERLIS conversion system now can be converted to SVG documents.

A visual assessment of the resulting screen maps served as a first evaluation of the resulting SVG documents. Further evaluation for better symbolization of generalization of the output is out of scope of this study.

Implementation Experiences

One of the main problems we have encountered is, that the SVG viewer plug-in from Adobe was the only one, which could successfully process the second test data set. All other SVG viewer software did not succeed to load this amount of data. Large data sets are typical for geodata. This is an open issue to be resolved outside our prototype software.

A well-known problem is the transformation of the coordinates in geodetic reference system to the screen oriented Cartesian coordinates with the inverse increasing northing values (vertical axis points downwards).

Another problem was the reorganization of the selected data objects according to their symbology and - related with that - according to their visual priority before they are output to the SVG document (rendering order). This is a basic inherent issue of the transformation process from geodata to graphic data which always takes a certain computation time and temporary storage.

Two very useful properties have been given to all generated SVG objects: An attribute containing an object identifier as a reference to the original geodata object(s) and an attribute indicating the object class name(s).

Future Work

During implementation and test, we have identified the following next steps as future work:

What is obviously lacking are data structures and functionality needed in order to produce generalized maps. In our research we try to extend the geo-visualization model, which includes an object-oriented, multi-representation management of geodata and product specific graphic data.

From a lesson learned about specifying generic standards we like to give recommendation to the development of SVG: keep it simple! If needed, modularise it in clearly distinguishable parts (candidates are interactivity, scripting and animation).

With respect of the broader goal investigating the ICT framework much remains to be done, as we will indicate in the next chapter.


In the introductory chapter we asked for the basic building blocks of a well-understood ICT framework and for "good" standards, which could contribute to such a framework and consequently also for national and global spatial infrastructures. In the background chapter we explained how the model-based method for data and services is a very promising solution to the interoperability problems we are facing today for data exchange as well as for service interoperability.

In the following section we try to establish criteria on future standards.

Five Criteria on Open Standards

These five criteria for "open standards" first have been internationally presented by a Swiss experts delegation at a meeting of an ISO group in Washington D.C./USA in 2001 [6]:

In table 2 we tried to collect for all relevant communication layers the available mainstream standards needed for interoperability between services. The table shows that there are many question marks indicated.

Note that for interoperability of services all (!) communication layers need to be explicitly specified before hand in contrast to interoperability of data where mainly the application layer must be specified. Focusing first on interoperability of data is the message we are sending out with INTERLIS since years with growing success.

Table 2: Communication layers and associated standards (parentheses indicate not yet established candidate standards).
Communication Layer Name Standard Generic Technology
Application Application Schemas Data Description


Function Description

Service Negotiation ?
Service Publishing & Discovery ? (JXTA?)
Service Sequencing (Workflow) ?
Service Description/Location ? (UDDI? JXTA?)
Transactions/Reliability/Routing ?
Message/Protocol XML / SOAP Protocol
Transport and Network HTTP(TCP/IP), SMTP

If standards conform to these criteria they are good candidates for an ICT framework and, for example, form part of a common web service model, which is extensible according to local (federalistic) and future needs.

A Common Model-based Web Service Model

What we try is to collect and design building blocks of a common model-based web service model on top of the above-mentioned standards (c.f. table 2). In figure 4 there is a proposed sketch of common web service interactions needed in order to publish (step 0), find (steps 1 and 3), and finally call (step 3) web service A1 (application A), which delivers the desired response (step 5).

The interaction model in figure 4 is very similar to the one a working group of OGC proposed recently as a "common OGC services model". The common issue is that everything is based on interfaces of data and operations.

A Sketch of a Common Web Service Model

Figure 4: A sketch of a common web service model.

In table 3 there are some web service operation names and operation descriptions listed in order to give an idea about what type of services are meant. There are some OGC specifications mentioned, like the web map server (WMS, raster maps), the web feature server (WFS, vector data) and the web coverage server (WCS, imagery/elevation data). Currently, they all are "multiple platform-specific" and not platform-neutral. Sooner or later, these specifications probably need to be reengineered; there would be means to simplify this task.

Table 3: Web service operation names and descriptions with standards to consider.
Operation Name Description Standard Candidates for Output / Response
GetRasterData Gets raster data objects OGC WMS?
GetVectorData Gets vector data objects typically from a database INTERLIS! OGC WFS?
CalculateView Filters data objects and/or calculates a view INTERLIS? OGC Catalog Server? SQL?
CalculateTransform Calculates a transformation between datum and coordinate systems INTERLIS? OGC Transformation?
MapObjectsToSignatures - INTERLIS? OGC SLD?

What turns out to be essential - besides the many open issues - is, that we need to agree on a common web service description schema! Here, the platform-neutral model-based method comes in again: What we already have is a common language to model such a schema and encode the resulting data! So, why invent yet another XML dialect by hand?

What already are in discussion now are standardized schemas about data (so-called metadata about data!) like the following, all described in UML, INTERLIS and XML Schema:

What we now look for is a web service schema consisting of a publication description and a service binding: this is what is perhaps meant by "metadata about services". In the simplest case it could be a collection of text fields used for the name and the description of a service. What makes this model common before hand is that it uses time proofed communication means such as UML and INTERLIS and that there exist already a lot of INTERLIS-based tools for the creation and configuration of related applications.

So, we have a lot of questions to consider:

  1. How to establish a network of heterogeneous clients and distributed servers in order to publish and find web services (peer-to-peer technology as shown in figure 4)?
  2. What are the common generic operation semantics, like publish, find and bind? Being loosely coupled operations they should remain state-less as far as possible; can they?
  3. How does a given service communicate with another one in order to establish a sequence or chaining (a workflow) of services, (as shown in figure 4 in step 6 between service A and B)?
  4. How do we design typical services for common tasks, such as geo-visualization, and draw the line in the form of interfaces (as shown in table 3)?
  5. How far can we build on mainstream standards (as shown in table 2)?

But, before we come to discuss these questions, there is still an open debate about how to combine the multiple platform-specific approach (of OGC) and the model-based, platform-neutral approach (of ISO, the approach also proposed here).

Conclusion: Towards Open Geo-Visualization Services

Currently the ICT is changing even faster than before - at least measured in amounts of paper and words. But viewed from a distance it becomes clear that there are still the same interoperability problems around to solve. Still, there is quite some standard specification and adoption work ahead.

We think that users don't have to wait for standards anymore as they can start defining their schemas (application metadata) right now with UML and INTERLIS: encoding rules will provide automatically derived data formats, like XML Schema and/or derived interfaces, like IDL successors. If - perhaps in the future - new encoding rules appear, e.g. in the form the international ISO 19100 series, tools will help us to adapt to those new standards!

A timely adoption to new standards is exactly something that the top-down, platform-neutral model-based method tries to achieve. And even better: With the model-based method it is potentially possible even to be combined with future OGC specifications. On other words, also the common OGC services model could be enhanced with the model-based method just as it is being currently discussed in version 4 of GML, the XML vector format of OGC.

Some open standardization issues shown in table 2 perhaps are resolved by mainstream ICT. But, for the organization process to agree on a common web service schema for geodata is of such high priority now that we can't wait. Fortunately, we don't have to, if we adhere to the above-mentioned criteria on open standards!

Investigating best practices and standards for interoperability what we really need is a sound generic ICT framework with 'sustainable' standards designed by professional software architects. By virtue of the "model-based approach" this framework is system-neutral and will be capable to adopt forthcoming standards - like SVG. After over ten years of experience in the implementation and use of this model-based method we have enough indication that it is feasible and that it is the crucial factor of successful geo-information services.

As a conclusion we can state, that - due to model-based INTERLIS technology - a very advanced ICT framework and a geodata infrastructure is established in Switzerland ready for the implementation of open geo-visualization services!


The author would like to thank the GIS coordination center (COGIS) ( and the Directorate of cadastral surveying at Swisstopo ( for the support.


[1] A. Morf and H.R. Gnägi, "Generating SVG From System Independent Conceptually Modeled Geodata", SVG Open / Developers Conference, Zurich, Switzerland, July 2002.

[2] OGC, "Web Map Server Implementation Specification" and "Web Catalog Server Implementation Specification", Open GIS Consortium, USA, 2001.

[3] ISO TC211, ISO 19119 "Geographic Information - Services".

[4] M. Colan, "Evolution or Revolution? A Technical Overview of Web Services", Online-Presentation, September/October 2001.

[5] OMG, "The model-driven architecture" (MDA) - an inititative of OMG.

[6] ISO TC 211, "Presentation of the Swiss Member Body", ISO TC 211 Meeting, Washington D.C./USA, 2001.

[7] COGIS, "INTERLIS 2 Reference Manual", Coordination of Geographic Information and Geographic Information Systems (COGIS) c/o Swisstopo, Wabern, 2001.

[8] InfoGrips, "INTERLIS Conversion System - Users Manual", InfoGrips GmbH Zurich.

[9] J. Kaufmann and J. Dorfschmid, "Reflections on the benefits and potential economies of geographic data standards", L+T Report series, report no. 17, february 2001, Swiss Federal Office of Topography, Wabern.

[10] S.F. Keller and H.R. Gnägi, "Modeling Fuzzy Geospatial Phenomena Using Application Patterns And Standards". In: First International Symposium on Robust Statistics and Fuzzy Techniques in Geodesy and GIS, organized by International Association of Geodesy, Zurich, Switzerland, March 12-16, 2001.

[11] S.F. Keller and H. Thalmann, "Modeling and Sharing Graphic Presentations of Geospatial Data". In: Proceedings of the 2nd Intl. Conference on Interoperable Geographic Information Systems (interop'99), 10-12 march 1999, Zurich (ed. A.Vckovski) LNCS-series, Springer Verlag.

[12] A. Neuman und A. Winter, "Kartographie im Internet auf Vektorbasis, mit Hilfe von SVG nun möglich". Online publication, version 2.5, 4, december 2000.

Valid XHTML 1.0!