| 
|] 
i 
  
way that a minimal sufficient set of functionalities for 
professional work are guaranteed in case of a platform 
migration. For GeoTeX, three levels, 0, 1 and 2, were 
defined. 0 is the lowest interface level with essentially 
no tools other than those provided by the operat- 
ing system; 1 is the alphanumeric interface level and 
makes no other assumption than the ANSI standard; 
2 is the graphic interface level, most likely to degrade 
after a migration. 
Realistic goal: that the system and the adjustment 
program be able to run at least at the interface level 
1 (see Section 5.2 and Figure 2) in the three de facto 
standard operating systems in scientific computing, 
DOS, UNIX and VMS. 
2.4 Drawbacks of general approaches 
A known effect of design principles similar to those 
of the preceeding sections is the proliferation of soft- 
ware shells which slow down the execution of some 
processes. Since that increase in computing time is 
approximately linear, it can be absorbed by faster 
hardware. In other words, the extra time budget of- 
fered by the new hardware can —and should— be 
partly invested in more complex software architec- 
tures. (Note that time and space algorithmic com- 
plexity remain a problem.) 
The real danger of a general approach is that ei- 
ther a number of useful tailored functionalities may 
be lost or that irrelevant details for a particular sub- 
set of applications may burden the operation of the 
software. 
In this respect, the following design concept must 
be fully realized in the implementation. 
Design concept: generalization of concepts must 
be rigorous enough to make developers write tai- 
lored modules —always of an informative auxiliary 
nature— in rare ocassions only; privileged users like 
project or department managers must have the pos- 
sibility to customize the software by setting defaults 
and abling/disabling options. 
3 ON THE FORMAL STRUCTURE OF 
OBSERVABLES 
The idea of defining the formal structure of observ- 
ables and other elements participating in an adjust- 
ment dates back to the late seventies [15, 17] and it 
has been driven by the need for automation, either in 
the design of geodetic data bases [17] or in the design 
of adjustment systems [7, 14]. 
Probably, there is more than one approach well 
suited for the management and reduction of pho- 
togrammetric and geodetic data. Even for a given 
658 
data structure approach, there might be different 
complexity levels; for instance, the general data base 
might contain information irrelevant to an adjust- 
ment. 
For the sake of simplicity and because the GeoTeX 
data base is not completely defined a simple adjust- 
ment oriented point of view will be adopted. Then, 
the main data types are: observables, parameters, 
constraints and sensors (instruments may be called 
as well). The sometimes used term formal structure 
of observables, is nothing else than a rough expres- 
sion for the definition of abstract data types. The 
data type observable is defined in GeoTeX as 
<Pn...pi><8...8;><0a1...0 > 
(1) 
€ 01.5017 € C1... Cn 2 
where pi...p; are the identifiers of the parameters 
involved, s1...5; the identifiers of the instruments, 
a; ... a auxiliary information (meteorological, etc.), 
01 ...0; the actual observed amounts, and c; ... Cm 
some representation of the covariance matrix. 
The above definition is polymorphic in the sense 
that a particular observable data type is a particular 
case of (1). A photogrammetric observation data type 
would be defined as 
< P1P2P3 > < 81 > < 0102 > <C...>, (2) 
where p; stands for an image orientation parameter, 
po for a point, ps for a selfcalibration parameter, s; 
for a metric camera sensor, 0102 for the image coordi- 
nates, and c; ... for the statistical information. Last, 
a photogrammetric observation, i.e. an instance of 
the former abstract data type could be 
8623 132451 9001 2345.7 —92356.6 7.5. (3) 
A control point observable data type would look 
like 
«7 «0100903. 2 €& C12: (4) 
Analogously, the abstract data type parameter is 
defined in GeoTeX as 
«2| 2«41...0. 2 « 0$...00» «€... 2, (5) 
where the meaning of p1, à1 . . - Gk, 01 -  . O1, €] - . . Cm, iS 
clear. 
Constraint and sensor data type definitions follow 
the same philosophy. 
4 DATA STANDARDS, ABSTRACT 
DATA TYPES AND DISCRETE 
NETWORK MODELS 
It is necessary to differentiate three concepts used 
throughout the paper: data [transfer] standards, net- 
> 
ud Bu £u 
au