compose a more complex object. Some underlying
data are propagated from the components to the
composite object in terms of the identifiers or
the pointers. The data models including the
primitive elements, the simple and the complex
features are shown in the following diagram.
| Complex feature |
Simple feature rds.
2
UT ei Rm Ths
finie) tere) (ensem
008
x :
CML Sl. Mi, M2, - x ( (M1, Pointer } j
e reet et © S S ET
Fig.6 Data model based on unified data structure
The arrows in the diagram express the identifier
linking or the pointers in the data files, the
ellipses contain the most primitive data in GIS.
The diagram shows that the vector structures and
the raster structures do not have any obvious
distinctions because they use the same primitive
data format--Morton key (see Li & Gong, 1992),
which can guarantee that the unified data
structure serves the two kinds of data and
support object-oriented data model.
3.3 Encapsulation Approach
An outstanding characteristic is that the data
and operation of an object are encapsulated in an
entity, which is helpful for large software
design and database protection. It is also
required in GIS. Our system is designed with an
object-oriented program language C++, which
support encapsulation of data and functions,
besides the operations for creating, deleting,
modifying, displaying, it may contain various
spatial queries and analysis operations. If all
operations are encapsulated with data, it is not
efficient. A new strategy presented here is that
the operations acting on geometric data are
divided into basic ones such as
creating,deleting, modifying, displaying objects,
which are encapsulated in a class, and appendant
ones including query and analysis, which are set
outside the class. Program construction is
written by Turbo C*t in figure 7
Class: name Appendant operations
{ main()
values of type
public: common values
basic operations call basic operations
) call appendant operation
)
(a) Definition of
a class construction
(b) main program
Fig.7 program construction and
definition of a class
4 OBJECT-ORIENTED MODELS
FOR ATTRIBUTE DATA MANAGEMENT
716
4.1 Relational Approach and
Object-oriented Data Model
Relational database management system are often
used to manage attribute data in GIS. There are
many similarities between the relational approach
and the object-oriented model. The relational
model has to a certain extent semantic mechanisms
of classification, generalization, and
aggregation. In a loose sense, a table such as
Relation 1 represents a class of parcels. The
tuples in this table such as that for parcel I,
are objects of this class. Generalization can be
used when there is a need to store properties
common to several classes. For example, the
classes of parcels and highways can be
generalized by the superclass of spatial features
in Relation 6. An aggregation can model composite
objects from their components, Relation 2 implies
an aggregation relationship between a parcel and
its boundaries. A map composed of different kinds
of spatial features is also an aggregation.
However, the fact that they share common behavior
can not be deduced from the relational data
model, which is lack of inheritance implement. A
strategy proposed here is to integrate a object-
oriented language such as HyperTalk with a RDBMS
like Oracle, which manages attribute data in GIS.
4.2 Object-oriented Programming in HyperTalk
Object-Oriented Programming (OOP) is different
from the traditional approach like Pascal,
Fortran. In OOP, data and procedures that operate
on the data are together, packaged in something
called an object. There are five central ideas in
OOP: object, message, method, class, and
inheritance.
HyperTalk is a programming language for Apple
Computers. In HyperTalk, some key ideas are very
close to OOP. HyperTalk uses some of the same
terminology, adopts some of the same methods and
adapts others, and in many ways looks and "feels"
like OOP. But it is not a real object-oriented
programming language, so it is called Object-
Like Programming language.
4.2.1 Object As mentioned above an object is an
entity that includes data and procedures that
operate on that data. Viewed from a programming
standpoint, objects are the elements of an OOP
system that send and receive messages. In
HyperTalk, there are five types of objects:
stacks, backgrounds, cards, buttons and fields,
and they can be considered as the operations
"icon" or data "container". Like OOP objects,
each of these can send and receive messages. Each
type of object can also be associated with a
script that contains handlers, which correspond
to methods (as will be seen in a moment).
4.2.2 Message A message in an OOP world
corresponds to a procedure or function called in
a procedural language like Pascal. Everything in
OOP is accomplished in only one way: one object
sends a message to another object and the
receiving object reacts. In HyperTalk, the
messages can be held by five types of objects.
Each type of message can be addressed to one or
more of the types of objects encompassed by
HyperTalk. The objects In HyperTalk can also
receive the messages that are sent by using other
language like SQL.
Ge
st
phe
da
cl:
agt
ob,
cl:
ob;
prc
Ope
inl
anc