The Setup & Situation:
I have a map series I'm producing right now to display the results of a complicated analysis of stormwater pond Assets. By the end of things, I've ended up with two subgroups that need to be in the same report with 99% the same layout/visible layers. Two of the chief differences are whether the Parcel layer data is visible or not, and what % of padding to add to the scale around the feature. (Set A shows extra parcel data with a 200% margin; Set B shows simplified parcel data with a 100% margin).
The simplest (relatively speaking; I wouldn't call this "simple") way I could see to do this was to split my Map Series into two components, and join them in Acrobat into a single document.
The Problem
My Map Series changes can be accomplished by duplicating the Layout and setting a different Series in each. I can even make use of "First Page" in my Set B to make sure my page numbers are properly contiguous as if they'd been the same.
But I also need to change layers. This means I have only two options:
- Both Layouts use the same underlying map, and I manually turn layers on/off prior to each export. This also means I have to repeat this manual operation every time I need to re-export, which increases the odds I'll forget one.
- Each Layout uses its own underlying map, so I can make the layer changes and they'll be baked into the design.
Obviously, Option 2 there is more robust & preferable. But if I do that, then I run into a host of issues from things pointing to the old pre-fork map. So far, I've run into the following things that all depend on a specifically-targeted Map and/or Map Frame:
- The Map Frame, itself
- The Legend
- The Scale Bar
- The North Arrow
- Map Series
- Dynamic Value fields that use "Insert Table Attribute" to target a specific layer on the map.
- I ran into two issues on this one. First, if the Map Frame in your duplicated Layout has the same name as the one in the original, then this dialog won't realize that anything has changed. I had to first rename the Map Frame to be something different, and then update this.
- Second, when you change the Map Frame target, it wipes out the targeted feature within that Map, as well as any expression you'd entered. I had to reselect/rebuild them manually.
I'm still working through this, so I'm not going to be at all surprised if the above list is missing multiple other similar cases. Thankfully, #2-5 all seem to redirect automatically when you do #1. The dynamic values in #6 were a big headache, though, because I had several such fields, and I had to each one individually.
Proposed Solution
Add the option to "Fork" a Layout that automatically also forks any embedded Maps, and redirects all functions accordingly, even if it's just via a GP Tool. There have been countless times that I've started from one combined project, only for things to diverge enough that I needed to spin part of it off into a new map. Duplicating the map and then making changes is usually the way to go, but when Layouts are also involved, things start to get complicated & tedious fast.
In theory, I could possibly write such a tool, but it would take me a lot more time and R&D than I can afford right now, especially since I don't know the CIM model all that well, yet, and that seems to be part of the "Insert Table Attribute" dynamic values.
