-------------------------------------------------------------------------- Modelling historical change in southern Corsica: temporal GIS development using an extensible database system. [1]Janet Bagg Department of Sociology and Social Anthropology [2]Nick Ryan Computing Laboratory, University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, UK. -------------------------------------------------------------------------- Introduction The history of GIS architectures is closely bound up with the development of modern database systems. The distinctive requirements of spatial data management for GIS and CAD have provided a major driving force in extending the range of applications supported by general purpose database systems. Improving database performance and the extension of the range of supported data types has in turn led to the development of more integrated spatial database systems in which much of the functionality of earlier GIS is incorporated directly in the database system ([3]Larue et al. 1993). A second issue linking GIS and database research is that of temporal data management ([4]Langran 1992, [5]Peuquet and Wentz 1994, [6]Al-Taha 1994). Although many prototype temporal database systems have been developed ([7]Böhlen 1995), most current GIS and database products remain snapshot oriented systems capable only of static representations of data. In these systems, change through time, although central to many applications, can only be modelled by very simplistic methods. After many years of research prototypes, we now appear to be moving into an era in which integrated GIS architectures will become commonplace. Several vendors of major database products, including CA/INGRES and ORACLE, have recently introduced spatial extensions designed to manage vector data in the form of points, lines and polygons. Despite these promising developments, the pace of change amongst the more established products is relatively slow when compared with that shown by several of the more recently introduced extensible relational and object-oriented database systems. In particular, support for raster-based spatial data is rare and the established vendors have yet to address the issues of supporting temporal models beyond that provided by the SQL standard. In this paper we begin by briefly reviewing some of the major limitations of the conventional loose coupling between spatial and non-spatial components. Closer integration of GIS and DBMS has frequently been offered as a solution to such problems, but examples of implementations are less common and reports of their use in non-trivial applications are even rarer. Here, we present a straightforward approach to the modelling of spatio-temporal information and the implementation of this model using [8]Illustra, an extensible relational DBMS. The approach relies heavily on the object-oriented features of this system, and provides a clear indication of what is possible with modern extensible relational and object oriented database systems. In the final part of the paper we illustrate these methods through their use in a project studying family, marriage and property in a mountain commune in southern Corsica. Spatial data comes from a series of land surveys consisting of maps and tabulated information and incorporates temporal changes affecting properties in and around the village from 1888 until the 1950s. The project also uses a large amount of information from other documentary sources which are linked to the spatial data. 'Conventional' GIS approaches Conventional GIS such as GRASS and IDRISI have concentrated on the management and manipulation of spatial, or geometric, information and provide only minimal support for links with non-spatial, or attribute, data stored in external files or databases. Others, such as ARC/INFO, have been developed from the outset as hybrid systems that manage spatial data using a specialised spatial engine and non-spatial data by a simple relational database system. The limitations of such hybrid approaches are well known ([9]Larue et al. 1993). Queries that bridge the spatial and non-spatial domains must be performed at the application or GIS integration layer and are unable to take advantage of optimisation, integrity control and constraint mechanisms within the DBMS or spatial data engine. Many applications of GIS are concerned with the study or analysis of a large body of information, only part of which may be spatially referenced. Ideally, it should be possible to deal with spatial and non-spatial data as components of a single coherent data model, with a single user interface that generates alphanumeric or graphical query results as required. In practice, users and application developers must often work with two distinct operational models. Although it is possible to model vector data in a relational form, the required level of normalisation and a lack of suitable multi-dimensional indexing methods place severe limitations on performance. Effective integration of spatial and non-spatial data management has become possible only with the development of suitable abstract data types and indexing mechanisms as integral components of modern database systems. A 'Spatial' Database With the passing of time, most of the historical reasons for the separation of function between spatial and non-spatial systems have been overcome. Increasingly, modern object-oriented and extensible relational DBMS support the development of new data types. For example, two- and three-dimensional points can be treated as distinct types, rather than needing to be spread over two or three columns of a relational table. Where the type system permits variable length large objects, vector polygon and path data can be managed as single objects. With this approach it is no longer necessary to decompose these into large numbers of point coordinates. Similarly, many systems now permit text and raster image data to be stored as large objects. Although some are limited to handling BLObs (Binary Large Objects) where the application is expected to interpret the contents of an amorphous object, it is increasingly recognised that user-defined data types, both large and small, need to be supported as first class objects with an appropriate functional interface to implement their behaviour within the database. The one-dimensional indexing methods of conventional database systems are notoriously inadequate for multi-dimensional spatial data, and methods based on Morton number or z-order ([10]Orenstein, 1986) provide only partial solutions. However, some database systems such as [11]POSTGRES ([12]Stonebraker and Rowe, 1986) have addressed this issue either by providing additional access methods suited to multi-dimensional data, or by allowing indexes to be built using user-defined functions. The benefits that accrue from developing such an integrated system are largely those associated with the use of database systems within any information system context. A single, coherent, data model covering all aspects of an application's data, both spatial and non-spatial, can support multiple views of the data whether they are concerned with conventional alphanumeric information, geometric or graphical representation, or GIS oriented map layers or coverages. Conventional database mechanisms can be used to control redundancy, enforce referential integrity and apply other application-specific behavioural constraints. If basic GIS functionality can be provided as an extension to normal database functions, then it is readily incorporated into any application without the need to address the difficulties of using separate systems. Illustra: An 'Object-Relational' DBMS In this paper we describe our experience of developing a spatial and temporal information system using [13]Illustra. Others have demonstrated its application to managing satellite imagery and associated metadata ([14]Anderson and Stonebraker, 1994). Illustra is a relatively new commercial database system that traces its ancestry to the [15]POSTGRES project at the University of California, Berkeley ([16]Stonebraker and Rowe, 1986). Illustra, described by its vendors as an 'object relational' DBMS, is an extensible system based on the relational model, but incorporating features more commonly associated with object oriented systems. Amongst the major features of Illustra are user-defined data types and functions, and inheritance between tables and types. The data type facility enables users to create specialised types and to define their behaviour by writing suitable functions, operators and aggregates. In addition to these 'base' types, composite types may be defined, and constructed types (arrayof, setof, ref) are available for any base type. A flexible rule system provides a useful mechanism for implementing complex behavioural constraints. Add-on libraries of data types and associated functions are also available as optional extensions. These 'DataBlades' are each tailored to a particular application area. Amongst them are collections of 2D and 3D vector spatial types and an image type library intended primarily for image processing applications. Unlike some simpler spatial extensions found in other systems, these include support for R-Tree indexing ([17]Guttman, 1984; [18]Beckmann et al., 1990) and directed graphs in addition to the basic vector types. Extending the Illustra temporal model Temporal issues in GIS can be divided between data management, display and analysis. From our database oriented perspective, it is first necessary to solve the problems of data management. There is now a substantial history of research on temporal issues in database systems ranging from discussions on the taxonomy of time ([19]Snodgrass and Ahn, 1985), through prototype implementations, to extensive proposals to extend query language standards ([20]Snodgrass et al., 1994). For a recent survey of much of this work, see [21]Tansel et al., 1993). The approach taken here has been to exploit the extensibility of a modern database system to provide an adequate range of data types to support application requirements. These types, together with a range of functions to implement their behaviour, permit temporal referencing of application objects and temporal queries against the database. They provide a platform for the further investigation and development of analytical and display methods suitable for GIS applications. Illustra provides a transaction time mechanism based on tuple timestamping and a 'no overwrite' storage system. Other than this, temporal support is limited to that of the SQL 92 standard and there is no built-in mechanism to support the concept of valid time ([22]Snodgrass and Ahn, 1985) beyond what can be achieved through conventional SQL statements. To support several historical and archaeological projects, one of which is described below, this basic temporal model has been extended to include date, period and interval types with both variable granularity and uncertainty. Unlike the conventional SQL types, these permit dates and durations of time to be specified with a granularity ranging from a single day to a millennium. Uncertainty can be expressed independently of granularity and the range of permitted dates covers a period of approximately ±5.8 * 106 years. These extensions provide a basis for modelling imprecise details of historical change in spatial and non-spatial data. Some aspects of this work have been reported elsewhere ([23]Ryan, forthcoming), and a detailed description of the implementation is in preparation. The instant type represents a located point in time or, more simply, a date. The alternative name is necessary to avoid conflict with the existing SQL type. The precision of an instant, its temporal resolution, depends on its granularity. Its accuracy is specified by an optional error or uncertainty figure. In the current implementation, the uncertainty term defines the bounds of a uniform distribution, but this will be extended to allow other distributions in a future version. Determinate periods must normally be expressed in SQL as a pair of datetime columns, but their use is sufficiently commonplace to warrant a distinct type. The period type represents an anchored duration of time and is specified by its start and end instants. Granularity and uncertainty are treated in the same way as for the instant type. The third type, the span, is an unanchored duration of time, similar to the SQL interval types but here there is only one type covering the entire range of granularities. [24]Table 1 shows several examples of the external representation of each of these types. The implementation includes a full set of Boolean comparison operators based on the rules of temporal topology (Before, During, OverlapAtStart, etc.). For indeterminate instants and periods, these are extended to include alternative versions that return the probability that the comparison is true. There is, as yet, no mechanism for dealing with relative time as, for example, when a is before b, and b is before c, but the date of one or more is unknown. In view of the extended date range covered by these types and their intended application to historical problems, some form of multiple calendar support is essential. At present the Gregorian and Julian calendars are supported, with an experimental implementation of the French revolutionary calendar. Functions are provided to convert between these calendars, and the default calendar can be chosen by the user. In due course, the calendar mechanism will be generalised and extended to allow user-defined calendars to be included. A simple mechanism for supporting valid time is provided by a ValidTime base class. Application classes derived from this inherit a range of methods that permit temporal topology comparisons at the tuple level rather than as functions operating on columns. In practice, this adds no extra functionality to the system but may be considered as extending the expressiveness of the query language. The current implementation, though sufficient for many applications, is regarded as an early prototype and much further development needs to be undertaken, particularly in the areas of probability distributions of uncertain dates, multiple calendar support and the expression of relative time networks. The spatio-temporal data model [25](Figure 1) Figure 1: Core elements of the spatial data model. Each class shown here is a virtual base from which other classes can be derived as necessary. The SpatialApplicationObject provides a means of spatially referenncing application objects by linking them with their geometric representations. The GeometricObject classes cover all drawable geometric types, whilst the MapLayer classes support the conventional GIS model of layers or coverages. Queries against the database may be composed from either an application or GIS perspective, either of which may result in a collection of displayable geometric shapes. The core of the spatial data model employed here is a simple structure centred on a collection of geometric objects -- points, lines, polygons, raster grids, etc. It permits straightforward access to subsets of these objects that form graphical representations of spatially referenced application objects. This provides an 'application view' of the spatial database in which general queries involving any spatially referenced object can return the geometric information necessary to display a spatial representation. At the same time, the structure also supports a more conventional 'GIS view' where layers can be constructed as required, and accessed by queries against this map-oriented part of the database. Besides the general benefits of having all data under the control of a database system this model offers several immediate benefits over that of the loosely coupled hybrid systems. In particular, it is a simple task to ensure that the DBMS maintains referential integrity between the spatial and non-spatial data. The model also ensures that only one copy of each geometric object is stored, irrespective of the number of application objects or map layers in which it is used. The SpatialApplicationObject provides a virtual base class for all spatially referenced classes within the application. Its purpose is to manage the links between objects in the application and their geometric representations. Unlike in a conventional relational approach, these links are implemented using a set-valued type to handle the 'foreign key' references to the geometric object classes. This single data member, geometry, of type setof (ref (GeometricObject_t)) provides links to one or more instances of the GeometricObject classes. This acts as a container for all instances of the GeometricObject classes that make up a graphical representation of the application object. This might be a set of lines or polygons, or a combination of different geometric shapes. Application designers may derive new specialised classes directly from SpatialApplicationObject to suit their particular requirements. The GeometricObject class is the virtual base for all geometric classes. Pre-defined specialisations include two and three-dimensional points, lines and polygons, and raster image data. These derived classes are sufficient for many simple applications but, where necessary, they are readily extended to match more complex requirements. The MapLayer class is a virtual base for all classes representing either complete maps or the conventional GIS concept of layer or coverage. MapLayer objects provide basic layer details common to all such maps including name, description, and bounding box coordinates, together with a data member that contains a set of references to instances of the GeometricObject classes. Pre-defined derived classes include VectorMapLayer and RasterMapLayer. These specialise the basic MapLayer class by adding appropriate details such as original scale and digitiser resolution for vector maps, or cell size for raster maps. Any class derived from the core spatial classes may include one or more of the three temporal types described earlier and so provide both spatial and temporal referencing. For example, a derivative of VectorMapLayer might include an instant to represent the date when the map was digitised and a period to indicate the currency of the map. A period timestamp attached to a class derived from SpatialApplicationObject provides a straightforward means of linking a temporal sequence of geometric representations to a single application object. Although not used in the application described later in this paper, there are circumstances in which it would also be desirable to add a temporal element to classes in the GeometricObject hierarchy. For example, data provided by mapping agencies may include survey dates corresponding to each geometric item. Here, timestamps associated with individual points, lines and polygons would provide a detailed survey history, whilst those associated with instances of the MapLayer class might correspond to map editions. As with information on the accuracy of surveyed data, it may often prove more appropriate to adopt this approach than to treat this information as global metadata, particularly where the modern map is a composite resulting from a long and complex survey history. Spatio-temporal queries The SpatialApplicationObject and MapLayer class hierarchies employ a symmetrical approach to referencing their associated instances of the GeometricObject classes through single data members containing sets of reference types. This structure can be exploited using Illustra's ability to return a polymorphic result set from a query against a single base type. For example, in the extended SQL syntax, the statement select g from GeometricObject g returns one tuple for each instance of an object within the GeometricObject hierarchy. Each result tuple contains a single column of type GeometricObject. This is a composite type which, in turn, contains all of the attributes of the particular (sub-)type. Polymorphic queries thus return a result set with 'jagged rows', where the number of attributes in each tuple depends on its type. Function-valued, or virtual, attributes can be defined with late binding, so that they also are evaluated correctly according to the type of each tuple. This method may then be used to retrieve all geometric information required to draw a single map: select g from ( select unique mapdata from VectorMapLayer where descrip like '%Quenza%' and Overlap(source_date, '1884'::instant) ) t, GeometricObject g where t = g.oid; Here, the inner nested select statement returns the set of references (object identifiers or OIDs) held in the mapdata member of the MapLayer object, in this case a vector map of the village of Quenza originally made in 1884. In this example the temporal restriction uses the Overlap function that evaluates to true if there is any temporal overlap between the two arguments. A simple equality restriction is inadequate because it would only succeed if the value was stored at the same granularity as the supplied literal. Stored values such as '1/4/1884', '4/1884' or '188x' are not treated as equal to '1884'. Using Overlap allows the query to match values of the source_date column that lie within, or overlap the start or end of, the specified year, irrespective of their stored granularity. Similar queries can be formulated to retrieve the geometry associated with one or more instances of the SpatialApplicationObject classes. One of these will be illustrated in the later section describing the example application. The Quenza Project In order to illustrate the use of these methods, we now present some examples from a project examining kinship, marriage and property in the [26]commune of Quenza in the mountains of southern Corsica from 1681 to the present day. Questions addressed by this work involve marriage patterns, patronage relations, property transmission, residence and migration. All have clear temporal elements. A database was built to access linked information from a variety of sources. Registers of birth, marriage and death, population listings and censuses provide information about family, marriage and residence. Legal documents such as testaments, contracts, sales or property divisions are rich in detail concerning social relations and the use of space. Information from fieldwork is also incorporated, including notes, annotated genealogies and photographs of events and places in the commune. The main sources of spatial information are surveys with maps and tables of data on use and ownership. Two historical land surveys exist for the commune of Quenza. When the French acquired Corsica from Genova in 1768, the administration set about discovering its value. The Plan Terrier de la Corse ([27]Albatriccia 1981), made between 1770 and 1795, recorded the types of land use in each commune and broad categories of ownership. New maps were made to accompany the volumes of figures and description. Text and maps were related through numbered areas which do not necessarily correspond to enclosures on the ground. The ancien cadastre is a survey of land parcels made in each French commune in the 19th century ([28]Clout and Sutton 1969). Quenza was surveyed in 1883-4. Two books recorded the ownership, extent and quality of each parcel; one presented this information by parcel, the other by owner. A further book listed built properties such as houses and factories. Communes were divided into sections within which each parcel was numbered. Alongside the books, detailed maps from new surveys were produced and annotated with the parcel numbers listed in the books. When properties changed hands, updated information was entered into the book listing by owner until 1913 when a new book was made. This in turn was updated until a complete new survey was made in the 1950s. The two maps have been converted into machine readable form using methods appropriate to their contents. The relevant parts of the Plan Terrier map were photographed and images stored on a Photo-CD to provide a source of raster-based data. The maps of the ancien cadastre were digitised in vector form as polylines representing parcel boundary segments. The associated land use and ownership information, together with the material from other historical documents, modern maps, field observations and interviews, has been recorded as conventional alpha-numeric data. Much of this information is temporally bounded and displays a degree of temporal uncertainty common to historical data. The questions asked of this temporal-spatial database range from conventional historical demography (population description, age at first marriage, etc.), to temporal aspects of transhumance settlements in the uplands. Graphically presented genealogies are used to plot other variables (residence, ownership, etc.). Work is also being done on querying and comparing processes, for instance the transmission of landed property. The application A number of tools have been built to query the spatio-temporal database and display textual or graphical results. The tools communicate indirectly with the database server using a simple client application which passes queries to the server and returns results in a readily interpreted form. Most have been constructed using Tcl/Tk ([29]Ousterhout, 1994). Tcl is a simple scripting language and Tk is a toolkit extension for building graphical user interfaces. The versions used here run under UNIX with Tk as an X Window System toolkit, but recent releases of Tcl/Tk are also available for Mac and PC platforms. [30]Figure 2[31] Figure 2 (45kB) Figure 2 shows the main spatio-temporal query and map display tool. This functions in a similar way to many GIS display modules in that it allows different collections of geometric information to be retrieved and overlaid to form composite maps. If required, a composite result can be saved as a new MapLayer object in the database. Objects to be displayed are selected by composing and executing SQL queries which can be entered 'by hand' in a pop-up window. However, the interface also incorporates a number of aids to query composition so that part or all of the query can be generated using menu options or other interface elements. In due course, these capabilities may be extended to provide a more complete visual query composition tool. The temporal range of each query is set using the two slider controls to the right of the map window. These set the starting date and duration of the period of interest. The particular object class to which the temporal restriction is applied is chosen from a list of classes in the 'Database' menu. Figure 2 shows the display after several distinct queries have been executed. Initially, vector point and line date were retrieved for three MapLayer objects corresponding to the 1884 and 1953 cadastral maps, and some recent fieldwork observations. These queries were of the same form as the example discussed earlier. The temporal constraints were then set to cover the period 1884-1893 and a further query executed to retrieve vector polygons corresponding to land parcels owned by one Jean Come Pietri at this time. Here, the temporal constraint was applied to Propown, a class that includes a valid time element and links Owner with Property. Owner contains a subset of all persons in the database, and Property contains groupings of land parcels that represent single 'units of ownership'. This class has data members holding details such as location, area and class of land, and is linked to the Parcel class, itself a derivative of SpatialApplicationObject. This final query was as follows: select g from ( select unique pa.geometry from Parcel pa, Property pr, Propown po, Owner o where o.owner = po.owner and po.prop = pr.prop and pr.prop = pa.prop and Overlap(po.valid, '1884~1893'::period) and o.snom = 'Pietri' and o.names = 'Jean Come' ) t, Polygon2D g where t = g.oid and Overlap(g, '(510700,4622800,512200,4624300)'::Box); The temporal overlap restriction supplied by the slider controls is applied to the valid time element of the Propown class. Unlike the earlier MapLayer example, the overlap is tested against a period type. The query result is limited to instances of Polygon2D and any derived classes. A spatial restriction is also supplied by the application to clip the result to include only those polygons within the displayed area. [32]Figure 3[33] Figure 3 (45kB) Where necessary, further temporal constraints may be added by manually editing the query. In figure 3 the main period of interest has been changed to 1910-1919, and separate queries, similar to that above, have been used to retrieve the land owned by three of Jean Come's siblings. These queries were edited to add further constraints to select only the land that had been owned by Jean Come in 1884. Line and fill colours may be selected from a menu, or set to correspond to a column returned by the query. Here, the fill colour was changed using the menu before each new query was executed. Separate queries were used here to show the land owned by each individual sibling. However, we anticipate that future versions of the application will include ways of using genealogical and inheritance information stored in the database to provide more direct access to groups of individuals and their properties. As well as drawing maps in response to queries, the application provides the user with constant feedback including the current cursor position in world coordinates and the type and OID of any GeometricObject under the cursor. As the cursor is moved these objects are highlighted. Double-clicking on an object is used to retrieve details of any associated SpatialApplicationObject. In most cases, this information is in alphanumeric form and is displayed in the query window, but this mechanism can also be exploited to retrieve graphical or other representations. Figure 4 shows a general view of the application with several of its component windows, including four photographic images that have been retrieved in this way. Spatially and temporally located photographic information represents a particularly important source for anthropological research. [34]Figure 4[35] Figure 4 (218kB) Four symbols (disks with direction of view arrows) can be seen on the map, two at the south-west end of the village and two near the north east corner of the window. These represent OrientedPoint2D objects, a sub-class of GeometricObject. A Photograph class derived from SpatialApplicationObject holds details of all photographic images stored in the database. Instances of this class are linked to OrientedPoint2D objects to provide their geometric representation. Each image is displayed in response to a query generated when the user double-clicks on its associated symbol. The Photograph class includes a timestamp, making it possible to selectively display symbols corresponding to photographs taken at particular dates. Conclusions The intention of the work described here has not been to develop a fully functional GIS platform, but to explore the potential of extensible database systems to support spatial and temporal applications. To this end, we have implemented a number of data types and functions concentrating on those of direct relevance to the particular application. Given a suitable platform, the implementation of such extensions is a relatively straightforward task and they can, in turn, provide the basis for adding further functionality as required by other applications. Despite these limited objectives, we are satisfied that a seamless method of managing both spatial and non-spatial data can be achieved, and that this approach is appropriate for building a complete GIS platform incorporating greater analytical capabilities. In this paper we have concentrated on the management of temporal and vector spatial data, but future work will also include further development of raster types, the implementation of layer algebra functions, temporal uncertainty and methods for handling relative chronology. In developing a single coherent data model for spatio-temporal information systems Illustra has proved to be an effective platform. The availability of suitable data types in the spatial and image DataBlades has allowed us to concentrate on the development of temporal types and of the core data model. It is, however, the object-oriented features of this database system that have proved most effective in supporting the implementation of our model. Polymorphism in query results and late binding of functions have proved particularly valuable, allowing us to work with easily extensible class hierarchies in the data model, and greatly simplified queries in the application. Without these capabilities, displaying a complete MapLayer or SpatialApplicationObject would have required a separate query for each sub-class of GeometricObject employed in the model. At present, the data model and application described here can only be supported effectively by products like Illustra or one of a relatively small number of object oriented database systems. Eventually, such features may become more widespread in relational database systems as the benefits of extensibility are more widely recognised. References A. Albitreccia, Le Plan Terrier de la Corse au XVIIIe siècle. Laffite, Marseille, 1981. K. K. Al-Taha, R. T. Snodgrass and M. D. Soo, 'A Bibliography on Spatio-temporal Databases,' International Journal of Geographic Information Systems, Vol. 8, No. 1, 95-103, January-February, 1994. J. T. Anderson and M Stonebraker, 'SEQUOIA 2000 Metadata Schema for Satellite Images', ACM SIGMOD Record, Vol. 23, No. 4, 42-48, December 1994. N. Beckmann, H.-P. Kriegel, R. Schneider and B. Seeger, The R*-tree: An Efficient and Robust Access Method for Points and Rectangles, Proc. ACM SIGMOD Int. Conf. on Management of Data, 322-331, 1990 M. H. Böhlen, 'Temporal database system implementations,' ACM SIGMOD Record, Vol. 24, No. 4, 53-60, December 1995. H. D. Clout, and K. Sutton, 'The Cadastre as a source for French rural studies'. Agricultural History:215 - 223, 1969 A. Guttman, 'R-Trees: A Dynamic Index Structure for Spatial Searching', Proc. ACM SIGMOD Int. Conf. on Management of Data, 47-57, 1984 G. Langran, Time in Geographic Information System, Taylor and Francis, London, 1992. T. Larue, D. Pastre and Y Viémont, 'Strong integration of spatial domains and operators in a relational database system', in D. Abel and B. C Ooi (eds.) Advances in Spatial Databases: Proc. of the 3rd International Symposium SSD 93, Singapore, June 1993, Springer-Verlag, LNCS 692, 53-72, 1993. J. Orenstein, 'Spatial Query Processing in an Object-Oriented Database System', Proc. ACM SIGMOD Int. Conf. on Management of Data, 326-336, 1986. J. K. Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, Reading, Mass., 1994. D. Peuquet and E. Wentz, 'An approach for time-based analysis of spatiotemporal data,' Proc. of the 6th International Symposium on Spatial Data Handling, Edinburgh, 1994. N. S. Ryan, 'Towards a generalised temporal model for GIS and database applications', in K. Lockyear and V. Mihailescu-Birliba (eds.), Computer Applications in Archaeology 1996, Proc. of the 24th annual conference held at Iasi, Romania, March 1996 (forthcoming). R. Snodgrass and I. Ahn, 'A Taxonomy of Time in Databases', Proc. ACM SIGMOD Int. Conf. on Management of Data, 236-246, 1985 R. T. Snodgrass, et al. TSQL2 Language Specification, published electronically, 1994, available via anonymous FTP from ftp.cs.arizona.edu. M. Stonebraker and L. Rowe, 'The Design of POSTGRES', Proc. ACM SIGMOD International Conference on the Management of Data, 1986. A. Tansel, J. Clifford, S. Gadia, S. Jajodia, A. Segev and R. Snodgrass, Temporal Databases: Theory, Design and Implementation, Benjamin-Cummings, Redwood City, California, 1993. -------------------------------------------------------------------------- Last updated: 22nd November 1996 References Visible links 1. http://lucy.ukc.ac.uk/Janetpage/index.html 2. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/ 3. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Larue 4. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Langran 5. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Peuquet 6. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#AlTaha 7. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Bohlen 8. http://www.illustra.com/ 9. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Larue 10. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Orenstein 11. http://s2k-ftp.cs.berkeley.edu:8000/postgres/ 12. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Stonebraker 13. http://www.illustra.com/ 14. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Anderson 15. http://s2k-ftp.cs.berkeley.edu:8000/postgres/ 16. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Stonebraker 17. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Guttman 18. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Beckmann 19. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Snodgrass 20. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#TSQL2 21. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Tansel 22. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Snodgrass 23. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Ryan 24. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/temptype.html 26. http://lucy.ukc.ac.uk/Janetpage/quen1.html 27. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Albitreccia 28. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Clout 29. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/Modelling_historical_change_in_southern_Corsica.htm#Ousterhout 30. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/fig_2.gif 31. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/fig_2.gif 32. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/fig_3.gif 33. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/fig_3.gif 34. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/fig_4.gif 35. file:///usr/share/eprints3/archives/kar/documents/disk0/00/02/15/08/01/fig_4.gif