Feature lifecycles and tracking change

Features within OS MasterMap Topography Layer have a lifecycle which is matched, where possible, to that of the real-world object they represent. For example, a new building becomes a new object in the Ordnance Survey main database and is treated as one feature, even if it undergoes change, until the building is demolished. With this approach, Ordnance Survey is emulating real-world behaviour within a digital model. Not all change to the real-world object will be reflected in a change to the feature. For example, the addition of a new porch to a house would usually be considered too minor a change to capture.

Different applications of the data will require different views of feature lifecycles. For some users, any change to the geometry or classification of a feature means it is no longer the same feature for their application, whilst others need persistence of features – so a feature continues to exist through extensive modification. Understanding change is important to understanding OS MasterMap Topography Layer and deriving the optimum value from it.

Lifecycle rules adopt the approach of allowing features to persist through changes, so far as is reasonable. There is inevitably some subjectivity involved in judging that a real-world object has changed so much it can no longer be considered the same object, so specific rules exist to govern this.

Topographic Object Identifiers

Ordnance Survey provides persistent managed identifiers as Topographic Object Identifiers (TOIDs). A TOID is a unique identifier, consisting of the letters ‘osgb’ followed by either 13 or 16 digits between 0 and 9. The TOID is allocated sequentially when a feature is created by Ordnance Survey and is never reassigned to a different feature. One of the key principles of unique referencing is that the TOID will stay the same throughout the life of a feature. This gives the feature continuity within its lifecycle and makes managing change in a holding of the product easier.

The TOID is provided in the GML attribute ‘fid’ of the osgb:Feature element, as shown below:

<osgb:TopographicArea fid='osgb1000000324268289'>

The TOID is provided in the GeoPackage and vector tile attribute 'toid'.

TOIDs enable explicit, maintained references between features in different layers. Other OS MasterMap products reference Topography Layer polygon features within which they are located, allowing the user to navigate between OS MasterMap products using the TOID.

The allocated TOID should never be shortened or amended as this will result in it not being compatible with other OS MasterMap products.

Feature version numbers

Although the nature of a feature might remain essentially the same throughout its life, it is likely to undergo change to its geometry or attributes. Each feature has a version number which is incremented each time there is change of any kind to the feature via one of its attributes. The change can be due either to real- world change or to processes not connected with a real-world change, such as error correction, geometric cleaning, and structuring of the data.

The previous version is referred to as the superseded version, and the new version as the superseding version. In a small minority of cases, a new version of a feature can be created without any apparent change to the product. This is due to change to internal database attributes used in the maintenance process but not included in product data.

Feature version date

The date on which the new version is created is recorded in the feature version date attribute. The date is important for tracking and identifying when change has taken place. Using the TOID, the version number and the version date, it is possible to track a feature’s changes over time. The date the version changed for Ordnance Survey will be different from the date on which the feature is loaded into the user’s file or database holding. Many translators provide an additional column to record the load date. It is important for the user to identify these dates in their holdings and to understand the difference between them if they want to be able to track changes.

One of the key differences between OS MasterMap features and other products is that, with the correct data storage model, a data holding can be rolled back and forward to a given point in time. It must be emphasised that this is the user’s responsibility, since only the current version is available in the product; none of the previous versions are included.

Lifecycle rules

The following sub-sections set out the rules that define the lifecycles of features in OS MasterMap Topography Layer. By understanding how change is defined and recorded within the product, users can start to identify what kind of change has a bearing on their applications and develop their own management regimes.

• Polygon feature lifecycle rules

• Line feature lifecycle rules

• general point feature lifecycle rules