Introduction

Terrain models used in GIS are discrete approximations of real terrain. A terrain model consists of a subdivision of a planar domain into cells (usually, either squares, or triangles), together with predefined rules for approximating the terrain surface and its attributes within each cell. The resolution of a terrain model refers to the size of its cells, and can be either uniform, as in regular square grids, or variable, as in Triangulated Irregular Networks (TINs). The accuracy of a terrain model refers to the error made in representing a real terrain, and may concern approximation of either geometric measures such as elevation and slope, or non-geometric attributes such as soil type and land use. Accuracy naturally increases with resolution. On the other hand, also the cost of storing, manipulating, analyzing, and visualizing a model increases with resolution.

[AL MOMENTO LEVEL OF DETAIL E' DEFINITO PIU' AVANTI (SEZ.5.3) COME TERMINE GENERICO PER RIFERIRSI SIA A RISOLUZIONE CHE AD ACCURATEZZA. FRSE PUO' ESSERE OPPORTUNO DEFINIRLO GIA' A QUESTO PUNTO E SOSTITUIRE EL SEGUITO DIVERSE OCCORRENZE (NON TUTTE!) DI RESOLUTION E ACCURACY CON LOD.]

Contemporary remote sensing technology can already provide data samples at a ground resolution of 1 meter and an accuracy in elevation of about half a meter, on the whole surface of earth [Dowman1999]. Data of this kind are actually acquired and stored systematically by geographical agencies of many countries. Very high resolution (up to WW cm) and elevation accuracy (up to ZZ cm) can be achieved locally with on-field photogrammetry devices.

[NOTA ENRICO: MI MNCANO QUESTI DATI, NON LI HO TROVATI SUI NOSTRI LIBRI. CHIEDERE EVENTUALMENTE AGLI ARCHITETTI].

More and more data of the latter kind are also available, at least in urban contexts. With such a wealth of data it would be possible, at least in principle, to build and update a global terrain database at very high resolution, with an accuracy sufficient to support any possible application at any possible location on earth. In spite of the huge size of data involved, nowadays such a database could be actually built and stored. However, its management is far from being a trivial issue.

An obvious observation is that not all applications need to work at the same scale, i.e., with the same resolution and accuracy. There are applications that need very high accuracy on a very local domain (e.g., architectural design), and applications that work with low resolution on a very large domain (e.g., weather forecast at a continental scale), as well as applications that span a whole range of different domain sizes and resolution/accuracy. Last but not least, there are applications that may highly benefit from a model having resolution and accuracy variable through the domain. Examples are landscape visualization, road planning and design, viewshed analysis, etc. Some such examples are discussed in Section [*].

Thus, given a reference model at the highest possible resolution and accuracy, and possibly on a global scale, the following basic problems arise:

The first issue can be seen as a problem of spatial indexing, while the second issue is more a problem of terrain generalization. A key aspect in the latter case is to optimize the trade-off between accuracy of representation and efficiency of operations. Naive solutions such as direct sub-sampling of regular grids give poor results, since resolution is reduced uniformly over the whole domain, disregarding terrain roughness and features. TIN-based techniques for terrain generalization give well-established means to maintain a relatively good accuracy by reducing the resolution and size of a model adaptively. On the other hand, on-the-fly generalization of rough data at very high resolution may be often impractical, due to its computational cost. Also separate storage of multiple models at different resolutions may easily create consistency problems, and it is insufficient for those applications that may require different resolution and accuracy in different parts of the domain.

Multiresolution terrain models have been developed in the literature to cope with these problems. Such models are built off-line from data at high resolution, and corresponding data structures are stored together with their access methods. Representations of a terrain at variable resolution and accuracy can be retrieved on-line from such data structures, according to the current needs of each application task. Accuracy requirements may be variable both in space and in time. For example, in landscape visualization, the accuracy needed in the various parts of terrain depends on their distance from the viewpoint, whose position may change over time.

Multiresolution models may also act as spatial indexes, since their internal organization naturally supports top-down spatial access. This additional feature makes such models not only suitable to provide the proper terrain model according to the requirements of a given application, but also efficient in supporting spatial queries.

In this paper, we address the management of resolution and accuracy in terrain modeling, in the context a prototype system called VARIANT (VAriable Resolution Interactive ANalysis of Terrain). The system is based on the Multi-Triangulation (MT), a multiresolution TIN-based model that we developed in our previous work [Puppo1996,De Floriani et al.1997,De Floriani et al.1998,Magillo1999], and it is implemented upon an object oriented library for managing the MT [].

The main idea behind VARIANT is to provide an extensible system which can be integrated with modules performing terrain analysis and processing, with the additional feature of using resolution and accuracy of the representation, possibly variable over the terrain domain, as further parameters in computation.

VARIANT directly supports basic spatial queries, as well as a few high level operations. However, the main purpose of the system is to provide the basic mechanisms to manage multiresolution, and to allow users to write extensions, i.e., specific application modules, which can exploit its multiresolution features in a transparent yet efficient way. An application can make simple use of VARIANT just as an interface to the database, in order to obtain models of the desired domain and at the desired resolution. But the major advantage of VARIANT consists in the possibility of writing applications that directly exploit its multiresolution features during computation.

The system consists of a few intercommunicating modules. A kernel encapsulating the data structure for the multiresolution model, together with operations for constructing and querying it, provides the basic engine to manage multiresolution. The multiresolution data structure is built off-line from high resolution data, by specific construction modules; the system provides some such modules, and others can be built according to specific application needs, by exploiting the construction primitives in the kernel. Once the data structure has been built, data can be accessed by application modules (programs) through query operations provided by the kernel. The system already supports terrain visualization, and some tasks in terrain analysis (e.g., extraction of contour lines, computation of visibility, etc.), which are designed to exploit variable resolution, and can be taken just as examples of possible application modules.

The remainder of this paper is organized as follows. Section [*] contains an outline of related work. Section [*] gives a brief description of the multiresolution model at the basis of VARIANT. Section [*] provides an overview of the architecture of VARIANT. Section [*] describe the system kernel in more details. Section [*] describes general criteria as well as tools available in the system to support multiresolution queries. Section [*] describes construction modules that are used off-line to build a multiresolution model. Section [*] describes a few applications that exploit multiresolution features on-line in terrain analysis and visualization, and also gives an outline of general mechanisms to extend the system with more applications. Finally, Section [*] contains some concluding remarks and directions of future developments.