Towards a Toolbox for Geographic User Interfaces Agnes Voisard INRIA 78153 Le Chesnay Cedex France
[email protected] Abstract
User interfaces are a prominent part of applications that manipulate graphic data (geography, cartography, CAD/CAM, ...). Although some work has been done recently in this area, each system usually has its own ad hoc user interface built from scratch, and there is no user interface model general enough for customizing the presentation of a speci c application which handles graphic data. This paper presents a conceptual model for describing user interfaces of systems manipulating maps in an object-oriented environment. The model proposed here is split into two levels: (i) the Interaction level and (ii) the External Spatial level. The Interaction level deals with high level interface objects, such as windows, as well as the interaction with the end user. In particular, we see the necessity of introducing a new kind of window devoted to map editing. The External Spatial level deals with objects which come from a mapping of the database objects onto objects manipulated by the end user. This work is a rst step towards the speci cation of a general toolbox for handling a variety of geographic applications.
1 Introduction User interfaces play a crucial role in applications dealing with graphic data, essentially because of the nature of the manipulated data. In general, the design of a friendly user interface is a way to o er the end user a high level of interaction with the database, hiding the low levels (which can be very complex in such applications). We focus here on applications called Geographic Information Systems (GIS). Only recently has some work been done in the GIS area for taking into consideration the needs of end users. Among the rst attempts to describe the functionalities of a user interface for a GIS, see [EF88]. Various types of geographic applications exist, and end users' needs may widely vary. For this it is important to provide developers with a toolbox for describing particular user interfaces. To do this, we rst need to list the elements involved in such applications, and then to de ne a high level language for manipulating these elements in order to describe a large variety of (customizable) applications. This language itself could be used through a WYSIWYG (\What You See Is What You Get") user interface, but it is not our purpose to de ne the corresponding graphic language, and we will just focus on a description of functionalities, objects This work has been partially carried out while the author was visiting the Center for Environmental Design Research at UC Berkeley. Work partially supported by the French Programme de Recherches Coordonnees BD3 and the ESPRIT BRA working group \GOODS".
1
and operations. We are interested here in all kinds of applications that manipulate a large amount of data (maps) stored in a Database Management System (DBMS). One particularity of maps is the heterogeneous nature of the data they contain: alphanumeric data and spatial data are combined. The alphanumeric data can be seen as the description of the geometry they are attached to, or in other words, as the semantics. In the sequel, we do not consider applications involving three dimensions. We assume that data is already stored in the DBMS, and that the user will not input data, but manipulate it through operations and queries from a user interface, even if it is possible to create new data via operations or queries. Designing such a toolbox involves the manipulation of several models: The user data model is a model tailored for geographic applications. As an example, we take the model described in [SV89]. In this model, a map is a set of tuples, each tuple having two kinds of components: non spatial attributes, or description (e.g., population), and spatial attributes (e.g., a region). Operations such as map overlay are de ned on maps. The database model is the standard database model. We chose the O data model [BDK91]. The entities manipulated by O are complex objects that belong to classes to which methods (operations) are attached. The objects types are built from basic types such as real, string, etc. and constructors set, tuple and list. The de nition of classes and methods forms the database schema. The data representation model is the logical representation of geographic components in the database model. It corresponds to a map database schema (or application). The map display model handles objects manipulated by the end user through the interface. The display model proposed in this toolbox has two levels: { The level that comprises the high level objects of the interface, such as the di erent windows, and their reaction on a mouse click. In particular, there is a need for introducing a new widget type, dedicated to map displays (that we call Map widget or MapGet). We call this level, the Interaction level. { The level that manipulates the (visual) objects displayed inside a window, derived from a mapping of the database objects onto the low level interface objects. We call this level, the External Spatial level. Figure 1 summarizes the di erent models mentioned above as well as the connections between them. 2
2
We decided to deal with data stored in an object-oriented environment, because of the easy matching between the data representation model and the external spatial model, and because of its philosophy for manipulating data: indeed, the notions of complex objects and methods seem well adapted to the manipulation of such data. More precisely, we chose the O data model to follow the work presented in [SV91] where a GIS prototype realized at Inria is described. 2
2
Display User Data model
External Spatial model
model Interaction model
6
6
?
?
Application (schema) Database model (O )
Application X, Motif GKS
2
External level
Support level
Figure 1: The models involved in a toolbox de nition We believe that the attempt to de ne a general toolbox independent of the database model and available for all DBMSs is bound to fail. Nevertheless, given a database model, it is realistic to de ne an external spatial model independent of the application, with a mapping from one representation to the other. This model should be general enough for handling a large variety of applications. Since we would like a model that manipulates interface objects to be as independent as possible of the application, we must assume the existence of a module for mapping the database objects onto \visual" objects, i.e., the objects displayed on the screen and manipulated by the end users. The fact that we chose (1) the O database model and (2) a particular user data model is not a strong restriction. We will see that a modi cation of these hypotheses implies minor changes in the toolbox speci cation. For example, if the map schema changes, only the mapping module will have to be reconsidered. 2
A general toolbox should contain a basic (extendible) set of standard operations (methods in an objectoriented environment) for manipulating geographic data in the database, but also a way for easily describing the graphical objects, operations on them, and the interaction with the end user. The second point is the main focus of this paper. As this is not a toolbox speci cation using a programming language but the presentation of a conceptual model, it should be emphasized that implementation aspects are not treated in this paper. It is just a rst step towards a complete toolbox description using standard tools such as Unix, X Window System [SG86], Motif [OSF89]. This paper is organized as follows. In Section 2, we brie y list the main features of geographic applications with an emphasis on map editing. Section 3 gives an informal presentation of the Map Display Model as well as the map display mechanism. In Section 4, the Interaction Model is presented, which manipulates the high level elements necessary for the interface. The External Spatial Model (low-level interface objects and operations on them) is presented in Section 5. The object selection operation, useful in geographic applications and complex in this context, is described in Section 6. Finally, we conclude in Section 7.
3
2 Features involved in geographic applications In order to formulate the problem of designing such a toolbox, it rst seems necessary to describe the main parameters to consider for designing geographic applications. In this section, we survey these elements, with an emphasis on map editing. We then present brie y an example of a user data model which corresponds to objects and operations the user usually has in mind. Such a toolbox should provide also a powerful query language capable of dealing with geometry. For instance, the system must be able to answer the query \what are the districts whose distance to a given point x (clicked on the screen) is less than twenty kilometers". However, the study of such a language is not in the scope of this paper.
2.1 Map editing
Type of geometric data
We consider that the user wants to display maps stored in a database, but also images (bitmaps) which can be used for visualizing backgrounds. This is generally the case in most geographic applications. Maps and images represent, in this context, di erent kinds of objects, although they may visually look the same. However, in this paper, we focus our attention primarily on maps. As it is common in such applications, we assume that the user is interested in manipulating points, networks and areas. At a low level, this corresponds to manipulating objects of (basic) type point, line and polygon, as well as sets of these types.
Windows for displaying maps
We denote by window a rectangular zone on the screen, and we assume that a window may contain other rectangular zones, called subwindows. The user should have the choice of displaying all maps either in di erent windows or in the same one (by superimposing the maps or not). If the map display is always done in di erent windows, there is a bijection between the displayed maps and the windows containing them. It can also be useful to visualize several maps in the same window without superimposing them, for example to see simultaneously the detailed map of a city and the country to which it belongs. This can be done using subwindows. If the user wants to display several maps in the same window, for instance, for superimposing two thematic maps, the system must be enriched with the capability of managing several layers. One way to achieve this is to add to the system a map stack manager in which there is a notion of current map on top. The other maps (or possibly images) are behind the single active map, and can be seen as transparent layers. This implies a selector mechanism for switching to another active map.
Display parameters Nature of the display
By the nature of data there are two kinds of displays. We distinguish (i) the display of geometric data (graphics) from (ii) the display of the alphanumeric data associated with the geometry. Usually, the latter is obtained from the user interface by clicking on a particular object on the screen, and the object pointed out is highlighted. This supposes the existence of a database function, say Selection-by-pointing, for nding the object(s) containing a point. Note that the precision of a user click may vary from an application to another (this is particularly true for points and lines) and is an application parameter. The speed of execution of object recognition strongly depends on the way data is stored in the database. In particular, the use of an index, such as an index a la quadtree [Sam89], is very ecient for accelerating access to spatial objects. If space on the display is not partitioned (e.g, if two polygons overlap each other) the problem of con icts in the recognition of several elements picked up by the user arises. The system must propose a solution for solving this problem.
Scale and coordinate system
Geographic data is stored in DBMSs in a given coordinate system with a given precision. The coordinate 4
system represents the reference in a plane of the data stored. At display time, we introduce the notion of scale which represents the proportion between the size of the displayed objects and their real size. Scale might often change at display time, for example if the user wants to resize a window, or to zoom or pan inside a window. In any case, the system must o er the user a way for seeing the scale (for instance, next to the map, or possibly superimposed on it), and the possibility of seeing the coordinates of the objects displayed inside a window (for example, all around the display window). Thus two important variables to take into consideration are the coordinate system and the scale factor, which take a fundamental place at map display time.
Display size
The size of the window containing a map, as well as the size of the map displayed inside the window, depends on the user's choice (see Figure 2). The two main parameters to consider are (i) the map transformation factor (scale) and (ii) the window size. We consider the following cases: The transformation factor is constant. The transformation factor can be determined by the highest coordinates in x and y of the manipulated map. A rst solution is to set dynamically the size of the window that contains the map, in order to manage the fact that the map always ts exactly into the window that contains it (Figure 2.2). This solution is only available if the map size allows it. Another solution is to have exactly the same window size for all the map displays, i.e., a constant determined for a whole session (Figure 2.3). In this case, some maps can look very small in comparison with the size of the window (in particular if a map is extracted from another one). This is why this solution seems reasonable only if there are not big di erences in maps size. Nevertheless, it can be used for comparing rapidly the size of di erent maps (e.g., a county and a state), and also if the user always works in the same geographical area. The transformation factor varies. A solution is to combine the two previous ones (Figure 2.4), i.e., to manage the fact that the map ts into a window whose size is constant (pre-de ned). This can be seen as case 2.3, followed by a standard zoom operation. The last solution is to have a constant window size and to see only a part of the map. The rest of the map can be scrolled. However, it must be noted that there are some rules for transforming a map. In particular, when the scale changes, there must exist a ratio in x and y with respect to original data in order to avoid a distorsion.
5
X
X
.............. .... .. .... ..... .....
X
"
"
D
D
\
\
Figure 2.1: two maps at the same scale
X
X
X
.............. ...... . .... ... ....
C
C
e
e
Figure 2.2: the map ts into the window containing it
X
X
X
............... ....... ..... ..... ....
C
C
e
e
Figure 2.3: the window size is constant
( X
(
X
(
(
X
D X
X
D
?
\
D
D
?
\
Figure 2.4: the map ts in the window containing it and the window size is constant Figure 2: Several choices for displaying maps
Legend
Legend is a crucial element for interpreting a map. It is used to rapidly grasp the characteristics of an object by associating a visual symbol to it, either a color or a text or a drawing, etc. However, \legend" is a generic term that encompasses di erent notions and it is necessary to separate the di erent kinds of legends. We distinguish four kinds of legends, which can be applied to an object whatever its type is (point, line, polygon): 1. The name legend consists in displaying the name of objects on the screen (for instance, \San Francisco" near a dot on the map of California). 2. The theme legend consists in distinguishing objects of di erent characteristics, usually with color or patterns. 6
3. The symbol legend associates a graphic symbol with each \type" of objects (e.g. the drawing of a castle). 4. The statistics legend that describes values through graphical representations such as pies and bars (this presupposes the existence of a connection with a module dealing with statistics). It is possible to simply handle the name legends, for example by storing name positions in the DBMS. The interest of the theme legend is to group several objects having the same characteristics for a given component. We are then interested here in the attribute values of maps. A table of correspondence is associated with the database, and a window or editor shows the user the correspondence between an attribute value and its representation in the legend domain. Let us consider the two following cases: 1. Maps with textual attributes (as opposed to numeric). For thematic maps with only one attribute (for example, crops), the standard treatment of legend consists in choosing a color for each attribute value. For example, to color in yellow the area in which corn is grown on a crop map, or, on a more general map, to color the forests in green, the rivers in blue, etc. If the maps have di erent attributes, one solution consists in choosing a color per attribute (e.g. green for forests, yellow for crops), and in choosing a gradation of this color for a particular value (e.g. pale green for pines). In this case, since it is not possible to show all the colors on the screen, the user must have the possibility of switching to another domain of value. 2. One way of dealing with legends of maps with numerical attributes is to split the values in intervals when it is possible. According to the user, di erent numbers of area sets (distinguishable by color) may be displayed on the screen. The typical case is the case of population. For example, two sets can be considered on a map: districts with less than one million inhabitants and districts with more than one million. Note that if the user wants to see explicitly the attribute values on the screen (e.g., the value \corn" or \1000" on a polygon), this case is related to case 1 (name legend) since there must be a way to describe where to place a value \on" an object on the screen, for example by storing its position in the database. The problem of dealing with symbol legend is related to cases 1 and 2 (theme legend). Indeed, the problem is to display (i) a particular symbol for a particular value (case 2), and (ii) as close as possible to the site of the objects that has this characteristic, e.g., the drawing of a church near the dot of an object representing a church (case 1). The treatment of statistics legend is in some ways related to problem (2-2), because the data is split into intervals. Statistics can be computed by an external module, and a pie or bar editor displayed close to the map (or superimposed). Symbols such as pies or bars can also be placed on the objects of the map display.
Objects modi cation
The main feature of an editing process is the possibility of modifying objects interactively and storing the modi cations in the database. For example, the user may erase the boundary between two counties (at a lower level, between two polygons). Since objects of a displayed map can change after an interaction with the end user, a map itself can be modi ed. The interface, which is between the user and the database, must send this kind of information to the database which will update the modi ed map.
2.2 Entities manipulated
The objects we will consider are maps already stored in a database as well as sets of maps. Although we do not want to consider the implementation of the objects in the database, we assume that the environment is object-oriented to facilitate our presentation. Then the entities manipulated are objects which belong 7
to classes and on which methods (operations) are applied. For more information about object-oriented databases, see [Ban88].
Maps
For the user data model, we use the algebra for thematic maps presented in [SV89], which has two levels: the Map level and the Geometric level. A map is a set of tuples, in which each tuple has at least one geometric attribute. This model only allows one to manipulate regions but we extend it with the notions of points and lines. In an object-oriented environment, this corresponds to two main classes, say Map and Geometry, with Geometry having as sub-classes Points, Lines and Regions. Basic operations on class Map are de ned, which generally use methods of class Geometry. For instance, method MapOverlay de ned on class Map utilizes method intersection de ned on class Geometry. As it is not our purpose to describe in detail all the operations that can be performed on maps, the reader is referred to [SV89]. The operations described in detail in that paper are clipping, map overlay, windowing, fusion, superimposition and geometric selection. An implementation of this model has been realized at Inria on top of the O system [BDK91] and is described in [SV91]. 2
Sets of maps
High level operations for manipulating sets of objects turns out to be very useful. As an example of an operation performed on sets of maps one can cite the browsing of the database to retrieve a particular map. These operations can be both graphical and not graphical. For example, the system can present to the user all the icons corresponding to the maps of the database, sorted according to a criterion for making the search easier. Since it is not our main concern to study these operations, this will not be handled in the model presented in this paper. However, we need to factorize information common to sets of maps (e.g., a theme legend). This information is stored in what we call a meta database.
2.3 Querying
There are several ways for extracting information from existing maps. The most natural, in this object oriented environment, is to call methods via menus on objects of class Map. For example, one asks for an overlay of two maps. The system must also provide a (graphic) query language powerful enough to deal with geometry. It can be an SQL like language extended with spatial primitives such as adjacent, intersect, etc. [SV91], or a high level interactive language. Indeed, some systems present the query language in a window containing elements such as operators, that the user can pick up for describing the query. This can be viewed as hiding SQL in order to provide a more friendly end user interface. One functionality useful for the user when answering queries is the notion of context ([Ege89]). It means that the user chooses a framework, and that the system is sophisticated enough to return as answer the \environment" of the result instead of the only result itself. We surveyed in this section parameters to take into consideration for map manipulation and, more precisely, map editing. In the following section, we will see how these general features are gathered in a map display model.
3 The Map Display Model The objects we want to display are maps stored in the database. They are transformed into objects of the Display model in order to be manipulated interactively. We assume that database objects of class Map exist, and that we are interested in manipulating them graphically. Basically, this class is composed of two subclasses that we call Geometry and Description. We are rst 8
interested in displaying maps' geometry. However, we will deal with tuple descriptions by communicating with the DBMS through the interface, for example, for displaying an object's description. De ning a map display model is a complex task if we want the display to be powerful and also insist on taking into consideration some modularity (see Section 2). This is the reason why we split the Display model into two levels: The Interaction Level It can be seen as the higher level of the toolbox: the corresponding model contains objects such as windows, which are the \ rst" elements for mediating between the application and the user. In Section 2, we saw intuitively the need to de ne a special window devoted to map editing. This Map widget, or MapGet to be short, is part of this model. The External Spatial Level The map displayed on the screen is composed of sub-objects which come from a mapping of the database model onto the External Spatial model. This model contains low level objects such as polygons, arcs and points, which have associated graphic attributes (e.g., color). Note that although these two levels are de ned independently of each other, there is obviously a strong communication between them. In this section, we outline the basic concepts of the two levels (Interaction level and External Spatial level), as well as the map display mechanism. Each level is detailed in the following two sections.
3.1 Informal presentation of the Interaction Level
Intuitively, the idea is to give the possibility of superimposing severals maps on the screen, and to provide the designer with tools for describing the objects he/she needs for a particular application. Figure 3 shows an example of a screen aspect. LayerStack2 .
LayerStack1 .... .... . ... ... ...... ....
.
B
B
.......... .........
.... ... ...... .... ........ ...
.
........ .......... .
.... ....
.... .... ....... ......
.
... ... ... ..
.
. .
... ... ... ..
. .
.
... ....
... ... ... ..
..
... ......... ..... .......... .
... ... ... . .... .... ...... ......
Figure 3: Example of map displays
MapGet
A widget is a window with associated semantics. In systems dealing with widgets, several classes of widgets are considered, such as text widgets, dialogue widgets, menu widgets, etc. They all represent di erent types of rectangular areas where di erent actions are de ned. Since programming in low level languages such as X Window System [SG86] can be a tedious task, the concept of widgets allows the programmer to have a higher level of abstraction which makes programming easier. In the same way, 9
we de ne a Map widget (or MapGet) for dealing with maps. Basically, a MapGet is an area on the screen for manipulating maps only. It means that a MapGet is used to display maps and to react on an event (mouse click).
Layer
Layer-Stack
It can be useful to visualize at the same time several maps without superimposing them. This is the reason why we introduce the notion of Layer, which represents a set of MapGets. In Figure 4, the rectangle on the left is a Layer with three MapGets. Several Layers have the possibility of sharing the same MapGets. Since one of our goals is to provide the application designer with the possibility of superimposing several (thematic) Layers, each Layer has the characteristic either \opaque" or \transparent". We will see below a structure able to manage several Layers. If an opaque Layer is ahead of other Layers, the Layers behind it will not be seen on the screen. On the contrary, each transparent Layer will be seen, until nding an opaque Layer, or if there is no more Layer to consider in the structure. Figure 4 shows a system with two transparent Layers, representing respectively for example crops and cities. These Layers have the two bottom MapGets in common. We need a structure for managing several Layers in a given order. This is why we introduce the concept of Layer-Stack which is a list of Layers. It represents the higher object of the Interaction model. Operations such as Shift-Up or Shift-Down are de ned on Layer-Stacks. Some operations usually allowed on windows such as iconify or move are also allowed on Layer-Stacks. The description of these operations is given in Section 4. LayerStack1:
Layer2
Layer1 ..... ... .. .. ... .... .... ......... ......... .
.... .... . ... ... ...... ... . ......... ..........
... ... ... ..
B
B
...... ... .... .... .. .. .... .
.......... .........
.... ....
.... .... ...... .......
.
.
.
........ ......... .
... ... ... ..
.
. .
. ........ ... ... .... .... .... .
.... ....
... ........ ..... ........... ..
.... ... ...... ........
. .
... ......... .... ...........
Figure 4: Two (thematic) Layers. An application is a set of Layer-Stacks (and of other elements that we will see further). The application displayed on Figure 3 has two Layer-Stacks.
3.2 Informal presentation of the External Spatial Level
In this level, we group the elements which are displayed inside a MapGet. When a map has to be displayed, an object which corresponds to it in the External Spatial model is computed. This object comes from (i) a type mapping from the database to the External Spatial model, (ii) a reading of the map stored in the database and (iii) a reading of the meta database (for example, for the legend). We call this object an image. An image is constituted of visual objects having a geometric attribute whose type is either Point, 10
or Arc or Polygon, or a set of these basic types, as well as attributes of visualization (e.g., a color). An image can be seen as an abstraction of the map to work on. It has a corresponding element which will be displayed: this element is a presentation which is linked to a MapGet. It is fundamental for independency to distinguish the notions of image and presentation, although they both represent a view of the same object. The di erence is that for a given map, an image is static as a presentation is dynamic. A map corresponds to a single image but may have several presentations. For example, one can decide to center an image in a MapGet or to ask the system to make it t into a MapGet: the image will stay the same while the presentation will change. Figure 5 summarizes the transformation of a map's geometry from the database to the user interface.
[
.. ... ....
................ ............. .. ... ..
`
`
.. ...
. ...................... ..................... .... .... ..... ... ... .. . . ... ... .. .. .. .. .. .. .. .. . ... .. ... .. . ... .......... ... ........... . .... . . . . .. .... . .. . .. .. . . . . . .. ... .. ... .. ... ... .................. ...
-
< ... >]
.. .. .. ... ...
E
.. .. ... .. ..... .... . . . ... . . . .... . . . ... ...
E
l
P
P
l
l C
.. .. .. .. l
C
-
@
@
@
h
h
A map in the DBMS
An image in the Spatial Model
A presentation on the screen
Figure 5: Map's geometry transformation from a DBMS to the user interface
3.3 Map Display mechanism
We can now describe brie y the main steps necessary to display a map on the screen:
Read a map in a database as well as the meta database (legend). Compute its image in the External Spatial model. De ne the interaction objects (MapGets, Layers, Layer-Stacks). Compute a presentation, given the parameters (\centered", \ ts-into-frame", ...). Link the presentation to a MapGet.
In this section, we presented informally the main objects necessary for editing maps. These objects belong either to the Interaction model or to the External Spatial model, which are both detailed in the next sections.
4 The Interaction model We assume that the Interaction level only sees the presentation of maps, i.e., their corresponding objects in the Spatial model, after the mapping process (which computes an image) and possibly transformations such as a change of scale. We will see in the following section how the correspondence between the database objects and the (basic) objects displayed, de ned in an external Spatial Model, is done. To introduce the objects and the operations de ned on them needed at the Interaction level, we de ne classes having a type 11
speci cation as well as operations (methods) associated with them. In this section, some basic concepts of user interfaces are rst described. Then the Interaction model's objects (MapGet, Layer, Layer-Stack) and operations on them are presented.
4.1 Some standard interface concepts
Window: a window is a rectangular drawable area on the screen, which delimits the place where the
interaction between an end user and an application is done. Usually, the following operations can be performed on windows, independently of their contents: Move, Raise, Hide. The following operations involve a modi cation \inside" the window, i.e., on the displayed objects: Resize, Scroll, Refresh, Zoom (not common to all applications). ScrollBar: a bar which allows to wander (pan) inside a window. Title Bar: a string on top of a window. Menu: a list of actions which may be performed \on" or \inside" a window. The menu is generally presented to the user after a click on the title bar.
4.2 Objects and operations of the Interaction model
To describe the high level objects needed to communicate with the end user, we use the O data model. For each class, we give the signature of the main methods that can be performed on it. When there is no ambiguity, the name of the class on which the method is applied is missing. The object on which a method is applied is called a receiver. 2
Figure 6 recalls the main concepts presented in the previous section. Layer-Stack < Layer f
MapGet
> g
Figure 6: Composition tree of the Interaction objects
Notation
represents the list constructor, [ ] the tuple constructor and fg the set constructor.
Point-Screen
We need to introduce the notion of point, that we call Point-Screen (to distinguish it from another point type in the External Spatial Model), and which will be used in several classes and methods. class POINT-SCREEN = [ x: int; y: int]
12
Frame
Class Frame will be used to describe an area on the screen (in particular, for the map widgets de nition).
De nition
class FRAME = [
x: y: w: h:
int; int; int; int]
Operations { Point-in-frame(p: Point-Screen)! boolean
checks whether point p is inside the receiver. { Shift-Frame(dx: int, dy: int)! Frame moves a frame (in any coordinate system), according to steps dx and dy.
MapGet
Recall (Section 3) that a MapGet is a particular area on the screen that allows to display maps. Since there are several ways of considering map manipulation (see Section 2), several kinds of MapGets have to be considered. We saw before that it can be useful to have some kind of reference map(s) which remains on the screen during a whole session. This is used to represent the geographical environment of the session which can be for example a country. Then it seems relevant to consider a sort of \constant" MapGet, in which only some operations are allowed. This special MapGet may also be used for the idea of context when answering queries. To de ne di erent kinds of MapGets, we de ne sub-classes of the MapGet class. For instance, class C-MapGet for constant MapGets and class V-MapGet for variable MapGets. Let us rst describe informally the MapGets characteristics: 1. A MapGet is a rectangular area which has a size speci ed in a Frame. 2. A MapGet has a special operation associated with it if it gets a mouse click. Let us call it the on-click operation (CallBack in the widget language). The result is the click coordinates in the coordinate system of the MapGet's frame. The piece of code corresponding to this action can be rede ned by the developer. 3. A MapGet has a variable associated with it, which corresponds to the graphical representation of a map. This variable, called presentation, comes from the lower level and is described in Section 5.
De nition class MAPGET
=
[ MG-FRAME: FRAME; MG-PRESENTATION: presentation ]
class C-MAPGET inherits MAPGET; class V-MAPGET inherits MAPGET;
Operations { on-click(x: int, y: int) ! Point-Screen
returns the coordinates of the click in the MapGet's Frame. { Switch-type-legend(type-legend: string) ! MapGet switches to another type of legend in the set f \theme", \name", \symbol"g. 13
{ Switch-theme-legend(attribute-name: string) ! MapGet
changes the theme of the legend displayed in the MapGet, according to attribute-name. { Scroll-In-V-MapGet(axis: string, direction: int, number-steps: int) on class V-MapGet ! V-MapGet scrolls according to axis (x, y), and direction (positive/negative) by moving inside an image number-steps times. { Zoom-In-V-MapGet(a-frame: Frame) on class V-MapGet ! V-MapGet zooms in a zone de ned by a a-frame.
Layer
We saw before that a layer is a set of MapGets. Since the MapGets are referenced by their name, it is possible for di erent layers to share the same MapGets (same instances of MapGet Class). With each layer is associated a boolean which indicates whether the Layer is transparent or opaque.
De nition class LAYER = [ L-MapGet: { MapGet} Transparent: Boolean
]
Layer-Stack A Layer-Stack is a list of Layers. The list structure has been chosen for giving the overlapping order.
As we saw before, each layer has the characteristic either \transparent" or \opaque". If an opaque layer is ahead of other layers in the list, the layers behind it will not be seen on the screen.
De nition class LAYER-STACK =
Operations { AddLayer(l : Layer) ! Layer-Stack i
{ { { { { {
AddLayer(l ) adds the layer l on top of the list containing the previous layers of the receiver. RemoveLayer(l : Layer) ! Layer-Stack RemoveLayer(l ) removes the layer l from the layers list of the receiver. ShiftUp() ! Layer-Stack the objects l of the receiver's layer list are popped up, and the rst one becomes the last one. ShiftDown() ! Layer-Stack the objects l are pushed up, and the last one becomes the rst one. Zoom(a-frame: Frame) ! Layer-Stack zooms in a zone (a-frame) de ned by the user. The zoom action is sent to all the concerned MapGets, and handled by a method of the MapGet class. Scroll (axis: string, direction: int, number-steps: int) ! Layer-Stack scroll number-steps times according to \steps" dx/dy de ned in an image (see Section 5) and to axis (x/y) and direction (positive/negative). The action is sent to all the concerned MapGets. On-click(x: int,y: int) ! Point-Screen the event is sent to the \ rst" MapGet concerned (i.e., which belongs to the rst layer). By default, the result (action associated with the MapGet) is the coordinates of the point in the MapGet's frame. i
i
i
i
i
i
i
14
{ MultiPick(x: int,y: int)! Visual-Object
This operation consists in selecting an object common to several layers. The mechanism is complex and is detailed in Section 6. { Display() ! This operation is obviously device dependent. It consists in displaying all the MapGets' presentation of all the receiver's layers. Although we do not want to consider implementation aspects since the model presented above is a conceptual model, we have to say that a Layer-Stack can be seen as a window known by the window manager. It is the rst intermediate between an application and an end user. However, some operations such as resize are not allowed in Layer-Stack, because they do not have a de ned semantics.
5 External Spatial model and links with the database
The goal of this toolbox is to provide an application developer with tools for manipulating maps stored in a database. We would like this manipulation, and, more precisely, the map display process, to be as independent as possible of the way data is de ned in the database. This is the reason why we propose an External Spatial model which will be used for the user interface, and more speci cally, for map editing. In the previous section, we saw that at the highest level, the interface only sees the presentation of maps. The presentation structure is described here, since the level described in this section is in charge of dealing with the components of a map. At the higher level, the External Spatial model is constituted of images, and images are themselves constitued of visual objects. The geometric type of these objects are built from basic geometric types Point, Arc and Polygon, as well as from the set constructor, and have methods de ned on them. It should be more powerful to provide the designer with the list and tuple constructors to handle a larger variety of applications. But in this case, from an implementation point of view, the correspondence between the geometric objects of the database and the geometric objects of the interface must be done by a mapping module which sees the internal structure of a map. If the application changes, this module has to be modi ed. A presentation is associated with a MapGet. It results in fact from an image transformation. Images and presentation are conceptually the same object, but a presentation is linked to a window (MapGet). In other words, images and presentations are di erent views of the same object, and an image can be considered as a virtual map object without any direct representation on the screen.
As high level objects of the External Spatial model represent really the link between the user interface and the database, we rst describe in this section some database aspects: (i) the meta database, which groups informations common to several maps, and (ii) database objects (maps). Finally, we present the objects of this model, i.e., images, presentations, and visual objects.
5.1 Meta Database
We group in this database all the characteristics concerning a set of maps manipulated in a particular application. It is necessary to factorize global information common to several maps for consistency reasons. For example, since all the maps displayed should show the same (theme) legend, the latter must belong to a meta-database. In the following, we deal only with the theme legend that we describe in a simplistic way since it is not our main concern. We suppose that we have a class, say Appli-Information, de ned as follows: class APPLI-INFORMATION: [ SomeInfo ... /* example, where data comes from */ ...
15
A-Theme-Legend: Theme-Legend] class THEME-LEGEND: { [ Theme: string; SetRepresentation: { [ Attribute-value: ... Representation: string] } ]}
The most simple way to deal with this kind of legend (Section 2) is to associate with each theme a set of couples (Attribute-value, Representation). For example, f [ theme: crops,f [Attribute-value: corn, Representation: yellow], [Attribute-Value: wheat , Representation: brown ] g ] g ) represents the legend associated with an application that manipulates crop maps. In this example, we de ned colors for the representation attributes, but we could have de ned patterns.
5.2 Database Objects
For manipulating objects in the database, we assume that the designer can use basic standard types such as real, string, bitmap, etc., constructors set, list and tuple [LR89]. All maps belong to the same class, Map, and an object of class Map has an attribute which represents a set of tuples, say SetGeoTuple. A tuple GeoTuple itself has the form [the-description, the-geometry], where the-description is the alphanumeric part of map component, and the-geometry the corresponding spatial attribute. We focus here on the manipulation of the objects corresponding to the-geometry.
Classes De nition class MAP = [
xmax-map: int; ymax-map: int; .... SetGeoTuple: { GeoTuple } ]
class GEOTUPLE = [ the-description: ListAttributes; the-geometry: GEOMETRY ] Subclasses of class GEOMETRY will use basic types of the External Spatial model (Point, Arc, Polygon) and constructor Set. class LISTATTRIBUTES .....
This schema has been chosen in our GIS prototype and is explained in [SV91] . 1
Operations { Create-image (theme: string) on class Map ! Image
creates an image from a map according to theme (this implies a reading of the theme legend). Other operations on class Map exist. They are not described here since they represent standard operations on maps and we want to focus on user interface aspects.
1 In particular, it is worth noting that this schema has been chosen because the O system does not allow dynamic class 2 creation: all maps must then belong to the same class (Map).
16
5.3 Visual Objects
A visual object is either an image element or a presentation element, i.e, a (visual) element of a MapGet and then the object manipulated by the end user. Such an object is not exactly an object in the database since its type corresponds to a type de ned in the External Spatial model. Attached to a visual object are visual representation attributes. Some attributes are only necessary for the display (e.g., color). We also consider spatial attributes corresponding to the shape of the object, and belonging to a class that we call Spatial (not to be confused with Geometry, which is the geometric class at the database level, and not at the interface level). The graphic representation of an object can change dynamically after an operation on a window (zoom, scroll, etc.), or by direct manipulation. For example, when the user clicks on an object for selecting it, this object is highlighted. A eld \HighLighted" of a visual object will then be updated.
Spatial is the common root of all geometric classes considered in this model. It corresponds to an Abstract
Data Type, i.e, it has a type speci cation associated with it (list of attributes) as well as methods. Some methods on graphic objects are factorized in this class, even if they are rede ned in subclasses. The subclasses of class Spatial are the following: Point, Arc, Polygon. The designer can also use the set constructor (at one nesting level).
Visual-Representation De nition class VISUAL-REPRESENTATION = [ Color: string; Thickness: string; HighLighted: boolean]
Spatial De nition class SPATIAL This class is the super class of the following classes. class class class class class class
POINT inherits Spatial = [ x: int, y: int] SETPOINT inherits Spatial = { Point} ARC inherits Spatial = [p1: Point, p2: Point] SETARC inherits Spatial = { Arc } POLYGON inherits Spatial = < a1: Arc, ... , an: Arc > SETPOLYGON inherits Spatial = { Polygon}
Operations
Note that the following list of operations is not exhaustive and is given as example. { Adjacent(s: Spatial) on class Spatial ! boolean { PointInPolygon(p: Point) on class Polygon ! boolean { Intersection(sp: SetPolygon) on class SetPolygon ! SetPolygon { Erase-boundary(sp: SetPolygon) on class SetPolygon ! SetPolygon { Intersection(sp: SetPolygon) on class SetPolygon ! SetPolygon { etc. 17
Visual Objects
The visual objects have to contain the database objects they come from. This is why we de ne a eld whose type is GeoTuple.
De nition class VISUAL-OBJECTS = [ VO-geotuple: GeoTuple; VO-Graphic-Attributes: VISUAL-REPRESENTATION; VO-Spatial: SPATIAL ]
Operations { Highlight() ! Visual-Object { UnHighlight() ! Visual-Object { Erase() on class Visual-Object ! () { ChangeColor(newcolor : string) ! Visual-Object { Display() ! ()
5.4 Checker-Board
This class is used in the image class de nition. Indeed, an image is split into intervals which are used for moving into it (for example, when scrolling). class CHECKER-BOARD inherits FRAME = [ dx: int; dy: int ]
5.5 Image
An image is the result of the rst map transformation after a reading of the database and before displaying the map. As an image is a link between the database and the user interface, its structure must have the identi cation of the manipulated objects. Thus we associate a map OID with an image.
De nition class Image
= [ I-map: map; /* I-map is the oid of the map */ referential: string; I-Checker-Board: CHECKER-BOARD; I-Visual-Object: set (VISUAL-OBJECT) ]
Operations { Create-presentation(a-frame: Frame, type-presentation: string) ! Presentation
creates a presentation, according to a-frame and to type-presentation (which gives the aspect of an image in a frame). { Zoom-in-Image(a-frame: Frame, factor: int) ! Image returns a new image whose objects come from the receiver. The objects are in the frame a-frame and their coordinates are multiplied by factor.
18
5.6 Presentation
An image is associated with a presentation. The image corresponding to a presentation can be either centered in a MapGet's frame, or shifted, or can t into a frame. Then a variable type-presentation of type string is associated with a presentation, and its value can be \ ts-into-frame" or \centered" or \shifted". A presentation is composed of visual objects, in the same way as an image is. The di erence is mainly in the coordinate system of the visual objects they contain. For an image, the coordinates are expressed in the map (in the database) coordinate system as for a presentation, they are expressed in a frame coordinate system.
De nition class Presentation = [ P-Image: IMAGE; scale: int; type-presentation: string; P-Visual-Object: set (VISUAL-OBJECT) ]
5.7 Application
An application contains general information (for example, the legend), as well as a set of Layer-Stacks.
De nition
class APPLICATION = [ AppliInfo: APPLI-INFORMATION; the-Layer-Stacks: { LAYER-STACK } ]
5.8 Object modi cation
When a visual object is modi ed, the variable presentation of its MapGet is modi ed and then the map's image is modi ed. To update this object in the database, we have (i) to get the image from the presentation associated with the MapGet, (ii) to transform the image into a map and (iii) to write the new map in the database (the new geometry is written in the corresponding eld of the map object).
5.9 Mapping of database objects onto visual objects
Since the model which allows the manipulation of the visual objects must be as independent as possible of the database, the type mapping of database objects onto visual objects is essential and must be expressed easily. However, the study of a mapping module is out of the scope of this paper since we just supply a toolkit for manipulating objects that we de ned, i.e., objects of type Point, Arc, Polygon and set of those types (at one nesting level). If the developer wants to manipulate a special spatial type, he/she has to program the mapping module. For example, if in the database a region is a list of polygons, it is not handled by our model since the designer has to use the types mentioned above.
6 Object selection The object selection operation is important for geographic applications and is now described. In our context, we can give two semantics to the operation of object selection by clicking. One can select an object of a MapGet, i.e, which belongs to one layer, but also an object which belongs to several layers. In this section, we give the main steps of the two algorithms.
19
6.1 Selection of an object in a Mapget
By default, this action may occur when pointing to an object on the active layer. For describing a special treatment on the selected object, the designer has to overwrite method on-click associated with a MapGet. We saw in Section 2 that the user usually clicks on an object for getting its alphanumeric attributes, which are in the database. This presupposes the existence of a module which contains a set of operations to be performed on database objects. The resulting actions of a click may be the following: 1. Recognition of the concerned MapGet (a) Get the top layer. (b) Get the MapGet. 2. Get the visual object O from the click coordinates in the MapGet's frame 3. Apply the on-click operation on object O, example: (a) Apply a graphic treatment, such as highlight on the object (and possibly un-highlight on the previously selected one), by creating a new presentation and then a new MapGet. (b) Call the function DB: Get-Description on the OID stored in visual object O and display the result in a widget (text editor).
6.2 Selection of an object in di erent layers
We called this particular selection MultiPick. This action consists in getting all the objects of di erent transparent layers. It is then close to the rst case, except that we have to traverse the di erent layers: For each Layer in the Layer Stack: 1. Recognize the concerned MapGet (cf 6.1). 2. Get the visual object O from the click coordinates in the MapGet's frame. 3. Possibly apply a treatment on object O. All the selected objects can be stored in a structure (set or list) which represents a new object, and which can be stored in the database.
7 Conclusion Considering the development and diversity of geographic applications, it is important to de ne a toolbox general enough for encompassing a large variety of applications. In this paper, we rst surveyed the parameters to consider when manipulating maps through a user interface, in order to gather them in a display model. The model we de ned is composed of two levels: (i) the Interaction level for manipulating high level objects such as windows and (ii) the External Spatial level for manipulating objects on the screen, i.e., map components manipulated by the end user. In particular, we saw the necessity of introducing a new window type, a Map widget (or MapGet), as well as a structure on top of it for managing (thematic) layers (called Layer-Stack). In the External Spatial model, one could provide more sophisticated types for manipulating geometric objects. We deal with the Point, Arc and Polygon types as well as the set constructor with only one level of nesting. At implementation time, a mapping module will have to be coded. This consists in de ning a mapping tree of the database types to the spatial model types. It could be useful to consider also the notion of bitmaps for displaying images (backgrounds) on the screen. We did not address this issue to simplify 20
the presentation. But, since maps and bitmaps are stored in the same database, it is easy to imagine a connection between a Layer-Stack and a bitmap, assuming for example that a bitmap is always seen at the \end" of a Layer-Stack (i.e, one can visualize it as a background). An extension could be also to consider more powerful bitmaps, such as hyper bitmaps (bitmaps with \sensitive" zones). Another extension concerns the interaction objects and their links with the database. We can imagine a more elaborated notion of MapGet allowing recursivity. The visual objects could be considered as MapGets whose frame is the bounding box of the object. We chose to work in an object-oriented environment for clarity when describing our model. We used the O model since this work is the continuation of [SV91], where a GIS prototype on top of the O DBMS is described. However, most of the concepts that we describe are general and can be used in other contexts. 2
2
The model proposed in this paper is not implemented. The next step is to specify this toolbox using standard tools. The main problem is probably the display of Layer-Stacks and of their components. Motif [OSF89] could be a good candidate for managing our windows on top of X Window System [SG86], but a problem arises since Motif does not provide tools for displaying geometry. We have rst to extend it with this functionality, using tools such as PHIGS [ISO89].
Acknowledgements
I am grateful to Jean-Claude Mamou and Michel Scholl with whom I've had many insightful discussions. I am indebted to Ken Gardels who gave me the opportunity of realizing this work at UC Berkeley, and with whom I had fruitful discussions. Many thanks to Benoit David, Jerry Kiernan and Jean-Claude Mamou for careful reading and comments on the nal version.
References [Ban88] F. Bancilhon. Object oriented database systems. In Proc. of the 7th ACM SIGACT-SIGMODSIGART conference on principles of Databases Systems, Austin, Texas, 1988. [BDK91] F. Bancilhon, C. Delobel, and P. Kannelakis, editors. The O BOOK. Morgan Kaufmann, 1991. [EF88] M. J. Egenhofer and A. U. Frank. Designing Object-Oriented Query Languages for GIS: Human Interface Aspects. In Third International Symposium on Spatial Data Handling, pages 79{97, 1988. [Ege89] M. Egenhofer. Concepts of spatial objects in GIS user interfaces and query languages. In Proceedings of GIS / LIS, 1989. [ISO89] ISO. Programmer's hierarchical interactive graphics system (phigs). In International Standard ISO, 1989. [LR89] C. Lecluse and P. Richard. The O database programming language. In VLDB, 1989. [OSF89] OSF. Motif 1.0 programmer's guide. OSF Journal, 1989. [Sam89] H. Samet. The Design and Analysis of Spatial Data Structures. Addison-Wesley, 1989. [SG86] R.W. Schei er and J. Gettys. The X Window System. ACM Transactions on Graphics, 5(2):79{ 109, 1986. [SV89] M. Scholl and A. Voisard. Thematic Map Modeling. In A. Buchman, O. Guenther, T.R. Smith, and Y.F. Yang, editors, Design and Implementation of Large Spatial Databases (SSD'89), pages pp. 167{192, Berlin, 1989. Lecture Notes in Computer Science No. 409, Springer-Verlag. 2
2
21
[SV91] M. Scholl and A. Voisard. Object Oriented Database Systems for Geographic Applications: An Experiment with O , 1991. To appear in The O BOOK, Bancilhon, Delobel, Kanellakis eds., Morgan Kaufmann, San Mateo, California. 2
2
22
Contents
1 Introduction 2 Features involved in geographic applications
1 4
3 The Map Display Model
8
2.1 Map editing : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.2 Entities manipulated : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2.3 Querying : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : :
4 7 8
3.1 Informal presentation of the Interaction Level : : : : : : : : : : : : : : : : : : : : : : : : : : : 9 3.2 Informal presentation of the External Spatial Level : : : : : : : : : : : : : : : : : : : : : : : : 10 3.3 Map Display mechanism : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11
4 The Interaction model
11
4.1 Some standard interface concepts : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12 4.2 Objects and operations of the Interaction model : : : : : : : : : : : : : : : : : : : : : : : : : 12
5 External Spatial model and links with the database 5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9
Meta Database : : : : : : : : : : : : : : : : : : : Database Objects : : : : : : : : : : : : : : : : : : Visual Objects : : : : : : : : : : : : : : : : : : : Checker-Board : : : : : : : : : : : : : : : : : : : Image : : : : : : : : : : : : : : : : : : : : : : : : Presentation : : : : : : : : : : : : : : : : : : : : : Application : : : : : : : : : : : : : : : : : : : : : Object modi cation : : : : : : : : : : : : : : : : Mapping of database objects onto visual objects
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
: : : : : : : : :
15
15 16 17 18 18 19 19 19 19
6 Object selection
19
7 Conclusion
20
6.1 Selection of an object in a Mapget : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 20 6.2 Selection of an object in di erent layers : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 20
23
