Spatio-Temporal Data Management Using Object ... - CiteSeerX

Spatio-Temporal Data Management Using Object Lifecycles A Case Study of the Australian Capital Territory Spatial Data Management System Dr Kristin Stock Abstract The representation of time in spatial information systems allows historical data to be maintained and analysed, but increases system complexity. While many early methods for handling spatio-temporality are limited or inefficient, more recent methods are expressive but complex. The object lifecycles method represents temporality using discrete stages in an object’s life, focuses on the aspects of spatio-temporality that are relevant to a specific land administration domain and is therefore simpler than the spatio-temporal methods that are designed to handle all scenarios. The method has been successfully applied in a production environment: the ACT Spatial Data Management System. Dr Kristin Stock ACT Planning and Land Authority 16 Challis Street Dickson ACT 2602 [email protected]

INTRODUCTION Spatio-temporal databases are databases that store information about both spatial and temporal characteristics of data in addition to the usual attributes; and identify changes to spatial and attribute data over time. Such systems allow historical data to be maintained so that the world can be represented at a particular point in time, and so that changes in a specific time period can be identified. A number of different methods have been proposed for the representation of temporal data in spatial information systems, ranging from snapshots of an entire database at a particular point in time to advanced event-based models that allow the full complexity of space-time relationships to be modelled, including relationships between space, time and attributes, and the patterns and form that those relationships might take. While these methods have become increasingly sophisticated and model reality progressively more closely, they have also become increasingly complex, mainly because they seek to provide a complete model of the way space and time interact in the real world. However, most production systems for everyday purposes do not require a full and complete representation of space and time, and a limited subset of such complete systems would suffice. This research proposed a method for handling spatio-temporality that is such a subset, representing only those elements that are needed for the system concerned. The object lifecycles method takes a processfocussed view of space and time, since this is most reflective of the environment for which the method was developed. It represents temporality using a series of stages in an object’s life, recording the dates on which those changes are attained. Possible stages are determined for a particular object type, and may be used to reflect changes to geometry or the nature of the object. The method is simplified by the exclusion of the representation of attribute changes, since these are rare in the system concerned. The contribution of this research is to illustrate the development of a method using a subset of temporality that is tailored to a specific application domain; and to propose a method for representing temporality that is suited to the situation described in this case study. The proposed object lifecycle method may be used in other similar application domains, and a similar approach to the development of a method for a given domain may be adopted for different application domains.

This paper initially reviews the nature of time as it applies to spatial information systems, and the aspects of temporality that may be represented. It then discusses the methods that have been proposed for the representation of spatio-temporality. The following section presents a case study: the Australian Capital Territory (ACT) Spatial Data Management System and describes the methods that were adopted to represent spatio-temporality based on the requirements of that particular system. Finally, the paper evaluates the object lifecycles method from the perspective of the original requirements and the practical implementation. ASPECTS OF TEMPORALITY The addition of temporality to a spatial database is accompanied by a significant increase in complexity. Spatial data are multi-dimensional, and the inclusion of the temporal component requires the consideration of a number of extra variables. Furthermore, there are many different aspects of time, each having an impact on the way time and space are represented in a spatial information system. Figure 1 provides a diagrammatic representation of the different aspects of time that may be addressed by a spatio-temporal information system. These aspects take the form of a spatio-temporal pyramid, with the most primitive aspects at the base and the richest, most complex at the apex. The bottom level of the spatio-temporal pyramid contains the three primitive components: location, temporality and properties (Yuan, 1999). These components represent spatio-temporality, but only at a basic level. The second level of the pyramid contains aspects that express changes in each of the primitive components:
Changes in temporality express creation, destruction, amalgamation, replacement, division and cloning of objects (Worboys, 2005).
Changes in the location of an object include movement, whether gradual, rapid or sudden.
Changes in the properties of an object (for example, a change to the name of a building). The third level of the pyramid contains aspects of spatio-temporality that express the relationships between changes at the second level:
The relationships between changes to temporality (for example, the relationship between the destruction of one object and the creation of another, or the amalgamation of two objects and the destruction of a preceding object).
The relationships between changes to object location (for example, a change to the alignment of a road and the boundary of an adjacent parcel).
The relationships between changes to object properties (for example, an increase in the height of a building and an increase in the number of storeys).

PATTERNS IN THE RELATIONSHIPS BETWEEN CHANGES IN LOCATION, TEMPORALITY AND PROPERTIES

RELATIONSHIPS BETWEEN CHANGES IN LOCATION, CHANGES IN TEMPORALITY AND CHANGES IN PROPERTIES

RELATIONSHIPS BETWEEN CHANGES IN TEMPORALITY

CHANGES IN TEMPORALITY

TEMPORALITY

RELATIONSHIPS BETWEEN CHANGES IN PROPERTIES

RELATIONSHIPS BETWEEN CHANGES IN LOCATION

RELATIONSHIPS BETWEEN CHANGES IN LOCATION AND TEMPORALITY

CHANGES IN LOCATION

RELATIONSHIPS BETWEEN CHANGES IN LOCATION AND PROPERTIES

LOCATION

CHANGES IN PROPERTIES

PROPERTIES

Figure 1: The Spatio-Temporal Pyramid

Between the third and the fourth levels are three additional aspects expressing the relationships between different aspects of change, including changes in location that are related to changes in time and changes in properties that are related to changes in location (a third aspect [changes in properties that are related to changes in time] is not shown in the figure because it does not have a spatial component, but most of the comments that relate to the two illustrated aspects also apply). These aspects also cover the types of relationships that may exist and provides a composite picture of how changes are interrelated. The fourth level of the pyramid expresses more complex spatio-temporal reasoning, referring to the relationships between changes to location, changes to temporality and changes to properties. This fourth level expresses a ternary relationship (in comparison to the binary relationships at the lower levels), and includes the expression of processes, cause and effect interactions, control interactions, coincidence, life histories, episodes, lifelines and chronicles (Langran, 1989; Worboys, 2005). The highest level of the spatio-temporal pyramid expresses the most complex aspect of spatio-temporality: the patterns between the relationships between changes in location, changes in temporality and changes in properties. These patterns may include: • chaotic or steady; • linear, sub-linear or branching; • cyclic or acyclic; • converging, diverging or oscillating; • clustered or episodic; • discrete or continuous and • based on instants, intervals or spans (Li and Cai, 2002; Peuquet and Duan, 1995). Patterns may also take the form of functions that determine the value of object properties or location based on time or vice versa (Li and Revesz, 2003). The aspects of time depicted in the spatio-temporal pyramid are those aspects that allow a spatio-temporal information system to express space, time and property values of objects in the real world, together with the

relationships between them. Other researchers have addressed the inclusion of additional temporal information in such systems (for example, Langran, 1993; Sutherland, 1996; Roddick et al, 1999), but this information takes the form of metadata of various types, and is system information rather than information about objects in the real world. These metadata aspects are not discussed further in this paper. The SNAP and SPAN ontologies developed by Grenon and Smith (2004) reflect the different levels shown in the spatio-temporal pyramid. The SNAP ontology represents temporality in the form of the three primitives at the first level in the pyramid, while the SPAN ontology includes the first through to the fourth levels in the pyramid. While the aspects shown in the pyramid represents increased richness and expressiveness, all aspects are not always necessary for all projects. Advanced spatio-temporal analysis may require many of these aspects to be considered, but many land information systems whose purpose is maintenance and presentation of temporal aspects will require only a subset of these aspects. As the level of expressiveness of a system increases, so does the complexity, and the two considerations must be balanced. MECHANISMS FOR REPRESENTING TIME The aspects of spatio-temporality that were presented in the previous Section express the kinds of information that may be represented in a spatio-temporal system. They address the question of what information a spatio-temporal system represents. Another important (and related) consideration is the question of how spatio-temporal information is represented in such a system. That is, what mechanisms are used to represent the aspects of time contained in the spatio-temporal pyramid? At a conceptual level, any spatio-temporal information system contains mechanisms for representing the three primitive components of such a system: location, temporality and properties. These three components are the basis of the triad model (Peuquet, 1994) and the three domain model (Yuan, 1999), and are fundamental to all mechanisms for representing time and space in information systems. At a logical level, the requirement to represent space, time and thematic or attribute information can be broken down into more specific methods of representation, these methods becoming more advanced over the last two decades, and progressively adding more of the temporal aspects shown in the spatio-temporal pyramid. The first spatio-temporal systems represented time using snapshots, and at their most rudimentary, these were snapshots of an entire database at different points in time. In order to fully represent temporality using snapshots, a snapshot is required each time a change is made to the database. This method works well for data that change infrequently and where there are multiple changes at a single time, as occurs in the case of natural disasters (for example, a catastrophic tidal wave). However, many spatial information systems contain data that change frequently in small increments (for example, land administration systems). Full snapshots are a problem for systems where data changes frequently because it is not practical to take a snapshot after each change due to high data volumes and the time taken to create the snapshot. Less frequent snapshots inevitably result in a loss in information and it is not possible to determine the time at which changes between the snapshots occurred, or determine how data looked at a particular point in time if that time does not coincide with a snapshot (Hornsby and Egenhofer, 2000; Hunter and Williamson, 1990; Langran, 1989). The problems involved in the full snapshot approach have led to refinement so that snapshots are confined to progressively smaller segments of the database, with three possible alternatives as follows. Relation (or table) snapshots, so that only relations that have changed are included in the new snapshot. This approach is suitable if there are significant changes to an entire table (for example, if the entire cadastral fabric of an area is modified), but suffer from many of the same problems as the full snapshot approach on a reduced scale (Langran, 1989). Tuple (or row) snapshots, so that only tuples that have changed are included in the new snapshot. This approach can be implemented in several different ways:

a)

storing a start and end date for each tuple, or possibly multiple start and end dates for different types of temporality; b) ordering tuples so that tables contain time slices with identity preserved across tuples and c) segregating history data in a separate table and connecting tuples using history chains (Hunter and Williamson, 1990; Langran, 1989). Attribute snapshots, so that only the attribute values that have changed are included in the new snapshot (Price, 1989) so that there is no redundancy. The space-time composite model (Langran and Chrisman, 1988) is an example of this approach (Yuan, 1999). These three approaches represent progressively less redundancy and consequently reduced data storage and management requirements. As a result, the representation of all changes (rather than periodic snapshots) becomes practical, and it is possible to determine exactly when a change took place or to view data at a specific point in time. However, there is a cost associated with the increase in richness of representation: the system becomes more complex and data maintenance becomes more difficult. In their basic form, all of the snapshot approaches model only the aspects in the first and second levels of the spatio-temporal pyramid (show in white in Figure 1). These methods do not model changes and events explicitly, but focus on the state of an object before and after the change, so relationships between events or changes cannot be explicitly represented. The methods also do not handle movement well (Yuan et al, 2004), and do not allow temporally determined relationships between objects to be defined. For example, it is not possible to identify when an object has changed to the point where it becomes a different object, or the link between the old and new objects (Worboys, 2005). More recent research has proposed the use of an event-based model for representation of spatio-temporality (for example, Peuquet and Duan, 1995; Chen and Jiang, 1998). This approach models events, changes or transitions explicitly, and therefore allows more advanced information about these events to be represented including relationships between events and changes to locations or properties (the third level in the spatiotemporal pyramid, shown in light-grey), and the form, pattern and constraints associated with those relationships (the top two levels in the pyramid, shown in dark-grey). Such interactions include collections of associated events of various types (for example, cause and effect), with varying time lags and complex (sometimes hidden) relationships (Li and Revesz, 2003). For example, the European MurMur project uses an event-based model to express object lifecycles and also provides tools for expressing constraints of various types, including before, after, during, starts, finishes, instantaneousness or continuity (Minout et al, 2004). The modelling of events in this way provides opportunities for much more advanced analysis of spatio-temporal relationships and moves beyond the ability to view data at a specific point in time or to examine changes in a time period (Worboys, 2005; Theriault et al, 2002). In addition to the usefulness of event-based modelling for analysis, the approach provides a better reflection of reality and thus allows a temporal data model to more adequately reflect the kinds of relationships that may occur in the real world. In reality, the relationship between objects, locations, attributes and time is complex, and this can only be correctly modelled with an event-based approach. Developments in spatio-temporal database representation have been closely mirrored by developments in mainstream database modelling. The relational data model could not adequately handle some of the early methods described above. For example, the attribute snapshots and the ordered tuple snapshots approaches violate the normal forms of a relational database (Langran, 1989) and, as a result, internally complex attribute values could not be queried without special tools and applications. However, more recent developments in database technology have made object oriented data models freely available and some of these issues have been resolved. Objects with internal complexity can now be queried in mainstream database products using an object-relational model (Oracle Corporation, 2002), although some GIS packages have yet to make the full flexibility of these models available through their querying interfaces. These recent developments mean that not only are some of the objections to earlier snapshot methods lessened, but also new methods that require complex object-oriented modelling can be more easily accommodated. Many researchers have advocated the use of an object oriented data model for spatiotemporal data representation (for example, Griffiths et al, 2001; Jacquez et al, 2005; Worboys, 2001; Yang

and Claramunt, 2003). These models allow the more complex structure of event-based spatio-temporal models to be expressed, and also provide for modelling of associated behaviour (Li and Cai, 2002; Chen and Jiang, 1998) and other useful features like inheritance and composition (Worboys, 2001). As this discussion has illustrated, research over the past two decades has provided increasingly richer mechanisms for modelling time, allowing spatio-temporal representations to more accurately reflect reality, and providing improved tools for advanced use and analysis of spatial and temporal information. However, each of the methods described above has a role to play in production spatial information systems, and some of the earlier, simple methods are still useful for particular purposes. An information system that models all of the aspects of time would be very complex and difficult to maintain, and it is likely that this is part of the reason that no single one of the models proposed in the past for temporal representation have been widely adopted (Hornsby and Egenhofer, 2000). For practical purposes, most systems only require a subset of these aspects to be modelled, and the model can thus be customised and simplified in various ways to meet the specific needs of the system concerned. The case study described in this paper adopts such a pragmatic approach, and is tailored to the requirements of the particular system concerned. THE CASE STUDY The ACT Planning and Land Authority (referred to as the Authority in this paper) is the agency responsible for planning and administration of land within the Australian Capital Territory (ACT). It maintains a range of data about land, leasing, planning and land administration in the ACT, and is the custodian of many of the relevant data sets. In order to provide for the appropriate management of land information, the Authority has spent the last few years designing and implementing a Spatial Data Management System (SDMS). This system is used to store, maintain, manage, present and supply data that relate to the cadastral and land administration fabric of the ACT. The SDMS has a three-tier architecture, consisting of data, applications and presentation layers (Figure 2). The layers are described in more detail in the following sections.

Spatial Data Management System ACTMAPi Intranet Viewer

Smartstore Files

Access Databases (Queries and Labels)

PRESENTATION LAYER

APPLICATIONS LAYER

VB-Geomedia Custom Commands

Geomedia GIS

FME Data Supply Tools

Refreshed Nightly

DATA LAYER

SDMS DB Production Spatial and Textual Database

Refreshed Nightly

LAND DB Denormalised Data Warehouse

Figure 2: The Architecture of the SDMS

Spatio-Temporality in the SDMS One of the fundamental requirements for the SDMS was that it be a spatio-temporal system. The historical nature of planning and land administration information is very important, and the method adopted for the handling of temporality was dictated by both user requirements and the nature of the data. The following requirements were particularly relevant: • Much of the data in the SDMS is process focussed due to the role of the system in supporting the land administration function. The most important data set is that of blocks (land parcels), and these blocks go through a process that involves multiple administrative departments within the Authority. This process is one of the most fundamental parts of the Authority’s business, is complicated and varies depending on the type of block (for example, whether it is urban or rural). Associated with this complex, multi-faceted process is the involvement of many different professionals with different views of the world. As a result, there is not a single view of when an object is created or destroyed. Planners consider a block to be created when it is proposed, engineers consider a block to be created when it is approved and surveyors consider a block to be created when it is registered. The method for handling spatio-temporality was required to accommodate these varying views of the world. • Many of the objects within the SDMS may have their geometries changed, and all of these spatial changes were required to be retained. • Few of the attributes of the objects within the SDMS change after initial creation of an object, unless they were entered incorrectly. The Authority is responsible for planning as well as land administration, and the system is therefore expected to play an increasing role in the future in planning decisions. This dictates that it provide the

ability to identify the state of the data at a particular historical point in time; changes that had occurred in a particular time period and the states and changes that an object experiences throughout its life. • The system was required to be capable of providing incremental updates. The following sections describe the method used to implement spatio-temporality in the SDMS in order to meet these requirements. The method for handling temporality is largely implemented in the data layer, but the other layers also play varying roles, and each is discussed below. The Data Layer The SDMS database contains about 270 data tables, and includes geometries of various types (lines, arcs, polygons, points and mixed tables). The database is built in Oracle Spatial, and the native Oracle Spatial geometry structures are used. Full temporality was not required in the SDMS because the objects in the SDMS database fall into two categories: those for which the geometries may change while the fundamental identity of the object remains (for example, districts), and those for which the geometry may not change unless a new object is created (for example, blocks). There are few cases where attributes of an object change over time, unless they were incorrect when originally entered. For this reason, the mechanisms adopted for handling temporality include firstly a mechanism for tracking an object through a series of stages in its life and secondly a mechanism for storing any changes to the geometry and the date on which they occur. However, they do not include mechanisms for recording changes to attributes The first mechanism is implemented using lifecycles. A lifecycle is a series of stages that an object may go through in its life, and there are about 20 lifecycles used across the database and many are shared by more than one object type. For example: the lifecycle for blocks includes Proposed, Approved, Registered, Retired and Deleted, and the lifecycle for various constructed objects includes Proposed, Approved, Constructed, Operational, Retired, Destroyed and Deleted. An object need not pass through all lifecycle stages (in fact, in some cases the information about a stage may be unknown or the stage may not apply). Most tables in the database contain a CURRENT_LIFECYCLE_STAGE attribute and the start date and end date for each stage through which a object has passed are stored in a separate STAGES_IN_LIFECYCLES table, which contains the relevant stages and dates for all objects in the database. The stages form a sequence, and the periods for each stage must not overlap each other, but must form a continuous sequence in time (that is, there must be no gaps between stages). Figure 3 illustrates the data model for the tables that store lifecycle information: • The LIFECYCLE_STAGE_SEQUENCES table stores the stages within a lifecycle and the sequences that are to be enforced between stages. • The TABLE_LIFECYCLES table relates a table to a lifecycle, indicating which lifecycle is to be used. A condition may be applied so that certain rows in a table use one lifecycle, while others use another. • The STAGES_IN_LIFECYCLES table contains temporal information for all objects within the database, including the start and end dates for any stage that the object has reached. The current stage has a null end date. The end date attribute is included for convenience and performance reasons (encapsulating all the relevant information for a given lifecycle stage in a single record), but it is possible to derive it from the following stage. • All tables in the database have a CURRENT_LIFECYCLE_STAGE attribute. This attribute is an exception to the general rule for most attributes that values do not change, but is not a real world attribute in the same way as most other attributes. It contains a derivable value and is included for convenience and performance reasons. Its value may also be determined from the STAGES_IN_LIFECYCLES table.

STAGES_IN_LIFECYCLES ID : NUMBER(10) = NOT NULL LIFECYCLE_STAGE_CODE : VARCHAR2(20) = NOT NULL TABLE_NAME : VARCHAR2(30) = NOT NULL OBJECT_ID : VARCHAR2(100) = NOT NULL START_DATE : DATE = NOT NULL END_DATE : DATE EXACT_START_DATE_FLAG : VARCHAR2(1) LAST_UPDATE_DATE : DATE LAST_UPDATE_USER : VARCHAR2(30) RECORD_CREATE_DATE : DATE CURRENT_LIFECYCLE_STAGE() STAGES_IN_LIFECYCLES_ID_SEQ()

TABLE_LIFECYCLES TABLE_ NAME : VARC HAR2(30) = N OT NULL LIFECYCLE_ID : NU MBER (3) = NOT NULL CON DITION : VARCH AR2(255)

LIFECYCLE_STAGE_SEQUENCES LIFECYCLE_ID : NUMBER(3) = NOT NULL LIFECYCLE_STAGE_CODE : VARCHAR2(20 ) = NOT NULL SEQUENCE_POSITION : NUMBER(2) = NOT NULL MIN _PREREQ_STAGE : NUMBER(2)

Figure 3: Database Tables that Store Lifecycle Information

The lifecycle system is only appropriate for stages that are sequential in nature, and that follow a given order. While it is not necessary for an object to go through all the stages in its lifecycle, the stages must be followed in order. It is not valid for an object to advance to a stage and then revert to a one that was earlier in a sequence (unless it were advanced in error), or to repeat a stage that had previously been applied. Therefore if something may occur to a object sporadically or repeatedly through its life, this is best handled by a different mechanism. The second mechanism provides facilities for storing changes to a geometry through time. This mechanism simply combines the use of the relational data model, where an object has a one to many relationship with its geometries, with a lifecycle that allows the geometries for an object to have a lifecycle stage of either ASSIGNED or DEASSIGNED. For a given object, only one geometry is ASSIGNED at a given time, and the multiple geometry assigned periods must not overlap each other. All of the lifecycles used by objects in the database include a lifecycle stage of DELETED. This is used when an object is in error, and is not to be confused with a lifecycle stage that may be used to indicate that a real world object no longer exists, in which case some other appropriate stage is used, depending on the object (for example, DESTROYED for physical objects like buildings). In combination, these measures mean that it is never appropriate for an object to be physically removed from the database, and such database deletion is prohibited for all users. All objects contain a LAST_UPDATE_DATE column, which is used to provide incremental updates to external clients. If a database row has a LAST_UPDATE_DATE that is after the date of the previous data supply, then this indicates that the row has changed or been added, and it is thus marked for inclusion in the incremental update. The prohibition on deletions simplifies the process for incremental update, because it removes the need for a separate list of deleted objects to be provided.

Figure 4 provides an illustration of the lifecycle stages for an example district (Gungahlin), and its associated district polygons. Table 1 contains the corresponding records that would appear in the STAGES_IN_LIFECYCLES table (some attributes are omitted in order to simplify the example, because they do not affect the general operation of the method).

Figure 4: Example Lifecycle Stages for the District of Gunghalin and its Polygons Object

Lifecycle Stage

Start Date

End Date

District of Gungahlin District of Gungahlin District of Gungahlin District Polygon #1 District Polygon #1 District Polygon #2 District Polygon #2 District Polygon #3

Proposed Approved Registered Assigned Deassigned Assigned Deassigned Assigned

1 Jan 2001 1 Apr 2001 1 May 2001 1 Feb 2001 1 Apr 2001 1 Apr 2001 1 Jan 2002 1 Jan 2002

1 Apr 2001 1 May 2001 1 Apr 2001 1 Jan 2002

Table 1: Example Records in STAGES_IN_LIFECYCLES for Gungahlin and its Polgyons.

The Applications Layer Intergraph’s Geomedia GIS software was used as the main component of the SDMS Applications Layer, but a large number of customised programmes were written to provide additional functionality. These additional programmes were required in order to shield users from the complexity of the data model, to ensure data integrity, to increase user convenience and to control multi-step processes that are common within the Authority. The following list identifies the groups of customised programs that were developed within the SDMS, and particularly discusses those that deal with the temporal aspects of the database. These tools are essential for the users to be able to effectively use and manipulate the spatio-temporal data. i. Tools to enhance data access, display and analysis, including: • Autoload presents an interface to allow users to select data layers and the geographical area of interest. It is specifically built around the ACT data, geography and administrative structure, and also

•

• ii. iii. iv. •

•

accommodates temporality. Users are able to select objects that currently have a particular lifecycle stage. View Block Sequences derives block history (sequences of successor and predecessor blocks through time) by performing a spatial query to identify all intersecting blocks, ordering the blocks according to their dates and allowing users to select the ordering and scope of interest depending on lifecycle stages to suit their world view. View More Information displays a range of attribute information about a data set, often as the result of multiple joins, sometimes including temporal data. Tools to assist with geometry editing (augmenting the set provided with the Geomedia software) Tools for data supply that access views containing simplified temporal information (for example, different views for different lifecycle stages). Tools for data maintenance, including: Enter Block and Section Attributes, Enter Road Attributes and Save Blocks, Sections and Roads control the entry of some of the Authority’s most important data sets. These data sets are interdependent, have high data quality and accuracy requirements, and must be entered as a single transaction. This group of customised programs ensures that the data are entered correctly and makes the process as easy as possible for users. Change Lifecycle Stage is one of the most important tools for the maintenance of temporality in the SDMS. It allows the user to change the lifecycle stage of any object in the database, performs appropriate integrity checks and makes other consequent lifecycle stage changes. It also allows replacement objects to be identified that inherit attribute values (for example, if an object is divided into two). The data maintenance group of tools includes programs for the maintenance of most of the main SDMS data sets, and ensures that the temporal data are correctly entered and maintained by creating appropriate records in the different tables that handle temporality. In this way, users are removed from some of the complexity of the spatio-temporal model.

The Presentation Layer The Presentation Layer of the SDMS provide access to users whose primary concerns are data viewing, querying and display. It is implemented as a web mapping application and is referred to as ACTMAPi. ACTMAPi handles temporality in a limited way, addressing two aspects: • Dynamic data are updated on a nightly basis, so that the most recent changes are available within 24 hours. This is particularly relevant for Authority staff who often work in areas of current development. • For most data sets, ACTMAPi displays a separate layer for each lifecycle stage. For example, there is a layer for blocks that are currently Approved, another for blocks that are currently Registered, and another for blocks that are currently Retired. This allows users to view historical as well as current data, but does not provide access to the full extent of spatio-temporal data in the SDMS. Future SDMS Developments A number of further developments to the SDMS are anticipated, and many of these relate to temporality. These were included in the original design and are an essential part of the full realisation of the spatiotemporal model, but were excluded from the main SDMS project due to resource constraints. These future developments include the following: • The development of further tools in the Geomedia environment to allow better use of temporal data. While the temporal data are stored in the database, this is only currently being used in limited ways. It is possible to build queries to perform more advanced spatio-temporal mapping and analysis, but many users do not have the skills or understanding of the data model to build such queries. Future tools will provide more convenient execution of queries to allow users to view data at a particular point in time, to view changes in a period and to trace the changes to an object through its lifecycle (possibly using animation). These tools will be made available both in the SDMS/Geomedia environment and through ACTMAPi.

• •

The View Block Sequences tool will be made available through ACTMAPi, as this information is of primary importance to many Authority staff members. Temporal querying and analysis will be made available through Web Services, so that the data can be accessed by other systems, both within the Authority, and externally. EVALUATION OF THE OBJECT LIFECYCLES METHOD

The object lifecycles method used by the SDMS focuses on the following aspects shown in the spatiotemporal pyramid:
at the second level, changes in temporality and changes in location (the SDMS does not handle changes in properties, because they are not relevant for the SDMS);
at the third level, relationships between changes in temporality (through the customised programs) and
at the fourth level, relationships between changes in temporality, changes in location and changes in properties, but only in a limited way (through the lifecycle database structure). The majority of the aspects not covered by the method would not be useful in the context of the SDMS, with the exception of the relationship between changes in location, which would be useful to handling changes to blocks that cause resulting changes to sections (the administrative area that encompasses blocks), and other similar relationships between different object types. This aspect may be included as a future extension to the method. The object lifecycles method does not fit neatly within the categories of spatio-temporal representation methods described in previous research. It relates to such research in various ways as follows: • It has some similarities to the attribute snapshot method because it stores changes to an attribute value (namely the lifecycle stage) and the dates at which those changes occur. However, it does not extend to all attributes (such an extension would be impractical and is unnecessary in this application) and does not focus on the change as much as the stage that an object achieves in its lifecycle. • It has some of the same outcomes as the event based method, largely because it addresses broader relationships between events and models processes, but it does not model events and does not provide the capabilities that are offered by such event based models (again because this application did not require these capabilities). • It is conceptually very similar to the idea of lifelines (Hornsby and Egenhofer, 2002; Theriault et al, 2002) or life histories (Galton, 2004), although these have normally been applied in the context of movement or as a focus for analysis of statistical patterns; and to life histories. These concepts are proposed as a very rich representation of spatio-temporality, normally including events, and are well beyond the requirements for the SDMS. • It is similar to the approach taken in the European MurMur project which also uses the term object lifecycles. This approach provides tools for the expression of temporal constraints, but does not allow for customised lifecycles based on object types, providing only a single lifecycle for all objects (Minout, 2004). The object lifecycles method may be evaluated according to its ability to address each of the originally described requirements for handling temporality in the SDMS as follows: • The object lifecycles method handles the process-focussed nature of the data in the SDMS by making lifecycles the central data representation method for handling temporality. Object lifecycles mirror the process that an object goes through, and each object’s lifecycle is selected based on the relevant process. The method also allows objects to have different lifecycles based on particular properties (based on the condition that may be attached to the relationship between a table and a lifecycle), and the temporal topology of the lifecycle (the requirement that the stage start and end dates form a contiguous sequence) is enforced through database constraints and the data maintenance applications that allow lifecycles to be maintained. The method maintains the multiple view of reality of different users by avoiding the use of stages signifying object creation or death in favour of multiple stages that represent different steps in a real world process. • The object lifecycles method allows all geometry changes to be retained using a dual table model and a lifecycle that shows that different geometries are assigned to a real world object at different points in time (for example, a district may have first one polygon assigned, and then when the geometry

•

•

•

changes, that polygon is deassigned and another is assigned). While this method retains all changes, some redundancy is involved when partial geometry changes occur (for example, if only one boundary of a polygon is changed). The entire object is created as the new version of the object, and this may result in duplication. Such redundancy could be removed by storing geometry components (points and lines) instead of an object geometry in its entirety as is the normal practice in modern GIS. The object lifecycles method does not contain unnecessary spatio-temporal representation for attributes that do not change. If attribute changes were to be accommodated, this could be done using a similar method to that used for geometries (a separate STAGES_IN_LIFECYCLES table for the attribute concerned), but this is not recommended due to the conceptual complexity. The object lifecycles method as implemented here would not be the most suitable choice for a system that requires substantial attribute changes, although adaptations may be possible. The object lifecycles method provides sufficient information to define queries to identify the state of data at a particular point in time, changes within a time period and states and changes in an object’s life, as well as other similar queries. The use of these types of queries in the SDMS have been limited thus far. The object lifecycles method and its associated storage of LAST_UPDATE_DATE allow incremental updates to be provided.

The object lifecycle method may also be evaluated in terms of its application in the production environment. The method represents a simplified form of spatio-temporality, representing only the aspects of temporality that are necessary within the specific context of the SDMS. However, some users still consider the system to be complex, specifically those who are responsible for data maintenance. In particular, it is sometimes difficult for users to determine which lifecycle stage should be adopted in a particular context, and which object’s lifecycle stage should be changed, although these problems are decreasing as their experience increases. For example, a district may have several polygons through time, and when a polygon changes, the old polygon is deassigned and the new one assigned. If a district ceases to exist, users sometimes find it difficult to determine whether the district itself should be retired, or the last district polygon deassigned. The former is appropriate if the district no longer exists, while the latter is appropriate if the district continues to exist but the polygon no longer applies, is not known or if the district has no spatial extents. The same issue applies to many structures across the database. In the wider context, data consumers have embraced the lifecycles concept, particularly with reference to blocks, and most find the lifecycle stages intuitive and reflective of reality. However, only a fraction of the power of the system is employed, and most users are only able to cope with data in a snapshot presentation. The most common data access mechanisms (the Autoload program and ACTMAPi) only present data in snapshot format (as layers of objects with a given current lifecycle stage). In these applications, views are used to collapse the full expressiveness of the lifecycles into a single snapshot view with which users are most comfortable. It is anticipated that better use will be made of the more detailed spatio-temporal data in the future for analysis and display, but this has not eventuated thus far, and demand for such functionality has been limited. Block sequences are an exception to this, probably due to the central role that blocks play in the business of the Authority. The work involved in maintaining information about object lifecycles is also an issue. The presence of particular stages seems to imply that knowledge about whether an object has reached a stage is available, and this is sometimes not valid. For example, constructed objects generally adopt a lifecycle that contains the stages Proposed, Approved, Constructed, Operational, Retired, Destroyed and Deleted, but often data maintenance staff are unaware of whether an object has been Destroyed, for example. While the method can be used to represent only the last stage that an object was known to reach (not implying that it has not reached a later stage), there is some argument for a simplified lifecycle including only data that are available and can be maintained. One of the problems encountered with the object lifecycles method was the initial inclusion of an Entered lifecycle stage indicating that the object had been entered into the database. This caused confusion because it was a system stage rather than a real world stage, and if the object was entered after any later stages in the lifecycle, there were problems with the sequence. Therefore, the object lifecycle method is best suited to the representation of real world stages (although another set of lifecycles could be maintained for system

stages). The Deleted stage is an exception to this, mainly because it indicates an error in the database and is used as a flag to indicate that the data should be removed from datasets generated using incremental updates. As a result of the lessons learnt from implementation and evaluation of the object lifecycle method, a number of generalisations can be drawn about the kinds of situations in which its application is appropriate, and the way in which it is best applied. These include: • It is best suited to domains where data is process-focussed. • It is only suitable for representing temporality that is sequential in nature, and does not handle sporadic, repeated or on/off events well. • It is best suited to environments where geometries change but attributes do not, or where only a limited number of attributes change (in which case the method must be extended to accommodate these changes). • It is not advisable to mix real world and system stages in a single lifecycle. CONCLUSIONS This research has illustrated that it is not necessary, and may not be desirable, to adopt a full treatment of spatio-temporality in the context of a given system. Each system has its own requirements, and while some systems for advanced scientific analysis may require the most complex and expressive approaches to temporality, including all of the aspects of temporality, many production systems will require only a limited set of spatio-temporal capabilities. In this scenario, system designers can mix and match aspects of the approaches proposed by different researchers in order to identify a combination that suits the requirements at hand. The object lifecycle method has proved suitable for the SDMS, but may be extended in various ways depending on requirements if it is to be applied to other systems. Such extensions include: • the inclusion of relationships between changes to location and geometry; • the reduction of redundancy in geometric changes and • extensions to handle attribute changes. The representation of temporality in spatial information systems has many important applications, and recent research has focussed on developing increasingly complex and expressive methods for this representation. However, such complexity is too difficult for many real world systems and their users to maintain and apply, and until users become more comfortable with the handling of spatio-temporal data, there are cases where a simplified subset is more appropriate. The contents of this subset must depend on the requirements of the system and the application domain. This research has provided an example of such a case and illustrated that the subset approach can work successfully in a production system. While it is working successfully, its power has not yet been fully realised, and one of the future challenges for the SDMS is to promote the increasing use of spatio-temporal data and allow users to employ it to achieve goals that are useful in their daily business. REFERENCES Chen, J. and Jiang, J. (1998) Event-based Spatio-temporal Database Design. Proceedings of ISPRS Commission IV Symposium on GIS – Between Visions and Applications, Stuttgart, Germany, 7-10 September 1998. International Archives of Photogrammetry and Remote Sensing, vol. 32, pt. 4. Galton, A. (2004) Fields and Objects in Space, Time and Space-Time. Spatial Cognition and Computation, issue 1, pp. 39-68. Grenon, P. and Smith, B. (2004). SNAP and SPAN: Towards Dynamic Spatial Ontology. Spatial Cognition and Computation, issue 4, number 1.

Griffiths, T., Fernandes, A.A.A., Paton, N.W., Huang, B., Worboys, M., Johnson, C., Mason, K.T. and Stell, J. (2001) Tripod: A Comprehensive System for the Management of Spatial and Aspatial Historical Objects. Proceedings of the 20th International Conference on Conceptual Modelling (ER 2001), Yokohama, Japan, 27-30 November 2001. Lecture Notes in Computer Science, vol. 2224, Springer. Hornsby, K. and Egenhofer, M.J. (2000) Identity-Based Change: A Foundation for Spatio-Temporal Knowledge Representation. International Journal of Geographical Information Systems, vol. 14, no. 3, pp. 207-224. Hornsby, K. and Egenhofer, M.J. (2002) Modeling Moving Objects over Multiple Granularities. Annals of Mathematics and Artificial Intelligence, vol. 36, no. 1-2, pp.177-194. Hunter, G.J. and Williamson, I.P. (1990) The Development of a Historical Digital Cadastral Database. International Journal of Geographical Information Systems, vol. 4, no. 2, pp. 169-179. Jacquez, G.M., Greiling. D.A. and Kaufmann, A.M. (2005) Design and Implementation of Space-Time Information Systems. Journal of Geographical Systems, vol. 7, pp.7-23. Langran, G. (1989) A Review of Temporal Database Research and its Use in GIS Applications. International Journal of Geographical Information Systems, vol. 3, no. 3, pp. 215-232. Langran, G. (1993) Issues of Implementing a Spatiotemporal System. Geographical Information Systems, vol. 7, no. 4, pp. 305-314.

International Journal of

Langran, G. and Chrisman, N.R. (1988) A Framework for Temporal Geographic Information. Cartographica, vol. 25, no. 3, pp.1-14. Li, B. and Cai, G. (2002) A General Object-Oriented Spatial Temporal Data Model. Proceedings of Symposium on Geospatial Theory, Processing and Applications, ISPRS Commission IV, Ottawa, Canada, 9-12 July 2002. Li, L.and Revesz, P. (2003) The Relationship Among GIS-Oriented Spatiotemporal Databases. Proceedings of the Third National Conference on Digital Government Research, Boston, 18-21 May 2003, pp. 375-378. Minout, M., Parent, C., Spaccapietra, S. (2004) A Tool for Transforming Conceptual Schemas of SpatioTemporal Databases with Multiple Representations. IASTED International Conference on Databases and Applications, DBA 2004, Innsbruck, Austria, February 17-19. Oracle Corporation (2002) Oracle9i Application Developer's Guide - Object-Relational Features Release 2 (9.2) Part Number A96594-01. http://www.lc.leidenuniv.nl/awcourse/oracle/appdev.920/a96594/adobjint.htm Peuquet, D.J. (1994) It’s about Time: A Conceptual Framework for the Representation of Temporal Dynamics in Geographic Information Systems. Annals of the Association of American Geographers, vol. 84, no. 3, pp.441-462. Peuquet, D. and Duan, N. (1995) An event-based spatiotemporal data model (ESTDM) for temporal analysis of geographical data. International Journal of Geographical Information Systems, vol. 9, no. 1, pp. 7-24. Price, S. (1989) Modelling the Temporal Element in Land Information Systems. International Journal of Geographical Information Systems, vol. 3, no. 3, pp. 233-243.

Roddick, J.F., Grandi, F., Mandreoli, F. and Scalas, M.R. (1999) Towards a Model for Spatio-Temporal Schema Selection. Proceedings of the 10th International Workshop on Database and Expert System Applications, Florence, Italy, 1-3 September 1999, pp. 434-440. Sutherland, N. (1996) Temporal Implications of Change Within the NZ LIS. New Zealand Surveyor, no. 286, pp.20-24. Theriault, M., Claramunt, C., Seguin, A.-M. and Villeneuve, P. (2002) Temporal GIS and Statistical Modelling of Personal Lifelines. Proceedings of Symposium on Geospatial Theory, Processing and Applications, ISPRS Commission IV, Ottawa, Canada, 9-12 July 2002. Worboys, M.F. (2001) Modelling Changes and Events in Dynamic Spatial Systems with Reference to Socio-Economic Units. In A.U. Frank, J. Raper and J.-P. Cheylan, Life and Motion in Socio-Economic Units, Taylor and Francis, New York, pp.129-138. Worboys, M. (2005) Event-oriented Approaches to Geographic Phenomena. International Journal of Geographical Information Systems, in press. Yang, Y. and Claramunt, C. (2003) A Process-oriented Multi-representation of Gradual Changes. Journal of Geographic Information and Decision Analysis, vol. 7, no. 1, pp.10-13. Yuan, M. (1999) Use of a Three-Domain Representation to Enhance GIS Support for Complex Spatiotemporal Queries. Transactions in GIS, vol. 3, no. 2, pp.137-159. Yuan, M., Mark, D., Egenhofer, M. and Peuquet, D. (2004). Extensions to Geographic Representation. In R. McMaster and L. Usery (eds), A Research Agenda for Geographic Information. CRC Press, Boca Raton, pp. 129-156.