Splitting Assets

The ability to split an Asset 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 associated with an Asset) at any given coordinate, at an effective date.

The returned feature set represents the two (or more in certain cases) new Assets, 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 Asset and Components are deprecated (see section on deprecation).

The following concepts are covered in this article:

Note: This article is specifically addressing Asset Split operations where the goal is to generate two (or more) distinct new Assets with their own Components (mirroring the original). Users may also be interested in reading about splitting asset components whereby the parent Asset is maintained, but a sub-selection of Components are split and duplicated within said parent Asset.

How a Split Works

The basic mechanics of the Asset 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 Asset, Component, and 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 ‘asset’ for an Asset Split.
• The Asset Record ID (asset_uid) of the Asset being split
• The Splitting Blade definition (intersection_wkt) defined in Well Known Text.
• An optional Posting Date (posting_date) for when transactions associated with the split operation should occur. This field will default to the current date/time if empty.
• 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 Assets and 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) Asset and Components
• Create the new Asset and Components
• Append the appropriate valuations and resources to the new Assets and 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 Asset Components could be represented by the following (basic) attribute data set:

With the ID of the Asset and the definition of the splitting blade supplied, the system first 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. The remaining portion of Twynam Avenue is associated with the second of the resultant two geometries.

Following the split, Twynam Avenue is now two (2) distinct Assets whose Components could be represented by the following attribute data set:

Asset 1 (highlighted in yellow)

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

Asset 2 (not highlighted)

NOTE: the returned data for ‘Asset 2’ represents 75% of the original Cost Unit values. All Components have been duplicated to the second Asset and can be managed in isolation of Asset 1 from now on.

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 posting date.
• The posting date must not conflict with a Locked Financial Year.
• Only linear Geometries can be split.

Resources Assigned to the New Assets

Following an Asset Split, the following resources are copied across to the new Assets. They are discussed in detail below.

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

Original Attribution

Each new Asset or Component record that is created will inherit it’s attribution from the original Asset or relevant Component. Attributes are copied to the new Assets and 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 Asset 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 Task Records are copied across in a split operation. This occurs at both the Asset and Component Register level. Please note, the same rules of ‘relevancy’ that apply to the Condition History, apply to Task Records.

What happens to the Original Asset and Components

Following an Asset Split operation, the original Asset and ALL of it’s 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 Asset record can be fetched via the NEW Asset record(s). Each new record maintains a ‘Deprecated Parent’ linkage back to the original Asset.

Note: In the case of an Asset Split operation, only the Asset records receive a Deprecated Parent link back to the original Asset. The Component’s do not receive such a linkage in this case as the operation was at the Asset level.

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 Twynam Avenue to be now represented as two (2) Assets, split by it’s intersection with Poate Street. In this case, the splitting blade would look like the following:

In the above, the Twynam Avenue Asset is 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 Assets and Components of such a split are shown below. The original Seal 1 and Base 1 features are not altered by proportionality, they are simply copied and associated with the new, shorter, Twynam Avenue Asset. The Seal 2, Base 2, and Earthworks Components however, are split between the two new Twynam Avenue Assets.

In the above, the Twynam Avenue Asset is 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 Assets and Components can be represented in the following table. As can be seen, Base 1 and Seal 1 features are copied and wholly associated with the first Asset (Governors Pde to Matthews Street). However, the Earthworks, Base 2, and Seal 2 are copied and distributed across the splitting blade.