Map Series: Arcade Expressions for Fields

[DavidSolari]

Please add the ability to use an arcade expression for every map series field: name, page number, spatial reference etc. This would decrease the iteration time for map series where I'd have to copy out a layer to a geodatabase just to add and calculate map series specific fields.

[RoseF]

I think this would be very useful!

Just a tip, while we wait for possible implementation -- in the past, I would create a new field and populate it (often using the Field Calculator) with values that helped me with the Map Series options. This gave me results similar to the ones you're looking for, but it requires adding new fields to your feature class. Not very elegant, but I hope it helps!

[wayfaringrob]

It would be nice if I could write an expression that drives the page names. Currently, you are limited to fields in your index layer:

This doesn't always get the job done, and adding a new field isn't always desirable or possible.

[MErikReedAugusta]

I just came to suggest exactly this, because I have a case where I need to drive a rotation, but my map series is built against a feature where I can't edit values, let alone schema, and I was trying to avoid having to make a copy of it just to calculate my rotations.

If the functionality was there, I could've written a 2-second Arcade script to handle the rotation automatically.  Now, instead, I have to pull a local copy of this layer and divorce it from the updated data, just so I can add a temporary field to drive the rotation.

[MErikReedAugusta]

Right now, when you create a Map Series, you can target fields for populating certain datapoints, using the "Optional Fields" section:

I have a case, though, where my rows have a procedurally-generated tag that I'm using for sorting and other internal operations.  Within that tag, part is functionally equivalent to "Group By".

If I wanted to also group the pages according to that portion of the tag, right now it means I have to create a separate field, run a Field Calculation to rip out the Group code, and populate it into my separate field.  Then I point Map Series Group By at that separate field.

But, if I could use Arcade or Python, then not only could I pull that Group code out with two lines of code: I could also trust that it's always up-to-date.  With a separate field that I target with a Field Calculation, I have to remember to re-run that calculation anytime something might change in the data that would affect the group.

Alternately, if the Sort parameter accepted an expression, then I wouldn't even need my sort field—I could generate it on the fly from the attribute points that resulted in it.

[SSWoodward]

---

With a separate field that I target with a Field Calculation, I have to remember to re-run that calculation anytime something might change in the data that would affect the group.

---

A solution for this might be setting up an attribute rule to calculate this on insert/update.  Are you able to use attribute rules in this workflow?

[MErikReedAugusta]

Unfortunately, that's not currently an option for two reasons:

1. I don't have access to make schema updates on all of the layers I would potentially need this sort of operation for.
2. Many in our organization haven't been able to make the switch from Desktop to Pro, and we've discovered that having a single Attribute Rule on a Feature means it can't be opened in Desktop anymore.  So we're not building any Attribute Rules into the Enterprise until everyone that interacts with a given Feature is ready to make the switch.

Between those two issues, it means I can't do this with the majority of the data in our Enterprise.  I have to pull a dead copy of that data and then produce whatever I'm looking to produce.

And if the data changes and I need to produce a new map, I have to do it all over again largely from scratch, as opposed to popping open my project and outputting a PDF based on the then-current data.

[SSWoodward]

I can see why those factors would keep you from using attribute rules in your strategy. Thank you for the additional context.