Object-Oriented User Interfaces for Map Algebra 1
IVAN LUCENA, 2GILBERTO CÂMARA, 3MÁRIO NASCIMENTO
1
Centre for Agricultural Informatics, Agricultural Reseach Agency (EMBRAPA), Brazil 2
Image Processing Division, National Institute for Space Research (INPE), Brazil 3
Computer Science Department, University of Alberta, CA
[email protected],
[email protected],
[email protected]
ABSTRACT Most GIS implementations include Map Algebra procedures to express complex spatial analysis models, and to generate new maps from existing ones. However, most Map Algebra implementations (whether command-line languages or graphical user interfaces) are based on an explicit use of raster data structures, with very little semantic information available to the user. This paper proposes a different approach: Map Algebra operations are defined in terms of higher-level spatial data types, such as surfaces, images, features, thematic and network. This allows the definition of an object-oriented interface where operations are matched to the specific spatial data types, thus making selection much simpler. This conception has led to the implementation of AMO, a friendly user interface for the generation of Map Algebra programs in SPRING (a public domain GIS). The paper discusses the conception and implementation of AMO.
1
Introduction
One of the most important concerns in GIS design is simplifying the user’s learning curve. Many current GIS implementations present the user with a bewildering amount of functions, which confuses both the novice and expert. As a consequence, the GIS user community has been divided into specialists on specific systems. This problem is seen as a significant impediment for a greater use of GIS technology. This situation is partly caused because the current generation of GIS does not support conceptual data models, which provide powerful abstractions. Most implementations force the user to understand about the intricacies of graphical data structures, who in reality represent the same mathematical entity. Despite the advances in data modelling, GIS interface design still plays a crucial rôle in determining user's acceptance of a solution. Therefore, the advances in data modelling need to be reflected on the system's interface, which should serve as a guide to the user, avoiding whenever possible - explicit referral to c omputer representations and allowing the user to concentrate on the geographical data.
This paper addresses this problem, from the point of view of designing a user interface for Map Algebra operations in a GIS (Tomlin, 1990). These operations can be seen as a set of operations that create new geographical data from existing data sets. Since Tomlin (1990) made a systematic description, Map Algebra procedures have been implemented in different systems. From a practical point of view, this paper outlines an initial proposal for a companion module to SPRING, a public-domain GIS solution developed by INPE, which is available on the Internet (at the website www.dpi.inpe.br/spring). This new module, which is called AMO, aims at providing a friendly interface for Map Algebra operations. AMO is implemented in the Tcl/Tk scripting language, because of our requirements have included multi-platform portability. The rest of this work is organised as follows. In section 2, we describe the LEGAL Map Algebra language, used in SPRING. In section 3, we describe the AMO interface. The work concludes with some brief considerations on the contributions expressed in the AMO design and implementation.
2
The LEGAL Map Algebra Language
LEGAL is the Map Algebra Language for the SPRING system (Câmara et al, 1996). As such, it uses the same object-oriented data model as SPRING, which is briefly described below. The SPRING data model is based on the perspective that a general GIS system should provide both fields and objects as basic abstract classes. The class of FIELDS can be further specialised into the subclasses THEMATIC (whose range is finite denumerable set - the themes of the map), SURFACE (whose range is the set of real values) and IMAGE (whose range is a set of discrete values obtained by an active or passive sensor). These classes can be further specialised by the user, according to his specific needs. For example, a user may create a “Suitability” class for maps associated to a land selection procedures, whose possible values indicate different suitability types (e.g., “Preferable”, “Unsuited”). The FEATURE class is composed of unique elements with descriptive attributes and multiple geometrical representations. These representations are maintained in instances of the class FEATUREMAP. The model supports two in-built sub-classes of FEATURE-MAP: CADASTRAL and NETWORK, which stress topological relations among regions and connected arcs, respectively. The SPRING data model distinguishes between these abstract definitions and their geometrical representations, as: • THEMATIC MAPS can be represented as a vector (polygon map) or as raster (integer grids). • SURFACES can be represented as vectors (contour maps, samples or TINs) or in raster format (floating-point grids). • IMAGES are represented in raster format. • FEATURES are represented in vector format.
•
boolean operators specify a set of conditions on THEMATIC and SURFACE fields, and the result is a THEMATIC field.
•
mathematical operators, such as arithmetic and trigonometric functions, can only be applied to SURFACE field.
•
focal operators, defined on a neighbourhood of each input location. The focal operators include: FocalSum, FocalMean, FocalMax, FocalMin, FocalStdev and FocalVariety.
•
zonal operators, where one geo-field (from the THEMATIC classes) is used as a spatial restriction on the operators on another geofield (from the SURFACE or REMOTE SENSING classes). An example of zonal operations would be: “Given an slope map and a soils map, find the average slope for each soil area on the map”. The zonal operators include: ZonalSum, ZonalMean, ZonalMax, and ZonalMin, ZonalStdev ZonalVariety.
The manipulation of fields includes many situations where a new result is generated. The operator New allows the association of temporary variables to persistent storage in the database. Additionally, LEGAL includes the operator Retrieve, which is used for a selection operation, when the name of the field is known. Combination of Fields and Features One important set of operators which is not explicitly present in Tomlin’s Map Algebra (which is concerned with raster data structures) is the possibility of linking the information associated in features to fields and vice-versa. To this end, LEGAL provides two operators: •
GenerateField is an operator that takes an attribute from a FEATURE and produces a THEMATIC map or a SURFACE. One example would be in the operation “Given a map of the counties of Brazil, generate a surface from the values associated to the population attribute”.
•
UpdateAttribute is an operator which creates or updates an attribute of a feature, based on the values of a field. It can be used in situations such as: “Given a map of the counties of Brazil and a surface with rainfall values for the country, create a new attribute for each county with the mean rainfall in its area”.
Map Algebra in LEGAL LEGAL provides the following types of operators on geo-fields, using terminology similar to Tomlin (1990): •
unary operators, which perform the mapping between different classes of geofields, such as Weight (transforms a THEMATIC field into a SURFACE one), Slice (transforms a SURFACE to a THEMATIC field), (transforms a Reclassify THEMATIC field into another THEMATIC of a different class).
Examples of Programs in LEGAL LEGAL is strongly typed and object-oriented. Each variable is associated to one specific data type, and the Map Algebra operators are understood as methods of the basic classes THEMATIC, SURFACE, IMAGE and FEATURE. LEGAL’s object-oriented approach gives rises to programs that express the transformations performed by Map Algebra in a very clear and readable fashion. The following program is an example of a boolean operation, where the conditions are set explicitly by the user to calculate a suitability map:
slope_tab = New(OutClass = “Slope_Classes”, [0.0, 5.0] : “Low”, [5.0, 15.0] : “Medium”, [15.0,45.0] : “High”); map1 = Retrieve(Name = “slope”); map2 = New(Name= “slope_class”); // Operation map2 = Slice(map1,slope_tab); }
Figure 2 – Slicing operator in LEGAL
{
// Defining the variables Thematic soilMap(“Soils”), slopeMap(“Slope”), suitMap(“Suitability”); // Retrieving data slopeMap = Retrieve (Name = “soil”); soilMap = Retrieve (Name = “soil”); // Creating a New Layer suitMap = New(Name=“suitb”, ResX=200, ResY=200, Scale=100000); // Operation suitMap = Boolean (CategoryOut = “Suitability”) { “Good” : (soilMap.Class == “Cd1“ && slopeMap.Class == “0-3%“ ), “Average”:(soilMap.Class == “Cd1“ && slopeMap.Class == “3-8%“), “Low” :(soilMap.Class == “Cd1“ && slopeMap.Class == “8-20%“) }; }
Figure 1 – Boolean Operator in LEGAL The following program illustrates the use of the Slice operator, which transforms a SURFACE field into a THEMATIC one. In this program, the user has a surface with slope values for a terrain, and wants to generate a map of “slope classes”, which can take the values ”Low”, “Medium”, “High”. Note that the user refers explicitly to the enumeration values that are associated to the “Slope Classes” map. { // Declarations Thematic map2 (“Slope_Classes”); Surface map1 (“Slope”); Table slope_tab(Slicing); // Instantiations
3
The AMO Interface
Albeit its expressive power, LEGAL language programming is seen as a difficult task by many users, especially those that do not come from a computer background. Therefore, it has been considered necessary to build an icon-driven interface to LEGAL. The AMO interface aims at providing a dataflow interface to the generation of programs in the LEGAL language. The idea is to use visual programming tools to allow the choice of data and operators, and by using the “drag-and-drop” metaphor, to combine these elements to form a useful manipulation procedure. One of the important specific concerns in Map Algebra operations is that not all operators can be applied to all data types. In a data-flow interface, it is important that each map can only be associated to a valid set of operators, to reduce the complexity of the operator selection task. In AMO, all maps are instances of classes defined in user’s conceptual schema, which are specialisations of the basic classes SURFACE, THEMATIC, IMAGE and FEATURE. In the same fashion as LEGAL, the Map Algebra operators are understood as methods of these basic classes. Therefore, when the user selects a map of a given class, it can only be connected to operators that are valid for this basic class. The user’s task is thus simplified and the risk of errors greatly reduced.
General Description The AMO interface is divided in two “areas” (see Figure 8, at the end of the paper):
THEMATIC
•
A “navigation” area, where the user chooses the data to be processed and visualised and the operators to be applied to such data.
SURFACE
•
A “presentation” area, which shows a dataflow diagram that describes visually a map algebra procedure. The area is also used for presenting and editing GIS language programs.
IMAGE
The “navigation” and “presentation” areas are associated to different types of operations, by means of the idea of “folders”. The navigation area has two folders: •
“Data”: The data folder allows for hierarchical data navigation, similar to popular desktop applications such as MS/Explorer.
•
“Operators”: The “Operators” folder provides a hierarchical view of the available operations for fields and objects manipulation and exploration.
Figure 3 – Icons associated to the THEMATIC, SURFACE and IMAGE data types operators)
The presentation area has two different folders: •
“Diagram”: A data-flow based interface for the expression of field and object algebra operations.
•
“Program”: A text-based interface for editing and running programs in the LEGAL language.
Figure 4 – Map Algebra Operators
AMO Icons
Creation of a Data-Flow Diagram
In order to provide visual cues to the user, we have associated different icons to the basic data model classes available in SPRING. Figure 3 shows the icons associated (from the top) to the THEMATIC, SURFACE and IMAGE data types. These icons are used as visual cues to the maps as well as to the operators (Figure 4 shows a partial list of the Map Algebra operators).
The data exchange between the folders uses the “drag-and-drop” metaphor. The map algebra procedures will be defined by a data-flow interface for chaining a sequence of operations. The user will select a map or an operator and will “drag” this element to the “Diagram” area, as shown in Figure 5.
At any moment, the user can inspect the LEGAL program being generated (see Figure 8). After the diagram is completed, the LEGAL program is ready for execution and can be saved or executed from the AMO interface.
Figure 5 – Dragging a map onto the “diagram” area
Thereinafter, the data-flow diagram is constructed step-by-step, by combining maps and operators. The chaining of data to operators follow the syntax rules associated to the data model definition. For example, a Slice operator (discussed in section 2) can only have a THEMATIC map as input and a SURFACE map as output. When configuration parameters are needed (for example, in the case of the mapping associated to the unary operator), they can be entered by means of special-purpose interfaces. In this case, the semantics of the data type are taken into consideration. For example, Figure 6 shows the interface for configuration of the Weight transformation operator. In this case, the values associated to the thematic map (the input of the Weight operator) are shown on the left side, and the user will assign numeric values, which will be used to produce the output map.
Figure 7 – LEGAL program generated by AMO
4
Final Considerations
Most Map Algebra implementations (whether command-line languages or graphical user interfaces) are based on an explicit use of raster data structures, with very little semantic information available to the user. Although similar ideas are presented in interfaces such as MapModeler (ERDAS, 1993), VFQL (Standing, 1995), Geographer’s Desktop (Egenhofer and Richards, 1993), GrassLand (Global Geomatics, 2000), the innovative content of the AMO interface is its strong link to an object-oriented data model. As we hope to have demonstrated in this article, the object-oriented paradigm is of great importance in allowing an easier matching of data to operators. The advantage of expressing these operations in terms of model classes (instead of describing them in terms of raster representations, as most Map Algebra implementations) is to enable user control at a more abstract and semantic meaningful level.
Figure 6 – Interface for configuration of the Weight operator
Therefore, we consider that the combined use of AMO and LEGAL forms a useful and innovative environment for developing Map Algebra operations, which is currently being used operationally by many SPRING users.
References Câmara, G.; Souza, R.C.M.; Freitas, U.M.; Garrido, J.C.P (1996). “SPRING: Integrating Remote Sensing and GIS with Object-Oriented Data Modelling”. Computers and Graphics, vol.15 , n.6, July 1996. Egenhofer, M. and Richards, J.. "The Geographer’s Desktop: A Direct-Manipulation User Interface for Map Overlay." In: Auto-Carto 11, McMaster, R. and Armstrong, M., eds. Minneapolis, MN. 63-71. 1993. ERDAS, Model Maker Tour Guide. Atlanta, GA, ERDAS, Inc. 1993.
Global Geomatics, Grassland Home Page, , May, 2000. Mark, David M. and Andrew U. Frank(1992). User Interfaces for Geographic Information Systems: Report On The Specialist Meeting. National Center for Geographic Information and Analysis NCGIA Report 92-3. Standing, C., Roy, G. G., Functional visual programming interface to geographical information systems, Interacting with Computers, vol 7, n. 3, 1995. Tomlin, D. (1990) Geographic information systems and Cartographic Modeling. Prentice Hall, New York.
Figure 8 – AMO Interface
