Mapgets: A Tool for Visualizing and Querying Geographic Information Agnes Voisard Institut fur Informatik Freie Universitat Berlin Takustr. 9 D-14195 Berlin Germany E-mail:
[email protected]
(to appear in Journal of Visual Languages and Computing, 1995)
The author has been supported by DFG grant No. Schw 415/1-2.
1
Abstract. Although geographic applications vary widely, their user interfaces have many requirements in common because of the spatial component of their data. Geographic data is not standard data, and appropriate tools are required (i) for editing (i.e., displaying and modifying) and (ii) for querying it. In this paper, we rstly study the major aspects of visualizing and querying geographic information within a database management system (DBMS) and their impact on the design of graphical geographic database user interfaces (GDUIs). We then present a map editing and querying model
as well as a general GDUI architecture. Both rely on the concept of the mapget (map widget), a mediator for manipulating geographic information interactively.
Keywords. Geographic information systems, database management systems, graphical user interfaces, cartography.
2
1 Introduction Ecient human-computer interaction is of increasing importance in many new database applications such as CAD/CAM, environmental management, or multimedia. In the area of geographic information systems (GISs), little e ort has been made to provide both designers and end-users
with appropriate tools for manipulating geographic data. Here we focus on GISs using a database management system (DBMS) as a support. Geographic database user interfaces (GDUIs) are concerned with two major aspects: (i) editing
and (ii) querying geographic databases (i.e., data sets where data is mainly geo-referenced data). We refer to the objects of interest of the database as geographic objects, and we focus on visualizing and querying them through some user interface. In the sequel, we de ne a map as a collection of geographic objects, although this term may not correspond to the term \map" used by the GIS community (we will get back to this notion below). Map visualization re ects the contents of a geographic database while obeying cartographic rules. Attempts have been made to understand end-users' needs [1, 2] and languages have been designed on top of SQL to embed cartographic features within the query language (see below). As an intermediary step, in order to help the user understand some map concepts and to manipulate geographic information, proposals have been made to move away from the classical database-map paradigm. These solutions stick to the mental model of the possible end-users and are usually based on di erent families of metaphors such as the geographer's desktop, the room metaphor or the map-overlay metaphor (for a comprehensive survey see [3]). Map querying can be either alphanumeric querying (e.g., \What is the population of France?") or spatial querying (usually expressed graphically). In the latter case, it is tightly coupled to user 3
interface aspects (e.g., \What are the drugstores in this area?", this area being drawn on the screen by the end-user). Some work has been done in the area of spatial query languages to provide the end-user with the possibilities of posing both alphanumerical and graphical queries. A customary approach is to extend SQL with spatial concepts [4, 5, 6, 7]. Other approaches o er a natural language based interface or a graphical query language based, for instance, on QBE (e.g., [8]), although these solutions are somehow limited and might lead to ambiguities. Another aspect of map querying is higher level (meta) querying, which cannot be handled by languages a la SQL. For instance, in the query \What are the categories of land use?", the end-user refers to the metaschema of the database. We can see already that interactive map visualization and querying require an elaborate graphical user interface together with a powerful query language for alphanumeric, spatial and meta querying. As far as DBMS environments are concerned, although they sometimes provide basic features to handle geographic data (such as spatial indices or ecient geometric processing), they are usually not designed to manipulate them graphically in an ecient way. In addition, even though visual languages have been de ned to show the contents of standard databases (e.g., [9]), only a few DBMS [10, 11, 12] o er a customizable and extensible graphical user interface (GUI). Designing a GDUI in this context becomes a dicult task. GISs are concerned with many di erent areas, such as planning, resource management, climate research, trac control, which may have an impact on the functionalities of a GUI (data input, cartography, representation of fuzzy objects, animation, use of graphic tools for statistics, etc.). The challenges in designing general GDUIs are partly due to this diversity and to the speci c characteristics of GIS end-users. Firstly, they are usually naive users who are unable to formulate 4
complicated queries. Asking them to master database aspects such as schemas is therefore hardly realistic. Secondly, they sometimes only have a vague idea of what they are looking for and rather than expressing exact queries, they may prefer to browse geographic information. Thus we intuitively see the need for a concept such as hypermaps, where maps have dynamic links to either other maps or hyper-documents [13]. Given these observations, the goal of this paper is rstly to gain some insight into the functionalities that a GDUI should provide, and then to propose a exible framework that both meets these requirements and satis es a large number of users. We believe that GDUIs will play a major role in the GISs of the future. To our knowledge, no work has been done so far to understand in detail the problems of designing powerful GUIs for geographic applications when connected to any DBMS. One of these problems is that such a design involves geographic DBMS features as well as graphic tools. A lot of progress has been made in both areas independently in the past ten years, but the bridge between them still has to be built. Recent work by ESRI, one of the world's leading GIS vendors, shows a trend in that direction with the new ArcView 2 product [14]. This paper is organized as follows. Section 2 outlines the main aspects of geographic information editing and querying. Section 3 tackles the problem of GDUI design: we list the major requirements of a GDUI and we discuss the advantages and inconveniences of two design approaches, namely strong integration vs. weak integration into a DBMS. Section 4 proposes a model for visual map manipulation embedded into a general map editing kernel architecture. This model hinges on the concept of the mapget (map widget), an integrator of an interface and a DBMS environment. Section 5 sets out our conclusions.
5
2 Geographic Information Visualization and Querying The goal of this section is to show the peculiarities of visualizing and querying geographic data (maps) as opposed to \standard" data (purely alphanumeric). We sum up the main aspects of map editing with emphasis on cartographic aspects. We then propose a taxonomy of queries one is likely to pose against a geographic database. The terminology not being standard in this domain, we start with an informal de nition of the terms used throughout this paper. The main objects we consider are maps stored in a database (sometimes called \thematic maps" or \themes" or \layers" in the literature). The geometry of a map can be either in a vector format or in a raster format (satellite images). We focus here on maps whose geometry is stored in a vector format. Generally speaking, maps are collections of geographic objects. For instance, a country is a geographic object. A geographic object has two parts: an alphanumeric one, or description (e.g., the name and population of a country), and a spatial one corresponding to its geometry. Usually, the geometry is constructed using the basic types point, line and polygon. In addition, a geographic object can be atomic or complex (made of other geographic objects). A city composed of streets and buildings
is a complex object. A map is more than a complex geographic object as it includes information on data it contains such as the coordinate system, the source of information, etc. A geographic database is a collection of maps. Note the di erence between a map as it has just been de ned and
the common term \map" which denotes a nal (and frozen) representation, for instance on paper, of what is called a map here.
2.1 Map Editing Map editing is concerned with both displaying and modifying maps. Displaying maps usually refers rstly to the display of the spatial (geometric) part of their geographic objects. Given the current 6
user interface technology, what the end-user sees and interacts with are cartographic objects in windows. The geographic objects' description can be displayed after pointing to cartographic objects. Displaying maps is even more complicated than just displaying raster, vector and alphanumeric data in a simple way: the end-user may want to have a simultaneous view of di erent maps (multiple windows), to superimpose several views of the same geographic space (map overlay), to attach a legend such as a color or a text to maps (see below), to change scale (e.g., zoom) on a whole map or on a subset of a map, etc. Another challenging problem is to display data at various scales and with di erent representations. A well-known related issue is generalization [15, 16], which serves to modify the representation of geographic data according to scale (e.g., for displaying in a smaller space). Hence a zoom operation becomes more elaborate than the equivalent of magnifying glasses. New cartographic objects can be computed by:
Simplifying the contour of a 2- or 1-dimensional geometric object (dropping points on a line).
Assigning a new representation to a geographic object according to scale. For example, a city represented as a polygon in the database can appear as a point or an icon. In the worst case, if the scale is too small, the geographic object will disappear unless it has some \semantic importance" [17].
Aggregating sub-objects that represent a partition of the plane. For example, on a map of states made up of counties, only the contour of the state (derived from the geometric union of the counties' geometry) could be shown.
Selecting sub-objects of a complex geographic object. For instance, on a map of cities, just represent a few buildings of each city. This shows that m geographic objects (the buildings 7
that compose a city) can be represented as n (n
