Surface Exploration and Analysis is to become a major 
group of methods of the class 'DTM Surfaces'. Applying 
these methods, the user should be able to find optional 
ways of surface representation in problematic areas, 
and to convince himself and others about the quality of 
it. "What-if" Analysis should enable him to apply 
different algorithms to the same set of tiles and to 
compare results numerically, analytically, and visually, 
e.g. by viewing shadows or shading in oblique light. 
Different methods of Quality Analysis should be at the 
user's disposal, e.g. transient and local data 
transformations (translation, rotation) to check on 
isotropy. 
Algorithm Sub-Classes are to be very independent large 
black boxes logically encapsulating data for a tile of the 
surface, local co-ordinate systems, (a combination of) 
interpolation algorithms, private surface representation 
(e.g. hexagonal tiling, or analytical forms), functions to 
service inquiries concerning this surface (z, components 
of f' and f" at a given location, the isoline at a given 
elevation, ray tracing, etc.), and in some cases even 
hardware (e.g. on a board). They should employ 
parallelity in their co-operation with each other (tiling), 
and with the Database Management class. 
Multithreading may be pursued (e.g. reading the data 
stream and setting up equations or matrices). 
Modules realizing the linear prediction algorithm in the 
current version of SCOP can be adapted to become one 
of the algorithm sub-classes of the new edition. 
Algorithms should fulfill, at least in co-operation, many 
requirements. Concerning data types, they should 
operate on points distributed at random and be able to 
deal with large variations in data density. They should 
exploit additional information carried by special data 
such as breaklines and structure (form) lines, both with 
or without elevation, contour lines, highs and lows. If 
possible, geometric information provided explicitly (e.g. 
normal vector components) should be used. 
Concerning quality, filtering of noise in data should be 
solved adequately. Attributes to each data element 
carrying a-priori accuracy characteristics should be 
taken into account. Outlier analysis (blunder detection) 
is important. However, an automatic blunder elimination 
should be avoided (Wild, 1983). Algorithm sub-classes 
should provide spatially distributed a-posteriori quality 
characteristics. 
Concerning the mathematics applied, algorithms may be 
widely different. There will be a series of vectorial ones, 
such as the linear prediction mentioned (Assmus, Kraus, 
1974). Solutions belonging to raster geometry will 
follow; they may rapidly gain importance - special 
hardware for them is on its way to become standard on 
PC-s, due to the growing interest in multimedia 
technology (array processors: Next Station, IBM PS/2, 
Apple Macintosh; massive parallelity may follow). To 
this realm belong neuronal nets with heuristic solutions, 
or, more realistically, systo/ic arrays. Hybrid algorithms 
may exploit advantages of both worlds, combining, for 
instance, the topologic capabilities of systolic arrays 
with the numeric precision of vectorial solutions. 
The DTM Sub-Class 'Special Enclaves' 
with Analytic Surfaces and 3-D Objects 
Applying true 3-D algorithms all over a DTM places 
tremendous burden on most computer resources and 
therefore they should be used only when and where 
inevitable. Terrain canopies, sometimes even vertical 
walls, and 3-D objects scattered over the surface 
966 
represent problems for "2,5 D" solutions defining 
locations just by a pair of (x,y) co-ordinates and carrying 
the third dimension (z) rather like an attribute of the 
point. Here, a hybrid solution is proposed, applying true 
3-dimensionality only within special enclaves surrounded 
by breaklines. 
As already mentioned, special enclaves are tiles of data 
with pre-defined "2,5" or 3 dimensional algorithms to 
operate on them. A growing choice of such algorithms 
should be provided, and identified by some names or 
codes to enable referencing them in data sets. 
Instances (data records) of this sub-class can be 
classified as: 
- data provided for the enclave to be approximated 
- by analytic surfaces such as a horizontal plane 
or a hyperbolic surface; 
- byrestrained surfaces such as minimal surfaces 
or such to fit river basins (Kalmar, 1991) 
- 3-D objects 
- terrain canopies, vertical walls, 
- 3-D constructs such as buildings or bridges. 
In the case of 3-D objects, a surface should be defined 
to represent, when needed, the continuation of the 
terrain surface passing the object. For this, the ways as 
used outside of the enclave should be used. Instead of 
defining the continuation surface, small enclaves can be 
coded as 'disregardable' for cases when the 3-D object 
is to be ignored (e.g. on a fast perspective view, or 
more characteristically, on an overlay with contour 
lines). 
In special cases, enclaves can become very large to 
carry, for instance, (parts of) a city model. For such 
purposes, complex software should be adapted and 
included in this system as another sub-class (Kager, 
Loidolt, 1989). 
Special enclaves should service the same requests as 
other algorithm sub-classes do. Additional options could 
become necessary in this respect, e.g. of providing the 
perspective image of the object according to 
specifications or providing special ways of access to the 
data for the purpose of editing them. 
Short Notes on Some Other Classes 
The class Graphics Sheets is to build up presentation- 
quality graphics stored, for the time of on-screen 
customization, as TOPDB tables. While frame 
composition is a direct task of this class, to fill the 
sheet with contents is via messages to other classes 
such as lsolines/Zones/Distributions, or Views. Upon 
such invocations, the user can interact with those 
classes. The graphics stored is then edited and 
customized by invoking the class 'Graphics 
Management'. 
Isolines/Zones/Distributions is an example of a class 
usually invoked from the class Graphics Sheets, it can 
however be invoked directly, as well. This second case 
becomes necessary when results are required in forms 
other than graphics output - e.g. as a stream or file of 
numeric values. 
The class Views is for vector and raster (pixel) type 
visualizations of the DTM including the input data, as 
well (e.g. a perspective view of the latter). The class 
should be capable of superimposing different 
visualizations where applicable (Ecker, 1991 and 
Hochstoeger, Ecker, 1990). 
DTi 
san 
infc 
infc 
ma 
the 
(Sic 
me! 
sec 
allo 
net 
a sl 
Exp 
of 
19% 
It i: 
diff 
fori 
DTI 
Slo 
visi 
(at 
vie 
cas 
sho 
of 1 
res, 
The 
diff