Latest Contributions by VinceE

I am confused by behavior I am experiencing when using a Composite Relationship Class (with forward messaging) in conjunction with a Topology. Below I have a "parent" polygon (black) that has relationship classes with a "child" polygon (blue) and "child" point (black plus sign). Both are composite relationships, and both have FORWARD messaging turned on. Things work as expected, meaning when I rotate ONLY the parent polygon, the children rotate with it. There are no Feature Datasets, Subtypes, or Topologies involved in this example: The below example is more complex, and where I am having problems. There are subtypes and a topology involved. There are again 3 feature classes: wotus_poly [subtypes: WETLAND, WATER] - a "WETLAND" type shown in green pool - no subtypes, shown in blue test_plot_pt [subtypes: WETLAND, UPLAND] - two "WETLAND" and one "UPLAND" shown in black and red, respectively Relationships (2): wotus_poly one-to-many composite with pool, forward messaging turned on. A second relationship class with the same properties with the test_plot_pt.     Topology: also a topology rule set up that requires all WETLAND subtype test plots must be within a WETLAND subtype polygon. Here is what the structure in Catalog View looks like (this is within a Feature Dataset for the topology): Here is a visual of a possible arrangement, and one where the topology rule would be validated correctly: The issue is that the "FORWARD" messaging aspect of the relationships DOES NOT WORK as expected. Rotating the parent has no impact at all on the location/arrangement of the child pools or points. Is this because these features are involved in a Feature Dataset? Is it because there's a topology involved in at least two of these feature classes? Are subtypes problematic here?   I have verified that DELETING the parent polygon, in green, will also delete the related children, as expected in a COMPOSITE relationship. So, there is some interference happening that prevents the geometric updates via forward messaging. Any help would be appreciated!     ... View more

I'm experiencing an issue where lines following a single "//" line are causing Attribute Rules to throw errors when trying to save them. The code below is essentially meaningless, but I can reproduce this exact issue in much larger scripts. This will not save, and throws the error shown (Object not found feat, Script line: 2).   // var feat = $feature return feat   This, however, saves as expected without any issues:   // var feat = $feature return feat   Seems like in the first example, that commented out first "//" line is ALSO consuming/commenting out the variable assignment on the following Line 2, and therefore the variable object is not found. I understand there isn't necessarily a good reason to use "//" to comment out a blank line, but I'm curious if this is expected behavior for some reason. Why would adding in an extra blank line make the difference? Thanks! ... View more

I have a polygon feature class related to a table via Relationship Class (one-to-many, GlobalID in polygon related to a GUID in the table, field called REL_ZONE_ID). I am updating this related table manually. The related table lists the segments that intersect the polygons (polygon labels shown here are a shorthand version of the full Globals, full version listed in the REL_ZONE_ID field). So basically it's a table that keeps track of the lines intersecting a given polygon. I am moving between Pro 3.1 and 3.2, so I can't yet reliably use "FeatureSetByRelationshipClass". The table shown is the related table, storing a record of each line that intersects a polygon.   I would like to do this automatically with a Calculation Attribute Rule, at INSERT, UPDATE, and DELETE. My approach: Get a FeatureSet of the records that are already related to the original polygon. Mark them for deletion by adding to a "delete" array. Review all line segments (time consuming?); if any intersect the newly updated polygon, append segment ID record to a new "adds" array. Return an "edit" record to delete the originally related records, and add the newly intersected records. The below does this, but it's a hack--I needed to add in the if (editType != "DELETE") because otherwise when a polygon was deleted, the rule would remove the currently related records as expected, but then add the same records back in (except with a NULL related ID, since the polygon would have been deleted, and not have an ID anymore). I thought I wouldn't need to do the if DELETE because I thought the "Intersect()" was being called on the $feature, and not the $originalFeature. So I assumed that if a feature was deleted, there couldn't be any intersections with the $feature, and therefore no records would be added to the "adds" array. To reiterate, the code below does exactly what I want, I just can't do it without the special "DELETE" caveat.   /*MANAGE RELATED SEGMENTS*/ //---------------------------------------------------------------------// // INPUTS var proVersion = 3.1 var editType = $editContext.editType // Get original/current polygon feature. var zone = $originalFeature var newZone = $feature // Get all polylines in SEGMENTS feature class. Geometry required for 'Intersects()'. var segmentsFS = FeatureSetByName($datastore, "SEGMENT", ["SEG_ID"], true) if (proVersion >= 3.2) { // Get table records that are related to the current POLYGON feature. var relRecordsFS = FeatureSetByRelationshipClass(zone, "ZONE_SEG_RELATION", ["*"], false) } else { // Get all records from the related table. // Filter when related ID matches GlobalID of orignal POLYGON feature. var relRecsFS = FeatureSetByName($datastore, "SEG_TBL", ["*"], false) var zoneGlobalID = $originalFeature.GlobalID var relRecordsFS = Filter(relRecsFS, 'REL_ZONE_ID = @zoneGlobalID') } // MAIN ------------------------------------------------------------------------------- # // Iterate over the currently related table records, add all 'deletes' array. var deletes = [] for (var relatedRecord in relRecordsFS) { Console(`ALREADY RELATED / TO DELETE: ${relatedRecord.SEG_ID} | ${relatedRecord.GlobalID}`) Push(deletes, {"globalID": relatedRecord.GlobalID}) } // For every SEGMENT line, check if it intersects current ZONE. If so, add to 'adds' array. var adds = [] if (editType != "DELETE") { // If a feature is deleted, there won't be anything getting added. "newZone" alone isn't working? for (var seg in segmentsFS) { if (Intersects(newZone, seg)) { Console(`FOUND NEW INTERSECTION / TO ADD: ${seg.SEG_ID}`) Push(adds, {"attributes": {"REL_ZONE_ID": newZone.GlobalID, "SEG_ID": seg.SEG_ID} }) } } } Console(`\nDELETE RECORDS:\n${deletes}\n\nADD RECORDS:\n${adds}`) return { 'edit': [{ 'className': 'SEG_TBL', // This is the TABLE where the edits are occurring. 'deletes': deletes, // [{'globalID': XXX}, {'globalID': YYY}] <-- 2 delete examples 'adds': adds // [{"attributes": {"REL_ZONE_ID": newZone.GlobalID, "SEG_ID": seg.SEG_ID}}, {"attr...] <-- 2 adds }] }     ... View more

I am trying to write a Calculation style Attribute Rule to restrict entries into a field to be unique values within the field. As an example, more than one row in the given table can't have a value of "TEST" in the given field--entries must be unique. The below achieves this (might not handle NULLs, but I can sort that out). What is constantly irritating to me is how I cannot figure out how to use the variables defined on the first few lines in the "FeatureSetByName()" and "Expects()" function calls? Updating the FeatureSetByName() call with the fcName and fldName variables will work when I hit "OK" in the AR code editor, but then fail when I try to save the rule. Updating Expects() to use the fldName variable throws an error right in the editor. Why do these functions work this way? If I change the name of my field, I have to go in and retype it 3 different times in the code? Why can I not just use one single variable for those names? Is this some Arcade/JavaScript idiosyncrasy I just don't understand? Thanks in advance to anyone who can sort me out on this. The point is to create a rule that can be used in different locations, with minimal updates to only the INPUTS section. Esri's example (link in the code below) hard-codes things, which is silly from a reusability standpoint. // INPUTS var fcName = "TEST"; var fldName = "Name_Text"; // These two lines must be written with the actual strings, not the variables above. var features = FeatureSetByName($datastore, "TEST", ["Name_Text"], false); Expects($feature, "Name_Text"); // MAIN // If any values in the field match the current row's value (and the IDs are different), // this is a duplicate, and an error. // Largely copied from: // https://support.esri.com/en-us/knowledge-base/how-to-identify-a-duplicate-field-value-using-an-attrib-000029088 for (var i in features) { if ((i[fldName] == $feature[fldName]) && (i.OBJECTID != $feature.OBJECTID)) { return {"errorMessage": "ERROR: value not unique within field!"} } } // If error above not found, return results dict with value as-is. var fldUpdates = Dictionary() fldUpdates[fldName] = $feature[fldName] Console({"result": {"attributes": fldUpdates}}) return {"result": {"attributes": fldUpdates}}   ... View more