McGlone - 6 
which can be shown. 
One can imagine defining parametric models for a number of basic building shapes, 
but as the shapes become more complicated, they may need to be represented using 
CSG methods. Level of detail also is a problem, depending upon the resolution 
of the imagery—describing details such as overhanging roofs or complex facades is 
difficult or impossible. 
3.4. Model interchange 
Since there is more than one system in the world, we must be concerned with model 
interchange standards. There are three common approaches: 
Lowest common denominator Interchange only the information that is con 
tained in all representations. This always results in information loss for non-trivial 
models. 
All things to all people Design a superset of all possible representations. This 
may be mathematically elegant and even theoretically possible within a specific type 
of model, modulo specific assumptions, but is infeasible across a range of model 
types. Even representations based on the same type of model will have implemen 
tation assumptions which make exact translation into another system difficult or 
impossible. 
Pairwise interchange The most common strategy—write a translator for each 
initial and target system pair. 
There is no perfect solution among the three alternatives. Any practical (imple- 
mentable) interchange format will probably result in information loss between two 
systems which are more than trivially different, since interchange is not a question of 
syntax but semantics. Two different model types are saying fundamentally different 
things about the world, and these statements may not be directly translatable into 
each other. 
Instead, any system which produces 3D models must be concerned with data inter 
change when it is designed. Some principles which should be followed in designing 
an interchange format are: 
• All information should be either explicitly contained in the file, or else unam 
biguously refer to generally accepted definitions. For instance, the interchange 
file should explicitly name the datum to which it is referenced, if it is in com 
mon usage, but does not necessarily have to define that datum. Interchange 
files which give coordinates in some undefined internal coordinate system or 
describe objects in terms of internal data structures are useless, since the only 
way to implement a reader for the interchange file is to re-implement the entire 
system.