nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best practices with using domains?

MDB_GIS

Is there any reason not to use the fully qualified attribute in the 'Code' column as well as the 'Description' column? I have been using numeric codes for a while now but they are sometimes a bit annoying to deal with. Specifically if I ever export the data. I'm contemplating just converting the field to a text field and using the fully spelled out attribute for both columns. Are there any real reasons not to do this?

Find more posts tagged with

Content Management

Geodatabase

Accepted answers

MErikReedAugusta

We have sort of a hybrid between the two approaches.

I abhor the numeric-code-with-text-alias approach to Domains. I get why it was used in the past, but as others have said: Data storage and throughput capacities are at a point these days where that has increasingly weakened utility, unless you're working with absurdly gargantuan datasets and long, complex calculations.

I interface with non-GIS people all the time, which often means spreadsheets are also going to get involved, and there's too much chance for error with the number/text combo approach.

On the flip side, though, there are plenty of values that are poor practice to allow into the raw data of your attribute table. For example, in our stormwater data, we had a condition domain that had as an option "Clogged > 20%".

That greater-than sign breaks all kinds of operations and generally just makes life needlessly difficult. So now that greater-than sign exists only in the Description/Alias. The raw code beneath just says "Clogged". (It was the only clogged value we had, otherwise it would've been "Clogged_20")

Other characters recommended to avoid in your raw code value, if you can afford to do so:

Ampersand (&)
Percent sign (%)
Less than & Greater than (<), (>)
Parentheses (()), Brackets ([]), or Curly Braces ({})
Double quotes (") and the angled/curly variants thereof
Single quotes (') and the angled/curly variants thereof
Spaces (this actually isn't that much of an issue. But some operations might be ever-so-slightly easier without them. This is a pretty small list, though, so grain of salt on excluding this one. We do typically replace our spaces with underscores for consistency & clarity, though.)

I also tend to avoid special characters that aren't on a standard keyboard, like the degree sign (°). They're not likely to cause problems with most operations, but on the rare case that someone's running a field calculation or something similar where they need the raw value, it just makes it a little bit easier for them to write & run that code. I also used to do this for unicode/plain text reasons in Python, but that's not really an issue anymore, since Python 3 switched to a baseline assumption of unicode.

It also helps avoid confusion in cases where there are multiple similar characters that could be easily confused, like the the degree sign (°) compared to the masculine ordinal (º). They're different characters with different purposes and code points, but to the average end user, they look identical in most fonts.

That's a situation ripe for errors.

All comments

MErikReedAugusta

I haven't encountered too many issues in SQL that I can remember, but they do occur with ampersand and less-than / left-angle-bracket in places like labels & text, for one. See my recent ideas post for more on those.

The single quote and percent sign are both reserved characters in SQL, so that could potentially cause you unnecessary headaches in your queries.

Other places you could theoretically encounter issue are automations & integrations outside of the Arc walled garden, because many of those characters are traditionally reserved characters in various coding languages. The quotes will be especially problematic, since any value that contains these characters can be presumed to be a text value, and nearly all coding languages use single and/or double quote to indicate a text string.

I don't remember the specific problem we were having with "Clogged > 20%", but it could theoretically have been the greater-than or the percent sign that triggered it. I do remember having to always account for it when I scripted things, for some reason, though. It got tedious, and gained us nothing all that valuable, so we changed it.

fklotz

@MErikReedAugusta Thanks for this thoughtful answer. I may have just been lucky so far or haven't done certain processes against the data where special characters were used in the domain codes but I don't recall running into any issues using special characters in Esri coded value domains in file geodatabases, SQL Server based enterprise geodatabases and ArcGIS Online. We don't often use special characters but have not always removed them and I may not be doing the things you have done to result in issues. I'm working for a municipality that has a standard in their enterprise GIS databases to have the code == value in their coded value domains, therefore I'm very curious if you could provide any specifics on this statement you made: "That greater-than sign breaks all kinds of operations and generally just makes life needlessly difficult." I'd like to use that information to limit any future issues we may have and maybe inform the municipality to get the standard modified.

BB1234

Short codes (just a few letters long) are handy for keeping SQL queries concise and readable.

select
    *
from
   active_transportation
where
    type in ('S','T','PP','MUP',...)

Users in our organization know what those codes mean; the codes aren’t too cryptic.

Sidewalk
Trail
Park Pathway
Multi-use Path

It’s also easier to remember a short code.

Like you mentioned in the original question, the other option is to use the full description as the code (code and the description are the same).

We have lots of lengthy descriptions with hyphens, brackets, etc. I wouldn’t be able to remember the exact spelling/wording/capitalization of those descriptions when writing SQL queries. So I wouldn’t want to make the codes be the same as the descriptions.

But I do like the simplicity of making the codes the same as the descriptions from a data entry/data integrity perspective. It would avoid the risk of the user entering the description when they should have entered the code (using the field calculator). It’s too bad there isn’t an OOTB way to prevent users from entering non-domain values in ArcGIS, using the field calculator, etc. Prevent non-domain values from being used (across the board, including GP tools)

KimOllivier

Actually you cannot use numeric codes for text fields any more at ArcGISPro in domains.They only allow ranges with digits.

It does half work in ArcMap but the text is always right justified and the widths go wonky. So even if you want to use digits, for say sorting they have to be character strings. I still hate this because our postal service uses leading zeros. My postcode is "0626" but if Excel get hold of that it morphs into 626 and so on.

Sometimes export tools allow you to choose between the code and description but since I am a programmer the codes will do just fine because you Have to use the code in SQL expressions anyway.

MDB_GIS

This was precisely the issue I ran into. It doesn't happen often because I try to stay away from shapefiles, but it is unavoidable with some of our departments, and it drives me nuts having to decipher the codes.

MDB_GIS

Very thorough and helpful answer. Thank you!

BillFox

We adopted the practice to keep both sides the same because when the feature class was exported it only held the code numbers which were pretty much useless without the user have a comparably lookup table to join with it.

ZachBodenner

That's a good point @jcarlson . I think the upshot is that, as with all data construction things, the end-user needs to be considered first and foremost. Are you the only one who manipulates this data? If so, what works best in your mind? Will you get turned around by codes that like the ones described in jcarlson's example, or does that make sense for your mind? Will anyone else be doing edits, especially in batch? How important is very consistent data entry to you? There's a lot to consider.

jcarlson

Agreed, codes sound nice at the outset but become a standard GIS joke. "What is a '13' in this layer, again?"

Like @ZachBodenner 's hypothetical, we do have some surveys where the question responses are things like "strongly disagree" and that sort of thing, but which we want coded to a numeric value for scoring purposes. But otherwise, I like to have the codes more descriptive if I can.

I will say, though, that we do not use the same exact value on both sides of the domain. Sometimes I have a displayed value like "no action required at this time". When I'm working with that same layer elsewhere, particularly when I'm using some expression or coding language like Arcade and Python, long values with spaces in them get very tedious and sometimes problematic to work with.

I try my best to keep the codes concise, but obvious in their meaning, so that they can be used as-is if needed. This will often be a common abbreviation, or a short version of the label. "not_needed", "processed", things like that.

MErikReedAugusta

We have sort of a hybrid between the two approaches.

I interface with non-GIS people all the time, which often means spreadsheets are also going to get involved, and there's too much chance for error with the number/text combo approach.

Other characters recommended to avoid in your raw code value, if you can afford to do so:

Ampersand (&)
Percent sign (%)
Less than & Greater than (<), (>)
Parentheses (()), Brackets ([]), or Curly Braces ({})
Double quotes (") and the angled/curly variants thereof
Single quotes (') and the angled/curly variants thereof
Spaces (this actually isn't that much of an issue. But some operations might be ever-so-slightly easier without them. This is a pretty small list, though, so grain of salt on excluding this one. We do typically replace our spaces with underscores for consistency & clarity, though.)

That's a situation ripe for errors.

ZachBodenner

I'll add on another thought in regards to anxiousness about long descriptions and special characters: i recently had a natural resources professional ask for a new domain for tree species names that included the botanical name as typically noted, so for example, the full Description of the domain would be "Red Oak (Quercus rubra)". My first thought was to have Code of the domain be just the common tree name (Red Oak in that case) and then have the code be the full botanical name. Ultimately I decided against it because even though botanical names can get cumbersome, especially with spelling, I foresaw the NR staff entering tree species names via the field calculator, and if they didn't use the options within that tool to ensure domain usage, there could easily be mis-entered data. So, I went against my personal better judgement and actually used the whole botanical name for both code and description (plus, some times a tree's common name can be the same even if they're different species, but that's a whole other issue!).

clt_cabq

once upon a time because of storage and data processing limitations codes either numeric or shortened/abbreviated values were needed but these days there is almost no reason for implementing this kind approach. I start to get anxious about long cumbersome descriptive terms, and sometimes processing a short uninterrupted string of values is easier than working with text that includes spaces, characters like hyphens and such. As long as you are considering how you process and display the data - for instance if there is some sort of ordering inherent in your data then you may want codes that reflect this so that you can sort or rank data appropriately, by and large you should make your codes mostly human readable.

ZachBodenner

I honestly get very turned around when the domain code is different from what you see in the attribute cell. I can imagine a case where you have qualitative data that's ordered in some way (likert-scale-style) where one value actually does fit in as "1" and on down the list, but I nearly always have the code and description match.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.