\documentstyle[twocolumn]{article}

\pagestyle{empty}

\setlength{\textheight}{9.00in}
\setlength{\columnsep}{2.0pc}
\setlength{\textwidth}{6.8in}
\setlength{\footheight}{0.0in}
\setlength{\topmargin}{0.0in}
\setlength{\headheight}{0.0in}
\setlength{\headsep}{0.0in}
\setlength{\oddsidemargin}{-.19in}
\setlength{\parindent}{1pc}
\renewcommand{\aa}{\"{a}}
\newcommand{\oo}{\"{o}}
\newcommand{\uu}{\"{u}}
\renewcommand{\AA}{\"{A}}
\newcommand{\OO}{\"{O}}
\newcommand{\UU}{\"{U}}
\newcommand{\s}{{\ss\ }}
\newcommand{\boxit}[3]{\framebox[#1][#2]{\parbox{#1}{#3}}}
\newcommand{\fig}[1]{Figure~\ref{#1}}
\newcommand{\IT}[1]{{\it #1}}

\makeatletter

\def\subsize{\@setsize\subsize{11pt}\xipt\@xipt}

%\def\section{\@startsection {section}{1}{\z@}{1.0ex plus 1ex minus 0.2ex}
%{0.2ex plus 0.2ex}{\Large\bf}}
\def\section{\@startsection {section}{1}{\z@}{-3.7ex plus -1ex minus
-.2ex}{2.3ex plus .2ex}{\large\bf}}


\def\subsection{\@startsection {subsection}{2}{\z@}{-1.7ex plus -1ex
minus -.2ex}{2.3ex plus 0.2ex}{\subsize\bf}}

\makeatother

\date{}

\title{\large SEQUOIA 2000 METADATA SCHEMA FOR SATELLITE IMAGES}

\author{Jean T. Anderson and Michael Stonebraker\\
\small EECS Department\\
\small University of California, Berkeley\\
\small Berkeley, California 
}

\begin{document}
\maketitle
\thispagestyle{empty}
\bibliographystyle{unsrt}

\begin{abstract}
Sequoia 2000 schema development is based on emerging geospatial 
standards to accelerate development and facilitate data exchange.
This paper focuses on the metadata schema for digital satellite images.  
We examine how satellite metadata are defined, used, and maintained.
We discuss the geospatial standards we are using, 
and describe a SQL prototype that is
based on the Spatial Archive and Interchange Format (SAIF) standard
and implemented in the Illustra object-relational database.
\end{abstract}

\section{Introduction}

The Sequoia 2000 project is developing a computing environment to support 
global change research, involving large volumes of complex data in many 
formats [1,2].\footnote{This research was sponsored by the
University of California and Digital Equipment Corporation.
Other government and industrial sponsors include the
California Department of Water Resources,
U.S. Geological Survey,
Construction Engineering Research Laboratory (CERL) of the U.S. Army
Corp of Engineers,
the National Aeronautics and Space Administration (NASA),
Epoch systems, Inc., Hewlett-Packard Corp., Hughes Aircraft
Company, MCI, Metrum Corporation, PictureTel Corporation,
Research Systems, Inc., Science Applications International Corporation,
Siemens Inc., and TRW Space and Electronics.}
The design goals for the database schema that manages these data include:

\begin{itemize}
\item 
Develop a database schema library composed of user-defined types and SQL 
templates that support earth science data.
A researcher uses these building blocks to create a database schema 
for a specific application. 
\item
Include enough metadata so files can be 
generated in widely-used scientific formats, such as netCDF and HDF.
\end{itemize}

This paper focuses on the metadata schema being developed to manage
satellite images.
Section 2 looks at satellite data and the metadata associated with 
a satellite image.  
Section 3 describes an approach for basing a database schema on emerging 
geospatial standards to accelerate development of the schema library and 
support interoperability.  
Section 4 describes a prototype implementation, which is based on a
geospatial standard and uses the Illustra object-relational database to 
manage the metadata and satellite images.
Section 5 addresses metadata maintenance.

\section {Digital Satellite Data}

To set the stage for our discussion of satellite metadata, this section 
describes data from the Advanced Very High Resolution Radiometer 
(AVHRR) sensor on the NOAA satellites.
First we introduce some satellite basics and describe a satellite image.
The satellite images described in this paper are end products produced
by the EROS Data Center[3]. 
Next we identify the metadata elements specific to a satellite image as 
well as some broader categories of metadata associated with a data set.

\subsection{Satellite Image Basics}

The AVHRR sensor has five channels that collect measurements in 
different wavelengths.
The first two channels collect visible and near-infrared measurements,
and the last three record thermal measurements in different spectral 
resolutions.
The point directly below the satellite has a spatial resolution of about 
1 kilometer and becomes increasingly distorted further away from the 
orbit path
because of the wide viewing angle and the curvature of the earth.

After data are transmitted to ground stations, the measurements are 
calibrated and corrections are applied. 
Data are corrected geometrically to reduce distortion, and location information
is added.  The data are then released for further processing [3,4].

These satellite images are perceived slightly differently by computer and 
earth scientists.  
The computer scientist focuses on structure and treats each image as a 
three-dimensional raster (a regular grid). The dimensions for this
data set are 2889 rows x 4587 columns x 10 deep.  
The earth scientist, however, focuses on the processes that created the image.
From his or her point of view, the image has 10 {\em bands} or {\em layers}, 
each created by a different process.  Each band is composed of 2889 lines 
and 4587 samples. 
The database metadata schema should support both viewpoints.

\subsection{Satellite Image Metadata}

How researchers access the data largely drives which metadata are stored.
Dozier [2] provides two examples of how researchers would like to query 
raster data:

\begin{itemize}
\item
Select all daytime AVHRR images for the Southern Sierra Nevada
between October 1991 and June 1992 and sort chronologically.

\item
Find the Landsat Thematic Mapper image closest to April 1, 1992, 
for the Bubbs Creek area that is cloud-free and has snow. Map 
the snow-covered area and snow grain-size index.
\end{itemize}

Both queries need date information (to retrieve images that match
the specified date) and geographic information (to restrict the spatial 
search to a specific region). 
The second query additionally requires access to information in the bands.
In other words, the metadata supporting these queries must include temporal 
and spatial information as well as the structure of the raster.
Table 1, below, summarizes metadata for a single satellite image from [3],
organized into three sections described in greater detail:
{\bf Grid}, {\bf Spatial Registration}, and {\bf Temporal Information}.

The {\bf grid} for the sample AVHRR data set was introduced briefly 
in the previous section; 
{\em i.e.,} it is made up of 10 bands, and each band has 2889 lines 
and 4587 samples.
The first five bands contain the calibrated measurements from the 
five channels on the satellite sensor.  
The rest of the bands contain information added by the EROS Data Center.
Band 6 contains the normalized difference vegetation index (NDVI),
which is calculated from the first two bands and indicates the degree of 
``green-ness" of a pixel.
Bands 7-9 contain satellite geometry information. 
Finally, these images are {\em composites} that were constructed from
images collected over a 14-day period to produce cloud-free images.
Each pixel in band 6 (NDVI) contains the ``best" NDVI measurement
for that pixel from all images.
Band 10 tracks the source image that was used for each pixel.

The image must be {\bf spatially registered} to a geographic coordinate system 
using a standard projection before many operations can be performed, such as 
overlaying an image with state or county boundaries
or transforming it to a different map projection.

\vspace{5 mm}
\small
\begin{tabular}{|l|ll|}
\hline
\multicolumn{3}{|c|}{Table 1: AVHRR Metadata} \\ \hline\hline
\multicolumn{3}{|c|}{Grid}                                        \\ \hline
No. lines                & \multicolumn{2}{l|}{2889}               \\
No. samples              & \multicolumn{2}{l|}{4587}               \\
No. bands                & \multicolumn{2}{l|}{10}                 \\
bands                    & \multicolumn{2}{l|}{AVHRR channels 1-5,}\\
		         & \multicolumn{2}{l|}{NDVI,}\\
		         & \multicolumn{2}{l|}{satellite zenith,}\\
		         & \multicolumn{2}{l|}{solar zenith,}      \\
		         & \multicolumn{2}{l|}{relative azimuth,}  \\
		         & \multicolumn{2}{l|}{pixel source date}  \\
units of measure         & \multicolumn{2}{l|}{meters}             \\
pixel size               & \multicolumn{2}{l|}{1000 (meters)}      \\ \hline\hline
\multicolumn{3}{|c|}{Spatial Registration}                        \\ \hline
map projection           & \multicolumn{2}{l|}{Lambert Azimuthal}  \\
lat/lon of center        & 100 West                 & 45 North      \\
false easting/northing   & 0                        & 0             \\ 
nw corner                & -2050000                 & 752000        \\
Bounding box:            &                          &               \\
\multicolumn{1}{|r|}{lower left lat/lon}  & -119.9722899             & 23.5837576    \\
\multicolumn{1}{|r|}{upper left lat/lon}  & -128.5300591             & 48.4030555    \\
\multicolumn{1}{|r|}{upper right lat/lon} &  -65.3946489             & 46.7048989    \\
\multicolumn{1}{|r|}{lower right lat/lon} &  -75.4163527             & 22.4793919    \\ \hline\hline
\multicolumn{3}{|c|}{Temporal Information}                       \\ \hline
Begin date               & 4-Jan-1991               &               \\ 
End date                 & 17-Jan-1991              &               \\ \hline
\end{tabular}

\normalsize
\vspace{5 mm}
This data set used the 
Lambert Azimuthal Equal Area projection, which is optimal for covering 
large regions. The central meridian for the projection was located at 
latitude 100 West, longitude 45 North (Gettysburg, South Dakota).  
The upper north west corner of the image is registered at 
-2050000, 752000, provided in {\em eastings} and {\em northings}, which are
the number of meters from the projection center (negative numbers are 
west of the central meridian). 
The latitude/longitude coordinates for each corner of the image form
a bounding box used in spatial searches.

{\bf Temporal information} allows extracting subsets 
of the data. A satellite image may have a single date and time the
image was taken. Composite images, such as the one referenced in Table 1, 
have a date range spanning the dates of all images used to create the 
composite.

\subsection{Satellite Data Set Metadata}

An image is stored as part of a larger data set, and a site may have many 
data sets. Additional metadata describe the data holdings for a site so 
researchers can find out what is available. 
Although this paper primarily focuses on raster metadata, we define 
the following broad categories of metadata for a satellite image data set:

\begin{itemize}
\item {\bf Raster:} 
As discussed above, raster metadata include grid structure, 
and spatial and temporal information.
\item {\bf Data Lineage:} 
Lineage metadata include the processing history, algorithms 
and parameters that were used to produce an image.
Better algorithms may be developed for processing images, or anomalies 
may be discovered in images years after their creation. 
For example, a better NDVI algorithm might be developed or the
raw data may have been calibrated incorrectly.
A researcher analyzing an image wants to know the processing steps 
that created an image as well as detailed information about the algorithms.  
He or she also might want to identify all rasters that were processed with 
a given algorithm; perhaps to reprocess them using a different algorithm. 
\item {\bf Data Set Description:} 
Researchers want to know what data sets are available at a particular
site as well as detailed information describing each data set.
High-level site catalogs and data set descriptions are critical for
data browsing tools such as TIOGA [5] and TECATE [6].
Metadata typically include geographic region, dates the data set 
covers, search keywords, data availability, and contact information.
\item {\bf Object Descriptions:} 
Researchers often need to know the structure of a database table or the 
specific properties of an attribute; for example, {\em longitude} is a 
single-precision float that must be between -180 and +180. 
Schema information is also needed to generate transfer files in a
specific format, such as netCDF or HDF.  
\end{itemize}

\section{Geospatial Data Standards}

Sequoia schema development is drawing from emerging geospatial standards 
to accelerate development and support interoperability.  So far we have 
been working with the Spatial Archive and Interchange Format (SAIF) [7] 
and the Content Standards for Digital Geospatial Metadata (FGDC) [8], 
which are among the contributors to the Open Geodata Interoperability 
Specification (OGIS) [9].

SAIF was accepted as a draft standard by the Canadian General Standards 
Board in 1991.
It is an extensible, object-oriented data modeling and archival/transfer 
standard that targets both geospatial and non-geospatial data.

The Federal Geographic Data Committee (FGDC) effort to specify a digital 
geospatial metadata standard began in 1992, resulting in a final draft  
published in 1994.  It adopts a simpler data model organized into a
hierarchy of data and compound elements needed to
document a geospatial data set.

The FGDC gave the Open GIS Foundation the task of defining an 
interoperability specification for geospatial database interfaces and
geoprocessing capabilities. Work on OGIS began in 1993.

Current Sequoia schema development is using the SAIF and FGDC metadata 
standards as starting points. 
SAIF is highly extensible and committed to integration with other standards.
The FGDC metadata standard is particularly useful for high-level metadata
and appears to be gaining popularity in the 
geospatial user community (for example, OGIS is 
proposing to use it for its high-level data set and catalog descriptions).
While OGIS is developing a comprehensive internal data model, 
as of this writing the specification is still a moving target.  Once OGIS 
is complete and services are implemented, it should not matter whether 
a Sequoia researcher implements a schema based on SAIF or the FGDC metadata 
standard, or any other supported standard, since interoperability 
will be handled by OGIS services. 

%% The reality:
%% standards don't map to each other
%% any standard must be extended, some support this (SAIF) and some don't (FGDC)
%% the underlying data model for the transformation service must be extensible

%% The sequoia wish list
It is important to appreciate that the data models underlying different 
standards 
do not map exactly to each other.  Furthermore, we realize from our initial 
experience with the FGDC metadata and SAIF standards that we would
probably need to extend any standard for Sequoia earth science data.  
Reliable methods are needed to transform between data models and describe
user-defined extensions without losing information.
Finally, we need the ability to extend the underlying data model that 
provides a transformation service.  Designing a schema that 
encompasses all Sequoia data has been challenging and we do not expect any
standard to anticipate every real-world object we want to share.  
Rather, transformation services should support an evolving 
schema and should provide a mechanism for extending the underlying model.

Transformation between data models, or schemas, is an important research area.
Rosenthal [10] describes an approach that uses a unified underlying data 
model comprised of the union of all features, noting that the complexity 
of a unified model is increased by any extensions made to it.
Bright [11] uses a global data structure, generated from an online 
system taxonomy, that contains concise descriptions of data available in all 
input schemas.  The resulting global structure (the `summary schema') is 
smaller and easier to modify than a union of all schemas.
%% The next option sounds attractively flexible, but one wonders how it would
%% scale to tera- and pedabytes of climate data.
Sciore [12] describes an approach that is independent of any data model.
Instead, the metadata (the `context') is attached to the value 
and conversion functions handle transformations between source and
target contexts.
These approaches are applied to the relational model; 
each would need to be extended to handle object-oriented capabilities.

Realistically, we do not expect to see tools that effortlessly 
provide interoperability services for some time.  
Adhering to standards today gives us a common framework and a less
ambitious degree of interoperability using tools the standards community
provides or tools we develop ourselves.

\section{Prototype Schema Implementation}

We implemented a prototype schema based on SAIF
using the Illustra object relational database,\footnote{Many thanks to the 
following individuals for early brainstorming on what a SAIF SQL raster 
might look like:
Kenn Gardels of U.C. Berkeley CEDR-REGIS, Sam Gustman of the U.S. Army Corp
of Engineers CRREL, and Mark Sondheim of the British Columbia
Surveys and Resource Mapping Branch.}
which 
supports SQL3 object-oriented features such as inheritance, polymorphism, 
and user-defined types. The Illustra spatial extension supplies the spatial 
data types, operators, and access methods needed to manage and query
geospatial data. We also use its large object data types to manage the 
satellite images.

First, we briefly introduce the SAIF data model, then 
show the AVHRR metadata from Table 1 loaded into a SAIF view in Table 2.
Next we describe the SQL implementation in Illustra,
%% \footnote{This presentation has been simplified somewhat to save space. 
%% The complete prototype is available at
%% ftp://s2k-ftp.cs.berkeley.edu/pub/sequoia/dba/illustra/contrib/saif.}
also discussing the 
SAIF types we modified and a few weaknesses in our implementation.

The SAIF standard includes many components, but we have focused primarily 
on its data model, which we organize into three layers: 

%% deliberately simplified

\begin{itemize}
\item {\em Building blocks} are base objects that include enumerations and 
primitive types. An enumeration is a list of named values. 
For example, the {\em UnitMeaning} enumeration identifies the real-world
units stored in another variable. Its domain of values is large
and include {\em metres, miles, degrees, radians, years,} and {\em seconds.}
Primitive types correspond to the types used in a programming 
language, such as {\em real, integer,} and {\em string}.
\item {\em Generic constructs} use the building blocks to define real-world 
objects. For example, we used the SAIF {\bf Grid} and {\bf StructuredData} 
types in our AVHRR raster prototype. 
\item The {\em SAIF Standard Schema} defines over 300 classes to form the base 
standard.  SAIF recognizes that no one will implement the entire schema
and provides rules and a syntax for defining a subset of the standard, called 
a {\em profile}.
\end{itemize}

Table 2, below, summarizes a SAIF view of our sample AVHRR metadata,
divided into the following parts that are described in detail: 
{\bf Grid}, 
{\bf StructuredData},
{\bf GeneralLocation},
{\bf TimeObject},
and {\bf SpatialReferencing}.  
SAIF types are listed in the left column;
compound types are italicized, and attributes are in regular type. 
The sample AVHRR metadata are listed in the right column.

\vspace{5 mm}
\small
\begin{tabular}{|l|l|}
\hline
\multicolumn{2}{|c|}{Table 2: SAIF Raster}                      \\ \hline\hline
\multicolumn{2}{|c|}{Grid}                                      \\  \hline
positionOfOrigin         & -2050000, 752000                     \\
                         &                                      \\
{\em GridReference:}     &                                      \\
ordering                 & rowOrder                             \\
originCorner             & nw                                   \\
cellPositionAtCorner     & false                                \\ 
originCoordinates        & 0, 0                                 \\
                         &                                      \\
{\em GridFramework:}     &                                      \\
gridDimensions           & 2889, 4587                           \\
gridSpacing              & 1000, 1000                           \\
units                    & meters, meters                       \\
OffsetStructure          & none                                 \\ \hline\hline
\multicolumn{2}{|c|}{StructuredData}                            \\ \hline
contentValues            & actual image                         \\ 
                         &                                      \\
{\em ContentStructure:}  &                                      \\
indexingScheme           & sequentialArray                      \\
attributeNames           & AVHRR channels 1-5,                  \\
		    & NDVI, satellite zenith,                   \\
		    & solar zenith,                             \\
		    & relative azimuth,                         \\
		    & pixel source date                         \\ \hline\hline
\multicolumn{2}{|c|}{GeneralLocation}                           \\ \hline
{\em BoundingBox:}       &                                      \\
minPoint                 & -119.9722899, 23.5837576             \\
maxPoint                 & -65.3946489, 46.7048989              \\ \hline\hline
\multicolumn{2}{|c|}{TimeObject}                                \\ \hline
{\em Duration:}          &                                      \\
startTime                & 4-jan-1991                           \\
lengthOfTime             & 14                                   \\ \hline\hline
\multicolumn{2}{|c|}{SpatialReferencing}                      \\ \hline
Projection               & LambertEqualArea                     \\
centralMeridian          & -100, 45                             \\
falseEasting             & 0                                    \\
falseNorthing            & 0                                    \\ \hline
\end{tabular}
\normalsize
\vspace{5 mm}

{\bf Grid} describes the geometry of the raster.
SAIF adds many metadata elements that generalize a grid, allowing it to 
be defined in any number of dimensions and in a variety of shapes.
While this is more functionality than an AVHRR raster needs, it allows 
describing other types of gridded data, such as global and
regional climate models.  Grid attributes include:

\begin{itemize}
\item {\em positionOfOrigin}, which stores the coordinates that map a corner 
of the image to a location on the ground.
\item {\em GridReference}, a compound type that orients 
      {\em positionOfOrigin.}
{\em ordering} specifies how data are ordered.
{\em originCorner} indicates which corner of the image
{\em positionOfOrigin} references.
{\em cellPositionAtCorner} indicates if the origin of a cell is
positioned at the corner (`true') or in the center (`false').
{\em originCoordinates} specifies the grid cell coordinates of 
{\em positionOrigin.}
\item {\em GridFramework}, a compound type that describes the grid structure.
The {\em gridDimensions} array stores the size of each dimension. 
The {\em gridSpacing} array stores the pixel size for each 
   dimension in real-world units; {\em i.e.,} {\bf 1000} meters.
{\em units} stores the real-world unit of measure for 
   {\em gridSpacing} in each dimension; {\em i.e.,} 1000 {\bf meters}.
{\em OffsetStructure} indicates if an offset structure applies, 
   such as would be used for a triangular or hexagonal grid.
   We list it as `none' for a regular grid.
\end{itemize}

{\bf StructuredData} stores the data and includes:
\begin{itemize}
\item {\em contentValues}, which contains the actual data.
\item {\em contentStructure}, a compound type that further describes the 
{\em contentValues} structure.
{\em indexingScheme} specifies if data have been ordered physically 
   in a specific format, such as run-length encoded.
{\em attributeNames} is an array of names. 
\end{itemize}

{\bf GeneralLocation} contains the bounding box coordinates for the image,
and {\bf TimeObject} contains temporal referencing. Finally,
{\bf SpatialReferencing} contains projection information, which we
include in Table 2 for completeness. However, projection handling has
not been implemented yet and is part of continuing design efforts.

We implemented the SAIF type hierarchies in Illustra, defining 
enumerations as new base types and compound types as 
composite types and tables. Figure 1 shows the resulting SQL.
(Note that {\em GridOrder, OriginReference, OffsetStructure, UnitMeaning,
IndexScheme,} and {\em SatelliteBands} are enumerations. 
For brevity, we omit the steps that create them as base types.)

We added the {\em SatelliteBands} enumeration
and, to take advantage of Illustra SQL features,
replaced the following SAIF types with Illustra types:

\begin{itemize}
\item   The Illustra {\em Pnt} type replaced the SAIF {\em Point} in 
        {\em positionOfOrigin}.  {\em Point}, intended for single points,
        carries ancillary information for each coordinate that would be 
        redundant for the large amounts of point data in some Sequoia data 
        sets.  The Illustra {\em Pnt} is composed of the pair of coordinate 
        values and supports spatial searches.
\item   The Illustra {\em Box} replaced {\em minPoint} and
        {\em maxPoint} in {\em BoundingBox} to take advantage of
        Illustra spatial search capabilities.
\item   The Illustra {\em image} type replaced the primitive type in 
        {\em contentValues}.  {\em image} is a fully typed large object 
        with supporting functions that allow manipulating data directly 
        from SQL.
\end{itemize}

\vspace{5 mm}
\small
\begin{tabular}{|lll|}
\hline
\multicolumn{3}{|c|}{Figure 1: SQL for SAIF Types}  \\ \hline\hline
\multicolumn{3}{|l|}{create type GridReference}                    \\
(&  ordering              & GridOrder,                             \\
&  originCorner          & OriginReference,                        \\
&  cellPostitionAtCorner & boolean,                                \\
&  originCoordinates     & arrayof(integer) );                     \\
\multicolumn{3}{|l|}{create type GridFramework}                    \\
(&  gridDimensions        & arrayof(integer),                      \\
&  gridSpacing           & arrayof(double precision),              \\
&  offsetStructure       & OffsetStructure,                        \\
&  unit                  & arrayof(UnitMeaning) );                 \\
\multicolumn{3}{|l|}{create table Grid}                            \\
(& positionOfOrigin       & Pnt,                                   \\
& orderAndOrigin         & GridReference,                          \\
& spacing                & GridFramework );                        \\
\multicolumn{3}{|l|}{create type ContentStructure}                 \\
(&  indexingScheme        & IndexScheme,                           \\
&  attributeNames        & arrayof(SatelliteBands));               \\
\multicolumn{3}{|l|}{create table StructuredData}                  \\
(& contentStructure       & ContentStructure,                      \\
& contentValues          & image );                                \\
\multicolumn{3}{|l|}{create type BoundingBox under Box;}           \\
\multicolumn{3}{|l|}{create type GeneralLocation}                  \\
(&  range                 & BoundingBox);                          \\
\multicolumn{3}{|l|}{create table Duration}                        \\
(&  startTime             & timestamp,                             \\ 
&  lengthOfTime          & integer);                               \\ \hline
\end{tabular}
\normalsize
\vspace{5 mm}

Figure 2, on the next page, shows the SQL statements that use the building 
blocks created in Figure 1 to create a sample raster table
and insert one row based on the sample AVHRR data in Table 2.

The following query finds all AVHRR images between October 1991 and June 1992 
for the Southern Sierra Nevada, ordering the results chronologically:

\vspace{2 mm}
\small
\begin{tabular}{ll}
select & startTime, contentValues from Raster\\
where  & sensor = `avhrr' \\
and    & startTime between \\
       & `1991-10-01 00:00:00' and `1992-06-01 00:00:00' \\
and    & Contains(range, `(-122, 35, -117, 38)') \\
\multicolumn{2}{l}{order by startTime;}\\
\end{tabular}
\normalsize
\vspace{2 mm}

With a constraint on time to eliminate nighttime overpasses,
this would perform the first Dozier query in Section 2.2.
This query could be simplified by replacing the {\em Contains} expression,
which requires the researcher to know the bounding box coordinates, 
with a user-defined SQL function that accepts a placename as a
parameter and looks up the coordinates automatically.
The next query uses such a function ({\em FindLocation}) and introduces
additional functions that would map the snow data ({\em MapSnow}) and find 
the image closest to a given date ({\em NearestDate}). 
The second Dozier query would look like this:

\vspace{2 mm}
\small
\begin{tabular}{ll}
select & MapSnow(contentValues) from Raster\\
where  & sensor = `landsat' \\
and    & NearestDate(startTime,`1992-04-02 00:00:00') \\
and    & FindLocation(range, `Bubbs Creek');\\
\end{tabular}
\normalsize

\vspace{5 mm}
\small
\begin{tabular}{|lll|}
\hline
\multicolumn{3}{|c|}{Figure 2: SQL for Raster Create and Insert} \\ \hline\hline
\multicolumn{3}{|l|}{create table Raster}                              \\
(& \multicolumn{2}{l|}{sensor varchar(20),}                            \\
 & \multicolumn{2}{l|}{satellite varchar(20),}                            \\
 & \multicolumn{2}{l|}{bands integer)}                            \\
\multicolumn{3}{|l|}{Grid, StructuredData, GeneralLocation, Duration;} \\
&                  &                                                   \\
\multicolumn{3}{|l|}{insert into Raster}                               \\
(& \multicolumn{2}{l|}{sensor, satellite, bands,}                      \\
 & \multicolumn{2}{l|}{positionOfOrigin,}                              \\
 & \multicolumn{2}{l|}{orderAndOrigin,}                                \\
 & \multicolumn{2}{l|}{spacing,}                                       \\
 & \multicolumn{2}{l|}{contentStructure,}                              \\
 & \multicolumn{2}{l|}{contentValues,}                                 \\
 & \multicolumn{2}{l|}{range,}                                         \\
 & \multicolumn{2}{l|}{startTime,}                                     \\
 & \multicolumn{2}{l|}{lengthOfTime) values}                           \\
(& \multicolumn{2}{l|}{`avhrr', `noaa-11', 10,}                        \\
 & \multicolumn{2}{l|}{`(-2050000, 7520000),'}                           \\
& \multicolumn{2}{l|}{GridReference(`rowOrder', `ne', `f', `[0,0]'),}    \\
& \multicolumn{2}{l|}{GridFramework (`[2889,4587]', `[1000,1000]',}      \\
& \multicolumn{2}{l|}{\indent `none', `[metres,metres]'),}               \\
& \multicolumn{2}{l|}{ContentStructure(`sequentialArray',}               \\
& \multicolumn{2}{l|}{\indent `[chan1, chan2, chan3, chan4, chan5, ndvi,}\\
& \multicolumn{2}{l|}{\indent satellite\_zenith, solar\_zenith,}         \\
& \multicolumn{2}{l|}{\indent relative\_azimuth, pixel\_source\_date]'),}\\
& \multicolumn{2}{l|}{`/data/f9101046',}                                 \\
& \multicolumn{2}{l|}{`(-119.9722899, 23.5837576,}                       \\
& \multicolumn{2}{l|}{\indent -65.3946489, 46.7048989)',}                \\
& \multicolumn{2}{l|}{`1991-01-04 00:00:00',}                          \\
& \multicolumn{2}{l|}{14);}                                            \\ \hline
\end{tabular}
\normalsize
\vspace{5 mm}

Finally, we note a few flaws in our prototype:

\begin{itemize}
\item More band information is available than the name we stored 
in {\em attributeNames}.
While band information for a given sensor is static, new bands may be 
added by researchers. 
We should create a new SAIF type that completely describes each band.
\item We need to implement the SAIF {\em SpatialReferencing} type
to manage projections.
\item We broke some rules by ignoring the supertypes the SAIF {\em Raster} 
inherits.  The next iteration should incorporate high-level SAIF constructs.
\end{itemize}

\section{Metadata Maintenance}

This section returns to the metadata categories described
in Section 2, discussing how
each is maintained and to what degree maintenance can be automated.

\subsection{Raster} 

We can automate raster metadata extraction and insertion into the 
database easily if the raster is in a standard format, such as netCDF.
UNIX scripts extract the header information and form the SQL insert statement.
If a raster is derived from another raster, for example a region is clipped 
and produces a new raster with different dimensions, the clip function can 
register the new grid information.

\subsection{Data Lineage} 

We insert and maintain lineage information at the raster level 
with Illustra database rules that capture processing information and insert 
it into lineage tables.
For example, the SQL statement that inserts a raster also triggers
an insert into the lineage table to describe the creation.
If a calculation is performed, information about any source raster(s) 
along with the function and parameters passed to the function must be tracked. 
Versions of the function (or program) that was applied must also be tracked.
%% Audit trail tracking and analysis can become arbitrarily complex, 
%% especially if data are distributed across multiple systems.

Lineage must also be tracked at the sub-raster level and
we are considering strategies for storing lineage for each pixel or 
for groups of pixels.
One option is to simply add another band to the image like the AVHRR sample 
data set did.  Section 2.2 described how a composite image was produced 
by storing the ``best" pixel from a series of images, with band 10
storing the source of each pixel.
The most inefficient option would be to store lineage information for each
pixel as a separate row in the table. 

\subsection{Data Set Description}
Entry and maintenance of high-level metadata is labor-intensive and challenging 
to automate.  Currently, data catalog ``inventories" require manual
intervention to evaluate and insert the information into the database 
and define a set of keywords for searching.  
But most researchers do not have 
sufficient time to provide comprehensive details for a data set. A hierarchical 
approach to metadata management is important, requiring a small set of
information at the top that gives researchers an entry point from which they
can query for optional details the data provider is able to supply.

Text-based systems will become increasingly important to automate
metadata entry of data set descriptions.  For example, the GIPSY [13] 
prototype automatically extracts geospatial information from text documents. 

\subsection{Object Descriptions} 

Entry and maintenance of object descriptions can be partially automated,
first by taking advantage of database system catalogs that maintain 
base information about all user objects.
An ancillary object description table stores additional detailed information.
Wherever an object is adopted from a standard, it is possible 
to load its description from electronic documents provided by the custodian 
of the standard.
Of course, any user-defined objects depend on the user to provide descriptions.

We are developing database schema tools that merge information from the 
system catalogs and object description table, and output object 
information in a variety of formats.
Initially we have focused on extracting the information to output
create statements for an object or set of objects.
However, the same information could be output in a different format, 
such as an FGDC metadata description file.  

\section{Conclusion}

The design goals of the Sequoia 2000 schema 
are to provide researchers with schema 
building blocks to create application-specific schemas and a
metadata infrastructure that supports generating data files in a 
variety of scientific formats.

We described a strategy for developing a database schema based on geospatial 
data standards to support these goals.  Sequoia can accelerate development
by drawing what it can from the available standards and extending them as 
needed to satisfy earth science requirements.
%% We were surprised by how long it takes to come up to speed on a
%% standard, yet appreciate that this approach is not as time-consuming as 
%% designing a schema from scratch.
The key challenge we foresee is transferring user-defined extensions
between different data models without losing information and, in particular,
extending the underlying data model that provides the transformation services.

Finally, we described how metadata are used and maintained. 
We are able to automate maintenance for all metadata categories to a degree, 
except for high-level data catalogs. Since they will be broadly accessed,
they need more automated entry.  

While this paper focused on management of satellite images, Sequoia 
schema development addresses the broader needs of earth science data.
Many of the metadata elements discussed in this paper also apply to 
other gridded, georeferenced data.

\vspace{5 mm}
\noindent {\bf References}

\noindent [1] Stonebraker, M., ``An Overview of the Sequoia 2000 Project,"
{\em Proc. 37th~IEEE~Computer~Society~International~Conference: COMPCON-92,}
San Francisco, CA, Feb. 1992, pp. 383-388.

\noindent [2] Dozier, J., ``How Sequoia 2000 Addresses Issues in Data and 
Information Systems for Global Change," Sequoia Technical Report 92/14, 1992.
Additional information provided by J. Dozier via e-mail.

\noindent [3] U.S. Geological Survey, 
``The 1991 Conterminous U.S. AVHRR Biweekly Composites,"
README file from the CD-ROM, EROS Data Center,  U.S. Geological Survey,
Sioux Falls, SD.

\noindent [4] Lillesand, Thomas M., and Ralph W. Kiefer,
{\em Remote Sensing and Image Interpretation,} John Wiley \& Sons, Inc.:
New York, 1987.

\noindent [5] Stonebraker, M., J. Chen, N. Nathan, C. Paxson, and J. Wu,
``Tioga: Providing Data Management Support for Scientific Visualization
Applications,"
Sequoia Technical Report 93/29, 1993.

\noindent [6] Kochevar, P., Z. Ahmed, and L. Wanger,
``An Intelligent Assistant for Creating Data Flow Visualization Networks,"
Sequoia Technical Report 94/52, March 1994.

\noindent [7]
Surveys and Resource Mapping Branch,
``Spatial Archive and Interchange Format: Formal Definition Release 3.1,"
Province of British Columbia, Ministry of Environment, Lands and
Parks, April 1994.

\noindent [8] ``Content Standards for Digital Geospatial Metadata,"
Federal Geographic Data Committee, Washington, D.C., June 8, 1994.

\noindent [9] Buehler, Kurt, ed.,
``The Open Geodata Interoperability Specification," Version 1,
October 1994, The Open GIS Foundation, 1 Kendall Square, Suite 2200,
Cambridge, MA.

\noindent [10] Rosenthal, Arnon, and David Reiner,
``Tools and Transformations--Rigorous and Otherwise--for Practical
Database Design,"
{\em ACM Transactions of Database Systems,} Vol. 19, No. 2,
June 1994, pp. 167-211.

\noindent [11] Bright, M.W., A.R. Hurson, and S. Pakzad,
``Automated Resolution of Semantic Heterogeneity in Multidatabases,"
{\em ACM Transactions of Database Systems,} Vol. 19, No. 2,
June 1994, pp. 212-253.

\noindent [12] Sciore, Edward, Michael Siegel, and Arnon Rosenthal,
``Using Semantic Values to Facilitate Interoperability Among
Heterogeneous Information Systems",
{\em ACM Transactions of Database Systems,} Vol. 19, No. 2,
June 1994, pp. 254-290.

\noindent [13] Woodruff, Allison Gyle, and Christian Plaunt,
``GIPSY: Georeferenced Information Processing System," 
Sequoia Technical Report 94/41, March 1994.

\end{document}

