nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Add Arcade Globals for Visualization/Symbology Execution Profile

AnnaEssington

I have a use case that incorporates the $map arcade global to update symbology for a layer but currently the only globals for the visualization profile are $feature, and $view.scale. It would be nice to have the $map global included in the visualization profile.

For my use case, I have a need to update the symbology of a census tracts layer so that when 20% of the housing units in a census tract are LIHTC (Low Income Housing Tax Credits) the symbology is different. I wrote an arcade expression (screenshot below) that sums up all the housing units in the LIHTC layer that intersects with a census tract, and then compares it the total housing units in the census tract to see if its more than 20%. This code works in a pop-up since pop-ups have the $map global.

Find more posts tagged with

Annotation & Labeling

Closed

Status: Closed

Comments

JohannesLindner

That would be helpful. Also, do the same for $datastore and for the labeling profile.

Though my guess is that evaluating this expression for each feature shown in the map each time the map is updated is going to be very slow. But for small datasets this would be great.

In the meantime, you can add a field to your FC and calculate it with your expression. This works for more or less static data, but is too much of a hassle for regularily updated datasets.

KoryKramer

@JohannesLindner regarding "In the meantime, you can add a field to your FC and calculate it with your expression. This works for more or less static data, but is too much of a hassle for regularily updated datasets." Couldn't that calculation be set up as an attribute rule so that the value would stay updated even with a changing dataset?

https://pro.arcgis.com/en/pro-app/latest/help/data/geodatabases/overview/calculation-attribute-rules.htm

AnnaEssington

Great ideas @JohannesLindner and @KoryKramer. However, currently the census feature I'm using is a hosted feature from the living atlas so I'm not able to add a field or edit the data.

JohannesLindner

@KoryKramer Yes, absolutely. I do this in my database. But that only works when data inside your database changes. In Anna's use case, you would define an Update Attribute Rule on the LIHTC feature class that runs her code and updates the intersecting features.

If the data is outside of your database, this isn't possible (?).

Imagine you are using census or parcel data. You don't author this data, you just use it in your map. It's not part of your database. You can only read it.

You could copy this data into your database and define the appropriate Attribute Rules. When the authority changes the data, you update your tables accordingly. That seems cumbersome and error prone, and you lose the advantage of directly using the authorative data.

In a case like this, I'd argue it's much simpler to just create a field in your table and recalculate it regularily or when you know the determining data changed.

Or, and this is the core of this idea, make the whole process dynamic by allowing the $map (and $datastore) global in the visulisation (and labeling) profile.

JohannesLindner

Just had a look at the Arcade profiles again. The calculation profile doesn't allow $map either, so my approach wouldn't work, anyway...

williamscraigm

There are no plans to extend the labeling or visualization profiles to include FeatureSet functionality for performance reasons. Label and visualization expressions are executed on a per-feature basis and a feature set query executed per-feature would slow down draw performance.

For this use-case the recommendation is to use a calculate attribute rule where the script is executed at data creation or update time rather than once per draw loop. FeatureSetByName can be used to perform FeatureSet lookups with any other dataset in the same workspace. Cross-database cases are not currently possible but an idea to support that for future workflows could be submitted for conversation.