ArcGIS Online

Transform your layers’ value with more functional attribute field names, aliases, and descriptions

What’s in a name? That which we call a rose. By any other name would smell as sweet.

Juliet Capulet

Wrong! There’s a lot in a name. Just ask any expectant parent trying to decide on a name for their child. Names are important, not just for people, but for your layers’ attribute fields!

What is a naming convention for attribute fields?

I think of field names the same way I do about complex words in English: as having a prefix, a root, and a suffix. Even if you’ve never heard the word “acrophobia” before, you might be able to get there by realizing that “acro” is a root that means height (think “acrobat”) and “phobia” is a suffix that means fear – fear of heights!

Prefixes and suffixes in field names help communicate the meaning of your field in a similar way. For example, for binary variables, variables that can only be yes or no (1 or 0), I often use the prefix “is” or the suffix “_flag”. Here are some examples:

When categorizing a continuous variable such as age, or minutes spent commuting, I tend to use my own personal shorthand of LT, LE, GT, and GE:

As you create more and more layers, you’ll undoubtedly come up with your own consistent naming conventions that make sense for your data needs. The key word here is consistent. Lastly, pick camelCaseVariableNames or underscore_variable_names and stick to it. Maybe you do an underscore after some ID number, but camel case for the rest. It’s a personal preference, but consistency is valued!

If you are building a layer that others on your team will use at some point, or that you might use several months from now, do yourself a favor and spend minutes to save hours later on. Good field names also help coworkers get up to speed quickly during collaboration. These types of naming conventions help when layers have dozens or even hundreds of related attributes, and you need to be able to make sure you’re using the right one for the right purpose.

How does this work on a real layer?

In my energy workers employment and wage layer, the prefix is the units of the wage (“h” for hourly or “a” for annual), the root is the value itself (e.g. “median”), and the suffix is the detailed occupational category (Bureau of Labor Statistics’ Standard Occupational Classification, or BLS SOC, for those who really want to know the details). For example, the field called h_median_499081 is the median hourly wage of workers with BLS SOC number 49-9081, which happens to be wind turbine service technicians.


Convey information about the original source

This energy workers employment and wage layer was originally a series of spreadsheets from the Bureau of Labor Statistics, with all kinds of metadata. My field names are a place for me to provide the exact identifier of the occupation classifications, which makes the value my field really is storing unambiguous.

Allow other analysts to work with your layer’s data quickly

Anyone using your layer with any kind of SQL logic will thank you for a consistent naming convention. Consistent field names make it easy for programmers to do systematic data transformations. For example, programmers can drop all of the annual wage fields (if the field name starts with an “a”, then drop), or multiply all hourly wage fields by 40 to get an approximate weekly wage (for all fields that starts with “h”, multiply by 40).

Easily communicate what your fields are with display aliases

I mentioned that my attribute field h_median_499081 is the hourly median wage for wind turbine service technicians. ArcGIS Online allows you to give your fields display aliases to communicate this using natural language. Aliases bring explanations into the layer in a user-friendly way. Aliases are much more accommodating than field names:

ArcGIS Online rewards layers that have aliases by using them throughout the whole product

They are visible in the auto-generated legend for the attribute you’re mapping. Here I’m mapping the count of employees who are wind turbine service technicians, attribute field tot_emp_499051. Nobody wants a legend that says “tot_emp_499051” when it can say “wind turbine service technicians” instead:

They are visible in Change Style view. If a layer does not have field aliases, you see the field names. If a layer does have field aliases, you see them when changing the map’s symbology:

In the attribute table view, the aliases appear as your field headers:

And, my favorite, in the fields list (under the Data tab in the Item Details), where you can sort your field names alphanumerically. You can even include a long description for each field with all the gory details. Here, I’ve done this by incorporating the long descriptions that the Bureau of Labor Statistics has for each occupation. Descriptions go that last mile, providing additional details and definitions pertaining to an attribute.

Are you convinced to give your fields aliases? Not yet? Wait until I tell you this: Aliases are preserved when exporting a web layer to a geodatabase!

There are many ways to apply aliases to your layers

The initial effort pays off

Next time you publish a layer, help your future self out by constructing consistent field names and descriptive aliases. The payoff is well worth the initial time spent choosing a consistent field naming convention and assigning aliases. Help yourself out so that you don’t have to remember what you were thinking months ago, or constantly refer to a codebook. Help other analysts in your organization who will work with your layer. Help those who will be viewing your maps by making the legend easy to read.

If you share your layer publicly with ArcGIS Online users worldwide, or nominate it to ArcGIS Living Atlas, you will be building trust and credibility in this layer, and in yourself as a professional GIS content creator!


About the author

(she/her/hers) Diana loves working with data. She has over 15 years experience as a practitioner of demography, sociology, economics, policy analysis, and GIS. Diana holds a BA in quantitative economics and an MA in applied demography. She is a senior GIS engineer on ArcGIS Living Atlas of the World's Policy Maps team. Diana enjoys strong coffee and clean datasets, usually simultaneously.

Notify of
Inline Feedbacks
View all comments

Next Article

What's new in ArcGIS Maps for Adobe Creative Cloud (June 2024)

Read this article