PRINCIPLES FOR A NEW EDITION
OF THE DIGITAL ELEVATION MODELING SYSTEM SCOP
L. Molnar
Institute of Photogrammetry and Remote Sensing, The Vienna University of Technology, Vienna, Austria
ISPRS Commission IV
Abstract:
DEMs as information (sub)systems storing vectors, raster, image pixels, and attributes. Communicating with other
databases, and accessing DEM information, via (TOP)SQL. Treating topology in terms of relationality; dealing with
true three-dimensionality. Main functions. Combining vectorial algoritms with those of raster geometry. Patchwise
processes with stages varying locally. Controlling DEM processing via object oriented programming in a multitasking,
and eventually distributed system. Machine independent base modules. Modes for real-time processing, sub-system
(slave or driver) mode, batch processing mode. Employing parallel programming including massive parallelity.
KEY WORDS: Digital Terrain Models, System Design
INTRODUCTION
A university institute has the two interconnected tasks
of teaching and of research. A new dimension has been
added to these tasks by some leading personalities of
the academic world of photogrammetry, in the first line
by Prof.Dr. Ackermann at the Stuttgart University,
followed by Prof.Dr. Kraus at the Vienna University of
Technology, and by many others. According to this new
dimension, results of recent university research are
made commercially available to the world of production
in the form of computer programs or modules - rather
than just as theoretical papers and research reports.
These programs should have the merit of applying new
technological methods. They can hardly be, however,
on the level of versatility of the available commercial
products. Recently, in view of some major
developments in computer science, the contrast
between merits and disadvantages of such research
programs became by far too large - concerning, in the
first line, object oriented design, graphical user
interfaces, interactive graphics, etc.
Current versions of the digital elevation modeling
package SCOP' represent a splendid example of the
aforementioned contrast. Therefore, and to refine the
package in many other respects, work has been started
on creating a new, open frame to hold some of the
current modules and all future ones. Principles proposed
for this architecture constitute the subject of this paper.
At the time of this writing, these principles are not yet
approved in any way as final. In many points, they
represent but a personal view.
THE "CLASS-ORIENTED" PROGRAM ARCHITECTURE
Sought is a highly modular, easily extendable
architecture to be implemented on most major
platforms, to combine some existing modules with the
new ones, and to be controlled, on the one hand, by
graphical user interfaces, and on the other - in batch
mode, on mainframes, or just as an option - by
command language.
The existing source of SCOP and of related programs
represent up to 200.000 lines of proven FORTRAN
code, one through ten years old. Three quarters of it
' INPHO GmBH, Stuttgart, and Institute of
Photogrammetry and Remote Sensing (IPRS) of the
Vienna University of Technology
962
could and should - indeed: must - be rescued.
Due to its FORTRAN-centered, cross-platform
programming expertise, the SCOP team is by now
extremely proficient in creating new modules to the
existing system. The price of giving up this expertise all
together could be, | am afraid, about one year per
programmer. So let's examine concisely whether there
is sufficient technical reason to do so.
There are two major recent developments in computer
programming affecting the application of FORTRAN:
first, the increasing necessity to address different
software and hardware resources such as graphical user
interfaces (GUIs), graphics libraries, external databases
(embedded SQL, GIS), or additional hardware. The
problem is not just that FORTRAN does not provide any
standard means for such purposes. More importantly,
different libraries, device drivers, software kits, and the
similar are nowadays supplied for C only. These
problems are then usually solved by mixed language
programming.
The second point concerns object oriented
programming. It facilitates a deeper reaching modularity,
a way of thinking coming much closer to that of the
user, it yields a highly modular and highly extendable
architecture, and it may aid greatly the transition to
distributed and parallel computing. On a fine-grained,
SMALLTALK-level, with object oriented operating
systems and compilers for all major platforms, and with
widespread processor support, distributed intelligence,
and parallel processing - on this level, object oriented
programming is not yet with us. For this, | think, even
developers have to wait for maybe five years. However,
a hybrid solution with a large-grained object structure
mixed with procedural parts is rapidly gaining
importance: the C++ solution and the similar ones,
based on structures designated as c/asses to
encapsulate both data and the methods (algorithms)
operating on them.
Externally, a (complex) class controlled by messages
resembles very much a (small) program controlled by
directives of a command language. (Small) programs
can thus be considered and employed as some common
denominator between classical procedural programs, on
the one hand, and (complex) classes of a C+ + type
object oriented program. As parts of an integrated
system, such programs could be termed processes. This
expression emphasizes dynamic so much that for most
of us it is hard to think of a process as of data, with the
code integrated. So after rejecting a series of terms
(e.g. complex object, or just complex),| found the name
autonomous class to suit best. An architecture then,
integrating such classes, will be termed a class-oriented
PRAY —— AR
"A f. NN
AY ™ “FY f^ fs
-— rn f. —— 1]
‘A NPA + M TR A ™ (A 08 TO 08 (à OY SS
— (S m fA | 9 e e CA TR IN ~~
— 0 £7» fA CU AA SS A
ci
