Defining feature class properties

When creating a feature class, you must specify several feature class properties that define its structure.

In most scenarios, the best option is to accept the default values for these properties provided by the Create Feature Class wizard. However, this section describes each feature class property so that you understand when and why you would need to use values other than the defaults and how changing those values affects your data.

Creating an appropriate feature class to suit your data model depends on the following feature class properties:

Name/Alias

The feature class name is a unique handle that identifies the feature class. The most popular way to name a feature class is with mixed case or using an underscore, such as MajorRoads or Major_Roads.

When you create a feature class, you should give it a name that indicates what data the feature class stores. Feature class names must be unique in a database or geodatabase—you can't have more than one feature class with the same name. Having two feature classes with the same name in the same geodatabase, even if included in different feature datasets, is not allowed.

The name you indicate when you create the feature class in ArcGIS for Desktop, however, is not the name of the feature class as it appears in the database or geodatabase. The database or geodatabase appends the name of the schema in which the feature class is stored. In all databases but Oracle, the name of the database is also appended to the name. This is referred to as the fully qualified feature class name. For example, if user Werther creates a feature class called alpacas in the spdata database, the fully qualified name of the feature class is

spdata.werther.alpacas

Therefore, it is possible for other users to create feature classes called alpacas because the feature classes they create will have their user names appended to the feature class names. For example, if user Gretchen created her own alpacas feature class, the fully qualified name would be

spdata.gretchen.alpacas

However, it is not recommended that you reuse feature class names even if they are stored in different schemas or databases. In this example, if both feature classes contained information about alpacas, there would be no reason to have two separate feature classes. If the data was distinctly different between the two feature classes, the feature class names should reflect that.

Note:

In Informix, even if you are storing the feature classes in separate schemas, they cannot have the same name.

Additional rules

• Names must begin with a letter, not a number or special character such as an asterisk (*) or percent sign (%).
• Names should not contain spaces. If you have a two-part name for your table or feature class, connect the words with an underscore (_), for example, garbage_routes.
• Names should not contain reserved words, such as select or add. Consult your DBMS documentation for additional reserved words.
• The length of feature class and table names depends on the underlying database. The maximum name length for file geodatabase feature classes is 160 characters. Be sure to consult your DBMS documentation for maximum name lengths.

Note:

Table or feature class names with the following prefixes are not supported:

• gdb_
• sde_
• delta_

Renaming fields

You can rename fields in a table or feature class from the Fields tab of the Properties dialog box. Fields in a geodatabase from the ArcGIS 10 release and later support renaming, and fields in database tables can be renamed.

To rename a field, right-click the feature class or table in the Catalog tree and click Properties. Click the Fields tab to see a list of fields in that table or feature class. Click on the text of the field you want to rename and type a new name. Click OK to apply your changes and close the Properties dialog box.

Restrictions for field names are similar to those for table and feature class names.

• Names must begin with a letter, not a number or special character such as an asterisk (*) or percent sign (%).
• Names should not contain spaces.

  If you have a two-part field name, connect the words with an underscore (_), for example, customer_address.

• Names should not contain reserved words, such as all or result.

  Consult your DBMS documentation for additional reserved words.

• Field names are limited to 64 characters in file geodatabases and 31 characters in most enterprise geodatabases and databases (30 characters in Oracle).

The following fields cannot be renamed:

• ObjectID and GlobalID fields
• Any Shape-related field; Shape, shape length, shape area
• The enabled, ancillary role or network weight fields of a network feature class
• Representation fields
• Fields in a feature class participating in a Network Dataset, Terrain, or Cadastral Fabric
• Fields used for Editor Tracking
• Relationship Class Primary Key and Foreign Key fields
• The Subtype field
• Raster fields

Aliases

When you create a table or feature class in a geodatabase, you can assign an alias to it. An alias is an alternate name. If you assign an alias to a table or feature class, that is the name users see when they add it to ArcMap. Users can still look up the name of the table or feature class by going to the Source tab of the Layer Properties dialog box.

Types of feature classes

Vector features (geographic objects with vector geometry) are versatile and frequently used geographic data types, well suited for representing features with discrete boundaries, such as streets, states, and parcels. A feature is an object that stores its geographic representation, which is typically a point, line, or polygon, as one of its properties (or fields) in the row. In ArcGIS, feature classes are homogeneous collections of features with a common spatial representation and set of attributes stored in a database table, for example, a line feature class for representing road centerlines.

Note:

When creating a feature class, you'll be asked to set the type of features to define the type of feature class (point, line, polygon, and so forth).

Generally, feature classes are thematic collections of points, lines, or polygons, but there are seven feature class types. The first three are supported in databases and geodatabases. The last four are only supported in geodatabases.

• Points: Features that are too small to represent as lines or polygons as well as point locations (such as GPS observations).
• Lines:Represent the shape and location of geographic objects, such as street centerlines and streams, too narrow to depict as areas. Lines are also used to represent features that have length but no area, such as contour lines and boundaries.
• Polygons: A set of many-sided area features that represents the shape and location of homogeneous feature types such as states, counties, parcels, soil types, and land-use zones.
• Annotation: Map text including properties for how the text is rendered. For example, in addition to the text string of each annotation, other properties are included such as the shape points for placing the text, its font and point size, and other display properties. Annotation can also be feature linked and can contain subclasses.
• Dimensions: A special kind of annotation that shows specific lengths or distances, for example, to indicate the length of a side of a building or land parcel boundary or the distance between two features. Dimensions are heavily used in design, engineering, and facilities applications for GIS.
• Multipoints: Features that are composed of more than one point. Multipoints are often used to manage arrays of very large point collections, such as lidar point clusters, which can contain literally billions of points. Using a single row for such point geometry is not feasible. Clustering these into multipoint rows enables the geodatabase to handle massive point sets.
• Multipatches: A 3D geometry used to represent the outer surface, or shell, of features that occupy a discrete area or volume in three-dimensional space. Multipatches comprise planar 3D rings and triangles that are used in combination to model a three-dimensional shell. Multipatches can be used to represent anything from simple objects, such as spheres and cubes, to complex objects, such as iso-surfaces and buildings.

Geometry properties

When creating a new feature class, you have the option to allow coordinates to contain measure (m-) values or z-values, for three-dimensional data.

Whether or not you need m- or z-values is determined by the type of data you are using.

By including m-values in your data, you allow attribute values to be stored at the vertex of point coordinates. In the case of linear referencing, m-values store measurements in the vertices along a linear feature. This allows a location to be found along the line. If you will be using linear referencing or dynamic segmentation applications with your data, your coordinates must include m-values.

Z-values are used to represent elevation or another attribute for a given surface location. In an elevation or terrain model, the z-value represents elevation; in other kinds of surface models, it represents the density or quantity of a particular attribute such as annual rainfall, population, and other surface measures. If you will be modeling elevation, creating terrains, or working with any three-dimensional surfaces, your coordinates must include z-values.

Coordinate system

When you create a feature class, you have to choose, or possibly create, a coordinate system. The coordinate system, along with tolerance and resolution values, makes up a spatial reference of a feature class. A spatial reference describes where features are located in the real world.

You can define a coordinate system for your new feature class in several ways:

• Select one of the predefined coordinate systems provided with ArcGIS. Navigate to a geographic or projected coordinate system that appropriately represents the area in your data model.
• Import the coordinate system parameters used by another feature class. If you want to use the coordinate system of another feature class as a template, you have the option to browse to it and import it.
• Define a new custom coordinate system. You can input values to create a coordinate system tailored to your needs.

If you choose to include z-values with your coordinates, you must also specify a vertical coordinate system. A vertical coordinate system georeferences z-values, most commonly used to denote elevation. A vertical coordinate system includes a geodetic or vertical datum, a linear unit of measure, an axis direction, and a vertical shift.

Measure values do not have a coordinate system.

If you don't have the coordinate system information for your data or you don't know which coordinate system to use, you may choose an unknown coordinate system.

The Modify option allows you to review or edit the properties of a coordinate system.

Learn more about map projections and coordinate systems

Tolerance

A spatial reference in the geodatabase also includes tolerance values. X,y, z-, and m-coordinates all have associated tolerance values that reflect the accuracy of the coordinate data. The tolerance value is the minimum distance between coordinates. If one coordinate is within the tolerance value of another, they are interpreted as being at the same location. This value is used in relational and topological operations when determining whether two points are close enough to be given the same coordinate value or if they are far enough apart to each have their own coordinate value.

The default tolerance is set to 0.001 meters or its equivalent in map units. This is 10 times the default resolution value and is recommended in most cases. The minimum allowable tolerance value is twice the resolution value. Setting the tolerance value higher results in lower accuracy in your coordinate data, while setting it lower results in higher accuracy.

Note:

Different tolerance values can produce different answers for relational and topological operations. For example, two geometries might be classified as disjoint (no points in common) with the minimum tolerance, but a larger tolerance might cause them to be classified as touching.

Resolution and domain extent

All coordinates of your feature class or feature dataset are georeferenced according to the chosen coordinate system, then snapped to a grid. This grid is defined by the resolution, which determines the precision (that is, the number of significant digits) of your coordinate values. The resolution establishes the fineness of a grid mesh that covers the extent of your feature class or feature dataset. All coordinates snap to this grid, and the resolution defines how far apart the individual lines of the grid are.

Resolution values are in the same units as the associated coordinate system. For example, if a spatial reference is using a projected coordinate system with units of meters, the resolution value is defined in meters. You should use a resolution value that is at least 10 times smaller than the tolerance value.

The default (and recommended) resolution value is 0.0001 meters (1/10 mm) or its equivalent in map units.

For example, if a feature class is stored in state plane feet, the default precision will be 0.0003281 feet (0.003937 inches). If coordinates are in latitude-longitude, the default resolution is 0.000000001 degrees.

For unknown coordinate systems, or for m-values, you will have to set resolution values appropriate to the type of data without explicitly setting the unit of measure.

Configuration keywords

In file and enterprise geodatabases, you can specify configuration keywords when you create a table or feature class to fine-tune how data is stored. The configuration parameters are grouped together into one or more configuration keywords, one of which is the default configuration keyword, which specifies the default storage parameters.

Choosing configuration keywords is not supported by personal geodatabases or databases.

When you create a feature class in a file or enterprise geodatabase, you can tell the database which configuration keyword to use. In most cases, the DEFAULT keyword should be used. In some cases, though, you might want to specify alternative configuration keywords when you create particular datasets or types of data to maximize their performance or fine-tune some aspect of how they are stored in the database.

Here are some examples of configuration keywords and their uses:

• DEFAULT: This uses reasonable default configuration and storage settings for most geodatabase uses.
• MAX_FILE_SIZE_256TB: If you are importing an extremely large image into a file geodatabase, you can specify the MAX_FILE_SIZE_256TB configuration keyword, which tells the geodatabase to allow the raster dataset to be up to 256 terabytes in size.
• SDO_GEOMETRY: If you want to add a raster dataset to an ArcSDE for Oracle geodatabase, you could specify the SDO_GEOMETRY configuration keyword, which tells the database to store the rasters in Oracle GeoRaster format.
• TEXT_UTF16: If you are copying a feature class that contains Chinese language characters to a file geodatabase, you can specify the TEXT_UTF16 configuration keyword so the text characters in attribute columns will be stored in UTF-16, which more efficiently stores Chinese characters.

Learn about file geodatabase configuration keywords

Learn about enterprise geodatabase configuration keywords

Fields and field properties

When you create a feature class in ArcCatalog or the Catalog window, you can specify the fields to be included in the feature class. You can also specify properties for fields, such as the field type and the maximum size of the data that can be stored in the field. Each field type has special properties.

All fields have properties, such as the following:

• Alias: This is an alternate name for the feature class field. Unlike a field's true name, an alias does not have to adhere to the limitations of the database and may therefore contain spaces and special characters and start with a number. You can only specify field aliases for feature classes in geodatabases.
• Allow Nulls: This controls whether the field will have a NOT NULL constraint on it when the field is created. If Allow Null Values is set to No, the field definition in the database will contain the NOT NULL constraint. If, on the other hand, you stay with the default of Yes, the field will be NULLABLE.
  Note:

  The geodatabase model is such that it will insert an empty value (numeric = 0, text = "") instead of a database NULL if, and only if, the field in the database has a NOT NULL constraint on it.

• Default Value: You can enter a default value to automatically populate a new feature or object when it is created with the ArcMap editing tools. Default field values can only be specified for feature classes in geodatabases.
• Length: This is a property of text fields that determines the maximum number of characters that may be input.

All feature classes have a set of required fields necessary to record the state of any particular object in the feature class. These required fields are automatically created when you create a feature class, and they cannot be deleted. Required fields can also have required properties such as their domain property. You cannot modify the required property of a required field.

For example, in a polygon feature class, OBJECTID and Shape are required fields. They do have properties, such as their geometry type, that you can modify, but these fields cannot be deleted.

If you create a line feature class in a geodatabase, an additional field is added to the feature class automatically to record the length of the line. If you create a polygon feature class, two additional fields are added automatically to record the length (perimeter) and area of each polygon feature. The units of measure for these values depends on the spatial reference defined for the feature class. The names of these fields vary depending on the database and spatial type you use. These are required fields and cannot be modified.

Certain field names appear in ArcGIS with their fully qualified names for feature classes stored within an enterprise geodatabase. For example, if you create or import a polygon feature class that contains a field named Area, the database, schema, and feature class name are appended to it. This is the name you will see in the attribute table of the feature class. That means for a polygon feature class named archsites stored in the prof schema of the museum database, the Area field looks like this:

MUSEUM.PROF.ARCHSITES.AREA

The following list contains all the field names that are fully qualified within an enterprise geodatabase:

FID, AREA, LEN, POINTS, NUMOFPTS, ENTITY, EMINX, EMINY, EMAXX, EMAXY, EMINZ, EMAXZ, MIN_MEASURE, MAX_MEASURE

For cases such as this, you might consider using a different field name or a field alias.

Importing fields

When you create a feature class, you have the option to import fields from another feature class or table. This option enables you to use another feature class or table as a template for the field definitions of the one you are creating. Once you have imported the fields, you can edit the field names, their data type, and their properties.

When you import fields when creating a feature class, the required fields aren't affected. For example, if you have set the Geometry type property for the new feature class to be Point, importing field definitions from a feature class in which the SHAPE field's Geometry type property is polygon will not overwrite the Point property.