3. INTEGRATION 
The continuous struggle with (and often against) three or 
four related software systems so to integrate the best of 
their respective services into harmonous products is most 
typical of to-days production. Rather than offering some 
specialized service in perfect quality combined with flexible 
means of integration, practically all systems try to augment 
their central functionality by simple additions of their own - 
additions too simple to be sufficient for professional 
application. 
To a considerable extent, this is also true of us. Realizing 
this, the structure of XX itself, and of applications created 
using it, are made such so to allow for manysided ways of 
integration - the scale reaching from file interfaces at its 
traditional extreme to interface objects at the other extreme 
- that of distributed object technology. 
3.1 Interface Objects 
One of the most versatile means for interfacing different 
components is via interface objects. This is true for 
components integrated under XX, and also for components 
of the software environment to be integrated into 
production systems. 
Objects are data bundled with the methods operating on 
them. Interface objects are data to be exchanged bundled 
with the methods to perform import and export of them. In 
special cases further methods may be necessary such as 
answering inquiries, performing changes etc. Interface 
objects may be parts of a distributed object system, or 
they may be implemented as client/server components; in 
more traditional cases systems both on the import and on 
the export side will link (parts of) their methods and share 
or attach-and-release the corresponding database. 
Methods on both the import and the export side will carry 
driver-type functions capable of communicating with the 
system on that side. These functions will be written using 
means provided by the system - e.g. library functions to 
access proprietary databases and/or to interpret internal 
data representation. 
3.2 Replacing Components by Standard Systems 
Although not without considerable effort, it should be 
realistic to re-write the driver-type functionalities in SX, UX 
and/or GX so to arrive at a really seamless integration with 
the most important standard systems (such as Arcinfo, 
Intergraph MicroStation etc. ). Re-writing the display- 
drivers of UX with the corresponding display library of 
another system will result in a user interface appearing to 
the user as part of that system. In case of GX, replacing 
the entire graphics functionality by that of another system 
could be reached this way. Certain changes to the XX- 
internal data communication and to its contents will also 
become necessary for this level of integration. 
For this way of integration, most of the important software 
systems possess the necessary libraries to this date. 
These are in most cases traditional (procedural) libraries, 
sometimes with "callback functions". Integration will 
become much simpler with the standard systems and their 
libraries becoming object oriented. 
Replacing the database of SCOP (TOPDB) by other 
DBMS systems is handled next (paragraph 3.3). 
3.3 [TOP]SQL 
Internally, this version of SCOP is storing data on tables 
managed by the topological and relational database 
management system TOPDB [Lo91]. TOPDB is addressed 
by statements formulated in TOPSQL - a subset of 
standard SQL with additional topologic/geometric 
datatypes and operators. 
TOPSQL statements can be re-formulated in terms of 
standard SQL, yielding a slow but functioning solution for 
replacing TOPDB by standard RDBMSs. 
Much simpler and much more efficient is this same way for 
those RDBMSs capable to handle geometry and topology 
in special ways. Recently, ORACLE corporation released 
a special version of its RDBMS with such extensions. 
ORACLE databases are widely used in our profession 
anyway; this extension will, as we believe, strengthen 
ORACLEs position. So it becomes specially simple for us 
to create version(s) of SCOP based directly on ORACLE 
databases. 
3.4 Data Conversion 
There remains to state that traditional data conversion will 
long retain its importance in bridging the gap between 
application systems - and therefore, we can and will not 
neglect creating such "bridges". 
4. REGIONS 
4.1 (Irregular) Algorithm Tiling 
Starting with this version of SCOP, the terrain (or other) 
surface can be subdivided into regions (an expression 
suggested by Prof. Ackermann), or - as referred to in 
[M092] - into (irregular) algorithm tiles. There is more than 
one reason for this new organization of surface 
representation: 
- different regions of the surface may be so 
heterogenous in their character that they need at the 
very least different parameters of representing them by 
the same algorithm (this also includes such parameters 
as grid-step or computing unit size); but more than this: 
- regions with different character may need different 
algorithms better suited to their specifics; this can 
include special cases such as cement roads, areas to 
be interpolated as (horizontal) planes or as river bases, 
and so on; 
- regions with different ways of data acquisition requiring 
special interpolation algorithms - e.g. as contour lines 
digitized, profiling or grid measurements, etc.; 
- introducing computationally intensive algorithms such 
as the ones capable of true 3D is hardly feasible for 
large models; also, this is only necessary in specific 
areas. These can be declared then as regions; 
- providing for a much more flexible switching among 
different (competing) algorithms than it would be 
possible for the entire model - e.g. for purposes of 
experimentation by the user ("what-if analysis"). 
572 
International Archives of Photogrammetry and Remote Sensing. Vol. XXXI, Part B4. Vienna 1996