Access a field value in a layer that is outside the edited layer's $datastore in Arcade's Attribute Rules profile

[JeffWard1]

I'm trying to populate a field in my Site Address layer with the Parcel ID of the intersecting parcel. After making several attempts and researching the docs I'm finding this isn't possible? I am unable to use FeatureSetByName because I can't access the $map global because I'm using ArcGIS Pro. And I can't use $datastore because my parcel layer is in another location. Is that correct? Right now my solution is to copy the parcels to the same file gdb as my site address layer and use that layer for my intersecting features.

The documentation isn't very clear on the $map global only being available in ArcGIS Online. Every time I try to use it in my attribute rule expression it says $map object is not available. The docs say I can use it in the Attribute Rules profile, but all I get is this:

Here's a paragraph from the docs saying I can use it in the Attribute Rule profile:

A collection of FeatureSets. This data type is only used when working with the $map and $datastore globals available in the Popup, Field Calculate, and Attribute Rule profiles. The $map represents a collection of layers (or FeatureSets) in the map of the feature executing the Arcade expression. The $datastore represents a collection of layers in the same feature service as the feature executing the Arcade expression.

I would really like it if I didn't have to copy my parcel layer over to the same geodatabase. Has anyone done this? Xander Bakker‌ - any thoughts?

Thanks

Jeff

[XanderBakker]

Hi Jeff Ward ,

If you look at the profile information (Profiles | ArcGIS for Developers ) for Attribute Rule Calculations you will see that you can only use the $datastore to access the data. 

I thought that maybe the FeatureSetByPortalItem could be a valid alternative, but it can only be used with Field Calculations and in the Popup.

So, unfortunately it is not possible to do this with Attribute Rules. Attribute Rules live in the database and I guess that this is the reason for not allowing information that is not in the same $datastore to be used in the Attribute Rule.

Attribute Rules‌

[JeffWard1]

Thanks Xander Bakker‌ for the clarification. I submitted feedback on the FeatureSetCollection documentation that muddied the waters for me. I will move all of my editing layers to the same file geodatabase so I can take better advantage of attribute rules.

[JoeBorgione]

Jeff-  you might try creating a database view of your parcels in the same datastore your others reside within.  I was going to do that but since the parcels I deal with are a subset of all the county parcels we just copy those in our areas of jurisdiction from the county service into our enterprise as a scheduled task.

edited to add...

Here is a copy of the rule I use to grab the parcel id from an underlying parcel layer:

var parcel = FeatureSetByName($datastore,"MSD.SLCOMSD.ParcelsMSD",["parcel_id"],true)
var intersectLayer = Intersects(parcel, Geometry($feature))
if (Count(intersectLayer) > 0) {
    var layer = First(intersectLayer);
    return layer.parcel_id;    
} else {
    return null;
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

This is thanks to Xander Bakker‌; the if else statement is critical.  Even though you know there is always a parcel coincident to your site address point, when you validate the expression, it'll choke and error out.

Jeff Ward‌

Jeff Ward‌

[JeffWard1]

Thanks for the input Joe. The way I'm understanding views is they reside in the same database as the source data? I'm working with file geodatabases - is it possible to create a view to a layer in another file geodatabase? Do you have samples you've used?

And thanks for your sample, I was able to get my expression to work using similar code, but I'm sure Xander Bakker‌ 's is better for error checking. Here's my expression, it works for the few address points I've done. I had it check for more than 1 because sometimes our parcel data overlaps and I had it flag it for investigation.

var intersectLayer = Intersects(FeatureSetByName($datastore, "TaxParcels"), $feature);
if (Count(intersectLayer) > 1){
 return 'insert serial';
}
else {
 for (var f in intersectLayer){
 return f.PARCELID;
 }
}‍‍‍‍‍‍‍‍‍

[JoeBorgione]

The database view resides in the same database as your site address points so (in theory) it acts like any other feature layer in $datastore.  Let me contact my esteemed colleague Ryan Sadler‌ : he creates them on the SQL server side.

[RyanSadler1]

Joe is correct.  You can create a view in the database that is basically a saved sql query of the columns you need.  The t-sql syntax follows this structure..

CREATE VIEW [OR ALTER] schema_name.view_name

AS select_statement;

I've even had success creating views that cross databases that are on the same SQL server instance.  Attention to permissions just comes into play.

Here's a good link that talks about views in detail for your geodatabase...

Views in an enterprise geodatabase—ArcGIS Pro | Documentation 

One important step to do after creating the view for the SQL server is that you need to register the view with the geodatabase using Esri tools afterward.

Also, be sure to include a shape column in the select statement if you are wanting the view to be a feature class.

I hope this helps.

[JoeBorgione · Accepted solution]

Jeff Ward‌: the thing with views is they work great for enterprise to enterprise (SDE) databases.  If your site address points reside in a fgfb, your options may be limited to:

Moving your site address points (and any other address point related data used in your rules) to the database where you parcels are. (basically what I do)

or

Copy your parcels to the fgdb where your site address points reside.  That's not a difficult option; what I'd do is create an empty feature class of the parcels but only use the fields you need for the rules to fire.  If all you need is ParcelID, that's a fairly simple feature class. Append your parcels to that f.c.

Then you can use a truncate followed by append to keep your parcels in the fgdb fresh as your authoritative parcels change. 

[JeffWard1]

Thanks for the help Joe. I ended up moving my layers to the same file geodatabase. They were before, but I was trying out the Address Data Management project package that had its own fgdb with the attribute rules set up in the project.

[MarcusArreguin3]

Does anyone know if anything has changed yet as far as accessing an alternative to $datastore such as $map? I tried using $map as in the original question and got the same error.