Processing COUs
Last updated
Was this helpful?
Last updated
Was this helpful?
The process to load the COU files will depend on a number of factors based on your own environment and requirements, including:
Database software
Data loading method or software
Feature retention and lifecycle requirements
There are two main scenarios that represent either extreme of the feature lifecycle options:
Latest feature view
Full feature archive
In this scenario, the COU files are processed and only the current version of every feature is retained. This will result in the same data holdings that would be achieved if a new full supply was received on this date.
To achieve this, either post-processing will have to be done once all COU data is loaded into a database, or the loading process will need to evaluate the COU data against your existing data and process accordingly. This processing will be based on the supplied attributes which detail the type of change and the dates for that version.
Each feature type is supplied with a Change Type attribute (changetype), which is populated from a code list value (changetypevalue).
Below is a table of the possible change types and the resultant actions required to maintain a latest feature view of the data for the specific feature type. Individual features should be targeted based on that feature type's unique identifier. In the majority of feature types, this will be the osid, but this is not always the case; therefore, please check the appropriate feature type documentation.
New
Insert as a new feature
Moved From A Different Feature Type
Insert as a new feature
End Of Life
Delete existing feature based on unique identifier
Moved To A Different Feature Type
Delete existing feature based on unique identifier
Modified Attributes
Update the record (see section below)
Modified Geometry
Update the record (see section below)
Modified Geometry And Attributes
Update the record (see section below)
A single feature may be updated multiple times in a single COU file when multiple changes occur within the selected COU frequency. Instead of suppressing all changes other than the last edit, the COU will contain all of the edits which have been made to that feature.
To obtain the current 'live' view of a feature, the latest edit is required; all previous edits can be discounted. In essence, this requires the following two processes:
Discarding all feature records with the exception of the latest Version Available From Date (versionavailablefromdate)
Discarding all feature records that have a Version Available To Date (versionavailabletodate) populated, i.e. it is NOT NULL. These records will also have the Change Type Value (changetypevalue) of 'End Of Life' or 'Moved To A Different Feature Type'.
In this scenario, every record is retained, giving a full lifecycle since the supply started of each feature. This will result in multiple records for each feature.
To enable this in a database, the default primary keys (as defined in the provided DDL scripts) will have to be changed to also include the version available from and to dates (versionavailablefromdate, versionavailabletodate).