You are here

Esri Fields 101

In a previous blog post, I discussed the value and creation of Esri domains.  These domains are assigned to database fields to assist with data entry. 

No matter your GIS application, there is always a need to update/tweak the database for new requirements.  

Even if the reader isn’t a database administer and doesn’t have database permissions to conduct the act, this post will hopefully enhance the dialogue to communicate those requirements.  So…..how does one create fields? 

The creation of fields is probably most easily conducted in ArcCatalog.  These procedures assume an ArcCatalog method:

  • Navigate to the desired feature class/layer or table.
  • Right-click on the object to be modified, and choose properties (or double-click).
  • In the Properties window, select the Fields tab (Figure 1).
  • In the list of fields, go down to the very bottom of the list.  Type the desired field name.  As an example, I have added a field titled “Address”.

Note:  Not all field names are acceptable, and there are some restricted values.  For example, an administrator is not allowed to name their field “field”.  A more common field name problem is “name” (suggest “st_name” for street name, etc.).  One also cannot have a space in the field name (If desired, add the space in the field’s alias).

Figure 1.  Feature Class Properties (Fields Tab)

  • Specify the field type.  There are four common types of fields:
  • Text – Used to store alphanumeric values (i.e., 430 W. Vine St.).   Usually up to 255 characters as specified in the properties.
  • Integer – Used to store whole numbers.  There are two types of Integers – Short (-32,768 to 32,769) and Long (-2,147,483,648 to 2,147,483,647).
  • Decimal – Used to store fractional/decimal values.  There are two types – Float (-3.4E38 to 1.2E38) and Double (-2.2E308 to 1.8E308).
  • Date – Used to store date values (i.e., 04/06/2015).
  • When complete, click the OK Button to dismiss the window.

Whenever possible, the user is encouraged to avoid text fields.  The end user will benefit much more by using Integer, Decimal, and Date options.  More statistical analysis options are available with OOTB Esri tools with non-text fields. 

When text fields are used, try to minimize the length of the field.  The longer the text field….the more memory (thus more processing required) is used whether the actual value actually uses the space or not. 

For example, let’s say we have a state field that is populated with the random value of “KY”.  If we use the default length of 50 characters, there will always be wasted storage of 48 characters.  In this example, we should have a length of 2 because we will always have a two-character state value.


When using Integer or Decimal fields, try to also use the smallest memory usage option.  The Long Integer option takes up twice as much memory (4 bytes) as the comparable Short Integer (2 bytes).  Very similarly, the Double Precision Decimal also takes twice as much memory (8 bytes) as the comparable Float Decimal (4 bytes).

Metadata Fields
For years, the only OOTB option for tracking record-specific metadata (i.e., who created it, who modified it, or when did they do it) was ArcFM™ Autoupdaters. 

There is now an Esri method that must be conducted to translate to ArcGIS Online and subsequent Collector editing (ArcFM™ properties are not applicable to ArcGIS online/Collector).
To configure the Esri functionality conduct the following procedure:

  • Open ArcCatalog and connect to the desired Geodatabase.
  • Navigate to the desired layer or table, and create the following fields (if necessary) using the methodology above:
  • CreationUser (text)
  • CreationDate (date)
  • LastUser (text)
  • DateModified (text)
  • While in the Properties Window for the layer or table, select the Editor Tracking tab (Figure 2).
  • Choose the option to Enable Editor Tracking.
  • Choose the desired fields for tracking as shown in Figure 2.
  • Click the OK button to save the changes and dismiss the window.

Figure 2.  Metadata Fields

Field Order and Field Visibility
ArcFM™ has also had the ability to change the field order and/or visibility for years.  These properties (once set) are stored within the database, and apply to ALL Stored Displays.  They cannot be tailored for specific requirements (i.e., end user vs administrator).

Esri’s method of establishing field order and visibility is through the ArcMap project (*.mxd).  As with the metadata, this configuration is directly usable for ArcGIS Online and Collector.  To establish, follow the following procedure:

  • Open the desired ArcMap project (*.mxd).
  • Right-click on the desired layer, and choose Properties (Figure 3).
  • Select the Fields tab.
  • The list of fields for the layer are on the left side.  To hide a field to the end user, remove the check in the option.
  • To alter the field order, select the field and then the up or down arrow keys (as applicable).
  • Click the OK button to dismiss the window.
  • Make sure to save the project prior to exiting.

Figure 3.  Field Order and Visibility

Hopefully this post has or will prove useful in your GIS work.  We love comments, so make me look good, and leave several.

Author Information

  • Brian Higgins

    Brian Higgins is a Senior Consultant at the Utility & Telecommunications GIS consulting company SSP Innovations in Centennial, Colorado.  He is a certified Geographic Information Systems Professional (GISP) with 22 years of experience in the design and development of GIS systems for the management of municipal infrastructure.

    See all items created by this author >

    Connect with me on:

Associated Posts: 

Category Tags:

Brian HigginsDataGIS

Comments

Hey Brian and Gang,

2 weeks ago, we turned on Editor Tracking and turned off the ArcFM AUs to manage the user and date metadata. We’ve since noticed a growing number – starting on day 1 of editor tracking being in – of the SDE user being stamped against different features.

We are trying to work out how and when this happening. Our theory we are trying to prove today is that when our ArcFM GDBM Replication Service automatically resolves a conflict (as this is how we have chosen to manage session versions, but not designs), it stamps the SDE user on it, as that is the user which is running the service.

Have you guys heard any other reports of this? Any other ideas? If we learn anything useful, I’ll post our findings here.

Dave
Western Power
West Oz

Sorry it has taken me so long to reply.  I have been on the road for awhile.

I personally have not heard anything, but I am glad you posted your concern.  I will research internally to SSP and post if I learn anything.

Hi Dave... we have not replaced the ArcFM AU's with editor tracking on any classes as of yet and instead are mostly using editor tracking on the Esri classes that are dedicated to ArcGIS Online / Portal collection/interaction. Therefore we haven't seen too many conflicts on them because they are either all edited in a single version or the classes are unversioned.

BUT, your guess seems solid in my opinion. The GDBM definitely applies edits when automatically resolving conflicts and therefore Esri would see that as an edit and update the editor tracking fields. I believe the GDBM filters out the ArcFM AU fields and likely does not override them when using the ArcFM AU's instead of editor tracking. If you confirm this, please do let us know.

Add new comment