Split cable (line feature) - Possible to identify new feature as resulting from split operation?

[Jens_Dalsgaard]

In context of planning new grid, quite often in a cabled grid you will split a cable to insert and connect a new substation or cabinet.

Let's say we have cable with GlobalID ABC123 and you split it, you will have two cables left:

1. One being the original cable feature with GlobalID ABC123 (the longest part)
2. One being a new feature being assigned this GlobalID ABC456 (notice: a new feature yet NOT a new cable)

In planning context it is important to know that this new feature with GlobalID ABC456 is in fact not a new cable. The planner does not need to buy this cable nor do any digging (except at the location of the splitting).

I was wondering if using Arcade (or other magic approaches) I could identify such 'new' feature as 'new feature because of a split operation and hence in reality not really a new cable'.

Please notice enclosed freehand drawing aiming at delivering some context. The two green cables are NEW.

The BLUE feature is new (feature) but does not represent a new cable - how may I omit this from the budget.

Any ideas are welcomed.

[MikeMillerGIS]

We do not have context in arcade that the insert was from a split unfortunately.  

[rlyding]

I had a similar issue working with water utilities where I needed a new unique value generated on splitting a line. Not sure if you would be able to add additional fields to your schema, but you could maybe setup an attribute rule that flags these specific wires on split. You would need a field to store that flag, but also another unique identifying field per wire segment other than globalid or objectid. Global ID and ObjectId don't work because they generates new values each time a feature is added.

When a split happens as you noted a new segment (the smaller part) is considered a Insert trigger on a attribute rule and all the attributes of original segment transfer to the new segment after the split tool is used.

In our data model we have an fid(featureid) field that is unique to each line segment. When a line is split via the split tool in Pro that original fid carries over to the new segment generated and you could use that to identify these split segments by doing the following. *fid in your case could be anything as long as it is a unique identifier other than globalid or objectid. In the case of the utility network assetid could work if you are using that.

Create a attribute rule for the line that triggers on Insert for the flag attribute. First you will check if the fid field is null if it is null return as this would be a new line added in through normal Insert editing and not a split. If the fid is not null then this is a segment that was created via a split and fid carried over so the code continues. Next you need to run a intersects to pull in intersecting lines and then filter that intersects feature set to only where the fids match these would be your 2 split segments. From there you could set your flag attribute on the feature as "new split" or however you want to handle that. Here is what the code could look like.

fid = $feature.fid
if (IsEmpty(fid) == false && fid != '') {
var fsInt = Intersects(FeatureSetByName($datastore, "YourLineLayer", ['fid'], false), $feature)
if(Count(fsInt) == 0) return
var fsLine = Filter(fsInt, "fid = @fid")
if (Count(fsLine) == 2){
return "Set What you Want Here for Flag Attribute Value"
}
return
}

[Jens_Dalsgaard]

Thanks, @rlyding. That should work. 

We do not have such unique non-GlobalID identifiers today, but we have ongoing talks with the market about establishing functionality automatically generating and maintaining identifiers on cables and lines which would be a prerequisite for the described approach.

Unique identifiers stating this cable is the third in a series of four serially connected cables / overhead lines between substation S123 and substation S456 hence will be assigned identifier S123-S456#3 (and the other three segments: S123-S456#1, S123-S456#2 and S123-S456#4).

After a split these identifiers must be automatically updated (as there are now 5 serially connected cables and overhead lines).

The updating of these identifiers could include an identification of "this 'new' cable is the result of a split" I wouldn't write this information to the cable but rather to a separate table.