A quick revisit – subtypes and domains in Collector for ArcGIS

Subtypes and domains are fairly useful geodatabase features to know about especially when it comes to data validation and design of editing templates.

Knowing what they are and when to use them can mean the difference between a consistent semi-automatic field data collection experience and database anarchy. We recently looked a little closer at these two features when reviewing a template for collecting weed and other pest observations for a local council or recording tree records for an arborist. Faced with hundreds of different species of weeds, we needed some way to minimize the list of possible values.

We had an inkling that subtypes and domains were the way to go but needed to apply a little lateral thinking. Every Esri example that appears in the help documentation seems to gravitate to either streets or water infrastructure (hence the lateral thinking). The story seems to go something like this:

“For example, the following codes in a subtype named RoadClass could represent valid classes in a feature class for streets:

0 – Local Streets

1 – Secondary Streets

2 – Main Streets”

Well that’s great if you have three different pieces of road but how would that work when you have hundreds of classified values such as weed and tree species. Well fortunately, the council was already collecting a field called Weed Form which basically indicated the growth form of the weed – shrub, vine, tree, grass and aquatic… These then could effectively be feature class subtypes.

Weed Form Subtypes

Collector Screenshot of Weed Types

We read through the Esri desktop help and various tutorials which showed some great screenshots of creating subtypes and assigning default values and domains for each subtype but it was only when we found a bit of a short and sweet discussion topic on one of the GIS chat sites that the penny really dropped: Using subtypes means that you can use different domains for the same attribute field.

This little nugget is not readily apparent in the Esri help or is perhaps not of great significance in building sewer networks but its absolute gold when it comes to species lists.




Cactus domain

Screenshot of species list for cactus weedform

This now meant that for each weed form, we could have a different species list or domain, i.e. AquaticSppDomain which was a significantly shorter list than the original single, all species in one domain. We could also arrange domains alphabetically or in whichever order makes the most sense to the field teams.

When we applied the subtypes, set an edit template and assigned the default values and made use of our new domains, the result was a much more useful configuration of Collector.

A sample Genus-Species data model

To demonstrate and to get you started, the following steps describe setting up a data model for tree inspections, in this case, the model was used with ArcGIS for Windows Mobile but works just as well with Collector.


In this case, there are Genus and Species fields and we make use of subtypes and domains to deliver the required user experience.

The sample data model is attached as an Excel Tree Data Model. The domain data can be imported to your geodatabase using the Excel to Table tool followed by the Table to Domain tool to create the domains for the different Species. You can manually manage domains via the workspace (geodatabase) Properties in ArcCatalog.

The first spreadsheet (tab) called Genus, has 2 columns (Code and Description). The Code column is the subtype which is an integer value. Note that we have ordered the Description in alphabetical order against the code sequence, as this will order the list of tree types and subsequently the Table of Contents or Legend. You could use any order that makes sense to your field team and improves efficiency.

Subtypes are a subset of features in a feature class, or objects in a table, that share the same attributes. They are used as a method to categorise your data. The only gotcha is that a subtype field is required and the subtype field must be of type integer. For more details on creating subtypes, read through the details here and remember that lateral thinking!

Tree Genus subtypes:

  • 0 – None
  • 1 – Acacia
  • 2 – Annona
  • 3 – Citrus
  • 4 – Eucalyptus
  • 5 – Ficus
  • 6 – Pinus
  • 7 – Ulmus

The subtype values and description will need to be typed in via the workspace properties and for this exercise, you could just copy the values from the spreadsheet Genus tab or the list above. You may want to define a range of default values for other attributes in your feature class related to each subtype (for instance the most common species within each Genus or even a particular default height value for the species).

The remaining worksheets (tabs) are Species names which are our Domains:

Tree Species domains:

  • Acacia
  • Annona
  • Citrus
  • Eucalyptus
  • Ficus
  • Pinus
  • Ulmus

For each species worksheet, there are 2 columns again (Code and Description). ArcGIS makes use of two domain types: Range and Coded. Range domains are numeric (float, integer, date, etc.) having a minimum and maximum bounded value. Coded domains are a set of specific values which are an integer or text type.

The domain description column has been populated with the common name of the species which can be useful for field teams who are not familiar with tree genera. If you wanted to list the tree species using the scientific taxonomy, you could replace the common name with the scientific name in the description, such that the Code and Description column has the same values. You could also change the Code column to use an integer set instead of a text set, just like we had done for Tree subtypes, above. However for this sample, the domain code uses a Text type.

The following domain listing is for the Citrus species:

Citrus Species domains:

  • Citrus aurantifolia – Lime
  • Citrus limon – Lemon
  • Citrus medica – Citron
  • Citrus reticulata – Mandarin

You will notice that we put the Genus name as a prefix in the Code. This was done for recognition and readability, considering the Tree taxonomy (classification) has hundreds of names. Of course, you could use any value you like. More information about working with domains can be found here.

A note on Domains and workspaces

Also remember that domains are workspace-related, meaning that its namespace applies across its workspace, in this case the geodatabase, where it is visible to all feature classes. This is different to subtypes which only apply to the assigned feature class.

This means that when you have many (hundreds) of domains, you need to use a naming convention such that they do not clash. In this case, we use the Species name as the Domain name, since they are unique.

Anyway, feel free to use this sample data model or develop your own data models where you may need one subtype with multiple domains!

Making use of the Attribute Assistant also helps minimise how much data is required to be collected in the field by replacing collection of attribute fields with a simple desktop workflow but that is a topic for another day…

Domains and Subtypes are really powerful components of your data model and hopefully you will start to see value in using them.

Happy data collecting,

Len and Geoffrey

9 thoughts on “A quick revisit – subtypes and domains in Collector for ArcGIS

  1. James P

    This is great information, thank you. I have a tree data collection project for use in Collector that has around 200 subtypes, based on genus+species. This ranges across 100 separate genus, so I could have saved myself around 100 subtypes if I had have structured it like you have here. I do however have the luxury of controlling domains and default values at the subtype level for every single genus+species of tree. I have genus+species dependent cultivar domains, and can assign common names, Maori names, and endemic status via defaults. The biggest challenge was getting the 200 subtypes to display in Collector in alphabetical order, as the subtypes do not display in Collector in the order that they are created. This order appears to change depending on the number of subtypes that are used. I won’t go into the details here, but I am planning to write a post on Geonet outlining the issue and how I solved it.

    1. lenolyott Post author

      thanks James, glad you found it useful. I have seen some of the good work you have been doing!

  2. Lee

    Great article. I have been working on something similar with tree data collection. For this I have a subtype field with around 500 different tree genus that link to the relevant tree species domains. The issue I have is displaying these in ArcGIS Collector as 500 different symbols for the user to select from in Collector is not ideal. When I use the same data in ArcGIS for Windows Mobile I can set the layer to be displayed as a single symbol and the subtype and domain field continue to function without issues. However in Collector, using a single symbol display for a layer containing subtypes seems to stop the subtype field functioning. Have you run into this problem or do you know of a solution to it?

    1. lenolyott Post author

      Thanks for your thoughts Lee. My thoughts on still having something like 500 genera is to possibly look at regionalising them by ecosystem, community or geographic distribution. I know that some very rich communities will still have 500 genera but I think in most cases, you could cull the list further. Yes, there would be an overhead in maintaining several different lists but you may only have to do this once and your users will love you for it (potentially). On your second problem of wanting to use one symbol for ALL subtypes – I have heard of this and I will follow up with the consultant who was facing this issue. My question is whether you need to see only one symbol at point of collection or are you talking about subsequent display of the data? If the latter is true, I would consider having a different webmap with the same feature service styled differently (i.e. just one symbol for all trees). In webmaps, feature symbology will persist with the webmap and will not alter the original symbology of the feature service.

    2. Liedeke

      Hi Lee,
      I was reading this blog trying to find out something about lists in Collector. I read your problem and I think I know exactly what you mean. It’s been some time so maybe you already found the solution, but I think you need to look into your Feature Template (You can find it when you start to edit the feature in ArcGIS; right-click the feature class and look under Edit features while in Edit mode; there you’ll find Organise Feature Templates). There you can define how your feature class will behave when you pick a certain subtype. I had exactly the same problem when starting to work with Collector. Make sure everything is correctly defined there before you share it as a service.
      I hope this will help somebody.

  3. Emily

    This is great! Thanks for your post; this gets me closer to what I need. Maybe some of you can give me some further input on my project. I need to collect vegetation attributes for a vegetation mapping effort in Nevada. I will need to visit a location, then collect some site information (topographic data like exposure, slope, etc.) then note the dominant 3-5 species and their percent cover (this is where I need help beyond this post, because I need to collect percent cover of multiple species PER LOCATION). The project is fairly wide-spread, so I will be dealing with hundreds of plant species, and each location will differ in the species present. My question is about structuring the attribute table of the feature class as the first step of making a Collector app. Should the fields be:

    1. slope, exposure, species1, species2, species3… and up to some arbitrary number that I hope is enough fields. Then use *subtypes* to make picklists of species for each species# field that then get *domains* of percent cover.
    2. Fields- slope, exposure, ArtemisiaCalifornica, ChrysothamnusNauseosa, etc on up to every species that occurs in my project area, each constrained with a *domain* to correctly enter in the percent cover?
    I feel like the correct answer is option 1, but I can’t seem to figure out how the subtypes and domains should be set up. Option 2 is how the eventual attribute table of results will be structured, with each location as a row and every species in the whole project as columns with either a 0 percent cover or a collected value for each location. Which makes me lean toward 2 but that’s a very unwieldy thing to take into the field. I’d appreciate anyone’s input, and thanks for taking the time!

    1. lenolyott Post author

      Hi Emily, thanks for the comments. Something else to consider: For another client that has a known location, say a survey grid that they visit regularly, we use a related table that contains the species records organised via subtype and species specific domains. Percent cover is a single field in the related table and has its own coded domain. The relationship is 1:Many, in other words at one location many different species can be recorded. This could also work in your case where you create a new observation point which contains information about the terrain etc and then species are stored in the related table. The feature class that you create should have globalID turned on and then in the related table you create a field of type GUID which is the foreign key format for a GlobalID. Later when you do analysis on your species you can bring in the location information from your observation site. There is a great Esri blog about related tables. Let us know if this makes sense. Certainly will be easier than lots of extra columns.


Got something to say?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s