Figure 1: A typical image stored in our image database.
Duncan Cavens
Dr. Stephen R.J. Sheppard
Dr. Michael J. Meitner
Currently at the University of British Columbia we are charged with creating a Centre of Excellence in environmental visualization. In order to support this mission we have developed an ArcView extension to deal with our ever-increasing collection of georeferenced digital imagery. Issues of data capture, storage, querying and retrieval will be addressed.
At UBC's Collaborative for Advanced Landscape Planning (CALP), much of our work is centred around images. As researchers and planners whose primary concern is the visual appearance and representation of landscapes, we deal with deal with thousands of images every year. For each of our projects, we take a large number of photographs as source data and benchmarks for our landscape visualizations. Like many other professionals with substantial image libraries (such as landscape architects, environmental planners, architects, etc.), we have a constant battle to store and catalogue these images in a way which makes retrieval easy.
|
Figure 1: A typical image stored in our image database.
|
While our image collection and problems with image management are quite typical, the amount of information we collect for each image is not. As part of our procedures for landscape visualizations, we are required to be fastidious in our data collection. In order to accurately simulate landscape change at real locations, we collect data such as lighting conditions, time of day, and view direction. In addition, almost every photograph has geographic data associated with it, collected with a global positioning system (GPS). As we were designing a database to index our photographs, it became obvious that this wealth of data, coupled with a GIS linked database, could provide a powerful resource for one of our related research tasks: long term landscape monitoring.
As researchers who analyse, predict and recommend landscape changes, it is important that we are able to understand how past interventions have affected the visual quality of the landscape. Most of our landscape simulations involve projecting future conditions on an existing landscape. There is a great deal of uncertainty in this simulation process as many of the models and variables are extremely difficult to calibrate and validate. Part of the difficulty is a lack of historical landscape photography which would enable us to test our models by going backwards into time and running our simulations to the present. The photography that does exist is often poorly documented, if at all.
While there have been numerous articles about the need for systematic monitoring of landscapes (Smardon 1986), these systems (grouped generally as Visual Resource Management (VRM) or Visual Information Management (VIM) systems) are designed to monitor specific locations for specific purposes((Litton 1973), (Sheppard 1989)). They require a concerted effort on the part of the agency involved to select key photo locations, identify landscape categories, and deal with proposed interventions. While there are valid applications for such thoroughness, there is a common perception that these systems are unwieldy and bureaucratic. As a result, landscape photography is either incredibly detailed in its documentation, or documentation is not done at all. As a result, many communities, projects and researchers are not able to benefit from this rich resource (Sheppard 1997). We feel that by cataloguing and storing our exising photography in a way which is accessible and useful, we can build a powerful long term resource for ourselves and others.
The design of our system had to accomplish a number of goals:
Our image database system is implemented as a relatively simple client/server application, with a Microsoft SQL Server backend and an Esri Arcview 3.2 extension as the client. While our research group is relatively small and our dataset is initially quite small, it was decided that the long term benefits (security, replication, and scalability) of a full featured SQL database outweighed the relatively minor cost in terms of ongoing maintenance.
Part of the initial discussion was how much of the data to store within the SQL database. While it is possible to store the images directly as binary data within the database, this was rejected as too complex and unnecessary. It was decided that the database would store a reference to an image file, stored as a JPEG or GIF, which would reside on the server in a parallel file system to the database. For storage and copyright reasons only a small (200 by 200 pixels) thumbnail would be stored online. The source image is stored on CD in a centrally located area. This reduces the online storage requirements of the system, and provides an opportunity to control the distribution of the originals (the thumbnails are large enough to be understood, but not large enough to be truly useful.)
A related discussion was how the geographic data would be stored. Projects in our lab are run independently of one another, with very different standards for data locations, file formats and geographic projections. However, the image database was to transcend project boundaries and store information for the long term.
The issue of map projections proved cumbersome. As each project used a different projection, it was difficult to implement a system that would allow users to search a given geographic location to see if there were photos from previous projects. Initally, it was decided that this was an insurmountable given the very limited time budget allocated to the project. Each project was to store its points in a separate Arcview shapefile, and inter-project searching would for the time being remain impossible.
Once the system was in use for a couple of months, it became apparent that this limitation was hampering the system's ability to meet its design goals. It was impossible to search a given geographic location for photos if you weren't aware that a project existed, or had photos in that location. It was also obvious that this would be much more of a problem over the long term as more distinct projects were added to the database. With more projects and photographs, there would be more opportunities to search across project boundaries for photographs linked across time.
As a result, the point data associated with each photograph has been integrated into the main SQL table as a Latitude/Longitude pair. The point is dynamically reprojected each time the database is displayed in the GIS, eliminating the problem of having GIS data spread out amongst multiple files. While this was slightly more difficult to implement in the client application (Arcview does not inherently store projection data with its data), it improves the functionality drastically.
Figure 2: Simplified Database Schema for Image Database
|
The database design is relatively simple, with two primary tables. Each photo location has a single record in the Image_Viewpoint table, which stores general information such as an image description, date it was photographed, etc. As each photo location can have multiple photos (we often take multiple photographs as part of a panorama), each individual digital photograph is listed in the Image_Individual_Images table. This lists information to each specific photograph, such as image focal length (critical information for visual simulations) and the location of the thumbnail and original source file.
The relative simplicity of the data structure, and its general platform independence (it is not tied to any GIS system, client application or even database software) means that developing client applications are relatively straightforward. We currently have two: an Arcview 3.2 extension and a web based catalogue.
Most data entry and querying presently happens within Arcview. We have implemented the client application as an Avenue extension, so that the Image Database is accessible from any Arcview project. The extension adds a menu and a new document type ("Image Database View") to the project. The menu provides basic functionality, such as keyword searching, adding a new image, and searching by photo ID.
Figure 3: Screen Capture of the Arcview Extension (click on image for full size image)
|
The "Image Database View" is almost identical to the standard Arcview View. The only addition is that when the window is created, the user is asked to specify the projection for the particular view (based on a pull down box of typical choices). This allows the extension to add an "Image Database Points" theme. This theme dynamically builds all of the photo points contained within the current view area that meet the current selection criteria. This allows the user to view only a subset of the image points (by project, by date, or by keyword), making the dataset easier to navigate as it gets larger.
Care was taken to ensure that the "Image Database" theme worked similarly to a standard Arcview theme. By using the hotlink tool, the user can click on a point and bring up an information window describing the photos associated with this point. If the user searches for a photo via the search facility (by keyword, project, etc..) the selected photo is highlighted in the typical Arcview way (by turning the point yellow.) This allows the user to easily integrate the image database in their typical work pattern.
Adding a new image is similarly easy. As most of our photos have GPS data associated with them, all the user needs to do is select the relevant GPS point from their GPS theme, and select "Add Photo.." They then enter the relevant data from our paper photo record form, and select "Save..". The user is asked for the file location of the original digital photograph, and the extension automatically creates a reduced thumbnail of the picture and stores it in the database. Each photo requires about 3-5 minutes to enter in the database, with the majority of this time being data entry (we are taking steps to reduce this time- please see 'future work' below.)
While the Arcview interface works very well, it did not meet all of the expressed needs. It requires that users have a specifically configured piece of software (Arcview), and that they understand the Arcview interface. Many users, particularly project partners not directly associated with our lab, are interested in images from a thematic perspective, rather than a geographic one.
To meet this need, we implemented a simple web based interface to the database, allowing anyone to search the database by project, keywords or image description. Web users can view all of the data associated with each photograph, except for the geographic location of the photos. While it would be possible to implement a web based map server, it was decided that there was not sufficient demand to warrant such a system. In particular, the issue of which GIS coverages to use as a base map for any given photograph would be difficult: each project has radically different requirements. Given that we are an organization of approximately 10 people, it was not viewed as a priority.
Figure 4: Some sample screen shots of the web interface. (Click on image for full size.) The database is available online at http://www.calp.forestry.ubc.ca/resources.htm.
|
The web interface has proved very successful as we can redirect outside queries about imagery that we possess to the web. Outside users are able to quickly determine if we have a photograph that would be useful for them without any assistance from lab members.
Our image database has been quite successful- it has enabled us to keep track of images that would otherwise not be usable outside of the narrow definitions of a particular project. We are convinced that its usefulness will grow with time. After less than a year after implementation, the system already indexes close to 2000 images.
Part of the success of the system is its simplicity- it is very simple to use and integrates well with the researchers other tasks. The one complaint we have received, however, was in the amount of time it takes to input each photograph. As a result, we are investigating the feasibility of building a simple data entry application that needn't be directly connected to the database. Rather than having the photographers write down their photographs, they could enter the information directly into a laptop. This could cut down their data entry time to almost nothing.
Another improvement we are contemplating is moving the client application to Esri's ArcGIS platform. As our database is not tied to any client, porting the client to this radically different environment should only require a couple of days' effort. It may also provide us with the opportunity to better link the web interface with the underlying geographic data.
While the web interface was not our initial focus, it provides one of the most interesting implications of this work: it has the potential to provide the general public with information about historical changes to the landscape. Much of our simulation work is in highly contested regions, where visual change is a critical part of public debate. As visual databases grow in size, they could provide a public record of the impact of past interventions.
At the same time, for our own internal use, the image database has greatly simplified our daily tasks of searching for and cataloguing images. The long term benefits of such data organisation and dissemination has obvious benefits to an organisation such as CALP. It is hoped that with further development and implementations, the usefulness of online image databases can become more widely appreciated.
Litton, R. B., Jr. (1973). Landscape control points : a procedure for predicting and monitoring visual impacts, USDA Forest Service Research Paper, Pacific Southwest Forest and Range Experiment Station.
Sheppard, S. R. J. (1989). Visual simulation: A User's Guide for Architects, Engineers, and Planners, New York, Van Nostrand Reinhold.
Sheppard, S. R. J. & Parker, Tom (1997). "Photo-monitoring: a tool for measuring landscape change." International Association for Impact Assessment (IAIA) '97 Proceedings New Orleans, March 1997.
Smardon, R. C. (1986). Urban Visual Description and Analysis. Foundations for Visual Project Analysis. R. C. Smardon, J. F. Palmer, and J. P. Felleman. New York, John Wiley & Sons: Chapter 8, p 115-40.
We'd like to acknowledge all of the CALP members who commented on the system design and were diligent in finding the many bugs in the system.
Duncan Cavens
Collaborative for Advanced Landscape Planning
Forest Sciences Centre
2045-2424 Main Mall
University of British Columbia
Vancouver, BC., Canada V6T 1Z4
E-Mail: duncan@cavens.org
Phone: (604) 822-6708, FAX: (604) 822-9106
Stephen R.J. Sheppard
Associate Professor
Collaborative for Advanced Landscape Planning
Dept. of Forest Resources Management and Landscape Architecture Program
Forest Sciences Centre
2045-2424 Main Mall
University of British Columbia
Vancouver, BC., Canada V6T 1Z4
E-Mail: shep@interchange.ubc.ca
Phone: 604 822-6582, fax: 604 822-9106
Michael J. Meitner
Assistant Professor
Collaborative for Advanced Landscape Planning
Department of Forest Resources Management
Forest Sciences Centre
2045-2424 Main Mall
University of British Columbia
Vancouver, BC., Canada V6T 1Z4
E-Mail: meitner@interchange.ubc.ca
Phone: (604) 822-0029, FAX: (604) 822-9106