Change only updates
A Lightning Talk
What is a Change Only Update?
A Change Only Update (COU) file contains only features that have changed in the feature type since the last version
The following attributes are used to determine how to process each of the records provided in your Change Only Update files
Unique Identifier: The unique identifier for the feature type, one of; UPRN, USRN, OSID
Version Date: This is the date when the feature was last updated in OS product databases.
Version Available From Date: This is the date when the feature became the latest version and was published to customers.
Version Available To Date: This is the date when the feature was superseded by an update or ceased to exist.
Change Type: This is a code list which gives more information about the type of change which has occurred, and in simplest terms can relate to:
INSERTS
UPDATES
DELETES
Change Type | Definition |
---|---|
New | The feature has been added to Ordnance Survey's master database. |
Moved From A Different Feature Type | The feature has been updated, resulting in it changing feature type. |
Modified Attributes | One or more attribute values, excluding the geometry, have been altered. |
Modified Geometry | The geometry only of the feature has been altered. |
Modified Geometry And Attributes | The geometry and one or more other attributes of the features have been altered. |
End Of Life | The feature has been removed from Ordnance Survey's master database. |
Moved To A Different Feature Type | A feature which has been updated, resulting in it being removed from this feature type and added to another one. |
What can I order?
COU Files are only available with:
CSV files, not Geopackages
A daily or monthly schedule
Unfiltered OS NGD Supplies*
*Filtered Data: An OS Select+Build recipe which has been filtered by attribute values or a Data Package filtered by geographic coverage
Unfiltered Data: A recipe or data package which has not had any filters applied (attribute or geographic)
Geopackage files
Initial Supply | Update Options |
---|---|
Daily (filtered / unfiltered) | Not available |
Monthly (filtered / unfiltered) | Monthly Full Supply |
Annual (filtered / unfiltered) | Annual Full Supply (from March) |
Comma-Separated Values (CSV) files
Daily (filtered) | Not available |
Daily (unfiltered) | Daily COU |
Monthly (filtered) | Monthly Full Supply |
Monthly (unfiltered) | Monthly COU or Monthly Full Supply |
Annual (filtered / unfiltered) | Annual Full Supply (from March) |
Gitbook: OS NGD data ordering and currency
Processing COUs
The process to load the COU files will depend on a number of factors based on your own environment and requirements, including:
Database software
What are you loading it into?
Data loading method or software
How are you loading it?
Feature retention and lifecycle requirements**
How much data do you want to keep?
**There are two main scenarios that represent either extreme of the feature lifecycle options:
Latest feature view
Full feature Archive
Processing a COU
In the following examples, follow the flow chart down on the left and at each stage the correspondingly coloured tables on the right are the entries in the data tables relating to that stage
Example 1 - Two new pre-build addresses are created in an LLPG
Example 2 - One record deleted in an LLPG because it was an error
Example 3 - One address updated in LLPG (geometry, attribution or both)
Example 4 - A pre-build address becomes live and in-use
Important things to note
Automate the process: essential if doing daily!
Currency of OS NGD data: The update frequency for the different OS NGD collections are not all daily, for example:
Transport Network : 1 month
Water Network : 3 months
Boundaries Collection: 6 months
COU files can be empty: COU files will contain any changes which have been made to the underlying data within the selected time frequency. If no changes have been made to a selected feature type of your choice, then you will receive a blank COU file.
Child components: These are related tables including; cross reference, date time qualifier and related entities tables. These have no geometry and no ‘Change Type’ attributes. They have a unique id and also the unique reference of the ‘parent’ feature and it’s version date.
related entities table: add_gb_prebuildaddress_altadd
unique id (primary key): alternateaddressid
Parent id (foreign key): uprn & featuretypeversiondate
Links that may be useful:
This content has been developed from what was originally a Lightning Talk PowerPoint slide set. These slides are available to PSGA members to view and download from the PSGA members area of the OS website
Last updated