arcuser

Help Yourself and Others with Effective Field Naming

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

Juliet Capulet (from Romeo and Juliet)

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 the attribute fields in your layers.

What’s a Naming Convention?

I think of field names the same way I do about complex words in English. They have a prefix, a root, and a suffix. Even if you’ve never heard the word acrophobia before, you might be able to figure out its meaning by realizing that acro is a root that means height (think acrobat), and phobia is a suffix that means fear. In this case, fear of heights.
Prefixes and suffixes in field names help communicate the meaning of the data in your field in a similar way. For example, for binary variables, which are 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:

isVeteran or veteran_flag
isTeachingHospital or teaching_flag
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.
LT for less than (e.g., LT18 means less than age 18).
LE for less than or equal to (e.g., LE5 means a commute time of 5 minutes or less).
GT for greater than (e.g., GT60 means a commute time of more than an hour).
GE for greater than or equal to (e.g., GE65 means age 65 and over).

As you create more layers, you’ll undoubtedly come up with your own consistent naming conventions that make sense for your data needs. The key word is consistency.
Lastly, pick a format—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 now that will save you hours later. Good field names also help coworkers get up to speed quickly when collaborating. 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.

 

Prefixes and suffixes in field names help communicate the meaning of the data in your field. The combination of prefix, root, and suffix in this field name tells you that the value this field contains is the median rate for wind service technicians provided as an hourly rate.

How Does This Really Work?

In my Energy Workers Employment and Wages layer (https://bit.ly/3c4ns9w), available on the ArcGIS Living Atlas of the World, the prefix is the units of 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 from the Bureau of Labor Statistics Standard Occupational Classification (BLS SOC). For example, the field called h_median_499051 is the median hourly wage of workers with BLS SOC number 49-9051, 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 that contained all kinds of metadata. My field names let me provide the exact identifier of the occupation classifications, which makes the value my field is storing unambiguous.

Allow Other Analysts to Work with Layer Data Quickly

Anyone applying any kind of SQL logic when using your layer will thank you for using a consistent naming convention. Consistent field names make it easy for programmers to do systematic data transformations. For example, if all hourly wage fields start with an “h,” programmers can multiply these fields by 40 to get an approximate weekly wage.

 

ArcGIS Online rewards you for providing aliases for field names by using them throughout the product: in the legend, in pop-ups, and in field headers for attribute tables.

Display Aliases Communicate What Your Fields Are

My attribute field named h_median_499051 is the hourly median wage for wind turbine service technicians. ArcGIS Online allows you to give your fields display aliases that communicate this information using natural language. Aliases bring explanations into the layer in a user-friendly way.

Aliases are much more accommodating than field names because they allow up to 255 characters. This lets you use a complete phrase to describe the field. That is usually enough room to spell out acronyms and abbreviations, so please do. Unlike field names, aliases can begin with numbers and contain spaces and special characters.

ArcGIS Online Uses Aliases throughout the Product

ArcGIS Online rewards you when your layers have aliases by using them throughout the whole product. Aliases are visible in the auto-generated legend for the attribute you’re mapping. When I map the count of employees who are wind turbine service technicians from the attribute field named tot_emp_499051, the legend reads Wind turbine service technicians instead of tot_emp_499051. This is much better.

Aliases 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 those aliases when you change the map’s symbology.

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

And my favorite use of aliases is in the fields list under the Data tab on the item details page, where you can sort field names alphanumerically. The item details page is where you add a long description for each field with all the gory details. On the item details page for my Energy Workers Employment and Wages layer, I incorporated the long descriptions that the Bureau of Labor Statistics has for each occupation. These descriptions go that last mile and provide additional details and definitions pertaining to an attribute.
Are you convinced to give your fields aliases? Not yet? Wait. Did you know that aliases are preserved when exporting a web layer to a geodatabase?

Many Ways to Apply Aliases to Layers

If you are publishing a web layer from ArcGIS Pro, all aliases on your feature class will be transferred. This also adds aliases permanently to their source file in the geodatabase.
In ArcGIS Online, you can apply aliases within the Map Viewer using Configure Pop-up > Configure Attributes. This is also where you can toggle the display of fields in your attribute table on and off, change the order in which fields display in the attribute table, and format fields (e.g., number of decimal places shown or use of comma separators for thousands).
In ArcGIS Online, on the Data tab of the item details page, you can add long field descriptions, which lets you move the data’s documentation closer to the GIS analysts who will be using your layer.

You can also change aliases on a hosted feature service using the Feature Service Alias Updater tool written by my colleague Lisa Berry and available at no charge. I use it so often I have added it to My Favorites in ArcGIS Online. It’s great for doing bulk updates to a layer with dozens of fields.

 

In the item details page, you can add a long description for each field. For my Energy Workers Employment and Wages layer, I incorporated the long descriptions that the Bureau of Labor Statistics has for each occupation.

The Initial Effort Pays Off

Next time you publish a layer, help your future self out and anyone else who will use the layer by constructing consistent field names and descriptive aliases. The payoff is well worth the initial time. You won’t have to remember what you were thinking months ago or constantly refer to a codebook. It will help other analysts in your organization who will work with your layer and those who will be viewing your maps by making the legend easy to read.

If you publicly share your consistently named and well aliased layer with ArcGIS Online users worldwide or nominate it for inclusion in the ArcGIS Living Atlas of the World, you will be building trust and credibility in this layer and in yourself as a professional GIS content creator.

About the author

Diana Lavery

Diana Lavery loves working with data! She has over a decade of experience as a practitioner of demography, sociology, economics, policy analysis, and GIS - making her a true social science quantoid. Diana holds a BA in quantitative economics and an MA in applied demography. She has been with Esri as a product engineer on Esri's Living Atlas and Policy Maps teams since 2017. Diana enjoys strong coffee and clean datasets, usually simultaneously.