Concepts

Concepts

Below please find a first draft of the concepts and/or issues of incremental updating and versioning, which we identified at our workshop on 4-5 August 2001 (Beijing, China) and revisited at our workshop on 14-15 October 2002 (BKG, Frankfurt a.M., Germany).

Second draft of the concepts of incremental updating and versioning

15 October 2002

The International Cartographic Association's (ICA) Working Group on Incremental Updating and Versioning held its third meeting in Beijing, China, from Saturday 4 to Sunday 5 August 2001, which was its second joint workshop with the International Society for Photogrammetry and Remote Sensing (ISPRS), on Incremental Updating and Versioning of Spatial Data Bases. As this is a new field of research, one of the outputs of this workshop was this first draft of the concepts and issues of incremental updating and versioning. At the Joint ICA/ISPRS/EuroGeographics Worksop, held at the BKG Headquarters, Frankfurt am Main, Germany, it was decieded to join groups 1 and 2 and to discuss these issues, by e-mail, throughout the year toward the Durban meeting, planned for August 7-10, 2003.

The Working Group will now refine these further, with the aim of producing a book for the 2005 ICC in Spain.

The concepts and issues identified at the Beijing Workshop were grouped into eight categories. Categories 1 and 2 were agregated together before resolving to discuss the issues by mail, as follows::

1. Dating and Versioning issues

2. ~~Versioning issues~~

3. Standards issues

4. Economics issues

5. System maintenance issues

6. Administrative organisation issues

7. Quality control issues

8. Modelling issues

9. New issues

1. Dating issues

1.1 Versioning vs time as a coordinate

1.2/5.8 What about legacy data sets? (updating backwards)

1.3 Future history as well as past history!

1.4 Temporary updates

Up Page

2~~. Versioning issues~~

~~Versioning vs time as a coordinate~~

1.5/5.7 How does one deal with temporary versions? (which are kept until one has better versions)

~~What about legacy data sets? (updating backwards)~~

1.6 To which version of the base data is an end user referring? Users don't necessarily refer to the same one.

1.7 Need to support superseded database schemas

Versioning

~~Temporary updates~~

Up Page

3. Standards issues

3.1 A language for IU&V

3.2 Standards for IU&V

3.3 Standard language

3.4 Standardised data model

3.5 Minimum level of correctness of data to be able to do updating

3.6 Where should GPS points be collected for a building (entrance, corner, driveway, etc)?IHO's event updating - what standards do they use?

Up Page

4. Economics issues

4.1 Where is the benefit if map updating using a GIS takes longer than manual updating?

4.2 Need an after-sales service to ensure the users understand how base data are being provided Capture once, use many times.

4.3/5.3 Capture once, use many times.

Up Page

5. System maintenance issues

5.1 Need to be able to re-supply an object as it was originally supplied

to the customer.

5.2 Cartographers producing maps vs GISers producing data bases

5.3 Capture once, use many times.

5.4 Distribution of alternate spatial attributes updated in parallel?

5.5 Multi-step process for updating and distributing updates

5.6/7.7 Secondary updating

5.7/1.5 How does one deal with temporary versions? (which are kept until one has better versions)

5.8/1.2 What about legacy data sets? (updating backwards)

Up Page

6. Administrative organisation issues

6.1 Who has the authority to make updates?

6.2 At medium scale, cartographers update manually faster than the GISers update GIS

6.3 Legal issues of manual updates and database updates

Up Page

7. Quality control issues

7.1 Perhaps need a detector for updates happening too frequently (indicating a problem)?

7.2 Defect management (audit trail of changes)

Should one fix errors in superseded data?

7.3 Need an error-free data base to enable fully automated IU&V

Can't send errors!

Automated quality control procedures

Can expedite the updating process

7.4 Correcting data before updating

7.5Quality control

7.6 Multi-step process for updating and distributing updates

7.7/5.6 Secondary updating

Up Page

8. Modelling issues

8.1 Log the old value as well as the new value

8.2 Some operators make more mistakes than others

8.3 Source codes (system, instrument, operator, date, etc)

8.4 Operator resistance to monitoring

8.5 Can end up with more metadata than data!

Not so bad if metadata recorded automatically

8.6 Photogrammetric data capturing and updating takes place in 3D, but the data base

invariably is in 2D

8.7 Overloading identifiers

8.8 Supporting spatial topology across the temporal dimension

8.9 Maintaining integrity of data/relationships through time

8.10 Database and real-world time

8.11 Object life cycles

Maintain objects for as long as possible

8.12 With a large, seamless data base with parallel updates, topology needs to be

restored/rebuilt locally after updates

8.13 Transparent/administrative (dynamic) tiles?

8.14 How should we deal with address error?

8.15 Compound features need to be updated when components are updated

8.16 Map update vs database update

8.17 No one perfect solution

8.18 Set of models

8.19 Incremental updating

2D, 3D and/or 4D

8.20 Spaghetti or topologically structured data?

8.21 Standardised data model

8.22 Incrementally correcting data

8.23 Updating data that does not meet the standard of the basic data

8.24 Mapping to a better standard

8.25 Point information provided with indirect references (% along arc, street number)

8.26 Hierarchical vs sequential vs regional vs thematic vs layer vs etc

8.27 Cartographic rules (freehand, cartographic generalisation) vs database rules

(geometric accuracy)

8.28 Alternate spatial attributes

Master layers and cartography layers

8.29 Maps for presentation vs databases for analysis

8.30 Need to add more models to the data base

8.31 How much topology must be built explicitly?

8.32 When does one integrate new features into the existing topology?

8.33 Temporary updates

Further concepts and issues were identified during the second day of the workshop, but these have not been grouped into categories:

Up Page

9. New issues

9.1 Standardised transfer models

9.2 Recommendations for vendors

9.3 Users may make recommendations for producers, and vice versa

9.4 Education, implementation, guidelines, assimilation/absorption

9.5 A way of explaining to one's boss what one needs to get the budget!

9.6 Expectation management (up and down)

9.7 Expectation management (up and down)

9.8 Most users use different software from the producers

9.9 Unique Ids

9.10 Geocoding? Error detection?

9.11 Error recovery of identifiers after system crashes

9.12 Different semantic interpretations of the same object at different scales

9.13 A position is unique depending on the scale and the accuracy with which one

can measure them

9.14 Maybe we need a questionnaire on unique IDs to use?

9.15 Sharing unique Ids with other organisations and countries

9.16 Authentic registration

9.17 One authority to ID and maintain a particular type of data

9.18 Automatically repositioning old data

Switzerland is testing this for their 1:25k

9.19 Interdepartmental rivalry!

9.20 There are no heavens in the world, only partial heavens!

9.21 Privacy

9.22 Does one sell updates, does one have an annual licence, does one give them for free,

etc?

9.23 Standards are not readable, they need to be made simpler

CEN vs ISO/TC 2 vs OGC vs proprietary vs ???

9.24 Publishing our material in other languages, especially in Chinese

Up Page

For more information, please contact the co-chairs of the Working Group :

Antony Cooper

icomtek, CSIR

PO Box 395, Pretoria, 0001, South Africa

email: acooper@csir.co.za

Telephone: +27 12 841 4121; Facsimile: +27 12 841 4720

Ammatzia Peled

Department of Geography, University of Haifa

Haifa, 31905, Israel

email: peled@geo.haifa.ac.il or: rjb@rjb-3d.com

Telephone: +972 4 8 240 148; Facsimile: +972 4 8 249 605

Up Page