Newsgroups: comp.infosystems.gis
Date:         Fri, 24 Jul 1992 17:06:00 PDT
              <GIS-L@UBVM.BITNET>
From:         Chris Hermansen <clh@TFIC.BC.CA>
Subject:      Re: Object-Oriented DBMS and GIS
X-To:         GIS-L@UBVM.cc.buffalo.edu

Mike Goodchild writes:

>     In the NCGIA Core Curriculum on GIS, there is a unit
>     entitled "Trends in GIS" in which there is a comment that
>     some object-oriented database management systems (OODBMS)
>     may not be well-suited to GIS applications.  In
>     particular, some OODBMS are:
>
>     1. not well adapted to storing natural feature information,
>     2. not well suited to complex spatial analysis, and
>     3. often have embedded proprietary data structures
>
>     I understand the 2nd and 3rd points, but I'm not quite sure
>     about the first.  Is this referring to the problem of
>     representing continuous surfaces or large objects such as
>     raster images in an OODBMS, or something else perhaps?
>
>Since I (and Karen Kemp) did the final editing, here's my response.
>In brief, yes, I would argue that OODBMS are not well adapted to
>processing digital representations of fields.  When a TIN, raster,
>polygon network etc is used to represent a field, the objects which
>populate the database (triangles, pixels, polygons respectively)
>are artifacts of the representation and scale dependent.  Of course
>one can regard the entire representation as an object, and while
>that is useful for extracting windows from archives, it doesn't
>help much in modeling or analysis.  That's what I assumed Jack
>Dangermond to mean in his original version of that unit, and that's
>why I left the statement in as editor.

Without trying to be a pill, this doesn't help (me, at least).

OK, so I postulate a GIS dataset made up of "atomic" GIS data items.
For example, I have a TIN made up of triangles.  I'll grant you that
the triangles are indeed artifacts of the representation (in fact,
they ARE the representation), and I'll grant you that they are scale
dependent.

What is there about an OODBMS (any OODBMS) that makes it difficult to
use for implementing this type of data representation?

I would say that actually, OODBMS would facilitate implementing data
structures like TINs, since (a trivial example), they would permit
defining a persistant class called triangle with whatever methods were
necessary to fiddle it.  One could subsequently use these triangles as
part of an elevation model -OR- part of a polygon coverage, depending
on application.

The only obvious OO drawback I can see is the lack of a common standard
in query languages; I believe that the flexibility of OODBMS almost
precludes such (but I'm ready to be proved incorrect!)

A modest proposal (apologies to Darius' countrymen):

... some relational database management systems (RDBMS) may not be well
suited to GIS applications.  In particular, some RDBMS are:

1. not well adapted to storing natural feature information (because their
   speed of insertion is too slow for capturing data at high speed,
   because they do not generally support transitive closure in table relates,
   because they do not generally allow extensions to permit implementation
   of handy features like spatial indexing, etc)

2. not well suited to complex spatial analysis (again, the insertion speed
   problem for dealing with dynamically created data elements, again the
   issues of transitive closure and spatial indexing)

3. often have embedded proprietary file structures (like C-ISAM)

To this I would further add that most or all of these limitations are overcome
in Postgres, and that many are overcome in commercial products like I*, O*,
and S*.  Well OK not D* :-)

>
>There are further aspects of the context which are perhaps
>important.  This is a "Trends in GIS" unit intended to reflect the
>current state of the industry and where it might be going, rather
>than abstract ideals.  Hence while points 2 and 3 are true of many
>products currently marketed as "object oriented GIS", the unit does
>not attempt to deal with whether they are true of the abstract
>properties of OODBMS.  For example, it is true that in an abstract
>sense an OODBMS is extensible, but in practice current systems such
>as Postgres have embedded certain predefined extensions of SQL,
>such as search polygons.  Similarly, I'm open to correction here but my
>understanding is that while TIGRIS is marketed as an
>object oriented GIS, it is not extensible in the abstract sense.
>Unit 22 tries to explain the GIS interpretation of "object
>orientation" at greater length.  I think there's a good case for
>a new unit defining the abstract ideal of OOPS and OODBMS, and
>its significance for GIS.

May I point out that Postgres is in fact a relational database, NOT an
object-oriented one; that it uses a query language called Postquel, which
is an outgrowth of Quel, university Ingres' query language; and that it
not only comes with some builtin spatial stuff but also lots and lots of
ways to extend it (with type definitions, rules, operators and functions,
and so forth).  Not bad for a RDBMS with OO extensions, which (I think)
is Dr. Stonebraker's point - you can get many of the benefits of an
OODBMS while living in the relational world, which (perhaps not obviously)
also leaves you with most of the benefits of an RDBMS...

Geez!  I'm starting to sound like a huckster flogging Postgres.

Maybe what's really at issue here is that everyone is trying to climb aboard
the OO bandwagon, because it looks like a good marketing policy, and whether
they are in fact OO or not.  If TIGRIS is marketed as an OO GIS and it's not
extensible, then it isn't OO, either.

Can we agree that, at minimum, an OODBMS is an OO programming language with
persistence?

Is there also room to agree that the OO approach, namely, providing a
convenient way of binding together data types and procedures that operate
upon them, is not inimical to spatial processing?

Finally, if a salesman walks up and says "my GIS is based upon an OODBMS",
can we also agree that 1) he might be lying; 2) it might still be a crummy
GIS; 3) it might be the slickest thing since sliced bread for reasons
unrelated to its OO-ness; and 4) someone else may have a better product
written in COBOL and using MUMPS (OK, this is probably unlikely).

I would like to finish up by saying that I strongly believe that the potential
benefits of OO-tech do not preclude anyone from creating bad software from
it, just as good GIS software does not preclude anyone from creating lousy
maps.

Have a pleasant weekend!

Chris Hermansen                         Timberline Forest Inventory Consultants
Voice: 1 604 733 0731                   302 - 958 West 8th Avenue
FAX:   1 604 733 0634                   Vancouver B.C. CANADA
clh@tfic.bc.ca                          V5Z 1E5

C'est ma facon de parler.
Newsgroups: comp.infosystems.gis