Setting Defaults in ArcFM Data Migration… or Not
Your ArcFM Geodatabase includes (or at least typically includes) as part of its definition specifications for “default” values that will be assigned when the feature is created or, optionally, when a subtype designation is changed. Defaults may be defined for all features in a class, or assigned for specific subtypes in the class, but in either case the values will be assigned each time the feature is created. (Note that any values defined in any ArcFM Favorites will take precedence over defined Geodatabase defaults).
This is very useful standard behavior available with ArcGIS/ArcFM.
However, the question posed in this blog is: Do we want default values applied when we migrate data from your legacy mapping environment into your new ArcFM environment? There’s not really a right or wrong answer and we’re not going to promote one view or the other, but it is a decision that needs to be made when you begin the migration process design.
Before talking about pros and cons, we need to remember that we’re talking about a policy that will be applied to records that have field values in the source data that may or may not be assigned a value by the migration process. Any field that has a non-null value in the source data will be assigned a corresponding value by the migration.
So… with that, here are some pros and cons for your consideration:
Reasons NOT TO Set Defaults for Migrated Features
- How do we know? Unless we have some special knowledge about the data field (possible but not likely) we really don’t know what values should have been that are now left <null>. If we didn’t know what values to assign then, why is that now, after the fact we think we know? It’s been a long time since the old college logic class, but its seems there is some type of logical fallacy here.
- We would be applying different conventions than used in the legacy environment. By our decision to make use of default values for fields in our ArcFM Geodatabase we’re expressing confidence that, given a class and possibly a subtype we know what certain properties of each new feature we create will be. Back to our pole feature. If we now make use the default value [BUR] for FOUNDATIONTYPE, we’re confident within some margin of error that this is the predominant type of foundation, and if there is a different one our editing users will make a change to the field. But this was not the case in the legacy system – or else there would not be <null> values in the first place.
Reasons TO Set Defaults for Migrated Features
- Why would there be a difference between “migrated” and “new” features? If we can say with confidence that within our ArcFM implementation that, for example, every wood pole we create will automatically be assigned the default value of [BUR] “Set Normally in Earth” for the field FOUNDATIONTYPE, would this not also be true of poles created in the legacy mapping system? Why would the occasion of a data migration be the dividing point between a default value being assigned and not being assigned? This would seem fairly arbitrary.
- Help ensure attribute queries are valid for fields with default values. If defaults will be applied going forward, but not applied with the data migration, then an attribute query on a defaulted field will, to be valid, distinguish between migrated and post-migrated features. Sticking with our example of pole foundation type, say the migration assigned 10% of all poles a foundation type of [BUR] matching values in the source and 20% of poles had some other non-null value and the remaining 70% were all <null>. But after the migration no poles had a <null> because of our default value, and the vast majority had a foundation type of [BUR]. So our query suddenly shows that all new poles are “Set Normally In Earth” – but that’s just an artifact of our data strategy, no change in business processes.
- Use of default values was not available before. This is a simple one. Not every GIS or database application has the ability to assign default values to fields. It may be the case that we would have wanted to if we could, but couldn’t so we didn’t. And now that we can, let’s have at it!
So, there you go. Pros and cons for setting default values on migration. No doubt you can add “pros” or “cons” of your own. And again, we’re not promoting one approach over the other, but we do highly suggest that you make a conscious decision about which approach to take. If you’re interested in how this is done in code, check here.
Defaults and ArcFM Favorites
The presence of default values defined in the Geodatabase will be trumped by any values set in the ArcFM Favorite. This is easy to demonstrate. Below we see the result of a pole (SupportStructure) created from the normal ArcFM Features tab. The new feature initially takes on database default values.
However, if we use an ArcFM Favorite where the FOUNDATIONTYPE field is assigned a default value of “Set Extra deep in Earth” then that value will take precedence.
Setting Default Values in Code
The following code snippet is based on a sample provided in the Esri ArcGIS Resources.
