Working Group on Incremental Updating and Versioning of the International Cartographic Association (ICA)

Minutes of Pre-Congress Workshop WS 13 of the XIXth Congress of the International Society for Photogrammetry and Remote Sensing (ISPRS)

Joint ICA and ISPRS Workshop on Incremental Updating and Versioning of Spatial Data Bases

Saturday 15 July 2000, RAI Congress Center, Amsterdam, the Netherlands

This workshop constituted the second meeting of the International Cartographic Association’s Working Group on Incremental Updating and Versioning, which was started during the 19^th International Cartographic Conference and 11^th General Assembly of the ICA, in Ottawa, Canada, in August 1999.  The workshop opened at 09:10.

Attendees:

Ammatzia Peled, Israel (Convenor, and co-chair of the Working Group)

Bengdt Rystedt, Sweden (ICA President)

Ferjan Ormeling, Netherlands (ICA Secretary General)

Joachim Bobrich, Germany

Josep Luis Colomer, Spain

David Danko, United States of America

Maxim Shoshany, Israel

Basheer Haj-Yehia, Israel

Paul Hardy, United Kingdom

Peter Hojholt, Denmark

Wing Kan Man, Hong Kong

Kira Shingareva, Russia

Patrick Vorster, South Africa

Kees Wevers, Netherlands

Antony Cooper, South Africa (Rapporteur, and co-chair of the Working Group)

The URL for the Working Group's Web site is: http:\\geo.haifa.ac.il\~icaupdt

After a brief welcome by Ammatzia Peled, Bengdt Rystedt gave the background to how the ICA works.  ICA Commissions fall under the auspices of the General Assembly and proposals to form a Commission need to be distributed at least five months before the General Assembly meets, which happens every four years.  ICA Working Groups fall under the auspices of the ICA’s Executive, who can establish them when necessary.  Bengdt emphasized the need for this Working Group to collaborate with other ICA Commissions and Working Groups (e.g.: Generalization), and with sister societies, such as the ISPRS.

The keynote address was made by Antony Cooper, who attempted to provide a framework for the deliberations in the workshop by identifying all the different aspects of incremental updating and versioning that need to be understood and that could be worked on by the working Group.  In particular, he highlighted the differences between the cartographer’s temporal domain and the data sets temporal domain.  The full text of his presentation is available on the Commission's Web site.

Ammatzia Peled spoke about processes they have instituted in Israel for updating their urban data base.  They produce automatically updating logs for each layer: sequence number, feature ID and operation code (adding, deleting, moving or splitting feature, or updating attribute table).  The log is used by managers for assessing how much work was done, so it does not link together changes, record who made the changes or time-stamp the changes.  The abstract and presentation materials are on the Web site.

After tea, Ammatzia Peled spoke about their 3D photogrammetric updating.  The mapping authority segments the data set into tiles rather than models, and the contracting photogrammetry company has to ensure that their updates integrate properly into the master data base.  A quality control module is run automatically to perform logical tests within and between layers.  In the incremental check module, all layers are compared to the original file extracted from the data base, some interactively, some automatically.  The abstract and presentation materials are on the Web site.

Joachim Bobrich made a presentation on "Fusion and Incremental Updating of Cartographic Generalized Data".  They have identified eight methods for generalization: selection, simplification, exaggeration, classification, typification, symbolization, aggregation and anamorphose.  They use generalization meshes (with linear features as the boundaries), and updates are then done within a mesh.  One only has to consider the impact of the changes on features in that mesh.  Currently, they have to implement any displacements manually, but they are developing a cost-based algorithm for determining how displacements can be done.  They now have a practical toolbox for generalizing.  They discard the new version of the data set once they have printed the paper map.

Peter Hojholt discussed parallel map systems, that is, maps that cover the same area with the same or different types of data.  TOP10K is the Danish national vector base map, with a five-year revision cycle by external subcontractors.  It has about 40 feature classes with strict topology rules and metadata for every point in the data base.  Topology is checked automatically, but completeness is checked manually.  Revisions are done according to the current specifications, and only differences are meant to be updated.  Feature identifiers are assigned only in house, to ensure consistency.  Contractors send the changed data, indicating with a “+” that the data should be added, or a “-” that it should be deleted.  The update for each separate layer has to be sent explicitly by the contractor, but where there is a XOR between layers (e.g.: high rise Vs low rise), they can update the other layer automatically.  With time, they will introduce updates based on the number of changes.  They could keep the changes in their data base, but they don't do so.  They record only the cartographer’s temporal domain, because it is too expensive to keep the data sets temporal domain as well as well.

After lunch, Paul Hardy gave an extended presentation of Laserscan’s products for implementing incremental updating and versioning, especially Gothic, their second platform, which is object oriented.  Real world entities are abstracted and held as objects, with classes, instances, inheritance and methods.  The data are encapsulated with their behaviour.  Gothic is strong in handling references from object to object.  They use object dataset versioning and long transactions to handle change through time.

The Gothic object lifecycle methods construct, modify or destroy object, or merge versions into mainstream.  Each object automatically validates its creation and so on, and triggers side-effects (reflexes), which are changes to other objects.  It provides an audit trail, so one can review all the changes made.  Gothic versions contain just the changes - like a transparent overlay on the original data.  With dataset versioning and long transactions, updates (may be done in parallel) are merged back into the mainstream at a later date, with conflicts being resolved interactively.  Gothic versions are stable and private and contain changes (e.g.: introducing a new class) to the schema as well as to objects.  The version tree can be compressed and backed up, and there is a tool for diagnosis and repair.  The updates are not just for the core data base, but are also used to provide users with updates.

Paul also discussed two of the International Hydrographic Association’s standards, S57 (which is very permissive) and the Electronic Nautical Chart (ENC) profile, which was defined to make it more practical.  Passing just incremental updates was part of the design of S57, through the Record Update Instruction (RUIN) to feature objects or spatial objects.  The updates are not cumulative, so all have to be applied and in the correct order.  The updates come from only one data owner, every week.  S57 uses ISO 8211, which adds complexity!

Finally, Paul discussed the Spatial Object Transfer Format (SOTF), which is based on XML and is being proposed to the Open GIS Foundation (OpenGIS).  GML is an XML encoding for real time access to geospatial data – it says what a feature is.  SOTF supports multiple inheritance and is for archiving data sets so that in years to come one can understand the data.  For incremental updating in SOTF, the level of granularity is the feature.  Features are tagged as new, modified or deleted.  The DTD for the schema describes the transfer format (identifies the tags), while the schema content describes what the object classes and so on are.  DTD allows for the description of data and checking the validity of tag names.

After tea, Kira Shingareva discussed the work of the ICA’s Planetary Cartography Commission, which she chairs.  They are producing a series of multilingual maps of the planets and their moons and a glossary for planetary cartography.  These are thematic as well as topographical maps - geology, geophysics, physical properties, morphology and climate maps.  The data from each mission to another planet is kept separately in its own data base.

The presentations and discussions highlighted what a crucial issue incremental updating and versioning is, but they also highlighted how poorly the subject area is understood, with participants having quite disparate views about what is meant by “incremental updating” and what is meant by “versioning”.  This emphasizes the importance of this Working Group and the need to clarify and define the terminology.

The following are a number of key insights provided by the workshop and key issues that need to be addressed:

• We need to define carefully the issues the Working Group is addressing - we do not yet have a common understanding of what is meant by incremental updating or by versioning.

• We need to identify the sub-components of these issues.

• We need to compile a glossary of relevant terms (using the work of others).

• If one changes a feature, should one change its unique ID?

• Versioning is not just temporal, but also applies when one creates a different version (e.g.: through generalization) for a specific client, etc.

• Generalization will become the way of producing special-purpose products from the base data set, and not just a way of producing a smaller-scale data set.

• Should the time stamps of features be updated, even though the features haven’t been changed, just to confirm that their data are still valid?

• For a data set’s temporal domain, one could record the date of starting applicability and date of ending applicability, as is done by the AA in the United Kingdom.

• When should a change be registered?  It might depend on the diligence of the contractor!  When the specifications are changed, one can expect many updates.  Sometimes, it is easier for the contractor to delete the old object and send the new object, rather than to send just the extra part.

• Does updating and/or versioning imply an improvement in the data set?

• Some attributes can be transferred automatically from the old to the new feature, but it might not be safe to do so for all features – one can provide the user with hints.

• The tale of the disappearing frogs in the forest: there are two forests near each other, each with its own (different) species of frog.  With time, trees grow between the forests leading to them being merged to create a new, single forest: if the two original forests are deleted from the data base to be replaced by the new forest, the frogs will disappear!

The workshop closed at 17:15.