Building a Multi-Scale Database with Scale-Transition ... - CiteSeerX

Building a Multi-Scale Database with Scale-Transition Relationships Thomas Devogele, Jenny Trevisan and Laurent Raynal IGN / COGIT, 2, Av. Pasteur, 94 160 Saint-Mandé, FRANCE Tel : 33 1 43 98 85 44 Fax : 33 1 43 98 81 71 {devogele,raynal}@cogit.ign.fr, [email protected]

Abstract Building multiple representations is one of the key problems in GIS. To tackle this problem, we have chosen to connect geographic data from mono-scale representations to build a multi-scale database with scale-transition relationships. These scale-transition relationships connect two sets of elements (classes, types or objects) representing the same phenomenon of the real world and carry the sequence of multi-scale operations to navigate from one representation to another. From this concept, a process has been defined to build multi-scale databases, in three steps. The first step is dedicated to the declaration of correspondences and conflicts between input schemata by the means of scale-transition relationships. In the second step, conflicts are resolved and schemata are merged. Finally, the third step corresponds to data matching, with the help of geometric, topologic and semantic information. Scale-transition relationships between objects are created during this last step. To validate the process, a multi-scale database has been produced from two existing mono-scale sets of road network data. The first results of this kernel are satisfactory.

Keywords Multi-scale, Multi-representation, Geographic database, Schema integration, Data matching, Scale-transition relationship.

1.

Introduction

Building multiple representations is one of the key problems in GIS [Brugger et al. 89]. Indeed “hierarchical planning with different levels of detail for different parts of the task, seems to be common in human way-finding” [Mark 89]. However geographic databases are very similar to maps, i.e. only one representation at one scale is available. Nevertheless, a geographical database does not formally include the notion of scale (the ratio between the size of an object on the map and its real size on the ground) ; [Goodchild 91] [Müller et al. 95] speak of precision (degree of detail in the reporting of a measurement), accuracy (relationship between a measurement and the reality which it purports to represent) and resolution (the smallest object which can be represented). For geographic databases, it seems judicious therefore to connect the determination of these three concepts with the notion of scale commonly associated with a map. So, a multi-scale database is a geographic database, which allows us to represent the same phenomenon of the real world at different levels of precision, accuracy and resolution. Consequently, designing a multi-scale database requires a representation mechanism of schema and data at different levels. Three methods can be used to build a multi-scale database [Govorov 95] : • In the first method (see figure 1), a cartographic generalization1 process is used to generate databases at smaller scales from a single database at the greatest scale. Cartographic generalization can be either automatic or interactive. For the moment, this solution seems difficult for the following reasons :

1

Cartographic generalization modifies data in order to produce a simplified, or more abstracted representation, for the sake of map legibility [Lagrange and Ruas 94].

SDH’96

-1-

(i) There are no generalization tools in GIS allowing automatic generation representations less detailed than the most precise representation [Müller et al 95]. Indeed, modifications in cartographic generalization are complex, varied and intricately interwoven. (ii) An entirely interactive generalization is too long and too difficult [Müller 92] and for these reasons seems inadequate for final users. (iii) all the pieces of information which are wanted in the generalized representation, are not present in the most precise representation. Indeed, new themes may come on top of generalization. • The second method consists of a mere collection of geographic databases with no link whatsoever between objects. Some rules can be used to control the choice of the database to display according to the graphic scale. Nowadays, this method is implemented in some GIS (Apic, GeoConcept, ArcView) but these rules are limited (the notion of scale is unsuitable for geographical databases). For example, it would be necessary to include other parameters such as the density of the zone to define display rules. • Finally, in the third method (see figure 2), a multi-scale data structure is defined in order to link representations. This last solution seems the best compromise between the re-use of existing databases and their enrichment by integration. This is why we have adopted it. The aim of this integration is not to obtain a single representation but to allow interoperability between representations and to link homologous objects between the different representations of the same phenomenon of the real world. This integration is a “semantic integration” ; schemata are integrated according to the values of data. Input representations may be physically distributed databases or data sets. In the first case, we have one distributed database [Ceri and Pelagatti 87] or a federated database [Sheth and Larson 90], and in the second case we have a single database. This article discusses the latter type of multi-scale database.

Figure 1 : a single database with a cartographic generalization process

Figure 2 : multi-scale data structure Nevertheless, the design of multi-scale data structures is difficult, due to the implicit cartographic generalization complexity [Lagrange and Ruas 94]. We have therefore opted for the concept of scale-transition relationship [Devogele and Raynal 96] defined in section 2. We will then describe the process to build a multi-scale database in section 3. Note that this process has been experimented and validated on road network databases. Section 4 offers some conclusions.

2.

Designing a multi-scale database

In this section, we will first discuss some multi-scale database research given in the literature and its limitations. This will allow us to introduce the concept of the scale-transition relationship. Finally, the assets of the scale-transition relationship will be given.

2.1

Overview

Any geographic representation is an abstraction of the real world with its own concept to represent the phenomena of the real world. Designing a multi-scale database raises three kinds of problems: • Correspondence between abstractions. Abstraction translate phenomena of the real world into instances of databases, by focusing only on parts of these phenomena. From research on DBMS, only the concept of views [Günther 89] [Abel et al. 94] has been suggested to overcome this problem. However, scale problems are not approached in this context. • Correspondence between objects from different representations. Tree structures [Jones 91][Kidner and Jones 94][van Oosterom 95][Timpf and Frank 95] [Rigaux and Scholl 95] have been proposed to describe links between the different representations. However relationships in the real world are not always hierarchical when scale varies. • Defining the matching process between objects. Data matching is a generic term to indicate methods and algorithms to search two geographic sets of data for groups of objects that represent the same part of the SDH’96

-2-

real world. To identify homologous objects, geometric matchings [Raynal and Stricher 94] [Edwards 94] [Gabay and Doytsher 94] have been suggested. We will show that they are insufficient in our kernel. What is more, these three independent problems have never been coordinated.

2.2

Representations With Scale-Transition Relationships

To design multi-scale databases, it is necessary to integrate abstractions and to connect instances. With this aim, the concept of a scale-transition relationship which uses the object-oriented data model, is proposed. The concepts used in this article are those of type, class and object. • Type defines a template for all its objects. It provides a common representation for all objects of that type and a set of operations on those objects. A type can be an atomic type (integer, real, string, boolean and enumeration) or a structured type (tuple, set or list). Types are linked by subtyping (a type A is a subtype of another type B if an instance of A is a instance of B) and inheritance (a type A inherits from another type B if A shares all the behaviours of B). • Class is a grouping of instances of a given type. • Object is an instance of one type and is included in one class. Each object has both an invariant identifier (OID) and a value. With these concepts, we can define what a scale-transition relationship is. Scale-transition relationships connect two sets of elements (types, classes or objects) representing the same phenomenon of the real world and carry the sequence of multi-scale operations to go from one representation to another. Scale-transition relationships are oriented links. Since they include multi-scale operations, scale-transition relationships are describing and storing some amount of cartographic generalization. They are more advanced structures than simple relationships between elements. Multi-scale operations are defined in [Devogele and Raynal 95] and [Peng 96]. Two categories can be distinguished : • Cartographic generalization operations as described in [Shea and McMaster 91] and [McMaster and Shea 92]. • Schema modification operations which are basically borrowed from the database theory, and more precisely from schema evolution and schema integration such as those defined in [Motro 87] [Scherrer et al. 93] and [Scholl and Tresch 93]. For example, in figure 3, one can distinguish : -Scale-transition relationships between a set of buildings and a built-up area carrying the multi-scale operation : amalgamation [Shea and McMaster 91]. -Scale-transition relationships between a road section and another road section carrying the multi-scale operation : simplification [Shea and McMaster 91]. Of course, some elements may not match due to deletion in the less detailed representation.

amalgamation simplification Figure 3 : Representations with scale-transition relationships

2.3

Assets of scale-transition relationships

These scale-transition relationships can describe the correspondence between schemata (type and classe definitions) and to link data from different representations. Furthermore, a multi-scale database using scale-transition relationships allows us to answer the different needs of multi-scale database users : • From a practical point of view, this concept allows intelligent zoom [Timpf and Frank 95] between the different representations, and analysis of data from different representations. Queries can be applied SDH’96

-3-

simultaneously on sets of buildings and built-up areas even if these two classes are not defined in the same representation. Navigation between the different representations [Car and Frank 95] [Langou and Mainguenaud 94] is also feasible because scale-transition relationships authorize to go back and forth between representations. • Information transfers between levels also become possible, giving access to the sequence of multi-scale operations between elements. This means that, at least in some cases, it is possible to propagate an update performed at some detailed level, to a less detailed level [Kilpeläinen 95]. Indeed, once the scale-transition relationship carries enough information (precise sequence of multi-scale operations, values of parameters,…), the update, also required at the secondary level, may be activated through the conversion from the basic level. However, it is clear that such an automation might prove to be quite difficult if complex geometric transformations or transformations involving sets of objects are needed. • Finally for mapping agencies, the database merging favours quality control, and the concomitance of representations in a single structure facilitates maintenance of consistency. Besides, the information on quality (geometric accuracy, semantic accuracy, …) can be easily obtained by comparison of the less detailed database, to the reference database. In any case, building a multi-scale database allows us to derive new products and to integrate new data.

3.

Process to build a multi-scale database with scale-transition relationships

Two stages are distinguished in the process to build a multi-scale database : schema integration and data matching. • Schema integration allows interoperability between existing databases, since a multi-database language and an integrated data description can be defined. This first stage is inspired by works of [Spaccapietra et al. 92] [Dupont 94] that use assertion-based methodology. This methodology splits the integration process into two distinct steps. The first step is dedicated to the declaration of correspondences and conflicts between input schemata by using scale-transition relationships. In the second step, conflicts are resolved and schemata are merged. • In the second stage called data matching, homologous objects (representing the same real world phenomenon) are connected. This process generates scale-transition relationships between objects by using semantic, topologic and geometric information. Finally, to test the feasibility of such principles, a multi scale database kernel [Trevisan 95] has been realized from two IGN’s mono-scale databases (BD CARTO® 2 and GÉOROUTE® 3) in the area of Marne-la-Vallée (367 km of road for BD CARTO® and 991 km of road for GÉOROUTE®, the network in this area being varied and dense). This kernel has been developed in O2 [O2 91] and GéO2 [Raynal et al. 95] [David et al.93]. For the sake of easy reading the BDC acronym is adopted to designate BD CARTO® and the G acronym is adopted to designate GÉOROUTE®.

3.1

Declaration of Scale-Transition Relationships

Declaration of scale-transition relationships is done at two levels : between classes and between types.

BD CARTO® contains the basic geographical information, that is necessary for the production of 1:100,000 topographic maps, for national and regional development and network management. BD CARTO® has been created by processing existing 1:50,000 maps (scanning, vectorization, topological structuring). 2

GEOROUTE® is a topologically structured road-planning database containing precise data for urban areas and uses BD CARTO® data for other areas. GEOROUTE® is used for transportation purposes. 3

SDH’96

-4-

3.1.1 Scale-transition relationships between classes Scale-transition relationships between classes are used to describe correspondence between collections of instances ; i.e. they indicate that one instance of class 1 in the schema 1 corresponds to one instance of class 2 in the schema 2. More complex correspondences are also possible. For example, Crossroads classes do not correspond GÉOROUTE® BD CARTO® exactly : -One instance of the G Crossroads class corresponds to 0 or One instance of the BDC Crossroads class (whether it is suppressed or preserved). -One instance of the BDC Crossroads class can correspond to 1 complex crossroad in G (figure 4), which is composed of instances of Crossroads and Sections classes in G. Indeed, due to the change of scale, some instances of Sections and Crossroads classes are Figure 4 : The same crossroads in BDC and in G suppressed or are symbolised in a set of fewer objects. Extended to all classes in the kernel, the scale-transition relationships are : from BDC to G (Table 1) and from G to BDC (Table 2). BDC →G

G →BDC

1 Road

1 Road

1 Road

(0-1) Road

1 Section

(1-N) Sections

1 Section

(0-1) Section or 1 Crossroad

1 Crossroad

(0-N) Crossroads and (0-N) Sections

1 Crossroad

(0-1) Crossroad

Table 1 : Scale-transition relationships from BDC Table 2 : Scale-transition relationships from G classes to G classes classes to BDC classes Once scale-transition relationships between classes have been described, it is necessary to describe scale-transition relationships between types. 3.1.2 Scale-transition relationships between types Scale-transition relationships between types describe differences in structure. These scale-transition relationships can be declared only for types whose classes correspond. Scale-transition relationships between types can be declared according to the values of data in correspondence and not according to type parameters (name, domain,…). These differences are described by multi-scale operations (see section 2.2). For example, BDC crossroad type correspond to G crossroad type : they describe the same phenomenon of the real world. For tuples, attributes must be also link. These two tuples have three common attributes (kind_of_crossroad, and toponym, geometry). Furthermore the BDC type has one own semantic attribute: spot_height. - kind_of_crossroad attributes of BDC and G that describe the nature of the crossroad, are enumerations (authorized values : simple crossroads, roundabout, interchange, …). Globally, they correspond but some values have been added or suppressed. Thus, the multi-scale operation is a function of change for lists of authorized values. -Toponym attributes which indicate the name of the crossroad, correspond semantically but they do not have the same structure : in BDC, toponym is a tuple (attributes: Kind, Article, Wording) while in G, toponym is a character string. These, the multi-scale operation is a function of transformation of tuple into character string. -Geometry attributes correspond exactly, they represent points. There is no multi-scale operation associated with this scale-transition relationship. -Spot_height attribute is only present in BDC. So, the scale-transition relationship is a deletion. This example shows a few correspondences between types. The whole set of scale-transition relationships established in the prototype will be made available in [Trevisan 95].

3.2

Schema Merging

Schema Merging is the step that unifies corresponding types and corresponding classes to build the integrated schema. In this step, the best integration techniques are chosen for each kind of scale-transition relationship. The literature proposes several techniques to integrate schemata, depending on whether we prefer to preserve or to delete the initial schemata and on the kind of integrated schemata that we wish. In our case, we want to obtain SDH’96

-5-

a schema which will be able to represent all the instances of input schemata, without loss of information by unifying structures and will be able to connect data of different input representations most precisely. To transcribe scale-transition relationships between classes, the integration technique is to create a relationship between types corresponding to classes. For scale-transition relationships between one class and many classes (or between many classes and many classes), the integration technique is to create one (or many) super-class(es) and the relationship is carried by the types of these super-class(es) (see figure 5). Therefore, these super-types are anchor points to scale-transition relationships between instances. Thus for Crossroads and Sections of BDC and G, super-types Net_el_G (Network elements of G) and Net_el_BDC (Network elements of BDC) have been created and a relationship STR_Element (scale-transition relationship between network elements) has been defined between these two super-types. All scale-transition relationships between Sections and Crossroads classes (mentioned in tables 1 and 2) are grouped in these relationships. For scale-transition relationships between tuples, a technique of generalization between types has been chosen, i.e. for each pair of corresponding types (for example Crossroad types of BDC and G), a father type is created supporting common attributes (called Crossroad, in the kernel, see figure 5) and two son types are maintained for the specific attributes (called Crossroad_G and Crossroad_BDC, see figure 5). For scale-transition relationships between enumerated types (for example kind_of_crossroad of BDC and G) supporting functions of change for lists of authorized values as multi-scale operation, the chosen integration technique is to create a new enumerated type. This type is defined by merging authorized values of these two types. For scale-transition relationships between a tuple type and a primitive type (for example toponym types of BDC and G), the chosen integration technique depends on the complexity of the transformation mechanism. If the transformation process is manual, these types remain separated ; otherwise, the tuple type is preserved and the primitive type is transformed. The latter technique is applied for toponym types of BDC and G. Once this step is finished, we have a multi-scale schema allowing us to represent input types and to represent scale-transition relationships between their instances. This multi-scale schema can be either the schema of federated databases, or the schema of a single database with several data representations. Figure 5 presents the merged schema in our kernel. Road Id Num Adm_class administrator

is composed

Id Vocation Nb_ways Nb_total_lanes Nb_up_lanes Nb_down_lanes

Begin Node Section End Node Surface_state Access 2 {ordered} Position Communication Diversion_network Direction No_drive Geometry Weight_limit

Crossroad Id Toponym Kind_of_node Geometry

Hight_limit

Road_G

Road_BDC STR_Road Multi-scale_Ope

Section_G

Section_BDC Toponym Use Installation_day frost

Add_begin_left Standard_way Add_begin_right Width_limit Add_end_left Length_limit Add_end _right Vehicle_limit Specific_equipement

Father type Son type Relationship representing Scale-Transition Relationship

Crossroad_G

Crossroad_BDC spot_height

Net_El_G STR_Element Multi-scale_Ope Net_El_BDC

Figure 5 : Multi-scale schema (OMT model [Rumbaugh et al. 91]) This base supports two representations integrated in a single schema, but the objects themselves are not yet matched.

3.3

Data matching

Data matching is a generic term to indicate methods and algorithms to search two geographic sets of data for groups of objects that represent the same part of the real world. First, we will define the different types of data matching used, then we will describe the process realized in the kernel, before presenting some of the first results. 3.3.1 Different kinds of data matching In the current context (a single multi-scale database), the data matching step is realized after the schema merging. Scale-transition relationships between objects are therefore constructed in a permanent manner. To SDH’96

-6-

match data, semantic, topologic and geometric information is used to overcome the shortcomings of simple geometric matching as presented in [Raynal and Stricher 94] [Edwards 94] and [Gabay and Doytsher 94]. • The semantic matching put objects in correspondence according to their semantic attributes, which are a key. Objects are matched on the value of their keys. • The topologic matching uses composition or topologic relationships between the different objects to match data. If two relationships correspond, then this correspondence can be used to find homologous objects linked by this relationship. • The geometric matching ; data are matched by their location with a measure of distance between objects. Other geometrical characteristics, as the direction [Gabay and Doytsher 94] have been proposed to match these data. 3.3.2 Data matching process for the kernel These three kinds of matching have been necessary for the kernel. Furthermore, the process order is fundamental (data forming a network, many relationships exist between them). Thus three successive matching processes (see figure 6) have been defined : road matching, crossroad matching and section matching. Road_BDC Road Matching

( Road_G, Road_BDC )

Road_G

Sections Matching

Section_BDC

Crossroad_G

Road_BDC, Crossroad_BDC, Section_BDC

( Section_BDC, {Section_G} ) UNMATCHED DATA

Section_G

Crossroad_BDC

INCONCICTENCY

Crossroad Matching

Section_G

Road_G Crossroad_G Section_G

( Crossroad_BDC, {Crossroad_G, Section_G } )

Figure 6: Data matching process for the kernel Road matching : This algorithm uses only semantic information (keys are attributes : number and administrator) and generates object pairs (Road_BDC, Road_G). Crossroad matching : This procedure is more complex, using geometric and topologic information. Indeed, first, we automatically determine a search area4 Search around each BDC crossroad (see figure 7) ; G crossroads in area this area are automatically selected. Group 2 Then, by using topologic relationships between crossroad and section, we form connected groups (figure 5 : 4 connected groups). We compute the connected group whose dangle sections Group 3 Group 1 (sections connected to the group) and bi-connected sections (sections belonging to the group) match with dangle sections Group 4 of the BDC crossroad. On figure 5, we observe that group 1 matches with the BDC crossroad. This algorithm is used for all BDC crossroads and generates object pairs (Crossroad_BDC,{Crossroad_G,Section_G}. Figure 7: example of connected group Section matching : Henceforth, BDC sections may be matched with G sections (previously, G sections matched with BDC crossroads must be removed). This matching is achieved in two stages. In the first stage, sections belonging to semantically matched roads are matched road by road. Then the other sections are matched.

4

A search area is the intersection between a circle and the Voronoï diagram [Yap 87] of punctual BDC crossroads

SDH’96

-7-

Geometric section matching is realized with the help of the Hausdorff distance [Raynal and Stricher 94] [Hangouët 95] [Hausdorff 19]. We obtain three kinds of G sections : • Matched section : Only one distance of the BDC section from this G section is less than the matching threshold. • Litigious section : Several distances of the BDC section are less than the matching threshold. We can not choose the homologous BDC section with distance alone. • Unmatched section : No distance of BDC section is less than the matching threshold. Either this section has no homologue, or this section has one homologue but distance is superior to the matching threshold. Although those last two matching algorithms are not optimal (certainly, one can integrate more semantic information), a process which has been able to match real data sets has been realized [Trevisan 95]. We can present the first results. 3.3.3 First results Results of road matching are 100% correct. As for crossroads, a manual match was also performed to check the automatic process. For 284 crossroads, results are as follows : • For one BDC to one G matching (191 cases), automatic matching gives good results in 84% of cases. The remaining 16% are results including the right result but also some parasitic elements. • For one BDC to many G (49 cases) results are average. Automatic matching gives good results in 41% of cases, gives a result containing only a part of the right result in 28.5%, and gives a result including the right result in 30.5%. No matching between BDC crossroads and G crossroads (44 cases), has been also analyzed: • The main reason is border objects (49.4%) for which some dangle sections are missing (in BDC or in G). • The second reason of mismatch is inconsistency (39%) ; updates are not the same and semantic or geometric quality is wrong. • The third set of reasons are conflicts between BDC crossroads being too close (5.8%): a part of the complex crossroad can not be matched with the BDC crossroad because it is in another research area [Trevisan 95]. • The last set of causes are the translations (5.8%) between the two representations that are superior to the matching threshold. Results of section matching are approximately 75% correct.

3.4 Generalization of this process Our building a multi-scale database for road network data has demonstrated the feasibility of such databases from data sets. This process can be generalized whatever : • the data (network, land use, topography, …). For example, for land use data, the schema integration phase does not change much, on the other hand the data matching phase necessitates a new process [Kidner 96] (distance between surfaces, relationship of neighbourhood, …). • the number of representations. This process can be generalized to more than two input databases by using the same methods (schema integration into a single schema then, matching two by two of instances). • the location of representations (data set, distributed databases). For the integration of distributed databases into a federated database, our first results will still have to be improved. Indeed, with autonomous databases, data matching will not be computed after schema merging, but during the processing of the multi-scale queries and only for the data involved. This “on the fly” process is very interesting but necessitates a very effective matching process. • the needs (data analysis, quality controls, …). According to the application chosen, the multi-scale schema will not comply with the same constraints. Therefore, the schema integration technique is different. Building multi-scale database is an adaptable process. This process depends on the data, the needs, the number and the location of representations. This work can be also generalized for different kinds of multiple representations (temporal, thematic,…). In this cases, new operations of correspondence will have to be defined.

4.

Conclusion

In this article, we have described a process to build a multi-scale database with scale-transition relationships. This is a three steps process : declaration of scale-transition relationships between schemata, schema merging and data matching. Because management of this kind of database is difficult, some problems must be first tackled (update, data manipulation language,…). This process must still be thorough, by optimizing the data matching and by working on the retrieve-and-store of multi-scale operations. We are continuing our research SDH’96

-8-

into the integration of geographic databases (databases from different sources or databases stemming from a generalization process).

References D.J. Abel, P.J. Kilby and J. R. Davis (1994) The systems integration problem, in Int. J. Geographical Informations Systems Vol. 8 N° 1, pp 1-12. B. P. Brugger, R. Barrera A. U. Frank, K. Beard and M. Ehlers (1989) Research Topic on Multiple Representations in NCGIA Initiative 3 Workshop on Multiple Representations, pages 53-67. A. Car, A.U. Frank (1994), Modelling a Hierarchy of Space applied to Large Road Networks, in IGIS’94, LNCS n°884, pp 15-24. S. Ceri et G. Pelagatti (1987) Distributed databases: principles & systems, McGraw-Hill. B. David, L. Raynal, G. Schorter and V. Mansart (1993) Why objects in a geographical DBMS?, in Advances in Spatial Databases, pp 264-276. T. Devogele, L. Raynal. (1996) Modeling a Multi-Scale Database with Scale-Transition Relationships, in Samos’96, T.Sellis D. Georgoulis Eds. pp 83-93 Y. Dupont (1994) Resolving Fragmentation Conflicts in Schema Integration in 13th Int. Conf. on The Entity Relationship Approach. G. Edwards (1994) Characterising and maintaining polygons with fuzzy boundaries in geographic information systems, in Spatial Data Handling,Waugh and Healey Eds., Taylor&Francis, pp 223-239 Y. Gabay and Y. Doytsher (1994) Automatic adjustement of line maps, in GIS/LIS pp 233-241. M.F. Goodchild (1991) Issue of quality and uncertainty, in Advances in Cartography, Müller Ed., Barking, Essex/ Elsevier pp 113-139. M.O. Govorov (1995) Representation of the generalized data structures for Multi-Scale GIS, in 17 th ICA/ACI Barcelonna pp 2491-2495. O. Günther (1989) Database Support for Multiple Representations, NCGIA, in Initiative 3 Workshop on Multiple Representations, pp 50-51 C.B. Jones (1991) Database architecture for multi-scale GIS, in Auto-Carto 10 volume 6 pp 1-14. J.F. Hangouët (1995) Computation of the Hausdorff distance between plane vector polylines, in Auto Carto 12, pp 1-10. F. Hausdorff (1919) Dimension und äusseres in Mass. Mathematische Annalen n° 79, pp 157-179. D. Kidner and C.B. Jones (1994) A Deductive Object-Oriented GIS for handling multiple representations, in Spatial Data Handling, Waugh and Healey Eds., Taylor&Francis, pp 882-900. D. Kidner (1996) Geometric signatures for determing polygon equivalence during multi-scale GIS update, in Second Joint European Conference, IOS Press, pp 239-247. J.P. Lagrange and A. Ruas (1994) Geographic information modelling: GIS and generalisation, in Spatial Data Handling, Waugh and Healey Eds., Taylor&Francis, pp 1099-1117. B. Langou and Maiguenaud M. (1994) Graph data model operations for network facilities in a geographical information system, in Spatial Data Handling, Taylor & Francis, pp 1002-1019. T. Kilpeläinen (1995) Requirements of a Multiple representation database for topolographical data with emphasis on incremental generalization, in 17 th ICA/ACI Barcelonna, pp 1815-1825. D. Mark (1989) Multiple views of multiple representations, in NCGIA Initiative 3 Workshop on Multiple Representations, pp 68-71. R. McMaster and S. Shea (1992), Generalization in Digital Cartography, Association of American Geographers. A. Motro (1987) Superviews; Virtual Integration of Multiple Databases, in IEEE Transactions on Software Engineering 13 (7), IEEE, pp 785-798. J.C. Müller (1991) Generalization of spatial databases, Geographical information Systems Principles and Applications, Maguire, Goodchild and Rhind Eds., Publisher Longman Scientific & Technical, pp 457-475 J.C. Müller, J.P. Lagrange, R. Weibel and F. Salgé (1995) Generalisation : state of the art and issues, in GIS and GENERALISATION, Müller, Lagrange and Weibel Eds., Taylor & Francis pp 3-17. O2 (1991) The O2 System; in Communications of the ACM, Vol 34,n°10. W. Peng, K. Tempfi and M. Molenaar (1996) Automated Generalization in a GIS, Geoinformatic’96, West Palm Beach pp 135-146

SDH’96

-9-

L. Raynal, B. David and G. Schorter (1995) Building an OOGIS prototype: experiments with GeO2, in Auto Carto 12 pp 137-146. L. Raynal and N. Stricher (1994) Base de données multi-échelles: Association géométrique des tronçons de route de la BD Carto et de la BD Topo in EGIS /MARI’94, pp 300-307. P. Rigaux and M. Scholl (1995) Multi-Scale Partitions: Application to Spatial and Statistical Databases in SSD ‘95, pp 170-183. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W.Lorensen (1991) Object-Oriented modeling and design, Prentice Hall Eds., Englewood Cliffs. S. Scherrer,A. Geppert and K. Dittrich (1993) Schema Evolution in NO 2, Institut fur Informatik der Universitat Zurich technical report n° 93-12. M.H. Scholl and M. Tresch. (1993) Schema Transformation without database reorganisation, in ACM SIGMOD Record, (22;1). K.S. Shea and R.B. McMaster (1991) Cartographic Generalisation in a digital environment When and how to generalize, in Map generalization, Buttenfield and McMaster Eds., Longman Scientific & Technical, pp 103-118. A. Sheth et J. Larson (1990) Federated database systems for managing distributed, heterogeneous, and autonomous databases,in ACM Computer Surveys 22,3 (Sept 1990), pp 183-236 S. Spaccapietra, P. Parent, Y. Dupont, (1992) Model-Independent Assertions for Integration of Heterogeneous Schemas, in Very Large DataBases Journal, 1(1), pp 81-126. S. Timpf and U. Frank (1995) A Multi-scale DAG for cartographic objects, in Auto Carto 12, pp 157-163. J. Trevisan (1995) Conception d’une BD Multi-échelles, ENSG Academic report, IGN Saint Mandé. P. van Oosterom (1995) The GAP-tree, an approach to 'on-the-fly' map generalisation of an area partitioning, in GIS and GENERALISATION, Müller, Lagrange and Weibel Eds., Taylor & Francis, pp 120-132. C.K. Yap (1987) An O(n log n) Algorithm for the Voronoï Diagram of a set of simple Curve Segments in Discete Comp. Geom. 2 journal, pages 365-393.

SDH’96

- 10 -