Select to view content in your preferred language

Address Data Management solution errors in ArcGIS Pro 3.1

1178
5
01-31-2023 01:35 PM
ChrisFox
Esri Regular Contributor
1 5 1,178

At ArcGIS Pro 3.1 there are changes in attribute rules to improve performance with how features are queried across feature classes. When requesting a FeatureSet you can specify which fields should be returned and this can improve performance. This option was available in previous versions, but prior 3.1 if you were in an edit session all fields were returned regardless of what you requested in the FeatureSet. At 3.1 this behavior was changed and now only requested fields are returned.

Some of the rules included in the Address Data Management solution at version 2.0 did not request all the necessary fields used later in the rule. As a result you will receive errors at 3.1 for rules that previously ran successfully at 3.0 or 2.9. For example when constructing a new road and splitting an existing road you will get error "Arcade error: Field not found centerlineid, Script line: 47".

We will be releasing an update to the Address Data Management solution in March that will address these issues. However, if you have already implemented the solution it will be easier to update the rules on your existing feature classes. Below I describe the 3 feature classes and 5 attribute rules that need to be updated. All of these changes will also continue to work at Pro 2.9 and 3.0, so you can make these changes now in preparation for 3.1. For more information on how to edit attribute rules, see Create and manage attribute rules in the ArcGIS Pro help.

RoadCenterline: 'Update Site Addresses' calculation rule

On line 62 of the rule (line 2 in the snippet below) add "globalid" to the list of returned fields.

var updates = []
var siteAddresses = Filter(FeatureSetByName($datastore, "SiteAddressPoint", [addressfullname_field, addrnum_field, municipality_field, "globalid"], false), addressfullname_field + " = @origFullName");
var globalid_field = Schema(siteAddresses).globalIdField;

 

RoadCenterline: 'Update Validation Status' calculation rule

On line 43 of the rule (line 2 in the snippet below) add id_field, munileft_field, and muniright_field to the list of returned fields. Update To:

var search_string = id_field + " IN @ids" + " OR " + fullname_field + " = @fullname" + " OR " + fullname_field + " = @fullname_orig"
var roadCenterlines = Filter(FeatureSetByName($datastore, "RoadCenterline", ["objectid", id_field, munileft_field, muniright_field], false), search_string)
var road_objectIDs = [];

 

RoadCenterline: 'Address Range Overlap' validation rule

On line 31 and 44 of the rule (line 4 and 17 in the snippet below) add "globalid" to the list of returned fields.

// Find any roads were the range overlap on the left side and get their IDs
if (!IsEmpty(fromLeft) && !IsEmpty(toLeft) && (fromLeft != 0 || toLeft != 0)) {
    var search_string = fullname_field + " = @fullname" + " AND " + fromleft_field + " <= @toLeft" + " AND " + toleft_field + " >= @fromLeft";
    var leftRoadCenterlines = Filter(FeatureSetByName($datastore, "RoadCenterline", [fullname_field, fromleft_field, toleft_field, munileft_field, id_field, "globalid"], false), search_string)
    
    for (var road in leftRoadCenterlines) {
        // Test that the road is not the same as the feature, that it either is in the same municipality or intersects the feature, and that it has not already been added to the ids array
        if (road.globalid != $feature.globalid && (road[munileft_field] == munileft || Intersects(road, $feature)) && !Includes(ids, road[id_field])) {
            Push(ids, road[id_field]);
        }    
    }
}

// Find any roads were the range overlap on the right side and get their IDs
if (!IsEmpty(fromRight) && !IsEmpty(toRight) && (fromRight != 0 || toRight != 0)) {
    var search_string = fullname_field + " = @fullname" + " AND " + fromright_field + " <= @toRight" + " AND " + toright_field + " >= @fromRight";
    var rightRoadCenterlines = Filter(FeatureSetByName($datastore, "RoadCenterline", [fullname_field, fromright_field, toright_field, muniright_field, id_field, "globalid"], false), search_string)

    for (var road in rightRoadCenterlines) {
        // Test that the road is not the same as the feature, that it either is in the same municipality or intersects the feature, and that it has not already been added to the ids array
        if (road.globalid != $feature.globalid && (road[muniright_field] == muniright || Intersects(road, $feature)) && !Includes(ids, road[id_field])) {
            Push(ids, road[id_field]);
        }     
    }
}

 

SiteAddressPoint: 'Postal Address' calculation rule

On line 48 of the rule (line 2 in the snippet below) add "globalid" to the list of returned fields.

    // Get the related postal addresses
    var postalAddresses = Filter(FeatureSetByName($datastore, "PostalAddress", [pstlcity_field, pstlstatus_field, represent_field, "globalid"], false), siteaddid_field + " = @ID");
    for (var pstladdress in postalAddresses) {

 

PostalAddress: 'Postal Address' calculation rule

On line 30 of the rule (line 2 in the snippet below) add municipality_field, stateabbreviation_field, and status_field to the list of returned fields.

// Get the related site addresses, if there are no related records return
var siteAddresses = Filter(FeatureSetByName($datastore, "SiteAddressPoint", [fulladdr_field, municipality_field, stateabbreviation_field, status_field], false), id_field + " = @siteaddid");
if (Count(siteAddresses) == 0) return;

 

5 Comments
by Anonymous User
Not applicable

....

ChrisFox
Esri Regular Contributor

@Anonymous User at this time we have made the decision not to update already deployed items included with a solution. This is because after an item is deployed any number of changes can be made by the user. This makes it difficult to push updates to an item without breaking any customizations they may have been made.

There are some cases when a solution update doesn't require changes to a service or layer. In those cases we will not deploy a new version of the service, we may just deploy an updated map or app on top of the previously layer. So in these cases you won't have to move or re-load the data to new layers. However, when schema changes are required we will deploy a new version of the service with the updates.

This is something we are looking to improve in the future to reduce the need to ETL data between old versions of the service to a new version.

ChrisFox
Esri Regular Contributor

This issue with Pro 3.1 was resolved in the March 2023 (version 2.1) release of the Address Data Management solution.

LeoDCG
by
Emerging Contributor

issue still exists when downloading the solution from Enterprise FYI.

ChrisFox
Esri Regular Contributor

The version 2.1 of the Solution (w/ the fix) is also available in Enterprise 11.1. If you are using a previous version of Enterprise the Pro project will still have this issue, if you are just interested in the latest Pro project I would recommend deploying to ArcGIS Online as this will always have the latest version.