FieldNote Desktop: an Experimental Spatio-Temporal Information System.

Nick Ryan

N.S.Ryan@ukc.ac.uk
Computing Laboratory, University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, UK.

Background

'FieldNote Desktop' is one component of a system designed to support context-aware computing in the field. Developed as part of the Mobile Computing in a Fieldwork Environment (MCFE) project, it is an object-oriented temporal GIS providing storage, visualisation and management facilities for collections of field survey data.

The mobile components of the system have been described elsewhere [Ryan et al. 1998; Ryan et al. forthcoming, Pascoe et al. 1998]. They comprise several applications designed to run on hand-held computers such as the 3Com PalmPilot and Apple Newton. Information about the user's environment, including location derived from an attached GPS receiver, is used both to add contextual information to notes as they are recorded and to aid retrieval of relevant material recorded during a previous field campaign or by another field worker.

In a context-aware application the computer monitors, and responds to, various aspects of the user's environment [Fitzmaurice 1993, Schilit et al. 1994]. In our approach, which derives from Peter Brown's work on stick-e notes [Brown 1995, 1998, Brown et al. 1997], the environmental factors can be both physical and logical. Apart from location, physical criteria could include, for example, date and time as measured by the computer's internal clock, and temperature or ambient light level measured by attached sensors. Logical criteria may include the author of a note, subject keywords and the historical period to which the note refers. Typically, the user specifies a set of criteria to describe contexts of interest and these act as search filters that determine which information is made 'active' as the user moves through their environment.

Both the mobile and desktop components of the system have been designed to support a wide range of student and research fieldwork activities. They have been developed in association with several field projects including surveys of an Iberian/Roman town in Andalucia [Keay 1992], upland pastoral settlements in Corsica [Bagg and Ryan 1997], and animal census and behavioural studies in Kenya [Pascoe et al. 1998, Pascoe et al. forthcoming].

The FieldNotes collected on the hand-held computers need to be brought together and managed by a central system, either on a desktop machine or on a laptop whilst in the field. Many notes can be represented as relatively simple data structures. A brief textual note describing an artefact or feature would be associated with the author's name, the date and time when the note was created, and the coordinates of the location at which it was created. We can readily envisage such data stored in a single database table. Slightly more complex notes would be created when several observations are recorded at a single location. For example, a recording form designed for sampling surface scatters of artefacts might result in a database structure with two tables (Figure 1).

Figure 1: example FieldNote data model, representing a recording form for surface sampling.

The combination of a simple GIS and database package would appear to be a reasonable basis on which to implement such a system. This is one approach that we are pursuing in order to develop a simple system that can be taken into the field on a laptop computer. However, this approach has limitations. FieldNotes are not restricted to recording textual or tabular data. Notes may also include more complex spatial information, such as the linear or polygonal extent of a feature, or photographic images. Such images may also be tagged with a point and orientation that represent the location and view vector of the camera. In the future, we may consider adding sound or video clips to this range of data types.

Most current GIS are poorly equipped to handle complex attribute data and most DBMS are equally unsuited to handling spatial and image data. As a pragmatic, if not particularly elegant or efficient, solution to this problem, GIS typically employ a rudimentary linkage with a database system to support 'attribute' data. Indeed, most GIS users have come to accept the distinction between 'spatial' and 'attribute' data as if it were essential or even 'natural'. In fact this is a wholly artificial distinction between two sets of attributes that together describe spatial objects. It results not from a well-structured functional design but, rather, from the historical limitations of both GIS and DBMS.

A FieldNote is temporally referenced to its time of creation and, particularly with archaeological data, to the period of the material described in the note. The first of these is a timestamp, typically to the nearest second, derived from the computer's clock. The other will invariably lack such precision and may involve considerable uncertainty. Indeed it will often be specified by an expression such as 'late 3^rd to early 4^th century' or simply as a period name -- 'roman'.

Few software systems are equipped to perform any but the most rudimentary operations on temporal data. This is certainly true of both GIS [Castleford 1992] and DBMS [Cheetham and Haigh 1992]. However, extending these systems to provide greater temporal functionality has been a prominent activity in both the GIS [Langran 1992; Peuquet and Wentz 1994] and database [Tansel et al. 1993; Snodgrass et al. 1994; Böhlen 1995] research communities. Today, these limitations can mostly be overcome by using an 'extensible' database system [Stonebraker and Rowe 1986; Ryan 1992a, 1992b].

The following section briefly outlines the facilities provided by a modern extensible DBMS, and the remainder of the paper describes an experimental implementation of the FieldNote Desktop that has been built upon such a database system. The DBMS has been extended to provide

• a significant level of GIS functionality in the database server, including support for vector and raster spatial data,
• support for imprecise and uncertain dates, and
• support for other types including photographic images.

The result is a single system with no artificial fragmentation of the data model. This has made it possible to build simple client programs to display and analyse the full range of data represented in the FieldNotes.

Extensible DBMS

Extensibility has become a major feature of modern large-scale client-server database systems. At a minimum, it offers the possibility of extending the limited range of data types supported by the SQL standard [ISO 1992] to provide for application-specific requirements. This makes it possible to create tables using columns based on the new type. For example, a 3D point can be defined as a single data type, thus allowing a location to be recorded using a single column, rather than the three that would normally be required. This alone is a useful capability, but the major benefit of this approach is that it is also possible to add type-specific behaviour in the form of functions that can be used in SQL queries. The 3D point could have an associated distance function, so that queries of the form

select distance(a,b) from ...

where a and b are columns or values of the 3D point type, would return the calculated distance between the two points.

Extending the range of data types is not a task for an end-user. The types and their associated behavioural functions must be created by a programmer and are often implemented as dynamically loadable libraries. However, some vendors supply pre-defined libraries for common application requirements such as spatial vector and image-processing types.

The database system used here is Illustra. Atkinson and Stonebraker (1994) have demonstrated its application to the management of satellite imagery and its associated metadata. It is commercial database product that traces its ancestry to the POSTGRES project at the University of California, Berkeley (Stonebraker and Rowe, 1986). Described by its vendors, Informix, as an ‘object relational’ DBMS, Illustra is an extensible system based on the relational model, but incorporating several features more commonly associated with object oriented systems. Much of Illustra's functionality has now been incorporated into the Informix Universal Server product.

Amongst the 'object-oriented' features of this database system are support for table definitions as types, and inheritance of state (columns) and behaviour (virtual columns implemented as functions) between tables. The inheritance mechanism leads to a particularly powerful feature, that of polymorphism, in which a single query can return tuples of different types.

Table 1: examples of the temporal data types instant, period and span. Dates are specified here in day, month, year format, but input and output using the ISO year, month, day order is also supported.

Temporal Data types

New data types have been developed to support historical and archaeological dates, periods and intervals. Unlike the conventional SQL types that allow only exact dates, these dates and durations of time can 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 * 10⁶ years. Table 1 shows several examples of the external representation of each of these types.

• 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.
• The period type represents an anchored duration of time and is specified by the instants at which it starts and ends. Granularity and uncertainty are treated in the same way as for the instant 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.

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 forms that return the probability that the comparison is true. There is, as yet, no mechanism for dealing with relative time as, for example, in archaeological stratigraphy, when a is before b, and b is before c, but the date of one or more is unknown.

Limited support for multiple calendars is provided. At present the Gregorian and Julian calendars are supported, with an experimental implementation of the French revolutionary calendar.

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 spatio-temporal data model

The core of the spatial data model employed here (Figure 2) 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.

Figure 2: the core types of the spatial data model

• The SpatialObject 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 SpatialObject 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.

The individual classes within the GeometricObject hierarchy make use of basic vector and raster data types provided by add-on libraries (‘DataBlades’) for Illustra. For example, the Point2D class inherits an identifier (geom_id) from GeometricObject and adds location, a column of type Pnt. The definition of Pnt comes from the 2D spatial library. Similarly, the RasterObject class uses the image class from the image library.

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 SpatialObject provides a straightforward means of linking a temporal sequence of geometric representations to a single application object.

FieldNotes are incorporated into this model by deriving new specialised classes directly from SpatialObject as shown in Figure 3. Here, the basic FieldNote class inherits its location from SpatialObject in the form of a reference to one or more instances of the GeometricObject class. For most notes, the associated geometry will be provided by a single Point2D or Point3D object. The derived note class PhotoRecord, however, might use the OrientedPoint2D class to provide its geometry.

Figure 3: FieldNote classes derived from the generic SpatialObject base class.

Spatio-temporal queries

The SpatialObject 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 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 column is a composite type that, in turn, contains all 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. Here, the result set can contain points, lines, polygons or any other type from the GeometricObject hierarchy.

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 '%FieldNote%'
        and Overlap(source_date, '1997-09'::instant)
    ) t, GeometricObject g
    where t = g.oid
    and Overlap(g, '(254000,4135500,255000,4136500)'::Box);

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 part of a vector map of the FieldNote material collected during September 1997.

In this example there are both spatial and temporal restrictions using the respective Overlap functions. The temporal restriction in the inner query 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 ‘1997-09-12’ or ‘199x’ are not treated as equal to ‘1997-09’. 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 period, irrespective of their stored granularity. The spatial restriction in the final lines limits the result to GeometricObject sub-types that overlap the specified bounding box.

Similar queries can be formulated to retrieve the geometry associated with one or more instances of the SpatialObject classes. For example, the following query will return all notes from the FieldNote hierarchy that were created during September 1997, have the word 'masonry' in their body, and are located within the specified bounding box.

    select g from (
        select unique geometry 
        from FieldNote 
        where bodytext like '%masonry%'
        and Overlap(created, '1997-09'::instant)
    ) n, GeometricObject g 
    where t = g.oid 
    and Overlap(g, '(254000,4135500,255000,4136500)'::Box);

FieldNote Desktop

The desktop program (Figure 4) is a relatively simple application written in Tcl/Tk [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.

The program 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. A limited number of map manipulation and analytic functions are also provided. All data manipulation is performed by the database server and this 'front-end' program is little more than a user interface. The simplicity of the program lies in the fact that it only performs two basic tasks, query composition and map display. Queries, such as those described in the previous section, are dispatched to the server. Results are returned as text, images or vector data, and are in a form that can be readily displayed by the program.

The controls on the right hand side of the window provide access to layers and allow the user to specify colours, line styles, temporal constraints, etc. 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 that can be entered 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.

The map display area shows FieldNote locations for a set of notes collected at el Gandul, Andalucia, in September 1997. These are superimposed on contour and roads/tracks layers. The cursor, an arrow visible near the centre of the map, points at one of the circular note symbols, and the body text from this note is displayed in the text area at the lower right corner of the window.

Figure 4: the prototype FieldNote Desktop system showing a set of notes collected at el Gandul, Andalucia, in September 1997.

Conclusions

The intention of the work described here has not been to develop a fully functional GIS platform, simply one that was suited to the requirements of managing the FieldNotes collected by our mobile systems. Despite these limited objectives, the model and application demonstrate that a seamless method of managing both spatial and non-spatial data can be achieved. This approach is appropriate for building a complete GIS platform incorporating greater analytical capabilities.

The heart of the system is the spatio-temporal data model implemented in an extensible DBMS. At the moment, such functionality is only available in a small number of freely available research prototypes and some of the large-scale commercial client-server database products. Certainly some of the latter will run on the more powerful modern desktop PCs, but their cost and complexity keep them out of reach of all but the most well-funded archaeological units and the research community. Nevertheless, it seems reasonable to expect that eventually these capabilities will become available in some of the less expensive and more popular desktop database systems.

Much further development needs to be undertaken on the temporal data types, particularly on the probability distributions of uncertain dates, multiple calendar support and the expression of relative time networks. Future work on the spatial aspects of the system will also include further development of raster types and further implementation of layer algebra functions.

Acknowledgements

Many of my colleagues at the University of Kent have contributed to the ideas described here. Particularly noteworthy contributions have been made by Peter Brown, David Morse and Jason Pascoe.

Simon Keay and David Wheatley of the Department of Archaeology at Southampton University, Janet Bagg of the Department of Anthropology at the University of Kent, and Kathy Pinkney and Alan Birkett of the Department of Biology at Manchester Metropolitan University have all made valuable contributions to the development of the MCFE project. Their asisstance and enthusiasm, and their stimulating fieldwork projects have provided ideal envronments in which to develop and test the ideas reported here.

A license to use the Illustra DBMS was initially provided by Illustra Inc. under their University Grant Program in July 1994. Since Illustra was acquired by Informix, John Pickford (Northern Europe ATG Manager, Informix Europe) has been instrumental in ensuring continued support for our spatio-temporal database research under the Informix Engines for Innovation programme.

References

Al-Taha et al. 1994: 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.

Anderson and Stonebraker 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.

Bagg and Ryan 1997: J. Bagg and N. S. Ryan, ‘Modelling historical change in southern Corsica: temporal GIS development using an extensible database system’, in Z. Kemp (ed.), Advances in GIS 4, Taylor & Francis, London, 1997.

Beckmann et al. 1990: 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

Böhlen 1995: M. H. Böhlen, ‘Temporal database system implementations,’ ACM SIGMOD Record, Vol. 24, No. 4, 53-60, December 1995.

Brown 1995: P. J. Brown, 'The electronic post-it note: a metaphor for mobile computing applications', IEE Colloquium on Mobile Computing and its Applications, ??, 1995.

Brown et al. 1997: P. J. Brown, J. D. Bovey and X. Chen, 'Context-aware Applications: from the Laboratory to the Marketplace', IEEE Personal Communications, 4, 5, ??-??, 1997.

Brown 1998: P. J. Brown, '????', Personal Technologies, ?, ??-??, 1998.

Castleford 1992: J. Castleford, ‘Archaeology, GIS, and the time dimension: an overview,’ in G. Lock and J. Moffett (eds.), CAA91: ComputerApplications and Quantitative Methods in Archaeology, 1991, BAR International Series S577, Tempvs Reparatvm, Oxford, 7–14, 1992.

Cheetham and Haigh 1992: P. N. Cheetham and J. G. B. Haigh, ‘The archaeological database – new relations?’ in G. Lock and J. Moffett (eds.), CAA91: ComputerApplications and Quantitative Methods in Archaeology, 1991, BAR International Series S577, Tempvs Reparatvm, Oxford, 7–14, 1992.

Fitzmaurice 1993: G. W. Fitzmaurice, 'Situated Information Spaces and Spatially Aware Palmtop Computers', Communications of the ACM, 36, 7, 38-49, 1993.

ISO 1992: International Standards Organisation, Database Language SQL, ISO Tech/9075, 1992.

Keay 1992: S. J. Keay, "The 'Romanisation' of Turdetania", Oxford Journal of Archaeology, vol. 11, no. 3, pp.275-315, 1992.

Langran 1992: G. Langran, Time in Geographic Information Systems, Taylor & Francis, London, 1992.

Larue et al. 1993: 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: Proceedings of the 3rd International Symposium SSD 93, Singapore, June 1993, Springer-Verlag, LNCS 692, 53-72, 1993.

Lock and Moffett 1992: G. Lock and J. Moffett (eds.), CAA91: ComputerApplications and Quantitative Methods in Archaeology, 1991, BAR International Series S577, Tempvs Reparatvm, Oxford, 1992.

Orenstein 1986: J. Orenstein, ‘Spatial Query Processing in an Object-Oriented Database System’, Proc. ACM SIGMOD Int. Conf. on Management of Data, 326-336, 1986.

Ousterhout 1994: J. K. Ousterhout, Tcl and the Tk Toolkit, Addison-Wesley, Reading, Mass., 1994.

Pascoe 1997: Pascoe, J. 'The stick-e note architecture: extending the interface beyond the user', Proc. ACM International Conference on Intelligent User Interfaces, 261-264, 1997.

Pascoe et al. 1998: J. Pascoe, D. R. Morse and N. S. Ryan, 'Developing Personal Technology for the Field', Personal Technologies, 2, 28-36, 1998.

Pascoe et al. forthcoming: J. Pascoe, N. S. Ryan and P. J. Brown, ' From Acacias to Olives: Context-Aware Computing in Ecology and Archaeology ', GPS World, forthcoming.

Peuquet and Wentz 1994: D. Peuquet and E. Wentz, ‘An approach for time-based analysis of spatiotemporal data,’ Proceedings of the 6th International Symposium on Spatial Data Handling, Edinburgh, 1994.

Ruggles 1992: C. Ruggles, ‘Abstract Data Structures for GIS applications in archaeology,’ in G. Lock and J. Moffett (eds.), CAA91: ComputerApplications and Quantitative Methods in Archaeology, 1991, BAR International Series S577, Tempvs Reparatvm, Oxford, 107–112, 1992.

Ryan 1992a: N. S. Ryan, ‘Dealing with time and uncertainty in historical databases’, in J. Smets (ed.) Actes du 5ème congrès international de la ‘Association for History and Computing’, Université de Montpellier III, Montpelier, France, 1992.

Ryan 1992b: N. S. Ryan, ‘Beyond the relational database: managing the variety and complexity of archaeological data,’ in G. Lock and J. Moffett (eds.), CAA91: ComputerApplications and Quantitative Methods in Archaeology, 1991, BAR International Series S577, Tempvs Reparatvm, Oxford, 1–6, 1992.

Ryan et al. 1998: N. S. Ryan, D. R. Morse and J. Pascoe, "Enhanced Reality Fieldwork: the Context Aware Archaeological Assistant" in V. Gaffney, S. Exon, and M. van Leusen (eds.) Computer Applications in Archaeology, 1997, British Archaeological Reports no ???, Oxford, 1998.

Ryan et al. forthcoming: N. S. Ryan, D. R. Morse and J. Pascoe, "FieldNote: extending a GIS into the field" in J. Barceló et al. (eds.) Computer Applications in Archaeology, 1998", (forthcoming).

Ryan and Morse 1997: N. S. Ryan and D. R. Morse, 'Mobile Computing in a Fieldwork Environment', Life Sciences Educational Computing, 8, 1, ??, CTI Centre for Biology, University of Liverpool, March 1997.

Schilit et al. 1994: B. Schilit, N. Adams and R. Want, 'Context-Aware Computing Applications', IEEE Workshop on Mobile Computing Systems and Applications, 85-90, 1994.

Snodgrass and Ahn 1985: R. Snodgrass and I. Ahn, 'A Taxonomy of Time in Databases', Proc. ACM SIGMOD Int. Conf. on Management of Data, 236-246, 1985

Snodgrass et al. 1994: R. T. Snodgrass, et al. TSQL2 Language Specification, published electronically, 1994, available via anonymous FTP from ftp://ftp.cs.arizona.edu.

Stonebraker and Rowe 1986: M. Stonebraker and L. Rowe, ‘The Design of POSTGRES’, Proceedings ACM SIGMOD International Conference on the Management of Data, 1986.

Tansel et al. 1993: 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.