Data Layer Field Descriptions


All metadata information is subject to our disclaimer. Metadata information is maintained manually. All metadata is subject to errors inherent in a manual process.

GIS Layer Field Names and Standard Fields

GIS Layer Field Names and Standard Fields describes attribute fields we don't document in our GIS layer field metadata. It is also useful to help understand fields that can propagate to other formats and become "stump trash".

"Stump trash"

Fields described as "Stump trash" are generally unintended stump fields left over from an operation on the data layer. Stump fields may be leftover from old coverage to Shapefile conversions or passed through from merging of other layers during the development of the data layer. These fields are generally of no value.

These fields are created and maintained by ArcInfo coverage processing and editing as part of the standard items or "stump". They are necessary and useful in coverages. That is, stump fields are not trash in coverages. They are part of the coverage model. Those items and others are useful not only to ArcInfo, but sometimes to us as well.

  • All coverages have stump items of cover# and cover-ID where "cover" is the coverage name. The cover# field provides a useful unique (if not constant) identifier.
  • For polygonal coverages, stump items AREA, PERIMETER and LENGTH have meaning to us in addition to ArcInfo software.
  • For linear coverages, of stump items FNODE#, TNODE#, LPOLY#, RPOLY# and LENGTH, only LENGTH may have meaning to us.

When coverages are converted to shapefiles, the "#" and "-" characters in the stump item names are converted to "_" underscore characters.

The problem comes when the coverage with its stump items is converted to a Shapefile. The stump items may still be useful, but if any changes are made to the Shapefile geometry, then those items are not adjusted or recalculated by Shapefile software. Therefore, AREA, PERIMETER, LENGTH and others could simply be wrong and should not be trusted when copied into Shapefiles as a result of conversion. It's best to delete all converted stump items so there is no confusion and possible mis-use. These fields in Shapefiles represent a possible data mis-interpretation risk (source of incorrect data) as well as causing conversion problems. The same logic applies to conversion of coverages to Geodatabase format.

Stump trash and other unwanted fields may come from:

  • Conversion from a coverage to a shapefile and back to coverage. Coverage stump item names ending in # and -ID get converted to shapefiles field names ending in _ and _I (or _ID). If this shapefile is converted back to a coverage, these fields are created in the coverage like any other shapefile field. Since the special characters in the item name were changed when it was converted to a shapefile, the name does not conflict with newly created stump items in the coverage. Stump trash created through this path can be considered worthless and the stump trash fields should be deleted.


  • Coverage layers may be merged with other layers through spatial joins (union, identity, intersect) and possibly other operations. In these cases ArcInfo passes through both typical items and stump items as part of the spatial operation. Most of the time, the stump items that were passed through are of no value. Also, passing though items that didn't exist in the original layer creates items that are only populated with data from the original layer. Many of these fields are of little use or value after a spatial join.


"Conversion trash"

Fields described as "Conversion trash" are generally fields left over from an operation on a data layer. These fields are generally of little or no value to us.

Conversion trash may come from:

  • Converting a regions subclass into a polygon coverage. In addition to operations on coverages, the process also occurs when a polygon shapefile is converted to a coverage. Conversion trash fields in this category include
    • POLY#  (POLY_ when converted to a Shapefile)
    • SUBCLASS#  (SUBCLASS_ when converted to a Shapefile)
    • RINGS_OK

    POLY#, SUBCLASS, and SUBCLASS# come from the REGIONPOLY ArcInfo command and RINGS_OK and RINGS_NOK come from the REGIONCLASS ArcInfo command which may be invoked as part of regionpoly processing.


  • It's likely there are other fields generated by other ArcInfo Workstation commands.
Follow UsShare this page

Geographic Information Systems

33 N. Stone Ave., 15th Fl.
Mail-Stop Code DTBAB17-425
Tucson, AZ 85701

Phone: (520) 724-6670
Fax: (520) 791-6588

Department Home Page
Department News
Department Directory
Department Feedback Form