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. However, this section describes each feature class property so that you understand when and why you 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 feature class properties described below.
Name and Alias
When creating a feature class, provide a name that indicates the 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.
To ensure that a feature class name is unique, ArcGIS uses fully qualified feature class names to prevent possible duplicate names. A fully qualified feature class name may prepend the name of the schema where the feature class is stored and may also prepend the name of the database the feature class is stored in to the feature class name. If one of the components in the fully qualified name is unique, the feature class name is considered unique.
The following image shows examples of the same feature class—Hurricane_Paths—created in different types of geodatabases. In all cases, the geodatabase is named Florida. For the enterprise geodatabase examples, the feature class owner is named GIS.
The following table correlates the numbers in the image above with its corresponding data storage type, description, and structure of the fully qualified feature class name applied when stored in a database or geodatabase.
| Image number | Data storage type | Description |
|---|---|---|
1 | File Geodatabase (.gdb) | Only the table or feature class name provided is used. The structure for a fully qualified feature class name would appear as [FeatureClassName]. |
2 | Mobile Geodatabase (.geodatabase) | Mobile geodatabases are built on a SQLite database and contain both a logical and physical database name. The physical database name consists of the file path, user-provided database name, and file extension. Though, regardless of the physical database name provided when a mobile geodatabase is created, SQLite always uses the reserved primary database name called main as the logical name. The structure for a fully qualified feature class name would appear as [main].[FeatureClassName]. |
3 | In some of the databases that ArcGIS supports, such as PostgreSQL, the name of the database or the data source name is also part of the fully qualified feature class name. The structure for a fully qualified feature class name would appear as [DatabaseName].[SchemaName].[FeatureClassName]. | |
4 | In databases and enterprise geodatabases, such as Oracle and SQL Server, ArcGIS prepends only the name of the schema in which the feature class is stored to the feature class name. The structure for a fully qualified feature class name would appear as [SchemaName].[FeatureClassName]. |
Feature class and table name rules and limitations
The following table lists supported feature class and table name character rules:
| Character | Start of name | Other position | In alias |
|---|---|---|---|
Letters (A–Z) |  | | |
Underscore ( _ ) | | | |
Digits (0–9) | | | |
Spaces | | ||
Symbols (other than underscore) | | ||
Superscript letters and digits | | ||
Subscript letters and digits | |
Additional feature class and table name rules and limitations are as follows:
- Feature class and table names cannot contain reserved words, such as select or add. Consult the database management system (DBMS) documentation for additional reserved words.
- Feature class or table names with the following prefixes are not supported:
- gdb_
- sde_
- delta_
- The length of feature class and table names depends on the underlying database. See File geodatabase size and name limits, Mobile geodatabase size and name limits, or Database data and ArcGIS for more information about database-specific limitations.
Note:
See Field names to learn more about renaming fields and field name rules and limitations.
Set 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 the map. Users can look up the name of the table or feature class by going to the Source tab on the Properties dialog box.
When you create a feature class or table in a geodatabase using geoprocessing tools, there is no parameter to specify the alias. However, you can set an alias for the feature class or table on the Source tab of the Properties dialog box.
- Right-click the feature class or table in the Catalog pane.
- Click Properties.
- Click the Source tab.
- Click the Alias property to enable editing of the name.
- Type an alias and click OK to set the alias for that feature class or table.
Types of feature classes
Vector features (geographic objects with vector geometry) are versatile and frequently used geographic datasets, 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 are asked to set the type of features to define the type of feature class (point, multipoint, polyline or multipatch).
Generally, feature classes are thematic collections of points, lines, or polygons, but there are several 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. You can use multipatches to represent anything from simple objects, such as spheres and cubes, to complex objects, such as iso-surfaces and buildings.
- 3D Object—A 3D geometry specialized in representing additional format support, such as materials, along the outer surface or shell of features that occupy a discrete area or volume in three-dimensional space. You can use 3D Objects to represent materials at a high level of detail to support aesthetics such as glossiness or roughness. You can use them on simple or advanced objects, such as spheres and cubes, and complex structures, such as iso-surfaces and building materials. 3D Objects use advanced associated tables to store multiple components for materials. These tables, along with planar 3D rings and triangles, are used in combination to model a three-dimensional shell.
Geometry properties
When creating a feature class, you can allow coordinates to contain measure (m-) values or z-values for three-dimensional data.
Whether you need m- or z-values is determined by the type of data you are using.
Including m-values in your data allows 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 are 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 specific attribute, such as annual rainfall, population, and other surface measures. If you are modeling elevation, creating terrains, or working with any 3D surfaces, your coordinates must include z-values.
Coordinate system
When you create a feature class, you must choose, or possibly create, a coordinate system. The coordinate system, along with tolerance and resolution values, composes 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. Browse 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 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 can choose an unknown coordinate system.
You can also edit the properties of an existing coordinate system by choosing to copy and modify it.
Tolerance
A spatial reference in the geodatabase also includes tolerance values, x,y coordinates, z-coordinates, and m-coordinates that 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.
Tip:
Tolerance properties can be set on the Environments tab of the Create Feature Class tool.
Resolution and domain extent
All coordinates of your feature class or feature dataset are georeferenced according to the chosen coordinate system and 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. 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 is 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, set resolution values appropriate to the type of data without explicitly setting the unit of measure.
Tip:
Resolution and domain extent properties can be set on the Environments tab of the Create Feature Class tool.
Configuration keywords
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.
In most cases, the DEFAULT keyword should be used. In some cases, though, you may 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.
The following are examples of configuration keywords and their uses:
- DEFAULT—This keyword uses reasonable default configuration and storage settings for most geodatabase uses.
- MAX_FILE_SIZE_256TB—If you are importing a very large image into a file geodatabase, you can specify the MAX_FILE_SIZE_256TB configuration keyword, and the geodatabase will allow the raster dataset to be up to 256 terabytes.
- 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 more about file geodatabase configuration keywords
Learn more about enterprise geodatabase configuration keywords
Fields and field properties
When you create a feature class using the Create Feature Class wizard or Create Feature Class tool, only the geodatabase-maintained fields are initially added, by default, to the feature class. You can add your own fields to the feature class in the fields view. The fields view allows you to specify the specific properties for each field, such as the field type and the maximum size of the data that can be stored in the field.
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 need to adhere to the limitations of the database and can 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 when the field is created. If Allow Nulls is set to No, the field definition in the database will contain the NOT NULL constraint. If you keep the default of Yes, the field will be NULLABLE.
Note:
The geodatabase model 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.
- Default Value—You can enter a default value to automatically populate a new feature or object when it is created with the ArcGIS AllSource 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 can 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 that you can modify, such as their geometry type, 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 in 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 prepended 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 in an enterprise geodatabase:
- FID
- AREA
- LEN
- POINTS
- NUMOFPTS
- ENTITY
- EMINX
- EMINY
- EMAXX
- EMAXY
- EMINZ
- EMAXZ
- MIN_MEASURE
- MAX_MEASURE
For cases such as this, 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 allows you to use another feature class or table as a template for the field definitions of the one you are creating. Once you import the fields, you can edit the field names, their data type, and their properties.
When you import fields during feature class creation, the required fields aren't affected. For example, if you set the geometry type property for the new feature class to store points, importing field definitions from a feature class in which the SHAPE field's geometry type property is set to store polygons will not overwrite the geometry type of the feature class.
Note:
When importing fields, if any high-precision date fields are imported, they will import as low-precision dates. Use the Migrate Date Field to High Precision geoprocessing tool to migrate date fields in a table to high precision. High-precision date fields support millisecond time as mm/dd/yyyy hh:mm:ss.sss.
Split model
When a line or polygon feature class is created, by default, a split model is automatically defined on the feature class. The split model is used to determine how the feature's geometry and its attributes within the table will be divided when a feature is split during the editing process.
The split model has the following two behaviors that can be defined:
- Update/Insert (default)
- Delete/Insert/Insert
The forward slashes in the split model name represent an ordered list of operations that occur on the feature within the feature class that is being split. Update/Insert is the default split model behavior and most users will never need to change it. The Delete/Insert/Insert split model is appropriate when you have specific modeling requirements, such as matching a particular format for interoperability and data conversion, that need to identify a split as a deletion of the original feature.
In addition to defining the split model on a feature class, you can also define the split policy on a relationship class. The relationship class split policy is used to determine how related records within the destination table are treated when a feature in the origin feature class is split during the editing process. Depending on the relationship class type, simple or composite, there are different split policy behaviors that can be defined, including Default (simple), Default (composite) and Duplicate related objects.
See Relationship class split policy for more details on how to set and use this relationship class property.
The split model on a feature class can be set using one of the following two methods:
- Feature Class Properties—From the Source tab on the Feature Class Properties dialog box, scroll down to Split Model. Clicking in the cell beside Split Model enables a drop down. Choosing a split model from the list populates the Set Feature Class Split Model geoprocessing tool and runs it in the background.
- Set Feature Class Split Model tool—Use the Set Feature Class Split Model geoprocessing tool to change the split model for a feature class.
Note:
If the input feature class is from an enterprise geodatabase, you must be the data owner to run this tool.
Update/Insert
By default, an Update/Insert split model is set on feature classes when they are created. Therefore, when a feature within this feature class is split during editing, the original feature is updated, becoming the largest feature, and the smaller feature is inserted as a new row in the table.
Example (Update/Insert):
The image below illustrates the before and after when a single cable, OBJECTID 2 is split within the cable feature class and where the split model is set to the default value, Update/Insert. Before the split, the first row is selected, OBJECTID 2, and the split editing tool is used to split this selected feature. After the split, notice the first row, OBJECTID 2, remains and its geometry and OBJECTID attribute value have been updated. This shows that OBJECTID 2 contains the largest feature after the split, and the smaller feature has been inserted as a new row in the table with an OBJECTID of 5. After the split, OBJECTID 2 and OBJECTID 5 have the same total length as the original length of OBJECTID 2 before it was split.
Delete/Insert/Insert
Once the split model is set as Delete/Insert/Insert for a feature class, when a feature within this feature class is split during editing, the split operation results in a deletion of the original feature that was split, followed by both parts of the split feature being inserted as new features with two new rows in the table.
Note:
Any feature class with a split model set to Delete/Insert/Insert will not open in versions earlier than ArcGIS AllSource 2.6 or ArcGIS Enterprise 10.8.1.
Example (Delete/Insert/Insert):
The image below illustrates the before and after when a single cable, OBJECTID 2 is split within the cable feature class and where the split model was set to Update/Insert. Before the split, the Set Feature Class Split Model geoprocessing tool was run to change the split model to Delete/Insert/Insert. The first row is selected, OBJECTID 2, and the split editing tool is used to split this selected feature. After the split, notice the first row, OBJECTID 2, has been deleted and two new rows, OBJECTID 6 and OBJECTID 7, were inserted. After the split, the two new features that were inserted have the same total length as the length of the original feature before the split.
Caution:
If the split model is set to Delete/Insert/Insert on a feature class that has been registered as versioned and the same feature is split in two ways within two versions, for example, the Default and child version, no conflict will be displayed since the original feature was deleted and two new features are inserted. Therefore, the child version will end up containing all variations of the split feature on reconcile. If the Update/Insert default split model is used, the same feature is split in two ways within two versions, an update/update conflict would be generated, alerting the user that something is wrong with the edits made.
Feature class properties
The split model for the feature class can be viewed from the Source tab on the Feature Class Properties dialog box, then scroll down to Split Model. 