COU overview

Change-Only Update (COU) is only available for GML format orders. COU is unavailable in GeoPackage or vector tile formats.

COU is data that is provided to bring a user’s data holdings up to date with the most recent data available from Ordnance Survey. COU contains, for a user’s defined area, only the features that are new or have changed (known as Inserts and Updates, respectively), as well as departed features (i.e. those features that have moved or have been deleted from the user’s data extent; known as Deletes). Any feature that is new or changed since the COU date the user provides will be supplied in its latest version and departed features will indicate which features have been moved or deleted since that date.

COU will not provide intermediate versions of features that have existed between the previous order and the most recent version. Conversely, COU may supply departed information for features that the user has never had, as they have appeared and subsequently disappeared between order dates.

COU data format

COU data is supplied in GML 2.1.2 format. Inclusion of features in the COU file is triggered by a new version of a feature appearing in the database with a version date between the previous and new order dates. In the data, these new and modified features (i.e. Inserts and Updates) are represented in the same way they would for a Full Supply. Departed Feature (i.e. Deletes) is a specific feature type only present in COU supply; it represents features to be removed from a user’s holding. The departed feature’s records contain the TOID of the deleted feature, its bounding rectangle, its theme or themes, and the date and reason for its departure.

DepartedFeature attributes

Features that indicate that a feature in a previous supply may no longer be relevant, for example, it may have been deleted or moved. This feature type is used in COU data supply only.

TOID or gml:id

The unique topographic reference number. It consists of the letters ‘osgb’ followed by thirteen or sixteen digits. The TOID must always be retained/stored in its entirety as any changes, including removal of digits, will make the TOID unusable with other OS MasterMap products.

• Type: String

• Multiplicity: [1]

boundedBy

The minimum enclosing rectangle that encompasses a geometry. For departedFeatures, this encompasses all geometries that a feature has had in its lifecycle.

• Type: Rectangle

• Multiplicity: [1]

theme

A theme that the feature belongs to.

• Type: String; see ThemeType

• Multiplicity: [1..*]

reasonForDeparture

This is set to ‘Deleted’ or ‘Vacated’ to indicate whether a feature has physically been deleted from the database or is no longer relevant due to change in COU supply.

• Type: String

• Multiplicity: [1]

deletionDate

The date the feature was deleted from the Ordnance Survey maintenance database.

• Type: Date

• Multiplicity: [0..1]

COU requires that information be provided for features that were present in a spatial query but no longer meet the query criteria. Such features may have changed theme so that they:

1. Are no longer in any of the themes being requested.

2. Have had their geometry modified between queries so that they no longer meet the spatial criteria.

3. Have been deleted.

These features are represented using the DepartedFeature Feature Type explained above. These are encoded the same way as other features.

For example:

<osgb:DepartedFeature fid='osgb5000005194950566'>
    <osgb:boundedBy>
        <gml:Box srsName='osgb:BNG'>
        <gml:coordinates>224628.890,641571.220 224628.890,
        641571.220</gml:coordinates>
                            </gml:Box>
                        </osgb:boundedBy>
                        <osgb:theme>Buildings</osgb:theme>
                        <osgb:reasonForDeparture>Deleted</osgb:reasonForDeparture>
                        <osgb:deletionDate>2017-02-02</osgb:deletionDate>
                        </osgb:DepartedFeature>
</osgb:departedMember>

Rectangle

A rectangle is a pair of points that are used to define a rectangular area that is aligned to the National Grid. One point defines the minimum easting and northing of the rectangle, the other defines the maximum easting and northing.

Example

Example class model:

Applying COU

All the information to update a user’s holding is provided in the COU file. How this is processed by the user’s software is obviously critical to ensuring that these changes are correctly applied. The basic principles that need to be followed to help ensure consistency are:

1. Ensure that the Initial Supply or latest Full Supply or COU has been correctly loaded. This can be checked with the feature validation dataset (FVDS), which gives a full list of the TOIDs that should be in a user’s current holding at time of Full Supply.

2. Ensure that the COU to be applied covers the period from the date of last supply (‘Extraction date’) through to the update date required.

3. Apply the COU to the existing holding. How this is applied will be dependent upon the user’s system.

4. Check the holding using the FVDS at appropriate intervals to ensure currency and consistency of data holdings.