Xander,
I have looked into that method and would work great for post collection and editing, but I am looking for something that can be utilized in the field or during collection. I do have use for field mapping in another project though, it would be really cool to see if the "$sourcefeature" and "$targetfeature" globals could be used with attribute rules.
--------------------------------------------------------------------------------------------------------------------------------------------------------
Robert & Xander
Yes that is what I am looking for. I used the following script to test:
var MACOG_Intersections_Poly = FeatureSetByRelationshipName($feature, 'MACOG_Intersections_Poly_HAS_Prg_SignalInvent_HandHoles', ['MACOG_ID'], false)
Return 'MACOG_ID'
this rule and the others I am using work great for generating unique_IDs / inheriting values from related features. The next question I have is about updating these fields. I know that attribute rules gives you the option to fire on Update and that with ArcGIS Pro 2.5 the $originalFeature global has been added to clean up the unwanted occurrences that are triggered when editing / attribute rules fire on Update.
Below I pasted attribute rules scripts that use the Attribute Rules dictionary keywords. Compared to creating many relationship classes and using the FeatureSetByRelationshipName function, what would be a benefit of use scripting that utilizes Attribute Rules dictionary keywords?
return { 'result': noAddress + ' addresses found in the district.', 'edit': [{ 'className': 'Address_pnts', 'updates': AddList }]
____________________________________________________________________________________________________
Mark other features requiring evaluation
You can author a calculation rule that marks other features as requiring either calculation or validation. When performing a calculation, the calculationRequired or validationRequired keyword can be used in a dictionary to reset the Validation Status attribute for one or more features. This is useful when a feature class is dependent on another feature class. In this example, the AssetID field in the Transformer feature class depends on the intersecting Substation feature class. A calculation rule is created on the yearName field of the Substation feature class. When the substation name is updated, the new name and the current year are stored in the yearName field. As part of this logic, all the transformers intersecting the substation in the Transformer feature class are marked as requiring calculation. There is a batch calculation rule on the Transformer class that will calculate the Transformer AssetID the next time the rule is evaluated to reflect the new name and year of the substation.
//Updating the substation name marks its transformers as requiring calculation and updates the yearName to the new name and year. //To recalculate the facility id on all transformers, mark all associated transformers as requiring calculation.var fsDevice = FeatureSetByName($datastore, "Transformer", ["globalid"], false)var fsDeviceIntersects = Intersects (fsDevice, Geometry($feature)) var transformers = [];var count = 0; for (var i in fsDeviceIntersects) transformers[count++] = i.globalid;var newName = $feature.name + " " + Year(Now())return { 'result': newName, 'calculationRequired': [ { 'className':"Transformer", 'globalIDs': transformers } ] }
Edit another feature class
You can use attribute rules to perform inserts, updates, and deletes to another feature class by using the edit dictionary keyword. The example below is a calculation rule on a text field of a district boundaries feature class. When editing a polygon in the district boundaries feature class, this attribute rule will update any intersecting address points with the district name.
var fsAddress = FeatureSetByName($datastore, "Address_pnts", ["globalid"], true)var fsListAddpnts = Intersects(fsAddress, $feature)var AddList = []var counter = 0var noAddress = Count(fsListAddpnts)if (noAddress > 0) { for (var address in fsListAddpnts) { AddList[counter] = { 'globalid': address.globalid, 'attributes': { 'add_district_name': $feature.DistrictName } } counter++ } return { 'result': noAddress + ' addresses found in the district.', 'edit': [{ 'className': 'Address_pnts', 'updates': AddList }] } } else { return 'No address points in district.'}
___________________________________________________________________
Advanced Attribute Rules – Editing features on another class with attribute rules
Creating features with attribute rules
Note: The `result` key is used to return the value to persist in the field `Field` which the attribute rule is assigned to. In this case I really didn't do anything to the feature being created so I just returned the same value of the field `Field` (I know, terrible name for a field sorry). When returning the same value, the system will detect that there is no change and will not perform an additional edit to the feature. This is useful to avoid triggering behavior associated with the field (if any) such as extension specific behavior, e.g. dirty area management in utility network.
Update existing features in another class
Now we want to add another attribute rule that performs an update. With this rule we want to ensure that the buffered polygon moves along with the point feature when it is moved. The best solution to achieve this would be to update the buffered polygon feature geometry with a new buffer after the update.