We are switching to Pro and are developing attribute rules to handle/manage internal unique ID fields depending on the editing function being performed.
So far, the rules developed handle:
1. copying and pasting from a backup (retaining the unique ID from the backup)
2. altering geometry such as moving a feature, editing vertices or reshaping (retains the unique ID)
3. merging features (retains the unique ID from the chosen preserved feature)
The only thing that we are having trouble with is when a Split is performed, in which case it retains the unique ID for both halves of the split feature (we want it to keep the unique ID on one half and assign the next unique ID in the sequence to the other)
We suspect an issue with either ordering of rules or contradiction within rules so are hoping someone can help simplify/condense into maybe one rule for this?
There are 3 rules currently, and here are the details in order of execution, and the expression they execute:
1. INSERT (uses Insert) - this is for adding new features and when a copy/paste is done:
if(IsEmpty($feature.FACILITYID)) {return "CYP" + NextSequenceValue ('CityPropertyFACILITYID_SEQ');} else {return $feature.FACILITYID;}
2. UPDATE (uses Update) - this is for splitting features:
if(Equals(Geometry($feature), Geometry($originalfeature))) {return $feature.FACILITYID;} else {return "CYP" + NextSequenceValue ('CityPropertyFACILITYID_SEQ');}
3. MERGE (uses Update) - this is for merging features:
if ($feature.FACILITYID !=$originalfeature.FACILITYID) {
return $originalfeature.FACILITYID;
} else {
return $feature.FACILITYID;
}
Note - FACILITYID is the sequentially driven unique field we are looking to increment and preserve values for. Sequence has been created and works perfectly. It seems like it is almost there, just needs some better logic and maybe order of execution or condensation into one rule (at least for the Update-driven rules). I've tried executing them in different orders etc. as well and it changes functionality on other fronts so this order we have now is the "best case" so far, pending the resolution of the Split issue.
Thank you for any help and suggestions!!
