We look at how to use attribute domains to enforce some data integrity.

Who’s a good consistent typist?  I’m ceratinly certainly not.  Let’s say you had to add a bunch of data into a spreadsheet, maybe names of students and their degrees.  If you’re anything like me, it’s hard enough to get names correctly typed every time, but then think about if for each student you also had to correctly type in their full degree name, like “Bachelor of Environment and Society”.  From a database point of view, this might be treated as different from “bachelor of environment and society” (all lowercase) even if all the spelling was correct.  And “Bachleor of Enviromnent and Society” is clearly different.  As humans, we might recognise that “BES” represents the same thing, but not so with most databases – they are a lot more pedantic and far less forgiving.  With only a few records, you might be able to pull this off doing it manually, but as the numbers rise, it becomes more and more challenging.  At stake here is data integrity.

GIS is no different.  In a recent post we looked at digitising land cover polygons and part of the process there was to assign an attribute value.  In that post I flippantly showed a drop down list of options that could be chosen from in the table to make this easier:

We use Attribute Domains to set these up and here I’ll show you how that’s done.

First important thing to know is that there are two types: range domains and coded domains.

Range domains are used with numerical attributes to ensure that any entered values are within a preset range.  For instance, you might have a pipe network where diameter is an attribute.  But all pipe diameters have to be within a specific range.  Once a range domain is set, if you try to add in a value outside this range, you get a warning to stop you doing so.

Coded domains can used on different attribute types including text, numbers and dates.  As the name suggests, there’s a coded value and a text description for each entry.  We have seen this before when setting up an app to collect dragonfly observations where species names would be impossible to type correctly every time.  I challenge you to type “Pseudagrion microcephalum” 10 times, using your phone keyboard, in the tropical heat, while hanging from a banyan tree over a tepid pool and get it right every time.  I tend to use coded domains a lot more than range domains.  In the Mt Grand case, this ends up as a the pre-selected list of land cover classes that users select from as we saw above.

Another important thing to note is that domains belong to a geodatabase, not a particular layer.  We set up the domain at the level of the geodatabase and then any feature class within that geodatabase can use it.

Here’s some detail on the Mt Grand land cover domain.  This started as a list of entries that were needed.  If I look at my project geodatabase in the Catalog pane and then right-click on it, Domains is one of my options.  When chosen, the Domains window opens up:

To the left are details about this particular domain: it’s a coded value domain on a text field.  The Split and Merge policies relate to what happen with naming when we’re editing features with different codes (big topic…I’ll kick it to touch, but see here if you’re keen). On the right you can see the Code and the Description for each.  Again, this belongs to the geodatabase but is available to any feature class within it.  Let’s say I’ve got a polygon layer that I’ll use to create my different land covers called NewLandCover.  I’ve added a text field called LandCover with a length of 25 characters to hold these data.  In its current form, the attribute is free text, meaning I can type whatever I want in each cell:

At the feature class level, the domain can be assigned to appropriate attributes.  Do this by opening the Fields View for a layer’s attribute table (with a table open, click the three horizontal lines at upper right, , and pick Fields View.  This opens up a new window focused on the attributes:

This is where we can add or delete new attributes and set their properties (but not the only place I can do this).  Notice the “Domain” column.  None of these layers has a domain set up but the LandCover text attribute could use it as it’s text.  To enable it, click in that attribute’s Domain cell and you’ll see a drop down menu with any available domains on the geodatabase :

Once these changes have been saved, the drop down list of choices will display whenever I click on this attribute:

In fact, I can’t even type directly into this fields – my only option is to pick from the list.  This allows me to enforce some data integrity and make sure whoever is working with this layer will add in acceptable values consistently every time.

So how do we set up a new domain?  It’s pretty straightforward.

Back in the Catalog pane, find your geodatabase, right-click it and choose Domains.

Click New Domain: 

Give it a name and a useful description and chose the field type and domain type from the drop down menu:

Add the codes and descriptions:

And now it’s available in the Fields View:

Nice. Only one question remains:

C