needed to
each data
it 3D data.
EM.
ge of both
juirements
juirements
ating will
should be
10V-GIS.
S is being
vey and
in 2006.
m several,
ygraphical
rocess. A
part from
“Top 10V-
' but more
All differ
| integrate
oplottine
nt images
ads more
ensing for
i-the-field
1e present
: 1:50.000
s valuable
computer
nand. The
also vary
goal is a
ngs and a
tabase.
EL
ed way. It
selection
riate data
ices to be
ng group:
c
International Archives of the Photogrammetry, Remote Sensing and Spatial Information Sciences, Vol XXXV, Part B4. Istanbul 2004
for answering the following questions we mostly based ourselves
on the experience of the persons whom we thank at the end of
this paper.
a) How should we produce change only updates for clients ?
* Which change metadata should be kept and on what level ?
One solution for producing change only is by automatically
comparing the data in the client's old database with the data in the
producer's present database, as developed by Beyen & Henrion
(1998) and by Badard (1999). IGN-France has continued in this
way, refined the programs, adapted the output format to GML2
and built a system around it for distribution through the web. This
method has many advantages: most important is that one needs
neither unique identifiers, nor change metadata. On the other
hand, this kind of software is not available on the market, so
NMA's have to develop it themselves and they have to provide
with upgrades whenever one of the underlying softwares is
upgraded.
The other, more classical solution for producing change only is
based on the use of unique identifiers and change metadata, as
developed by Galetto & Viola (1993, 1994) and Beyen (1994).
OS-England, TDKadaster-Netherlands and CIRB-Belgium are
amongst those who have chosen this solution. They differ in the
amount and the structure of the change metadata.
For several reasons, our project working group has chosen the
‘classical’ solution, with unique identifiers and change metadata.
We propose to only store change metadata that are necessary to
keep record of *who modified which part of the geographical
information, when and with what accuracy ?'(multisource). We
intentionally do not try to keep track of parent-child relationships,
nor of detailed geometrical operations (like partial delete, move
vertex etc.) Considering that the performance of the updating
procedure itself is much more important to us than the query time
for change only update data, we adapted the simplest possible
structure allowed by ISO19108, and like CIRB-Brussels (structure
indicated in bold in figure 1) we reduced the number of tables to
a minimum:
2 Tables
Active Old
Feature Type Feature Type
-ID -ID
-geometry -geometry
-attributes -attributes
-geom xy source
-geom z source
-attributes source
-geom xy source
-geom Z source
-attributes source
-load date -load date
-geom source -geom source date
date (optional) (optional)
-attrib source date -attrib source date
(optional) (optional)
rr -end date
-record number
Figure 1
The change only update data for customers can then be queried as
follows:
Add = the ID’s that appear only in the Active table
Mod - the ID's that appear both in the Active table and the Old
table
Del - the ID's that appear only in the Old table
(with end date > … )
743
If ever this solution shows not to work out as well as we hope
(e.g. due to errors in the timestamping, loss of ID’s, double use of
numbers, human errors caused by too complex procedures, clients
being unable to restore topology after receiving change only
updates, clients having modified the data structure ....) , we may
always turn back to the solution comparing databases.
b) Should priorities for performing operations on data be
modelled ?
Here we take the advice of Prof. Peled to do so. We should not
only follow the operations of the different updating operators, but
also manage them. We intend to make a hierarchy of groups of
operators for updating the geometry on the one hand and a second
hierarchy for updating the attributes on the other hand: e.g. for
identifying most objects a data classifier in the field should be
higher ranked than a stereoplotting operator, but for drawing the
right shape and position he should get a lower priority.
c) May updates automatically propagate to neighbouring
objects ?
We rely on Thierry Badard's experience and his advice not to
propagate updates automatically to neighbouring objects because
of the high risk of propagating errors as well. A semi-automatic
procedure is more appropriate.
d) Where and when do we need consistency checks ?
It is obvious that the consistency checks during the data loading
into the new database should be at least as severe as the ones
during the updating later. Otherwise the updating operators who
should concentrate on real modifications would be bothered by
error messages for old inconsistencies that could already be
solved before or by error messages due to unrealistic tolerances.
Hakima Kadri-Dahmani (2001, 2002) distinguishes 4 different
types of relationships (topology, composition, correspondence and
dependency) and 2 types of constraints that allow to identify and
solve conflicts (thematic and spatial constraints). We refer to her
work for a more detailed answer to the question above.
3. STUDY OF THE AVAILABLE DATA
3.1 The base map data
The first edition of the digital topographical base map is to be
completed in 2006, hence by then the first data will be 18 years
old. It would be considered as reasonable if we could perform the
first updating of the whole country in six years’ time. In that case
the data would in average be eleven years old at the moment of
their updating. It is beyond any doubt that in these conditions
stereoplotting is the most economical method for updating
(unless we obtain external update information that meets our
quality requirements). However, for updating by stereoplotting the
data have to be 3D.
We have two kinds of base map data at our disposal:
- 3D line = MicroStation design files, resulting from the
stereoplotting, with accurate 3D data that are roughly classified
but not topologically clean and not structured; these data represent
the situation of the landscape at the moment of aerial
photography; the parcel boundaries are often snapped to roof
borders, therefore their z-values are of poor quality, contrary to
the other elements.
- ToplOV-GIS = Arc Info coverages with data that have the
advantage of being topologically clean and completely identified
(with over 300 different codes) though that are 2D and a bit less
