Interactive Geographical Information System using Lisp-Stat: Prototypes and Applications

We present a general framework of exploratory data analysis defining a set of concepts and prototypes developed within the Lisp-Stat programming environment for a M-to-M links multidimensional approach. We overview the main domains and fundamentals on which we lay the developed interactive GIS. In a second stage, we detail the different prototypes we implemented in a software called ARPEGE' and how they collaborate in providing an interactive spatial data exploration. Then we show four examples of concrete geographical applications and their underlaying data models. We end on a discussion about the contribution and the limitations of our conceptual framework and its associated software, and open to future research.


Introduction
Interactive GIS has recently developed in response to the needs for geoscientists using analytic tools and to the rapid technological evolution in spatial data management systems and geovisualization. This led scientists and private companies to renew the spatial data models and to develop efficient functionalities for spatial and temporal analysis, cartography and data mining. However, the data base size and the complexity of the tackled problem increase so much that the users and the experts expect more and more efficient tools and functionalities. So there seems to be still a large range of research to improve interactive Geographical Information Systems (GIS). This paper presents one of these numerous potential investigations.
This research results from the work of geographers who try to keep aware of the current scientific trends in related disciplines, but who are not computer scientists. So did we build clearly the concepts of our software according to a resolute concrete and subjective point of view and an inductive, empirical approach. Lisp-Stat (Tierney 1990) has been for us a powerful container and argument to modelling our geographical space using objects closed to the concrete application components, in a different way than writing functions or procedures. It helped us a lot by providing an open, coherent and appropriate framework to design a geographical real world functioning and dynamics. These specific objects classes, that we'll call most of times 'objects' in the text, belong to the field of the geographical space analysis, due to their specific data, graphs and relations. Thus, our views will be to present how and why we made such conceptual choices and designed consequent object prototypes, depending on the application geographical features and on the user requirements.
Actually, this framework is a patchwork of concepts and dedicated prototypes produced case after case on a quite long term (5 years). Although there exist alternatives to such a system (the Tk package in R for instance: the Tk Rplot), we still develop within this environment and need to use the complete series of the resulting dedicated methods. For sure, with time and willpower, it should be fruitful to incorporate the ARPEGE' framework in other statistical software, i.e. R, S, Datadesk, etc. This article gives us the opportunity to combine and update the whole package of concepts, objects and methods we developed step by step, even if we still need to make the complete integration in a proper way. In the first section, we overview the main domains and fundamentals on which we lay the developed interactive GIS. Then we detail the different prototypes we implemented in a software we called ARPEGE' and how they collaborate in providing an interactive spatial data exploration. Finally, we give four examples of concrete geographical applications and their underlaying data models, that overviews the actual ARPEGE' capabilities.

GIS, complexity and interactivity
We now set the interactive GIS (Geographical Information Systems) back in context of spatial geographical decision support process. This requires different aspects belonging, at least partly, to the following fields: the spatial data usability, the systemic approach to manage the complexity, the Geographical Data Base Management Systems, the robustness and the Exploratory Spatial Data Analysis and spatial data mining.

Spatial data usability, decision support and robustness
As the recent research show, the spatial data usability is a wide and interesting field of research (Wachowicz, Riedermann, Vullings, Suárez, and Cromvoets 2002;Wachowicz and Hunter 2003;Gould, Laurini, and Coulondre 2003;Toppen and Prastacos 2004), that intends to make the link between the user with his/her experience, the data with their quality and the method with their robustness and efficiency. It is an original way of thinking the decision process, by focussing on the relationship existing between user and data, rather than working only on the data quality or on the methods which can support the decision making, such as multicriteria analysis. The goal is to make more efficient the use of spatial data thanks to a better fitness between the data and the user. There are indeed three main points of view to consider the problem of usability, whether it is user-centred (the cognitive approach), data-centred (the informational approach) or analysis-centred (the methodological approach) (Josselin 2003). Research and developments about spatial data usability aim to develop a general framework on all of these dimensions, nevertheless by favouring each time a point of view. This paper relates to this research field.
There are different manners to improve the robustness (l.s.) in the exploration process. The user can first of all assess the robustness of the statistical indices (s)he handles. This large topic is tackled essentially by mathematicians and statisticians Tukey 1983, 1985), developing fruitful research about robust metrics (Dodge 1987) in geostatistics notably (Cressie 1993). There also exist different means to assess for the robustness of a statistical indices according to a given batch of empirical data (Huber 2000;Hampel, Ronchetti, Rousseeuw, and Stahel 1986). But another way, more user-centred, consists in elaborating specific procedures in order to improve the user capacity to make a 'adequate analysis' and to provide a 'good decision'. We believe this dimension of the robustness to state as a crucial component of the decision process. That is the reason why we developed in our interactive GIS ARPEGE' some functionalities and graphic prototypes allowing to follow the exploration process, as we'll see later. A next step of integration would be to associate a group of persons working on the same project for a common goal: those approaches are actually being developed within the GIS research and are called the participatory GIS. Our position is that there remain still consequent improvements to be made to deepen the relation between the user and the data and to offer to him/her appropriate means to explore his/her data.

A systemic approach based on dynamical relations to manage the complexity
The need for experts and decision makers to improve their knowledge and their acuteness during the planning process becomes more and more pressing. The questions of environment and urban sustainability require the decision supporters and makers to deal with very large (spatial) data bases. This is nowadays made easier by the software capacity for storing and querying the data, that enables to tackle the problem and manage its complexity within a systemic approach. The systemic approach (VonBertalanfy 1980) is often considered as paradoxical to a Cartesian approach (Descartes 1637). It is partially true. Both Cartesian and systemic approaches break the problem in many parts. But while the first method expects the global solution to emerge from the sum of the disaggregated pieces, the second one (the systemic) focusses on the relation and the importance of its part of explanation. We think the interactive GIS must take that position and consider the relations as key components of the system. So do we jointly manage two levels of complexity: the geographical application (i.e. the spatial data) and the exploration (i.e. the data base structure, the software and its functionalities) systems.
But having defined the relations as available, selectable and modifiable objects isn't enough to provide a real efficient spatial data exploration. If this has a powerful impact on the model usability due to its representation, this doesn't make more accessible the spatial data. Indeed, we need to explore interactively the data through a complex, accessible and understandable systemic model. Dynamic links provide such a crucial requirement (Hasslet, Bradley, Craig, Unwin, and Wills 1991). The user must be able to 'feel' the data and the systemic model as (s)he explores them without worrying about any technical procedures required to allow the investigation. The idea is to provide a (as large as possible) set of efficient and fit-to-use methods of a high conceptual level to tune the parameters for visualizing and exploring the data, with different lights, keeping in mind that the maps and the graphs are not neutral vectors of information (Wood 1992;Monmonier 1993). Such a position leads to improve the efficiency and the speed of the methods, especially those dealing with large sets of data. We shall see further that we propose to implement different kinds of relations commonly composed by two elements, for selection and action. Both of them can operate using only a mouse or a key of the keyboard.

From geographical data base management systems to interactive Geographical Information Systems (GIS)
For users and experts in geography, the Data Base Management Systems and especially the Geographical ones provide very useful functionalities. The first one is the high capacity storage thanks to hardware evolution. The second one relates to the Structured Query Languages which are extended to topological and geographical needs. They allow to write easily quite complex queries adapted to geographical features (Longley, Goodchild, Maguire, and Rhind 2001). Sometimes, advanced Case Tools are implemented for making easier the model designing (Oracle and the GIS Smallworld System, for instance). The third interesting property corresponds to the graphical and cartographic functionalities in GIS software. The fourth functionality sets in the integration of both entity-relation and object oriented modelling, expressed in the famous Unified Modelling Language (Muller and Gaertner 2001). ARPEGE' tries to take into account (at least parts of) this progress. Let us notice that a few GIS software tend to include such dynamic links and exploration methods in their core (ArcGIS, for instance) or in additive components (Anselin and Bao 1997), that is a proof of their relevance.
But the contribution doesn't only come from the software of the GIS field. It also comes from the approaches which encompasse the philosophy itself of exploration, because it holds the basic bricks to build dedicated applications, for geography or any other discipline. This research or software belong to either the statistical domain of the exploratory (spatial) data analysis (EDA) (Velleman and Hoaglin 1981;Chambers, Cleveland, Kleiner, and Tukey 1983;Cleveland and McGill 1988;Cleveland 1993Cleveland , 1994Bailey and Gatrell 1995;Fisher, Scholten, and Unwin 1996) or the (interactive) (geo)visualization (Hearnshaw and Unwin 2000;McEachren and Taylor 1994;Peterson 1995;Kraak and Ormeling 1996;Card, Mackinlay, and Schneiderman 1999;Waniez 1999;Slocum 1999;MacEachren and Kraak 2001;Spence 2001;Josselin and Fabrikant 2003). For instance, Datadesk or Lisp-Stat or its affiliated software such as Arc (Cook and Weisberg 1999) or Vista (http://forrest.psych.unc.edu/) are developed in this spirit. In spatial analysis or data mining (Zeitouni 1999), there also exist different research and applications, among which a few are developed in Lisp-Stat (Josselin 1999;Banos 2001;Brunsdon 2001). That is the case of ARPEGE'. Although we just expect the storage capacity of hardware to increase, the computer memory and the processor cadence to provide a sufficient speed, we propose several ways to improve the exploration capacity. As we previously emphasized the important role played by dynamic links during the geographical data exploration, we propose to access to the data and to their relation only by graphic selection and links, rather than being forced to write (sometimes in many steps) and execute a query. We believe it highly accelerates the exploration process. About the cartographic and semiologic requirements (Bertin 1967;McEachren 1995), we guess they are not as important as in the classical 'static' cartography because the colours and the representations accuracy is made relative by the exploration process and the permanent access to individuals values.

The entity-relation model devoted to the dynamic links between the objects
Concerning the spatial data modelling, even if we didn't yet implemented a Case Tool, we associate the object oriented and the entity-relation models in the following way: the object oriented model enables to build a hierarchical structure of objects more and more specialized inheriting from their parents. This approach allows to access to the numerous statistical functions, slots and methods of the parent prototypes from which are inherited the geographical prototypes which can nevertheless process their own methods (polymorphism). The entityrelation model managed notably by lists in Lisp-Stat, fulfil until now our needs in terms of relationship.
To reach a systemic approach of space, we developed a generic method, that enables to combine spatial data interactive representations. When a user needs to query the spatial data, those have to be stored in a format allowing their quick and easy access. Although this functionality seems to be commonly implemented thanks to a direct link between objects, there should exist a similar way to provide it for multiple related individuals between for a couple of objects. That is what we propose with the ARPEGE' software (Josselin 1999(Josselin , 2000. This is a kind of extension of the dynamic links, in the sense it is enabled for any type of Many-to-Many relation, including association and aggregation. The internal data model of ARPEGE' includes several complementary components that the exploration process requires ( Figure 1): • the graph prototypes in which the geographical data use to be depicted, that may be a map, • the spatial data prototypes, those are geographical features with particular geometries, that may be polygons delineating geographical areas, • the relation prototypes between different graphs which make them dynamically interact, those able to trigger off different calculations and behaviour of different objects.

Prototypes within ARPEGE'
3.1. Graph objects used during an exploratory spatial process The geographical prototypes inherit from the graph prototype There exist a very large variety of information graphics (Harris 1996). All the geographical graph prototypes developed in ARPEGE' inherit from the top parent, the graph-proto, depending on the number of their associated variables. Most of them come from the 'obgeo' prototype which is adapted from the scatterplot prototype. The prototype specialization depends successively on whether it deals with spatial or temporal information, on the aspects tackled (e.g. exploration vs application time) and the objects handled (e.g. maps vs topological structure) during the geographical phenomenon exploration process and on more concrete purpose (e.g. variogram) and data (e.g. polygons) to which the graph prototype is devoted. The hierarchical structure is presented in the Figure 2. A specific 1 dimension object for geography analysis: The distogram prototype The distogram ( Figure 3) prototype is an histogram having additive properties (Josselin and Fabrikant 2003). This graph is useful in geography because it is often needed to group quantitative values in classes and also to assess the impact of the distribution on a map. We couldn't make this prototype from the histogram because its functionalities were too peculiar and required a complete re-design of the histogram. Indeed, the individuals are grouped by blocks in the same class. Their selection in the distogram involves the whole set of individuals in the class, although some of them can be selected in other linked graphs and then compressed down to the bottom of the target class in the distogram. It is not possible to select them individually. The distogram is associated to another object listing the available graphics modes. Thus, it is possible, with a simple click, to select the class, to move interactively a class boundary, to divide a bin in two, to group two bins in a unique one, to transform the variable or a part of it, to change the colours of each class. In the menu, the user can also access to several interesting ways to define automatically the class limits (by equal amplitude, quantiles or variance analysis). Dynamically linked to a map, the distogram is very useful to choose the appropriate number of bins and to enhance the pertinent boundaries (class limits) in a statistical distribution according to a variable mapping, its discontinuities and its local spatial autocorrelation, as we shall see later. A piece of the distogram Lisp code is given in the appendix.

Figure 3: The Distogram
A 2 dimensions map object: The time representation prototype We defined two separated prototypes, whether they are related to space vs time representation. They derive from a dedicated prototype, obgeo, developed to support the spatial analysis requirements. This prototype has specific slots and methods to enable to manage and make cooperate the space and time representation objects (i.e. a list of spatial data and relations and their types).
The time-representation prototype contents are mainly hierarchical ordered sequences of points. The graph includes a start point, one or many end point(s) and a series of inter-mediate points between those. Each point focuses on a given state of particular importance for the user or the application. When selecting one of these points, it sends a list of messages to perform the appropriate combined methods to a list of graphs and to highlight the involved individuals redrawn in the wished correct state. This kind of graphs is required by the user for two different purposes, involving two different time representations: • the application time: that is to say the process observed in its dynamics, including the geographical object births, life and deaths and even all events during a geographical process that mark the phenomenon; the user can build a scenario of events included in the application, a sort of film, in which s(he) will be able to identify any interesting stage of the phenomenon. If time lays on the X axis, then the sequence of ordered events is not regular. Using the brush, selecting the event(s) or launching the animation, the user has different ways to understand the dynamics of the territory (s)he studies.
• the exploration time corresponds to another time relating to the explorer investigation; it is indeed possible to mark checked times during the process in order to retrieve easily some key states. This kind of graphs is initiated when needed, then new points are added by the user, according to the way s(he) manages his/her exploration. At the end of the process, the user gets a picture of the important steps of his/her spatial data investigation. More information will be given in the section about how to extract complex objects or concepts composed of several selected objects, with their characteristics and their activated relations.
The time-representation prototype is a kind of dendrogram. Although it is not yet completely implemented, we can see an example of its structure in the Figure 4. The graph represents a sequence of exploration in a spatial database, during which the user stored several checkpoints.

Figure 4: A Time representation prototype
A 2 dimensions map object: The generic 'obgeo' prototype generates the map and the spatial-structure prototypes We often think about maps to depict the spatial information. In practice, there exist lots of other methods to help to understand how the geographical space is organised. Thus, the space representation prototype includes two main types: • the map-prototype, in which the spatial data are simply drawn, • the spatial-structure prototype, that provides complementary and synthetic views on spatial data, essentially based on their topological structure.
Most of the map prototypes we propose look like scatterplot prototypes in the sense they are based on an Euclidian representation of space, crossing two particular variables in Y and X: latitude and longitude. As we shall see when presenting the spatial feature objects, these maps can support several kinds of spatial data, including points (points-map prototype), arcs (arcs-map prototype), polylines and polygons (polys-map prototype, cf. Figure 5), and pixels or images (pixels-map prototype, cf. figure 6). As an example, we extracted a few of the code written to design the polygon prototype in the appendix.

Figure 5: A Polygons-map prototype
Sometimes, it is useful to have a description of the topological structure, that is to say, a clue, a statistical estimator or any method to emphasize the way the geographical objects are connected one to each others. For instance, a co-occurrence matrix gives the frequencies of all possible connexions between objects (every objects to all the others), a variogram crosses a variance with the distance between coupled objects, the fractal prototype does the same but transforms the two previous variables in log. The cooccu-matrix prototype behaves like an image whose pixels are disconnected (Figure 7). The variogram or fractal prototypes are plotted using a dynamic sampling when they deal with very numerous data ( Figure 8) and draw a non linear regression, such as a Lowess.

Space-time representation prototype
We also actually develop a generic space,time-representation prototype which allows to depict the 'time-geography' (Chardonnel 2001) objects. This prototype adds new properties to the spin-proto, such as arc drawing between points in 3D (using the method :add-lines), downground mapping and text adding. It can be used to study ordered series of events, in relation with their location. Z can be set as a discrete time or a sequence of a geographical object state (activity, transport modes, or any attribute of an individual). The Figure 9 shows a simplified example of how it can be used: we can follow the position of a group of people on the map in the bottom of the graph according to the transportation mode they use (represented in Z), successively the car (from point 44 to 48) parked in 48, the bus (from 49 to 58), then a walk down-town (58 and 59). As the obgeo prototype, this space-time prototype includes the slots and the methods necessary for ARPEGE' to work (the list of spatial data and relations, and their types).

Spatial feature prototypes to depict the specific geographical objects
The dedicated topological model The geographical information is built on a set of primitives, such as points, polylines or polygons, depending basically on their points coordinates (Figure 10 Heywood, Cornelius, and Carver 2002). We developed a generic model compatible with most of the spatial data models encountered in geography, however differing from them because of its high level of decomposition. While most of the common topological model separate the raster format and the vectorial format, we propose to associate them in the same framework. Moreover, topological model generally lays on four basic features: vertex, nodes, arcs and polygons. Despite the fact that these features ensure a sufficient topology management, they are not always taken into account as individuals. For instance, it is often necessary to create a node table to assign variables to nodes. It remains also delicate to handle segments or vertex, without re-building or searching into the complete geometry encoded in the polygons or polylines using a computer program.
In our spatial data model, we intend to reach the highest possible number of spatial granular- Figure 9: The Space-Time prototype ities. Indeed, we believe that every feature can be used at any time as spatial individuals for a measurement. For instance, when studying a road network, it may be fruitful to measure the sinuosity due to all the little segments along the roads, to sum the points (vertex and nodes) that compose a road, to count how many and which sort of roads are connected to a given category of road crosses. Our spatial data model ( Figure 11) aims to be as close as possible to the practical needs and also to allow the exploration of all the spatial primitives, dynamically linked through the topological structure. The most basic primitive is the point, which can correspond to nodes if they start or end an arc, or simple vertex. Two points can be aggregated in a segment (two linked points). Several segments make an arc, composed by two extreme nodes and a sequence of vertex. Finally polylines include several arcs. They describe simple chained arcs (a cycle) or more complicated networks with shared nodes (planar graph). A special case of polyline corresponds to the polygon: a closed simple polyline. Independently from its geometry, any geographical feature is also represented by an only point, the centroide for the polygons or the pixels areas, the centre of the segments or the polylines. This might be particularly useful when handling objects made with several different objects (a composite object). Figure 11: The spatial feature prototypes The Figure 12 shows a part of a map of polygons and polylines in the vicinity of the French river Loire. The geometries differ from each others but represent the same geographical space. The link between the two representations is made using a relation object.
The Figure 13 presents a network composed by sections of roads (arcs) and crosses (points). These data can be directely connected in order to study their reationship.
A complementary representation of spatial data consists in a raster continuous field. It is concretely a matrix of pixels whose values assign a given variable. This matrix may be a picture or a remote sensing image. Inside it, (groups of) pixels can exist whereas they share some specific properties, have the same value for an attribute, or correspond to a well delimited geographical objects. Images or raster objects are composed with pixels, with a given accuracy.

Spatial composite objects
The concept of (spatial) composite object is now widely approved by the researchers, the experts and the users in GIS ; see for instance Hornsby and Egenhofer (1998). It is indeed included in the normative specifications given for the geographical information modelling by the Open GIS Consortium (www.opengis.org). A composite object is an heterogeneous set of objects whose the association justifies the object existence ilself. Our definition is somehow differing from the current sense, because, beyond the set of objects, it includes a set of relations informed by a set of variables. The interest is that these variables can encode a list of objects (for selection in other objects), a statistical estimate (characterizing the statistical relation between two kinds of individuals belonging to two different objects), or even a behaviour (defined by a piece of code in a method assigned to the object).
For instance, a road network is a combination of different spatial data: the entire roads, their sections, the crosses ( Figure 13). Each relevant feature is mapped in the corresponding graph prototype: the roads in a polys-map object, the sections in an arcs-map object, the crosses in a point-map object. Moreover, the main road can be assigned to a linear set of pixels. The exploration of the topology structure is then enabled by the relation prototypes described in a following section. So, the user may be interested in finding a route as the shortest path in the network from a point A to a point B. But is is possible to tackle more complicated spatial analysis. For example, if the expert studies the occurrence of road accidents and the topological structure of these routes, the frequency of accidents and their type can be crossed with the number, the size and the type of the road sections, even the network connectivity. This leads to analyse the statistical dependencies between the basic elements making the composite objects through their relations. So, the spatial composite objects include objects and relations, all of them carrying their own variables, data, slots and methods. They are of great interest for the users and experts, especially when they are found out during the spatial data mining process and correspond to recurrent objects or patterns. Associated with other a-spatial information, these objects integrate many descriptors helpful to describe them on complementary points of view. This approach proceeds like an (interactive) spatial data mining. Every type of composite object can be grouped in a class and described with a lot of pointers and different geometries and semantics.
Among the all objects and relations involved in making the composition, the composite object has a slot giving the list of the key ones which are to be stored and showed for defining the object. Here is its general shape with sets of (optional) elements, as it is implemented in ARPEGE' (that can differ depending on the application):

(List-of-Graph-Objects List-of-Relation-Objects)
A graph object is described by its prototype, its identifier, its title and the list of its individuals with their attributes: (Graph-Object-Prototype Graph-Object-Name Graph-Object-Title List-of-Individuals-IDS Listof-Attributes) A relation object is similarly described, adding the origine and the target objects and a list of variables: (Relation-Object-Prototype Relation-Object-Name (From-Graph-Object To-Graph-Object) (Listof-From-Graph-Individuals-IDS List-of-To-Graph-Individuals-IDS) List-of-Variables) A variable has a name and a value: To end this section about the spatial composite objects, we propose to distinguish them according to their particular status. There are two main ways to identify composite objects, whether they correspond to successive steps of the observed geographical phenomenon or they are considered by the user as very important states during the analysis. In other words, the time line and its discrete points can be given by the application itself or by the user during the exploration process. In the first case, the application data base generates what we could call 'flags' during its own sequence, from its internal discontinuities or even automatically (every five seconds, a point is added to the time graph). The user can also play the role to insert these flags when (s)he feels it as appropriate. This can provide a simple storage of composite objects in a predefined class without any graphical representation, or a view of the exploration process in a time representation object as we saw above. In all these cases, there exist a 'flag', or a 'check-point' or a 'point', that enables to extract or to access to a composite object.
We shall see a few concrete examples in the applications presented below. But before, let us deepen a little more the relation prototype.

The relation prototypes: A way to link dynamically graph objects
The double purpose of the oriented relation prototype One of the crucial functionalities of Lisp-Stat is to provide a very efficient dynamic link between objects, due to object orientation, the possibility to send messages between objects and the quick selection by lists. As in most of the software developed in this statistical programming environment, the objects interact from the individual to the individual. We propose to enlarge this capability to many ways of relationship. We defined two principal objectives of the link: • the individuals selection: when a set of individuals is activated in a graph, a set of other individuals is selected and highlighted in (an)other graph(s); • the action: the individuals activation can also trigger off a more complex action having different possible impact on the object list.
Most of time, selection and action are related, but they can happen independently.
Generally, the relation corresponds to a piece of code that performs the dynamic link. This implementation, although efficient, has a major limit. Indeed, the relation cannot be informed because it is not considered as an object on its own. For instance, in spatial analysis, a relation can have a limited validity period: an interval or a date can be assigned to this relation. This is especially true for the topological relations when geometry of objects evolve during the life cycle. Nevertheless, this is a general issue to any type of relation. That is why we implemented the relation prototypes (Figure 14), as it is provided in the advanced data bases. They carry the relationship between a couple of objects. The relation prototype owns two key slots: • the list of the triggered objects, • for each of them, the lists of the targeted individuals.
It also implements specific methods according to the kind of relations developed.
Let us notice that our relations are one-direction oriented ('the object A has an effect on the object B' and 'the object B has an effect on the object A' are two different relations). There can exist some possible incoherence due to cyclic relations that users have to be aware of. Only binary relations are allowed (the ternary relations are decomposed in binary relations), due to the general functionalities of our relation prototype: selection and/or action.

The selection prototype
The selection prototype can define either a direct link (each individual of an object is represented in the other object, using the bijection prototype) or an indexation (i.e. any of the individuals can be possibly in relation with any of the other individuals). The indexation prototype provides three main types of relations: the association (the most general one), the aggregation (an individual of the object is always connected to at least one individual in the other object) and the filiation (a way to manage inheritance and historicity).
It can be surprising to consider the filiation as a relation. Indeed, the object orientation provides a useful framework for inheritance between objects. It is helpful to structure the knowledge at a high level of concept. But the filiation also becomes a specialization of the indexation prototype, in the sense it is ordered. A parent can have none or numerous children and an individual can inherit from none (it is the first one in the filiation) or many parents (l.s.). Two prototypes can be required whether we focus on the antecedence (ante prototype) or succession (post prototype). Those are very efficient to study (geographical) objects historicity.

The action prototype
On the other side of the Figure 14, we can see the action prototype, including three different prototypes. If the user wants to visualize individuals on a rather elaborated way (local zooms, specific colours, etc.) then s(he) can ask for the visualisation prototype containing several dedicated methods. Moreover, the need can also concern specific processes or calculation. In this case, the result won't be graphic but rather numeric (calculation prototype). Finally, the most complicated action on an object would be a change on its behaviour, such as starting an animation, changing the structure of its data, etc. The distinction between these three categories of actions is sometimes delicate to set, but this can help the user to decompose the relations in several parts easier to study.

Applications in spatial analysis
To build an application using ARPEGE', we need first of all to identify the objects we want to study and the relevant associated graphs depicting a category of geographical features or a statistical view of a discriminant variable. After having done that, the user has to find or to develop the most appropriate relational objects owning the functionalities and the methods required. The important part of the work is to populate and to update the index Many-to- Figure 14: The relation prototype Many for each couple of graph objects, especially for the indexation prototype. Most of times, the user will have to develop its own methods for customizing the action prototypes.
We now give three different uses of ARPEGE' and some of its prototypes in concrete geographical applications. What is it possible to? What is the information provided for making the exploration process feasible? What is the structure of the model and its relationship design. According to the import of this paper, we shall focus on the structure of the data model and the required objects (graphs, geographical features and relations), rather than thematic results that are detailed in other papers (Josselin 2003).

Exploring the dynamics of sport activity
As in most of the applications, the visualization object is used in the exploration process: this is one of the fundamentals of exploratory spatial data analysis. This first application gives a simple example of an exploration within a sample of objects described by a set of variables (Figures 15 and 16). The bijections manage the direct dynamic links between a map of polygons (some municipalities around the town of Besançon, France), two distograms (per municipality, the level of sport penetration and the sport activity balance) and a name list (the names of the municipalities). The objective of the global project was to enhance the municipalities missing equipments or sport association and to propose new settings.
In the example, the user can moreover design a strategy of exploration and follow it through different steps and directions using an exploration-time object. Each 'check-point' of the time explorer points to a state of all the related objects: it calls back the distograms shape and their current selection, the zoom on the selection in the map and the selected individuals in the name list. After a selection made within another object, the distograms process a calculation which redesigns their classes according to the selection. We can notice that, in this application, the whole set of relations between the distograms, the map and the namelist is bidirectional, whereas the exploration-time object can also send messages to the other objects, due to its particular status.

Exploring the 'agricultural flows' and aggregating the French municipalities
In this second example, we depict the agricultural flows scope and dispersion among the municipalities of the territorial division 'Isère', in South-East of France (Figures 17 and 18). Three geographical features are described by several variables: the municipalities with different sorts of flows (internal, outgoing or incoming) and a measure of territorial coherence called 'the territorial pertinence', the aggregates of municipalities, partitioning the space according to their territorial pertinence, and the flows strictly speaking, assessed by their values. Many graphs are involved: two polys-map objects (with polygons), an arcs-map object (with segments) and several related histograms. Exploring the functional and statistical relations between these different objects provides to extract composite objects considered by the user as relevant. This allows for instance to define the geographical areas where the agricultural activity is rather sustained.
This structure requires a quite complex set of relations: bidirectional bijections between maps and their own histograms and association relations between the three groups of features.
Those are due to the geographical system: a division includes one or many municipalities, a flow joins two separated municipalities. The relation linking the municipalities and the Figure 15: The spatial data model for exploring the dynamics of sport activity Figure 16: Exploring the dynamics of sport activity divisions has a particular behaviour, because it is possible to modify the spatial partition by a new aggregates composition in accordance with the expected distribution of the territorial pertinence. There exist different ways to make new aggregates, by switching two municipalities from an aggregate to another, transferring a set of municipalities or selecting a group of municipalities regardless of their aggregate initial membership. Once the individuals are selected, a message is sent through the relation to trigger off the map, and to change the structure of its spatial feature geometry and topology. In this case, the process is performed by two relation objects, a behaviour relation object and a calculation relation object. As the time exploration object presented previously enables the exploration monitoring, the composite object class allows to fix a list of states of data selection and relations activation that the user can be consider as important.

Exploring the wine ropes organisation on an image
This application presents a case of interactive image processing, whose aim is to find some relevant signatures of wine ropes organisation (Figures 19 and 20). We activate there a set of objects which aim to emphasize different dimensions of the studied territory spatial organization. The pixel values histogram shows a distribution of the radiometric levels. The co-occurrence matrix object calculates, for each cell of it, the frequency of the values corresponding to a given kind of pixels adjacencies (the pixel values are grouped in a few classes). The variogram object includes a new scaling dimension in the sense it crosses the absolute deviation between two pixel values and the distance that separates them. These three graph objects highlight several complementary aspects of the spatial structure. Figure 19: The spatial data model for exploring the wine ropes organisation This results in a dedicated exploratory structure composed by an image on which the user

Interactive GIS using Lisp-Stat
can move a resizable window in which the pixels are processed. The three graphic representations of spatial structure and an application time object store the change of three statistical parameters during the move of the window. Each stored value of the parameter can point on a state of the process, including the window location in the image, the list of the involved pixels, the co-occurrence matrix values, the coordinates of the Lowess processed in the variogram graph, the summary of the pixels value distribution, etc. For instance, here is such a composite object stored in the application-time object, including the prototype, the name, the individuals or parameters and a few statistical estimates:  30 27 17 6 16) (23 55 47 10  17) (18 46 32 13 19) (7 12 14 1 14) (9 15 17 10 37) So, when the user moves the window with the mouse, this activates the other graphs by a dynamic calculation which leads to generate a set of all the couples of contiguous selected pixels (N ) and a sample made instantly from the whole set of pixels couples (N 2 , a selected pixel is computed with all the others) to improve the speed. Figure 19 shows which types of relations are involved and Figure 20 a concrete example of the territory exploration.
4.4. Exploring the shapes and the evolution of a large river: The Loire (France) We shall end the series of examples by an environmental application, requiring a very large set of geographical data, because it includes the river Loire and its vicinity on a part of about 100 km long. In this example, the topology is directly coded in the model ( Figure 21). The goal is to find out small topological patterns whose occurrence reveals peculiar evolutions of the Loire between two different dates: 1973 and 1983 ( Figure 22). Five main objects are defined: two raster maps (remote sensing data on a part of the geographical extent and a set of joined aerial photographs) and three map objects (polygons-map objects for the land use in 1983 and its evolution, arcs-map object for the linear structure in arcs in 1983). Again, to each feature is attached a set of graphs, among which histograms are dominant (e.g. pixel values for the images, shapes and categories for the land use polygons and their evolution, twists and length for related arcs, etc.). The composite objects class is also available as in the second application we presented.
The relations are made with two principal sorts of prototypes. The bijection objects deal with the statistical representations and their relative geographical graphs and features. The association objects provide to explore the spatial data base in a specific way. Indeed, each pixel from both of the raster map is indexed to the polygons of the land use and its evolution. So can we directly get any relevant signatures combining sets of typical pixels values, land use areas categories and topological linear structure (arcs which compose the polygons).
Here is an example of a little part of a composite object 'loire65' extracted during the exploration process:

Conclusion and further works
In this paper, we explained the way we developed concepts and dedicated prototypes in order to model different geographical spaces within ARPEGE', among those we believe some are original and powerful (the distogram, the time representation, notably). A key point is that our approach exceeds the simple functionality to activate several graphs using a direct selection of individuals through dynamic links. Indeed, the M-to-M relationship is implemented and works very quickly. This modelling emphasizes the role of the relation as an explicit object that brings a useful information about how is structured and functions the geographical space.
It also provides to extract and store spatial composite objects corresponding to rather high level spatial concepts. Indeed, it involves an heterogeneous set of objects (spatial patterns), with their individuals and their relationship. On a practical point of view, we pretend the exploration process of a systemic geographical model is made easier using ARPEGE'.
But there are still some limitations to such a framework. The design of any application remains still very delicate to provide, due to the difficulty to populate the numerous pointers. The image and pixels management is not yet optimal (and very slow when dealing with large spatial extend), because of the possibility to handle group of pixels which led us to define the pixel as the most little grain composing an image. Some of the prototypes need their properties to be completed. Moreover, there is a quite high redundancy of information (i.e. data in the graph objects and in the relations), due to the relation objects structure. These points are relating to the way we implemented the concepts and might be at least partially solved by an efficient programming (spatial indexation, such as R-trees, etc.) we intend to provide. The Case Tool, called the 'Visioner', is actually being developed, in order to help the user to build and visualize his/her application structure. We also foresee, for a same graph object (for instance, composite), to depict different kinds of geometries, differently than pointing to geometries belonging to other graphs. Let us notice that, in none of our exploration processes of composite objects, we finally did not need to extract statistical relations between linked objects, even if their strength would encourage us to do it. Why? First, the only fact to extract composition of objects seemed to us sufficient at a first step of exploration. Secondly, if it seems easy to use statistical methods to assess the statistical relation between two variables describing a set of individuals (for example: the Khi square or the correlation tests), we didn't make any investigation to compute statistical estimators between variables describing two different batches of individuals.
So, these first developments open to other research able to improve again the spatial data usability: • improvement of the efficiency of the code and the completeness of the concepts; • use of robust methods for analysing the statistical dependency between objects of different classes through their relations; this work relates to the spatial data mining; • expanding of the concept of composite object: more easier selectable, available heterogeneous geometry, multiple geometries depending on the scale level; • finding applications where the information assigned to the statistical relations must be addressed and can be managed easily.