metric
TeX is
nodels.
ulation
mation
kernel
lel and
nmars,
not be
levelop
a SyS-
spatial
tradic-
id tai-
proper
| used.
bal ap-
. They
nt, ac-
on be-
as tra-
tasks;
y and
nation
[TY
S, gen-
nge of
neters;
" ones;
wer to
anges,
ability
3 com-
ection
e pur-
design
2.1 Generality
Usually, in a same organization, there are several dif-
ferent groups involved in point determination tasks;
namely, the geodesists, the photogrammetrists, the
remote sensing specialists and the surveyors. There
is no difference whether referring to ppm, % of flying
height, um, or pizel; they all perform similar com-
putations to estimate position, orientation and other
parameters. For each group, there is usually a dif-
ferent software system as well. This redundancy, be-
sides being an increase in software costs, implies some
additional complexity in data transfers and commu-
nication between processes. The situation is even in
contradiction with the current evolution of technol-
ogy towards more heterogeneous systems and proce-
dures. Examples are the GPS supported aerial tri-
angulation, the convergence of digital photogramme-
try and remote sensing, and the democratization of
geodetic surveying with the advent of GPS.
Since the statistical, functional and structural ab-
stract concepts are the same for any set of obser-
vations —indeed, an elementary statement from ad-
justment theory—, the natural solution to the above
mentioned problems is the development of general
point determination systems. These systems are
built around general network adjustment programs.!
Credit for a remarkable and early realization of this
idea goes to A.A Elassal and his GALS software
system [8]. At the ICC the idea has been real-
ized through the development of the GeoTeX system,
whose heart is the general network adjustment pro-
gram ACX (see [4] for a first and short description
and application).
The above discussion related to generality can be
summarized in two items: a design concept and a
realistic goal set to be achieved in the particular im-
plementation of GeoTeX/ACX.
Design concept: definitions of observable, condi-
tion and parameter polymorphic abstract data type
must be available; any particular abstract type of ob-
servable, condition and parameter must fit the former
definition.
Realistic goal: that the system and the adjustment
program be able to handle any combination of obser-
vations of the geodetic, photogrammetric, SPOT and
D'TM-surface type (in a 3 dimensional space).
2.2 Adaptability
Some commercial and operational software packages
exhibit certain difficulties in keeping pace with tech-
lTn the photogrammetric literature general network adjust-
ment programs are usually referred to as combined adjustment
programs.
657
nological and scientific progress. This constitutes a
major inconvenience for users, specially for those in-
volved in continous testing of new instruments, pro-
cedures or models.2
Moreover, it is quite frustrating that advanced
users, perfectly aware of the mathematics of their
experiments, cannot extend the software to fit their
needs.
As in the former section, the above remarks lead to
the following design and implementation items.
Design concept: The user must be allowed to define
observable, condition and parameter new abstract
data types. (Actually, ACX has been developed in
this way by the authors.)
Realistic goal: that the addition of new models take
only the formal definition of the observable and new
parameters involved (definition of the particular ob-
servable and parameter abstract data types), the cod-
ing of the observation equations and their jacobian
matrix, and linking; that very limited knowledge of
the software be essential for the extension of the mod-
els.
2.3 Portability
Moving from one platform to another is unavoidable
for many reasons: different collaborating organiza-
tions might have different platforms, the optimal de-
velopment platform might not be the optimal produc-
tion platform, the optimal field platform (PC) might
not be the optimal office platform, the optimal plat-
form today might not be the optimal platform tomor-
row, etc.
Therefore, from the overall software architecture to
the programming habits, portability has to be a main
concern. It is a fact that highly qualified profession-
als waste too much time in transferring software to
different platforms and plotting devices.
A last observation is that contrary to classic al-
gorithmic programming languages, which happen to
have well established standards, Graphic User Inter-
faces (GUI) are troublesome for scientific program-
mers and analysts. Actually, GUI standards appear
to be competition weapons between manufacturers
(see, for instance, [11]) rather than tools to easy the
work of developers.
As before, two summarizing ideas are highlighted.
Design concept: define levels of interface complex-
ity, built upon the same data structures, in such a
7In the opinion of the authors, it is a misunderstanding
that operational software mean stiff software; and conversely,
that “flexible” research oriented software mean a poor user
interface.
