Attribute Rules, evolving

381
8
Jump to solution
11-05-2019 12:15 PM
Highlighted
MVP Frequent Contributor

It's been a while since I last looked at Attribute rules, and the last time, the geomerty features weren't really....useful. Now it appears you CAN fire attribute rules based on geometry relationships with other layers! 

Looking at the example here Attribute Rules: What’s new in ArcGIS Pro 2.3 and ArcGIS Enterprise 10.7 , I see I can do a buffer and intersect spatial query, and Geometry Functions | ArcGIS for Developers  shows that within is possible, but just a count of within. What I'm interested in doing is calculating a field of a point based on what polygon it falls in. E.g if point is within the sasquatch territory polygon, the bigfoot field gets "yes", if it falls within the yeti territory polygon, it gets "no". Is this yet possible with Pro and Arcade? I think not? Any examples of this type of attribute rule? 

Tags (1)
1 Solution

Accepted Solutions
Highlighted
Esri Notable Contributor

Hi Tom,

Did you know about the github repo where people can share their expressions?

Share your Arcade expressions as templates 

I think that this one could be modified to do what you're asking:

arcade-expressions/CopyValueIntersectingFeature.md at master · Esri/arcade-expressions · GitHub 

View solution in original post

8 Replies
Highlighted
Esri Notable Contributor

Hi Tom,

Did you know about the github repo where people can share their expressions?

Share your Arcade expressions as templates 

I think that this one could be modified to do what you're asking:

arcade-expressions/CopyValueIntersectingFeature.md at master · Esri/arcade-expressions · GitHub 

View solution in original post

Highlighted
MVP Frequent Contributor

That is EXACTLY what I was looking for, and it worked. I now have 1,303,432 questions about attribute rules, but the take home is, I think they're going to solve a lot of our data management problems that arose when we stopped using SQL triggers. 

Highlighted
Esteemed Contributor

Why can't you continue using SQL triggers?  Did the latest version(s) of SQL Server not support your legacy workflows?

Reply
0 Kudos
Highlighted
MVP Frequent Contributor

Pro is the reason. Here's a short version of a very long story:

Back in the ArcMap, un-federated server days, we accomplished a LOT (90%) of routine data management with triggers. We're collecting thousands of new points weekly, and most of them have a very long list of what we call "Administrative Boundary" requirements: "What state is this in? What District is this in? What Watershed is this in? If it's above 4000' elevation, it gets this attribute". For our core data standard, there are about 20 of these, with some protocols (e.g NWI wetlands) having 30. SQL triggers handles most if not all of these spatial queries since we were using versioned: move edits directly to base with no child versioning. The important thing here is that this worked with ArcGIS Server Offline Feature Services (Right click, download local copy for editing), as being able to edit a feature service directly has never been, and never will be, an option for us. It's not a bandwith issue, it's a concurrency issue, and that's as much as I want to say about it. 

Now Pro. 

In order to be able to take feature services in Pro offline, we have to enable archiving on the SDE feature classes. Managing Archiving AND Versioning turned out to be a nightmare. So away went the versioning. Turns out with just Archiving, SQL triggers cause all kinds of havoc. We found other non-GIS issues related to triggers in this workflow, and have since banned them, as we also hang related non-GIS tables off the versioned-views (business table) and found the triggers are also breaking referential integrity. I've replaced the triggers with even more complicated python tool boxes that mostly automate everything, but still require the unhappy user to have to select something and push a button, whereas in the past, it was 100% automated. And the python witch magic is only available to my shrinking population of desktop users, as we're drinking the Kool Aid and pushing everything we can to Portal and WAB's and yanking access to desktop, because we can't afford the hardware requirements for Pro. 

Take home message: 

I used to think myself very clever for all the SQL scripting I did to make the triggers work, some of them very complicated. Now whenever something goes wrong in SQL, people wander around with bloodshot eyes for days muttering "Colson's damned triggers", and I covertly delete them and reply "nope, it was a hard drive failure, fixed it!". 

So we're back full circle, and it looks like Attribute Rules will do the same thing. Yay for attribute rules. 

Highlighted
Esteemed Contributor

Just to be clear, when you said that your org is drinking the Kool Aid and going to Portal instead of providing Pro to all of your current ArcMap users, does Portal mean an on-premise Portal or AGOL (ESRI's public portal)?

Reply
0 Kudos
Highlighted
MVP Frequent Contributor

We use both platforms, but use Portal and Web Application Builder apps to replace most of what users were needing desktop for. I say "most", as most editing and data management functions can be performed in a WAB. Some of the new stuff in AGOL, that is not yet in Portal WABS, like move a point using an XY value, is sorely needed but our upgrade path is pretty slow. My unrealistic, unicorn rainbow dream is to completely eliminate desktop all together. If we look at all other business applications that 90% of an org's users need for 90% of that org's work, it's all web-based. When I say web-based, I mean the application itself is a web app, not porting Pro through HTML-5 clients from AWS remote app hosting, because then I'm still managing Pro. Some internal discussions (at my workgroup level) have hinted that I better find a solution in that direction, as spending 5 or 6 figures on GIS computers every 4 or 5 years will never happen again. Why do you need GPU video cards and lots of memory? The budget and the HR people can do their jobs perfectly fine with web apps.....

If I use WAB Developer Edition, I can move a few more folks to web only, but we're discouraged from "Writing custom applications". 

Highlighted
Esteemed Contributor

Thanks for the info.  I'm just curious how you handle data that is tied to an Attribute Rule as it will no longer be accessible to ArcMap.  Does this limitation of Attribute Rules create headaches for you such as needing two versions of the same data with both versions being kept in-sync?  Maybe you have worked around this issue in another creative way?

Reply
0 Kudos
Highlighted
MVP Frequent Contributor

I am a long ways from rolling over this new attribute rule thing, and will probably limit it to the .001% of my data that I can completely manage in Pro.