4.3 Model subelements 
model-description defines a set of attributes that are 
needed to interpret the next subelements : a name, which 
is the name of the model, a user which defines the 
address where additional resources may be found, a date 
which is the date of creation or update of the model and 
three attributes (angle-units, ground-units, image- 
units) that define the units used respectively for angle 
measurements, for 3D coordinates or length 
measurements and for image measurements. 
orientation-list defines the list of coordinate systems that 
have already been calculated for this model. This element 
has a complex type consisting of an active-ref element 
which indicates the identifier of the last coordinate 
system that was in use when the model was stored, a 
bloc-factory element which enables the definition of a 
mapping between types of coordinate systems and java 
implementation (bloc-factory is optional) and an 
unbounded list of bloc-ref, i.e. singular or complex 
coordinate systems already calculated (see below). 
photography-list defines the list of photographs 
currently used in the model. Each photography is defined 
by an identifier (that must be unique in this list), a 
reference to a camera which is actually defined in 
another document and thus can be shared with other 
models in other projects and a reference to a file which 
defines the actual location of the image. 
point2D-lists defines a set of lists of point measurements 
made on the photographs. Each list of points holds a 
photo-identifier that defines the photography used to 
make the measures on (this photography must exist in 
photography-list, the list of photographs) and then an 
unbounded list of point. A point has a complex type, and 
several format will be allowed for convenience, see 
below. 
point3D-lists defines a set of lists of points that represent 
the 3D coordinates of the points obtained when building 
the model. There is no obligation to decide whether one 
point must or must not be in one of these lists rather than 
in another output of the project. Each list holds a ref- 
identifier that defines the actual coordinate system in 
which the points in the list are expressed, and an 
unbounded list of point. As previously said several 
formats are allowed for point and we will go in further 
details below. 
controlPoint-list defines an optional list of points that 
can be used as control points in order to calculate 
absolute orientation. A single list seems sufficient, but 
other requirements can make this changed. 
Finally, the block-list subelement is intended to provide a 
place holder for the definition of partially oriented 
models that use bundle block adjustment. A block-list is 
a list of block elements, each of them being defined by a 
block-identifier that uniquely identifies the block within 
the list, a sequence of identifiers referring to existing 
photographs and a block-orientation element. Each 
block-orientation element consists of a ref-identifier that 
refers to an existing coordinate system calculated with the 
data of this block and an unbounded list of point- 
identifier each referring to existing point measurements 
in at least one of the photographs of the block. 
4.4 Other main elements 
bloc-ref mainly consists in the definition of a coordinate 
system. It can be identified by attributes and holds a 
subelement that defines a 3D transformation. It can optionally 
contain a list of single ref elements that in turn define 3D 
transformations. Each of these single ref elements defines the 
transformation to be applied to express data in the coordinate 
system of the containing bloc-ref. For instance, a single ref 
element can define the transformation to be applied to points 
taken in a relative orientation to express them in an absolute 
orientation. This hierarchical structuring of coordinate system 
is not required since the list of single ref elements is optional, 
but it enables the storage of partially oriented blocks or the 
retrieval of all constructed coordinate systems during 
calculations occurring during the life of the model. More 
details will be available online 
(http://arpenteur.gamsau.archi.fr/ModelDefinition/index.html). 
As for point definition, several formats are allowed to define 
3D transformations: they can be defined from angles data 
(omega, phi, kappa), with matrix format or with one of the 
definitions given by the X3D draft specification. 
Several formats are allowed for point definition. The example 
below gives a good idea of these possibilities. These are 
respectively: with attributes for each field, with coordinates as 
a triplet of double values, with coordinates as an array (coma 
separated) of double values. 
  
Table 3 — Excerpt of point definition 
5. CONCLUSION 
We have presented how a photogrammetric project can be 
seen through the concept of Model and how this model can be 
formalized into an XML Schema. The purpose of this 
presentation was to propose such a schema to the 
photogrammetric community in order to leverage the ability of 
exchanging data and projects. This will be especially useful for 
works that imply data sharing between different teams that 
must cooperate. 
The Arpenteur project will provide an http site where 
interested individuals, teams or developers can find the 
complete ^ specification, useful tools to validate 
photogrammetric projects compared to the proposed schema, a 
java implementation of the model, a calendar defining steps to 
accomplish for the specification to complete and a mailing list. 
The interested individuals, developers or vendors should try to 
answer the following question: is there any possibility that 
would be expected in such a model and that is not covered by 
this 'description-specification' ? 
—352— 
Ref 
[Dr 
200 
Jou 
48-: 
Ref 
[Le 
com 
Ref 
[Ca 
Infc 
inte 
Vol 
aC 
[Dr: 
Dra 
"Fr 
doc 
Est 
Pots 
[Dr: 
Dra 
syst 
patr 
le 
17k 
octc 
sou: 
EDI 
362 
[Dr: 
met 
gen 
Inte 
Sep