Supporting Geospatial Data in the Field

Supporting Geospatial Data in the Field

L. L. Miller
Sarah Nusser
Iowa State University
Ames, Iowa 50011
Email: @iastate.edu
nusser@iastate.edu

Abstract
The amount of geospatial data continues to increase everyday. At the same time, the computing resources available to workers in the field are improving very rapidly. The result is that using applications based on geospatial data in the field is becoming more practical everyday.

This presentation looks at the available computing equipment and the basic issues in software development that are needed to support geospatial data in the field. Both software issues for the field applications and the infrastructure to gather and integrate the required data are examined. Expectations for future developments are also reviewed.

1. Introduction
Organizations at all levels actively collect and analyze data. Many organizations also depend on the usage of data in the field. As the amount and quality of geospatial data increases, organizations are actively looking at ways of incorporating and/or collecting geospatial data in their field operations.

Geospatial data has three obvious uses in the field. Navigation is an important use in most applications. Field crews need the appropriate maps/images to plot their course and adjust to unexpected obstacles and circumstances.

A second important use of geospatial data is to provide the field personnel with in depth information on the characteristics of the region that they are exploring. An application program can have access to a wide range of maps showing things like terrain, soil/rock types, weather conditions, etc.

Collection of geospatial data is another critical field application. Field operations gather information about the sites being explored for future operations. The new information can be used to augment existing maps. Collecting data in the field using software that uses current maps as a basis improves the accuracy of the integration of old and new data. Incorporating GPS data in real time provides additional improvement.

While all of these operations can be achieved using paper, computer applications provide several advantages. The three most important advantages are faster access, the ability to integrate existing maps, and more accurate data collection procedures.

To improve the use of geospatial data in the field, we look at software development considerations for supporting the use of geospatial data in field computing and a new approach to integrating data. After a brief overview of field considerations in Section 2, we look at the basic issues of developing software to support geospatial data in the field in Section 3. The model and prototype of an infrastructure that has been used to support use of geospatial data in the field is reviewed in Section 4. A brief discussion of future considerations is given in Section 5.

Figure 1. Geospatial data types.

2. FieldD Considerations
Before we can look at software issues, we need to examine what it is that we are supporting in the field. We must understand what kind of data that we are manipulating, what users in the field expect, what can be expected from users in the field, and the type of devices that should be considered.

2.1 Field Expectations
Field users have a very simple requirement for the data needed in their computer support. They simply want access to the data that they need when they need it. Moreover, they want the access to be seamless. They want access to data that allows them to use their application programs without worrying about any of the underlying issues of how the data has been gathered, integrated, and processed. Unfortunately, these underlying issues can be very complicated for some applications. The precise data required can be split over several data sources. How to integrate the data is nontrival in most environments. Ensuring that the correct data is available in the field when it is needed, can also be a difficult problem.

Using geospatial data in the field increases the difficulty of these problems. First geospatial data is richer than any alphanumeric data. Figure 1 illustrates the basic data types of geospatial data. Raster data in particular creates interesting complications. The number of different formats of raster data that are available is large. Issues like, resolution, coverage and accuracy make integration a difficult problem. The fact that we are dealing with images mean that the size of the raster data is staggering for many applications.

2.2 Field Users
There are several ways to look at the field users. The spatial cognition of a user is briefly discussed.

Each person has a different ability to make use of geospatial data. Even in something as basic as using maps to find a location, the difference is striking. Research in spatial cognition suggests that there are at least three recognizable levels of knowledge that people use to be able to “use” a map to find their destination. The levels are known as landmark, route and survey based[6]. A landmark based thinker uses a list of landmarks to find her/his way around in a new area. This type of individual needs map support to obtain the list of landmarks needed to navigate the region described by the map.

A route based person uses the map to familiarize themselves with the major routes(roads) that are available and only supplements with landmarks in regions where roads are very poorly marked or non-existent. In a heavily populated region a route based thinker focuses on the major routes and only uses the map for minor roads when they are close to their destination. This type of user tends to use the map to create a list of written directions (e.g., turn left on to I-35 North).

A survey based map user tends to see the full extent of the map and uses the map directly to interpret their navigation needs. When this type of user uses a map in advance of traveling, it is to familiarize themselves with the map.

2.2 Devices
The range of equipment that is available for using geospatial data in the field continues to grow every year. The equipment considered in this presentation ranges from laptops to wearable computers. The characteristics critical to using the devices with geospatial data are briefly discussed in the remainder of this subsection. Figure 2 illustrates a tablet, a PDA, and the visual portion of a wearable computer.

2.2.1 Laptops Today’s laptops are essentially mobile workstations. Only screen size and the need for battery power in the field separate a high end laptop from a workstation. Most software developed for a desktop application can be handled by a laptop in the field. In particular a GIS system developed for a workstation can be used by a laptop in the field. As a result we only consider the issue of downloading data to laptops in the remainder of this presentation.

Figure 2. Sample mobile computing devices.

2.2.2 Pen Based Tablets
The pen based tablets are a step down from laptops in resources, but still give that user a reasonable screen and allow they user to run a wide range of available off the shelf software. The pen based aspect of the tablets mean that a different approach to designing interfaces must be developed. The screen size is large enough that users can absorb about the same level of information from geospatial data as on a laptop screen.

2.2.3 PDAs
The PDA market is moving very rapidly today and a large number of business sectors routinely use PDAs in some aspect of their field operations. The applications include both data gathering as well as directional applications. Some of these applications make use of some geospatial data. Using PDAs for applications involving serious use of geospatial data, however, is just beginning to take off. While the resources available on PDAs continue to increase, there are some aspects of a PDA that require careful software development. Screen size is the most critical issue in terms of software dealing with geospatial data. Laying out a user interface that provides software options and renders usable map/image information on the screen places significant constraints on both the interface and software design.

2.2.4 Wearable Computing Like PDAs, wearable computer technology is developing rapidly. The resources available for a wearable system are increasing very quickly. Input devices for wearables are readily available, but they differ dramatically in how hard they are to use. In addition new approaches, like interpreting eye movement are on the way. The screen size on a wearable is even more critical than on a PDA. The small size of the screen image combined with the issues of working with the screen image are limiting what can be done with visual data such as geospatial data. Two important issues worth mentioning are the difficulty of working on the edges of the screen image and locating a precise point in the screen image. These restrictions are likely to limit the way geospatial data can be used in the field. While traditional applications of geospatial data may be hard to implement, wearable computers also bring new opportunities. One very interesting new possibility is the concept of augmenting virtual reality (Figure 3). To support more traditional applications, it is likely that wearables will be used in tandem with other computing devices.

Figure 3. An example of augmented vision using a wearable computer.

2.3 GPS
GPS systems are rapidly becoming part of all field applications involving geospatial data. While most of our discussion of working with geospatial data is useful without employing GPS, we assume that it will be part of most applications.

3. SOFTWARE DEVELOPMENT CONSIDERATIONS
The issue for developing application software for using geospatial data in the field depends greatly on the type of equipment being used. In Section 2 we briefly examined some of the characteristics of the computing devices likely to be used in the field. Laptops have become so powerful that other than screen size and battery life, they are essentially desktops. Even the available screen size does not greatly limit the use of geospatial data. The only real concern when developing interfaces for applications is that care must be taken to insure that the interface layouts used make wise use of the available screen size.

Pen based tablets have essentially the same screen size issues as a laptop. The fact that they are pen based obviously means a somewhat different approach to inputting data, but does not greatly change the basic approach to handling geospatial data.

The real issues come with computing devices that have drastically reduced screen size.
PDAs and wearables are two examples of current technology that have small screen sizes.

In the remainder of this section we look at two issues. The next subsection looks at the issue of interface development and Subsection 3.2 looks at approaches for working with geospatial data on a small screen.

3.1 INTERFACE DESIGN
The primary issue in developing an interface for an application is to provide the user with the necessary functionality while at the same time leaving the user with sufficient screen space to be able to read the maps. Clearly, this problem gets more difficult as the screen size gets smaller. The design of the screen layout is critical for applications used in the field where conditions for viewing the screen are generally not optimal, e.g., bright sunlight.

In our prototypes we have found hidden menus and pull down menus to be especially valuable in developing usable interfaces. They minimize the amount of the screen that is taken away from presentation of maps/images, while still allowing the application to have a high degree of user interaction and functionality.

Another consideration for interface development is ease of changing modes. The issue here is based on providing users with disabilities the ability to use the application programs. At first, we looked at simply developing a suite of interfaces for the basic application. It didn’t take long to realize that such an approach was too rigid. There is a close relationship between needs for certain situations and disabilities. For example, a field worker that is engaged in a difficult climb may not be able to spare either hands to enter data or eyes to study a screen. As a result, the application should come with the full set of modes built into it and it should be easy to switch to the best mode for the current user or situation. We are currently looking at this in our prototypes.

Another important issue is map orientation. To best serve users, it should be possible for the user to either view the map in true north or directional (direction that he/she is facing) mode. Our approach is to have true north as the default and give the user the option to switch to the directional mode.

The spatial ability of users should be considered in development of an interface. In particular this means providing supporting information in addition to the map. The possibility of doing this varies widely, but can greatly assist the user when possible. Simple examples of this kind of support are devoting part of the screen to written directions for landmark/route base individuals and making it easier for a user to get annotations documenting the theme map being rendered.

In the next subsection we look at dealing with presentation of maps and images.

3.2 GEOSPATIAL DATA AND SMALL SCREENS
The obvious problem with a small screen is how much can be shown at a time. Figure 4 is an example of a topographic map as it might be shown on a laptop or tablet. While the resolution of the map is readable at that level, Figure 5 illustrates what happens if we try to show the same map on a PDA. Readability is no longer an applicable term even in ideal conditions. In the field it is worthless without the ability to zoom in.

Since it is not possible to show the entire map, the application has to either support zoom in or a subsetting operation. Since zoom in is well known, we will briefly look at

Figure 5. Same map as in Figure 4 as it would appear on a PDA.

subsetting. In subsetting an application shows a clipped portion of the full map to fit the screen. The result is that the user steps through the original map/image. Two methods of control can be used. One approach is to let the user control what parts of the map/image that he/she sees on the screen. Figure 6 illustrates a set of three segments from the map in Figure 4. An application on a PDA would use the three individual images in sequence to illustrate a route through the area described by the complete map. Generally, segments overlap to give the user some sense of continuity. A second mode for selecting segments is based on the use of GPS. The common approach is to jump to the next segment when the GPS reading gets a fixed distance from the center point of the map/image on the screen. This can make it difficult to read the map, especially when traveling a high rate of speed. We have been looking at compromises for

Figure 6. Example of subsetting a route through the map in Figure 4.

our applications that fix the map segment for a fixed distance or time traveled. Another approach that we are playing with is allowing the user pick the location of the GPS icon on the map/image. The map still jerks as you travel, but the user can set the position of the icon to give him/her a better view of the portion of the map that is needed. For example, placing the icon at the bottom (or side) of the map relative to the direction being traveled allows the user a good view of what is coming up.

In the next subsection we briefly look at the infrastructure that we use to support the field environment.

4. Infrastructure Mdel
The essence of the infrastructure is to integrate the geospatial data sources. While a great deal of work has been focused on integrating business data [1,3,4,8,9,10], efforts to integrate geospatial data are rather recent. At this point, integration of geospatial data is an accurate research area.

4.1 Ingrstructure Role
The primary role of the infrastructure is to bring geospatial data from a variety of possible data source locations, integrate the data to form what is needed in the field and deliver the result to a fixed point in the computer network. What happens next depends on the type of field application and the resources available to the field operation. For most applications today, the field crew would use the infrastructure to create a set of electronic maps that are needed in their field operation. Once the infrastructure has generated the required data set, it would be down loaded to computing equipment that will be taken to the field. Staging of data to more mobile devices would be done in the field.

The problem with this approach is that users must live with the data that comes with the crew. Our approach is designed to allow a more dynamic approach when possible. In setting where wireless communication is reasonable, a request can be generated by an application program and passed to the infrastructure. After the request is processed, the resulting data can be communicated to the field.

4.2 Objecti Views
At the heart of our infrastructure, we use object views to provide the basic unit of integration. [10,11,12] A sample view is shown in Figure 7. The view defines the attributes needed by the application program and the derivation string that is needed to generate the data from the data at the sources defined by L1 and L2. Views can either be implemented in either the client server model or as mobile agents[2]. To this point in this project we have focused on mobile agent-based views (view agents), but expect that both approaches will be required in the final prototype.

4.3 AGENT VIEWS
A block diagram of our infrastructure model using mobile agents is shown in Figure 8. The user’s request is processed by a mediator. The mediator attempts to choose an existing view agent to process the request. If none exists, a new view agent is constructed. The resulting view agent is launched with the request. When the information for the request has been found, return agents are launched with the required data.

We use a scenario to illustrate the functionality of the view agent approach. The upper portion of Figure 8 illustrates the scenario. The requested data is defined by a view in the object-oriented view set (e.g., Figure 7). Note, that the function raster_vector_fusion must be a defined in order to create the layered map image. The view agent generated by C1 is sent to one of the computation servers in the infrastructure environment, since it has a method that must be executed. Once the agent arrives at the server it in turn spawns view agents (V1 and V2 in the example) that take the data requests to the individual data sources represented by the local interfaces L1 and L2. There the spawned view agents can communicate the request to L1 and L2 via the source wrappers. Note, the local interface views are seen as a set of static agents that are owned by the local data sources.

Depending on the size of the result, the view agents, V1 and V2, either return the resulting data to the computation server or spawn return agents to move overly large results back to the computation server. The computation server in turn executes the raster_vector_fusion method and creates the return result for the user. The final result is returned to the field wrapper either by the view agent C1 or a set of return agents is spawned depending on the size of the results. The field wrapper then passes the data to the user in the field. Note in the bottom portion of Figure 8, we have an example of a view that only requires data from one local interface.

4.4 COMPUTATION SERVERS
Computation servers are included for providing computation that can not be handled at either the field wrapper or the source wrapper. The primary example is processing data that comes from more than one source. A simple example is a conflation algorithm used on images from different sources.

To support the necessary computation, a computation server can either execute the methods of the view object and/or make use of the tools supported by an object-oriented data warehouse [5] that exists at most computation servers. The data warehouse sees the results of the data coming back from the data source wrapper as materialized views. The advantage of using the data warehouse to store and operate on the data is that the data warehouse can be used as an active cache. Based on our preliminary analysis of user needs, it looks likely that the user will need to use the same (or very similar) data again after the initial query. For example, for a small device the image used on the first request will only be a subset of a larger image (retrieved or constructed) as the field worker moves around the field he/she will need to have the image adjusted. In many cases the data in the data warehouse can be used without additional retrieval. The warehouse is viewed as an active cache, since the tool set (or view object methods) can be used to modify the data as needed by the user. The extra computational support is also critical to allow the environment to combine data from multiple data sites and to create an efficient environment.

Figure 8. View agent environment.

4.5 Mediators
Mediators [9] to handle geospatial data have a different task than those designed to integrate business data. With business data, the mediator only needs to work at the schema level, while with geospatial data one needs to be able to deal with the values stored in the data set. For example, searching in geospatial data must include finding data based on either coordinate information or symbolic pointers (e.g., region names, state names).

To do this we use a multilevel mediator based on ontologies (symbolic pointers), R-trees (bounding boxes, points), and rule sets (query generation).

In the next section we briefly look at future considerations.

5. Future Considerations
Many things are happening that will enhance computing in the field. Most notably a wide range of computing equipment and peripherals will enter the market over the next few years. Wearable computers will greatly benefit from improvements in peripherals. Approaches like tracking eye movement are especially interesting. While much of the important technology is expensive at this point, more general use will bring the price down. An example is GPS technology. Military grade GPS equipment is still very expensive, but consumer grade GPS tools are relatively inexpensive. More general use of GPS has both dropped the price and improved the accuracy.

Persistent storage continues to improve for equipment likely to be used in the field. Benefits in both the amount of capacity and dropping prices should be very helpful in supporting applications requiring large amounts of image data.

Improved battery life is a critical development for many of the equipment discussed in Section 2. Current batteries do not last long with a fully loaded PDA.

While there has been a great deal of progress in voice recognition in recent years, more needs to be done for it to be successful in field applications. Current capabilities suffer greatly outdoors on a breezy day.

Overall, the trend in computing devices and peripherals looks very positive for expanding field applications.

6. Conclusions
This presentation has looked at the issues surrounding use of geospatial data in field operations. In particular we looked at software needs for developing field applications.

Acknowledgements:
We would like to thank our colleagues, Mike Goodchild and Keith Clarke from University of California-Santa Barbara and members of our project team, Howard Butler, Ming Hua, Sheng Qu, and Peisheng Zhou from Iowa State University for their help.

References

Barsalou, T. and D. Gangopadhyay (1992). M(DM): An open framework for interoperation of Multimodel Multidatabase Systems. IEEE Data Engineering, pp. 218- 227.
Bradshaw, J. M. An introduction to software agents. In: Bradshaw, J. M. (ed.), Software Agents, Cambridge, MA: MIT Press.
Bright, M. W., A. R. Hurson and S. H. Pakzad (1992). A taxonomy and current issues in multidatabase systems. Computer, 25(3):50-60.
Hurson, A. R., M. Bright and S. Pakzad (1994). Multidatabase Systems: An Advanced Solution for Global Information Sharing. New York: IEEE Computer Society Press.
Miller, L.L., Vasant Honavar and Tom Barta. (1997). Warehousing structured and unstructured data for data mining. ASIS'97. Pages 215-224.
Nusser, S. M. and J.E. Fox. (2003). Using digital maps and GPS for planning and navigation in field surveys. Submitted to Journal of Official Statistics.
Nusser, S. M., L.L. Miller, K. Clarke and M.F. Goodchild. (2003). Geospatial information technologies for mobile field data collection. Accepted to Communications of ACM.
Subrahmanian,V. S, Sibel Adali, Anne Brink, Ross Emery, James J. Lu, Adil Rajput, Timothy J. Rogers, Robert Ross, and Charles Ward. HERMES: heterogeneous reasoning and mediator system, www.cs.umd.edu/projects/hermes/publications/abstracts/hermes.html
Wiederhold, G. and M. Genesereth (1997). The conceptual basis for mediation services. IEEE Expert, 12(5):38-47.
Yen, C. H., L. L. Miller, A. Sirjani and J. Tenner (1998). Extending the objectrelational interface to support an extensible view system for multidatabase integration and interoperation. International Journal of Computer Systems Science and Engineering, 13(4):227-240.
Yen, C. H. and L. L. Miller (1995). An extensible view system for multidatabase integration and interoperation. Integrated Computer-Aided Engineering, 2(2):97-123.
Yen, C. H., L. L. Miller and S. H. Pakzad (1994). The design and implementation of the zeus view system. Hawaiian International Conference on Systems Science, pp. 206- 215.