> For the complete documentation index, see [llms.txt](https://docs.os.uk/osngd/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.os.uk/osngd/getting-started/downloading-with-os-select+build/getting-started-with-csv/processing-cous.md). # Processing COUs {% hint style="info" %} Change-Only Update (COU) files are only available for CSV data supplies of the OS NGD. Further information about COU data supplies can be found on the [COU supplies](/osngd/getting-started/os-ngd-fundamentals/cou-supplies.md) page. {% endhint %} 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 {% hint style="danger" %} When processing COU supplies, it is essential that they are processed in the correct `productVersion` date order; therefore, in automated processes, we strongly recommend that you build in a test to ensure that the previous supply has been fully processed. For daily COU orders, that will be the previous day’s `productVersion` date; for monthly COU orders, that will be the preceding first of the month's `productVersion` date. {% endhint %} ## Feature retention options There are two main scenarios that represent either extreme of the feature lifecycle options: 1. Latest feature view 2. Full feature archive ### Latest feature view 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. #### Change type Each feature type is supplied with a **Change Type** attribute (`changetype`), which is populated from a code list value (`changetypevalue`). {% content-ref url="/pages/2AuZDPuP25QjNdeyPCub" %} [changetypevalue](/osngd/code-lists/code-lists-overview/changetypevalue.md) {% endcontent-ref %} 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. | changetypevalue | Action | | ----------------------------------- | -------------------------------------------------- | | 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) | #### Version dates 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: 1. Discarding all feature records with the exception of the latest **Version Available From Date** (`versionavailablefromdate`) 2. 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'. ### Full feature archive 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`). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.os.uk/osngd/getting-started/downloading-with-os-select+build/getting-started-with-csv/processing-cous.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.