How Can We Update Our Data to Reflect Our Data Model Changes?

September 6, 2013 — Corey Blakeborough

There’s a specific scenario that seems to be all too common out there today. Changes to the data model in a GIS environment are frequently made, but the actual underlying data remains as it was before. How can you change the value of every LABELTEXT field easily if it’s driven by autoupdaters that were just modified? Or how can you easily recreate or update a feature’s annotation when a new annotation class is added, or an existing expression was changed?

These are issues that I have frequently encountered recently, and they call for an easy-to-use solution.

The approach to problems such as this normally manifests itself as a script. This answer is not much different: a night-run batch application that processes a given version and makes changes to each object. But there are a few special components of this idea that make it more interesting.

 


Here are the elements of control that one needs in order to perform these mass updates:

Run Only the AUs You Want

A lot of the apex of control necessary for large-scale changes like this resides in the ability to control the granularity of configuration you need in order to accomplish your goals. For example, as we’ve discussed previously, AUs can get in the way of your mass updates. So we’ll turn them off. But what if we still want a specific AU, like your theoretical new LABELTEXT AU that pulls from related objects and makes your data look amazing?

Well, we’ll have to manually find and execute any AUs that you need run against each object in a given class (assuming the AU is enabled for it). To save time, we can include an option to only store the features after this process if fields have actually been modified.

You’d be able to add any number of compatible AUs to run against a feature or object class, but the key point is being able to control what gets fired and what doesn’t, without changing your configuration. No more Feeder Manager updates during your mass edits!

Manage Related Objects Efficiently

An AU doesn’t always cover the entire spectrum, though. Annotation is a huge example. It’s true that sometimes, annotation needs an AU to manage a field on the related feature that drives its text display, but this isn’t always the case.

Features like annotation use built-in Esri events to get updated. Esri tells the annotation whenever a related feature has updated, and the annotation feature then knows that it needs to re-evaluate its text expression and update its text.

AUs have no part in this process. As a result, we’ll have to give an option for specific related classes (either every related class, classes of a certain type, or specifically-named classes) to be told that their related feature was updated, just like its parent was. So when you make annotation expression changes, running this application would allow every expression to be re-evaluated, and all you had to do was start the program.

But there’s more on this one. Sticking to our annotation example here, annotation only updates its text when it sees that a parent feature is updated. What if you added new annotation classes to your annotation feature class? They won’t be created at all during an update. You don’t deserve to have to fix this manually, either.

Cases like this call for a slightly elevated scenario where we’ll need to allow designated eligible features to be deleted. The eligible relationships between these features can be told that a new parent feature was created, causing the related objects to perform specific functionality.

In the case of annotation, this functionality is to recreate the annotation. It’s incredibly difficult to recreate all annotation classes at the same time en masse if the features are already created, so we trick the annotation into thinking that its parent feature was just created in order to achieve the same results.

This is becoming incredibly useful. And sometimes, we want to only conditionally perform recreation on related features, so we’ll add in an option to only run the aforementioned recreation logic in the case of a feature already being (or not being) present.

Plugin Access for Easy Additional Manipulation

This is already a very versatile tool at this point, and once the tool is running successfully, you will probably anticipate seeing more requests flow in to add more steps to processing.

For example, what if you need to drop and recreate annotation for a feature class, but the existing annotation was already moved, rotated, and placed nicely and you don’t want to lose all that work? We’ll add functionality to store the position and rotation of existing annotation and apply it to the new annotation after it’s recreated. It’s as awesome as it sounds.

We want to allow things like this to be added to this sort of tool, but we also don’t want to make the tool too specific. Its versatility is key and we don’t want the code muddled with a bunch of very specific scenarios. If we dilute the tool with too many custom options, things can get a little complicated. We want to stay generic.

As we move forward with a variety of requests to make the tool even better, plugins seem to be the best course to this problem. We can keep a straightforward tool and build extra functionality to be integrated into the application if the user so chooses it.


Not much is missing now. We will need to make sure that the solution supports very large jobs by being able to split the load and process multiple versions simultaneously to save time. We’ll also want an option to reconcile, post, and compress every once in a while if we have an incredibly large amount of edits in certain environments.

In the end, we arrive at a solution that runs at night and can support a variety of options. Here’s an example: want to re-run LABELTEXT AUs against a feature where it’s only enabled on a few subtypes, make sure that a certain type of annotation is updated on the other subtypes, and have a third type of annotation be recreated entirely? This can be done in one program execution. The versatility of options and ease of use allow for a truly powerful solution to many issues arising based on data model changes.

Everyone has slightly different needs, but if you think that a custom-made data refreshing application might be for you, feel free to give us a shout and we can talk more about how something like this can be done specifically for you.

We Wrote the Book

The Indispensible Guide to ArcGIS Online

Download It for Free

Corey Blakeborough

Pre-Sales Architect

What do you think?

Leave a comment, and share your thoughts

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>


This site uses Akismet to reduce spam. Learn how your comment data is processed.