A modo de cierre: posibles primeros pasos de una agenda de políticas

During the Kenyan fieldwork the current value of the location context element was extracted from a Garmin 45 XL GPS receiver, and the work has done before selective availability was removed from GPS. The value had no real-time or post-processed corrections applied in order to try and improve its accuracy, so the real value would, for most of the time, lie within a one hundred metre error radius of the supplied value. This proved to be more than adequate for the needs of the giraffe behavioural study, which took place over approximately a one hundred square kilometre area. The location data recorded was for use in either virtually tagging stick-e notes to a location or to aid in finding an observation site at a later date. The uncorrected GPS location proved satisfactory for both of these tasks.

The maps of the reserve that were used by the ecologists had one kilometre grid squares scaled to approximately two by two centimetres, which made plotting anything more accurate than one hundred metres impractical anyway. In addition, much of the map data had been collected through uncorrected GPS track logs, so the maps themselves were only accurate to within one hundred metres. These maps were based on the ARC 1960 datum with a UTM grid (zone 37N/37M). The prototype software supported only latitude and longitude but fortunately the UTM format was only required after downloading the data to a desktop computer (for plotting it onto one of the maps in a GIS) so it could therefore be converted after downloading.

Support for the plethora of potential location formats could certainly be improved, but how should this be accomplished? Resources in terms of processing and storage on the PalmPilot are limited and perhaps not well suited to the rigours of converting the latitude and longitude values transmitted by the GPS receiver into other formats. Providing this functionality on the desktop computer may be a better solution as it is free of such resource constraints. Perhaps when transferring the stick-e notes from the

PalmPilot to the desktop computer the location fields could be automatically translated into the format that the user desires. The majority of use of this transformed location data will occur on the desktop computer anyway so it seems logical to perform the conversions there also.

In the field it is useful to be able to locate your current position and the points of previous observations. The StickeMap allows the user to do this very easily, although currently the program does not display any additional information besides the grid, user’s location, and stick-e notes’ locations. This could be improved by providing a background map facility where the StickeMap program could overlay its current screen onto a bitmap image of a local map. The map image could be tagged with a latitude and longitude marker on the desktop computer before being transferred to the PalmPilot, enabling the StickeMap to appropriately scale it to the correct latitude and longitude grid. A selection of different maps could be provided on the desktop computer (e.g. for vegetation, roads, pathways, watersheds, aerial photos, etc.) from which the user could select the appropriate one for the day’s activities. Alternatively, perhaps the user could also annotate the map with icons or sketches in order to depict landmarks or reference points, etc. Icons in particular would require much less processing time, e.g. when zooming in or out of the map the icon need not be resized or rescaled like a bitmap background would have to be. Such location-annotation icons could be implemented as a simple stick-e note consisting of a location, icon definition, and description field (so that when the user clicked on the icon a description could be displayed). Indeed, icons could be incorporated as a general feature of stick-e notes, where any note could have an icon field. Using these icon fields a specific icon could be created to represent a particular note in the map display or in any of the other context element visualisations. Closely related to location is direction. In the Kenyan fieldwork, direction was commonly recorded, e.g. the direction of a group of giraffe, the direction of travel, etc. Currently the user needs to carry a compass in order to establish direction, but there are other methods that can be used to automatically estimate direction, although not always to the accuracy of a conventional compass. The first method uses a knowledge of the user’s location so that a general direction of travel can be estimated if the user is keeping to a relatively constant heading (by simply projecting forward the user’s general trajectory). The second method could provide a measure of direction that is

Chapter 3: Ecology Fieldwork Tools

independent of the direction of travel by calculating it from the time and relative bearing of the sun. Finally, an electronic compass could be attached to the handheld computer to supply the direction in which the computer is facing. Any of the aforementioned methods could be most conveniently supplied as one of the proposed context element modules, extending the base stick-e note systems’ context element support.