You are using an outdated browser that does not fully support the intranda viewer.
As a result, some pages may not be displayed correctly.

We recommend you use one of the following browsers:

Full text

Systems for data processing, anaylsis and representation

difficult to retrieve an image by its name or
number(or other identifiers), but it may be for more
difficult to do it through selection criteria that
would be contained in the image. This may lead to
very long research, or even sometimes to tedious
image processing (e.g. for similarity retrieval).
This observation leads us to consider a more
powerful data model and processing methods that
can be used to handle large objects.
Before we discuss new data model and processing
methods that can be used to improve the system
performance on large objects handling, we need to
examine how users will make use of large spatial
objects in GISs. First, many queries are concerned
about the general information of large objects and
these can be classified as requests of meta-data,
i.e. information about large objects. The common
characteristics of this type of queries are that
queries touch a high volume of data, but the
generated answers are tiny by comparison. With
our model, it is not difficult to figure out that this
type of queries can be easily answered using DAD
or DRAD.
The second type of query is a kind of data mining.
Users try to query over a large set of objects in order
to find a small set of specific data. For example, a
user may want to find an image that has a certain
percentage of the snow coverage. This type of
queries does not require the exact and detailed
information, but instead requires the "overview" of
the special nature of a large object. In this case, low
resolution images with certain rules specified in a
query language to derive the required results are
possible solution for this purpose.
The third type of query displays a large spatial
object on a computer screen in order to do image
interpretation or image analyses. Due to the small
size of computer screen, only a very tiny part of the
large object can be displayed on the screen at a time
with the original data resolution. In this case we
can significantly improve the system performance
by windowing the image first and then only render
the small part of data on the screen. By buffering
the nearby part of the image, we can also perform
Zoom/pan in a very fast fashion. This can be very
significant when we compare to the case where the
whole image data needs to be read from a data
The fourth type of query is data browsing. Users
wish to perform data browsing because they are not
sure which type of data they are dealing with.
Class hierarchy or data base schema browsing can
be very helpful to the new users. Useful summary
information includes histograms showing data
statistical feature, images outline showing the
data extent and well-designed icons showing data
characteristics. For GIS applications it is our belief
that all these techniques are critical to the success
of GISs when they are used to handle large spatial
Before we present our new data model, let us
consider a simple example of a large image object.
The image is a Landsat image with DRAD such as
image dimension, the geographical location of the
image origin, the band number, the pixel precision,
the acquisition time, the control points used for
image geometric rectification, the parameters used
for radiation correction, the data quality, etc.. The
DAD data for the Landsat image may be its
histogram, classification result(a set of polygons
with category numbers), a two dimensional array
for the classification precision, a set of rules to
derive a certain theme (for example, a rule like:
"if a pixel value is large than 10 and less than 20,
then the pixel can be classified as water".) It is
difficult if not possible for the relational data
model to handle this non primitive data (e.g.
point, polygon, array), rules and data operation
methods. However, they can be well handle by an
object oriented data model [Zhou and Wilkinson,
1993]. In the above example, we could define an
object class Landsat image, with various
attributes to store meta-data, with methods to
present the correction models, and with class rules
to present the data classification rules[Hughes,
Two most often used methods to handle large
objects in object oriented models are: first, the
extended relational DBMSs use Abstract Data
Types(ADTs) to support large and unstructured
data such as images[Stonebraker, 1993]. It allows
users to define their own functions to manipulate
the ADTs. This method allows the system to be
extended, but leaves the extensions to its users. In
addition, the raw data is treated as unformatted
byte strings and very little semantic information is
maintained in the system. The second method
stores large objects in user defined classes, and
allows the data base administrator to define
methods and other attributes for classes[Deux et
al., 1991]. Usually both methods store raw data
using Binary Large OBjects(BLOB), and provide
the capability to store and retrieve them through
a query language.
In both methods the row data is treated as a whole

and no
users. ]
users mi
and clus
or opera
To mak
our dal
Using t
help us
the data
Many ci
to effect
as remo
DTM ai
with v
often re
objects r
In orde:
and ef
out lir
be opti
object -
1000 by
map) a
only a