Splitting Asset Components

The ability to split a Component is vitally important in keeping the Organisation’s financial reporting, engineering concepts, and asset management data policies in sync. The core concept involves splitting a linear geometry ( representing one or more Components) at any given coordinate, at an effective date.

The returned feature set represents the two or more new Components, each containing a distinct copy of the original Components, with each new Component being proportionately associated with one of the two (or more) resultant geometries. The original Components are deprecated (see section on deprecation) and the new Components are inherited by the original Asset.

The following concepts are covered in this article:

Note: This article is specifically addressing Component Split operations where the goal is to maintain the single Asset parent. Users may also be interested in reading about asset splitting whereby the parent Asset is also deprecated and the result is two (or more in certain cases) new Assets with all new associated Components.

How a Split Works

The basic mechanics of the Component Split operation is that a user submits a request to the system for a split to occur. The system will respond (assuming no errors occur) with the required Component/Resource inserts and updates that need to occur. Accepting this response will process the Split operation. This process is summarised below:

1. User submits request for a split operation
2. System assesses the request and responds with a detailed summary of the inserts and updates required to achieve the split
3. User accepts the response, and the split occurs.

Requesting a Split

To request a split, the following information is required:

• The Split Level (split_level) which must be set to ‘component’ for a Component Split.
• The Asset Record ID (asset_uid) of the Asset that ‘owns’ the Component(s) being split.
• The Component Record IDs (component_uids) of the Component(s) that are being split.
• The Splitting Blade definition (intersection_wkt) defined in Well Known Text.
• An optional Effective Date (effective_date) for when the split should occur. This field will default to the current date/time if empty.
• Optional Split Flags (flags) that can control facets of what will be copied across to the new Components. See ' Advanced Splitting: Resource Exclusions’ for more information.

System Assesses the Request and Response

Upon receiving a split request, the system will review the prohibitions detailed in the section, ‘When a Split can Occur’. It will then commence building a response that (if accepted by the user) instructs the system on how to:

• Deprecate the Old (split) Components
• Create the new Components against the original Asset
• Append the appropriate valuations and resources to the new Components.

User Accepts the Response and the Split Occurs

After reviewing the response - where the user can investigate in detail what will and wont be created - the user can accept the response and the relative Split Operation will occur.

How the Split Works at a Geometry Level

In order to perform the split, the user must provide a splitting blade - a linear geometry that cuts across the Component geometry/geometries at the desired split coordinate. See screenshot below:

*In the above screenshot, the Asset (Twynam Avenue) is highlighted in yellow and the user provided splitting blade is
located about 25% along it’s overall length. For the purpose of this example, we will assume that Twynam Avenue has
three (3) Components - earthworks, base, and seal - all sharing the same linear geometry running from Governors Parade
to Barr Street.*

Prior to the split, the Twynam Avenue Components could be represented by the following (basic) attribute data set:

Assuming the user only wants to split the Base and Surface Components (leaving the Earthworks untouched), they would supply the Asset Record ID, and the two (2) Component ID’s relating to the Surface and Base. The system then derives the NEW Component Geometries that would result from the split operation. See screenshot below:

*In the above screenshot, the split has occurred and the first of the resultant two geometries is highlighted in
yellow - a portion of the base and seal will be associated with this geometry. The remaining portion of base and seal
Components are associated with the second of the resultant two geometries. The earthworks are still associated with the
original geometry record.*

Following the split, Twynam Avenue is still one distinct Asset, however, instead of having three (3) Components, it now has five (5). The new Component Structure (ignoring deprecated Components) would look like this:

NOTE: the proportion of length between the smaller geometry and the original Asset is assumed to be 25% - the System has returned the new Cost Unit values based on this geometric truth.

When a Split can Occur

The following restrictions are enforced by the system when a user attempts to perform an Asset Split operation:

• The splitting blade MUST pass through the subject Geometry/Geometries at some point.
• The construction/Intervention dates of the Components cannot be after the effective date.
• The status effect of the Components must be active.
• The Component must have no Transaction postings that occur after the effective date.
• The effective date must not conflict with a Locked Financial Year.
• Only linear Geometries can be split.

Resources Assigned to the New Components

Following a Component Split, the following resources are copied across to the new Components. They are discussed in detail below.

• Original Attribution
• Transaction Summary
• Condition History
• Report Categories
• Task Records

Original Attribution

Each new Component record that is created will inherit it’s attribution from the original relevant Component. Attributes are copied to the new Components unchanged - The ONLY EXCEPTION to this is the cost units value, which is modified by the Component’s relative proportionality.

Transaction Summary

Each new Component record that is created will inherit a proportionate baseline value from the original relevant Component and the original Component’s Value is written-off. This means there is ZERO change in overall value in the system. Consider the following 50/50 split of a single Component into two (2) new Components.

The original transaction schedule would look something like this, with the carrying value displayed at the bottom.

As a part of the Component Split operation, the following transaction schedule would be generated and applied. Note: transaction schedule simplified to years for the example.

By the end of the process, the valuation summary for ALL Components would be:

Condition History

For each newly created Component, the relevant Condition History is copied to across in a split operation. The term ' relevant’ refers to whether or not the Condition record concerned the spatial bounds associated with the new Component ( see section: Advanced Splitting: Multiple Geometry Features), as well as whether or not the Condition record existed at the ‘Effective Date’ for the split operation.

The following table details this concept of ‘relevant’ Condition history for an Effective Date of 12/10/2000. Note, each row represents a Condition record that lasts from the Assessment Date until the Assessment Date of the subsequent row. That is, the above Component was considered to be in Condition 1 from January 1993 to February 1997.

Note: this condition record is carried over, however the Assessment Date is set to the Effective Date (October 2000) and a comment is added to reflect the original Assessment Date.

Report Categories

For each newly created Component, the LATEST (as at the Effective Date) relevant Report Categories are copied across in a split operation. That is, if a Component held a Special Schedule 7 Category of ‘Roads’ at the Effective Date, each new Component would inherit this Report Category.

Task Records

For each newly created Component, the relevant Auxiliary Data Records are copied across in a split operation. Please note, the same rules of ‘relevancy’ that apply to the Condition History, apply to Task Records.

What happens to the Original Components

Following a Component Split operation, the original Components are marked with a status code of ‘Deprecated’. This is a special system status code (that users cannot access) which marks the record as ‘superseded by another record or records’. Deprecated records remain in the system, but they are excluded from the default map view, tables, filters, dashboards, and reports.

Information associated with a Deprecated Component record can be fetched via the NEW Component record(s). Each new record maintains a ‘Deprecated Parent’ linkage back to the original Component.

Advanced Splitting: Resource Exclusions

When requesting a Component Split operation, a user can supply some optional flags that will alter what resources the newly created Components will receive. The flags currently available in the system are:

• Apportion Cost Units (apportion_cost_units - true/false): If not supplied, this defaults to TRUE. This flag indicates that the user wishes for the Cost Unit values of each new Component to be proportionately set based on its ' share’ of the original Component. If set to FALSE, each new Component will receive a Cost Units value equal to that of it’s parent Component.
• Copy Condition History (copy_condition_history - string): If not supplied, this defaults to all. This flag indicates what sort of Condition History the user would like to translate to the new Components. The following options are available:
  • all (default): All relevant Condition history will be copied.
  • latest: Only the most recent Condition record (relative to Effective Date) will be copied.
  • none: No Condition records will be copied.
• Copy Report Categories (copy_report_categories - true/false): If not supplied, this defaults to TRUE. This flag indicates that the user wishes for the relevant Report Categories to be copied to the new Components.
• Copy Task Records (copy_auxiliary_data - string): If not supplied, this defaults to all. This flag indicates what sort of Task Record History the user would like to translate to the new Components. The following options are available:
  • all (default): All relevant Records will be copied.
  • latest: Only the most recent Record (relative to Effective Date) will be copied.
  • none: No Records will be copied.

Advanced Splitting: Multiple Geometry Features

In certain situations, an Asset’s Components may not all be represented by the same Geometry record. See the cross-section view below:

*In the above example, the Asset (Twynam Avenue) is associated with five (5) Components. An earthworks Components,
represented by a single Geometry running from Governors Place to Barr Street. Two (2) base Components running from
Governors Place to Matthews Street and then from Matthews Street to Barr Street. And Two (2) seal Components running
from Governors Place to Matthews Street and then from Matthews Street to Barr Street (identical to the base).*

Given the above scenario, if Poate Street was to be extended such that it now crosses Twynam Avenue, the Asset Management and Engineering principles may require the Component’s of Twynam Street to reflect this new extent. In this case, the splitting blade would look like the following:

*In the above, the Twynam Avenue Components are to be split by its new full intersection with Poate Street. For the
purpose of the example, we will assume the split blade is 75% along the original Asset’s length.*

The resultant Components of such a split are shown below. The original Seal 1 and Base 1 features are not altered by proportionality, they are therefore UNMODIFIED by the split operation. The Seal 2, Base 2, and Earthworks Components however, are split by the intersection blade.

*In the above, the Twynam Avenue Components are to be split by its new full intersection with Poate Street. For the
purpose of the example, we will assume the split blade is 75% along the original Asset’s length.*

The association and proportion share of the new Components can be represented in the following table. As can be seen, Base 1 and Seal 1 features are left UNMODIFIED. However, the Earthworks, Base 2, and Seal 2 are copied and distributed across the splitting blade.