Change management and data association

This section introduces two aspects of deriving additional value from OS MasterMap Topography Layer:

• The first aspect is utilising the referencing and change-tracking attributes to identify and manage the impact of change on a user’s data. It discusses the process of applying change and the implications for archiving data.

• The second aspect is associating user data and OS MasterMap Topography Layer using the TOID as a common reference. This creates the potential to share data between departments and organisations. It explains what data association is and it gives examples of how data association can bring benefits to organisations.

Change management

The feature-reference and change-tracking attributes provide the opportunity for users to put in place a change-management regime. The system that the user uses to translate and load OS MasterMap Topography Layer should use the TOID and version information to update their local holding when a COU is taken onboard.

The software used to manage the holding needs to handle three types of situation: features that have been deleted (known as Deletes), features that are new (known as Inserts), and features that have changed (known as Updates). The software should resolve Deletes as a priority. It is important that COUs are processed with Deletes first, then Inserts and Updates. This is to ensure that updates are applied in the correct order.

Deletes

• In the COU, there is a list of features that have been deleted since the last time the user took data. There are some additional considerations with deleted features, but in essence, the software should find all the TOIDs and versions on the deleted features list in the COU, locate them in the main holding, and remove those features.

• In the case of superseded and deleted features, these could be removed totally from the user’s holding, but it may better suit the requirements of the user to archive them for future reference.

Inserts

• With a new feature, called an Insert, the software compares each TOID in the COU against the TOIDs in the existing holding. If the TOID exists in the COU but not in the main holding, it is considered an Insert and the software should put it into the holding.

Updates

• If the TOID already exists in the holding, the software needs to compare the version number in the existing holding against the version number in the COU. If the version number in the COU is higher than in the existing holding, the software needs to take out the existing version of the feature and replace it with the version contained in the COU. If, on the other hand, the COU version number is lower than the COU version number, the feature should be ignored.

Archiving the OS MasterMap data holding

As OS MasterMap features progress through their lifecycles, it is possible to develop snapshots of the features by holding superseded versions in a local data archive. By holding and maintaining a local data archive, users will be able to interrogate previous views of the world straight from their local data holding.

It is important to consider carefully how to archive OS MasterMap Topography Layer features, and what requirements the applications and users will have to access the older information. Archiving may be done by simply writing older versions of the data to hard media, or by a more sophisticated system of keeping historical data live. It is important for users to recognise their own unique requirements (be they user, statutory or regulatory requirements) as archiving can become a significant overhead in terms of storage.

Before designing or implementing an archive of OS MasterMap Topography Layer, it is advisable for a user to discuss requirements with their system supplier.