Feature classes in a geodatabase in Oracle
A feature class is a collection of geographic features, all of the same geometric type (point, line, polygon, multipoint, annotation, dimension, or multipatch). For example, you could store points for all the train depots along a railroad line in one feature class. In another feature class, you could store lines that represent all the railroad tracks.
This topic contains descriptions of the way a feature class appears in the Catalog window, in the database management system (DBMS), and in an XML document.
Feature classes in ArcGIS Desktop
There are seven types of feature classes you can create in ArcGIS Desktop: point, multipoint, line, polygon, annotation, dimension, and multipatch.
You can tell what type of feature class it is in the Catalog tree based on the icon. The following table shows the icon for each type of feature class.
Feature class icon |
Type of feature class |
---|---|
Point or multipoint |
|
Line |
|
Polygon |
|
Annotation |
|
Dimension |
|
Multipatch |
In Oracle, the name of a feature class as it appears in the Catalog tree includes the name of the user who owns the feature class and the name of the feature class itself.
For example, the feature class, parcels, owned by user Perrita, is listed as PERRITA.Parcels in the Catalog tree.
For a description of the different types of feature classes, see Feature class basics.
Feature class tables in an Oracle database
Feature classes in Oracle databases use one of three geometry storage types: ST_Geometry (the default), binary, or SDO_Geometry.
All feature classes have a base table (also called a business table), which stores attribute information, an Object ID, and a Shape field. The Object ID and Shape fields can have different names, but they are required to be in the base table of a feature class.
Annotation and dimension feature classes have additional required fields in their base tables. See Managing annotation feature class properties and Dimension feature properties for a list of these fields.
Feature class tables in an Oracle database stored with ST_Geometry type
Feature classes stored using the ST_Geometry user-defined type consist of a base table and a spatial index. For ST_Geometry feature classes, the ST_Geometry spatial column stores the geometry of the feature class in subclasses such as ST_LineString, ST_MultiPoint, or ST_Polygon. The geometry values are stored directly in this spatial column.
ST_Geometry feature classes also have an affiliated spatial index (S) table. The spatial index table naming convention is related to the identifier generated in the ST_GEOMETRY_INDEX table when the spatial index for the feature class is created. For example, a spatial index with an INDEX_ID value of 16 in the ST_GEOMETRY_INDEX table would be named S16_IDX$.
Creating a spatial index on a table creates an entry for the table in the ST_GEOMETRY_COLUMNS and ST_GEOMETRY_INDEX system tables. The information schema table ST_GEOMETRY_COLUMNS is used to perform selections and DML metadata operations. Stored procedures are used to insert and delete entries from the ST_GEOMETRY_COLUMNS table.
When a feature class is created through ArcGIS using ST_Geometry storage, a business table with an ST_Geometry column is created in the owner's schema. Also, records are added to the LAYERS, TABLE_REGISTRY, GEOMETRY_COLUMNS, COLUMN_REGISTRY, sde_spatial_references (if a spatial reference was defined), and GDB_ITEMS tables in the sde user's schema to track information about the feature class. The GDB_ITEMTYPES table in the sde user's schema defines the type of data it is, in this case, feature class.
Creating a table with an ST_Geometry column does not insert ST_Geometry metadata. It is your (or the application's) responsibility to register this metadata information.
Esri does not support manual manipulation of the system tables. For tables with an ST_Geometry spatial column that were registered with or created by ArcSDE, it is imperative that the metadata for those tables not be altered manually.
View a diagram of a feature class using ST_Geometry storage in Oracle.
You need Adobe Acrobat Reader to open the file.
Dashed lines indicate implicit relationships between columns; solid lines indicate explicit relationships between columns.
Feature class tables in an Oracle database stored with binary geometry type
Feature classes stored in a binary format—either ArcSDE compressed binary or the OGC well-known binary representation of geometry—in a geodatabase in Oracle consist of a base table and associated feature and spatial index tables as described here.
-
The base table
Under the binary schema implementation, the spatial column in the base table contains a feature ID that uniquely references the spatial data. The feature ID joins the base table to two other tables: the feature and spatial index tables. A database trigger is defined on the spatially enabled, nonversioned base table to maintain the relationship between records in the base table and feature table. All nonversioned feature class base tables have a cascade delete trigger, which ensures that if you delete the spatial column in the base table, it is deleted from the feature table. You can view these triggers in the Oracle Enterprise Manager. These triggers are automatically dropped whenever a feature class, either stand-alone or in a feature dataset, is registered as versioned. They are re-created when a feature class is unregistered as versioned. If you edit one of these triggers, then register the feature class as versioned, the trigger is dropped.
-
The feature table (F<layer_id>)
The feature table stores the geometric shapes for each feature. This table is identified by the number in the LAYER_ID column of the LAYERS table. The relationship between the base table and feature table is managed through the Feature ID, or FID. This key, which is maintained by ArcSDE, is unique for the spatial column.
Feature table definitionField name
Field type
Description
Null?
FID
NUMBER(38)
Primary key; the unique ID that joins the feature table to the base table
NOT NULL
NUMOFPTS
NUMBER(38)
The number of points defining the feature
NOT NULL
ENTITY
NUMBER(38)
The type of geometry stored in the spatial column (for example, point, line, or string)
NOT NULL
EMINX
FLOAT(64)
The minimum x-value in a feature; with eminy, emaxx, and emaxy, defines the envelope of a feature
NOT NULL
EMINY
FLOAT(64)
The minimum y-value in a feature; with eminx, emaxx, and emaxy, defines the envelope of a feature
NOT NULL
EMAXX
FLOAT(64)
The maximum x-value in a feature; with eminx, eminy, and emaxy, defines the envelope of a feature
NOT NULL
EMAXY
FLOAT(64)
The maximum y-value in a feature; with eminx, eminy, and emaxx, defines the envelope of a feature
NOT NULL
EMINZ
FLOAT(64)
The minimum z-value in a three-dimensional feature
EMAXZ
FLOAT(64)
The maximum z-value in a three-dimensional feature
MIN_MEASURE
FLOAT(64)
The minimum measure value in a feature
MAX_MEASURE
FLOAT(64)
The maximum measure value in a feature, nulls allowed
AREA
FLOAT(64)
The area of the geometry
LEN
FLOAT(64)
The length or perimeter of the geometry
POINTS
LONG RAW
Contains the byte stream of point coordinates that define the geometry
As features are inserted or updated, values for such columns as the extents and numofpts are recalculated automatically.
The relationship between the base table and feature table is managed through the spatial column and FID column. This key, which is maintained by ArcSDE, is unique. Maintaining the referential integrity between the base and feature table is important. You should not edit the records of either the feature table or spatial index table. Several indexes and constraints have been added to the base, feature, and spatial index table to ensure referential integrity is maintained. However, these indexes and constraints are removed when the feature class is converted to the load-only I/O mode, a state that allows rapid insertion of data into the feature class.
When the feature class is placed back into normal I/O mode—the state that allows users to query the feature class through an ArcSDE client—the indexes are created and the constraints are enabled. The conversion to normal I/O mode will fail if the unique indexes cannot be built on the base table's spatial column or the feature table's FID column. It will also fail if a value exists in the base table's spatial column that is not in the feature table's FID column. In this case, a reference to the offending base table record is loaded into the SDE_EXCEPTIONS table.
The feature table stores the geometry, annotation, and computer-aided design (CAD) elements in the POINTS column. The POINTS column might be defined as either BLOB or LONG RAW, depending on the setting of the GEOMETRY_STORAGE DBTUNE storage parameter. Set the GEOMETRY_STORAGE DBTUNE storage parameter to SDEBINARY if you want to store the compressed binary spatial data in a column defined as LONG RAW; otherwise, set the storage parameter to SDELOB if you want to store the compressed binary spatial data in a column defined as BLOB.
-
The spatial index table (S<layer_id>)
The spatial index of the binary implementation is the spatial index table. It stores references to shapes based on a simple, regular grid. This table is identified by the number in the LAYER_ID column in the LAYERS table.
The spatial index contains an entry for each shape and grid cell combination to support spatial queries. A feature that crosses into three grid cells has three entries in the table. When a spatial query is performed, the grid cells within the search area are identified and used to return a list of candidate geometries.
Spatial index table definition
Spatial index tableField name
Field type
Description
Null?
SP_FID
NUMBER(38)
Primary key; the unique ID that joins the spatial index table to the base table
NOT NULL
GX
NUMBER(38)
The spatial index grid x value
NOT NULL
GY
NUMBER(38)
The spatial index grid y value
NOT NULL
EMINX
NUMBER(38)
The minimum x value in a feature; with eminy, emaxx, and emaxy, defines the envelope of a feature
NOT NULL
EMINY
NUMBER(38)
The minimum y value in a feature; with eminx, emaxx, and emaxy, defines the envelope of a feature
NOT NULL
EMAXX
NUMBER(38)
The maximum x value in a feature; with eminx, eminy, and emaxy, defines the envelope of a feature
NOT NULL
EMAXY
NUMBER(38)
The maximum y value in a feature; with eminx, eminy, and emaxx, defines the envelope of a feature
NOT NULL
The spatial index table defines the grid range and extent of all geometry in an ArcSDE feature class.
- sp_fid—Contains the unique ID that joins the feature table to the base table
- gx/gy—Defines the feature's extent in grid cells
- eminx/eminy/emaxx/emaxy—Defines the extent of the feature in system units
In this example, the FEATURE-ID column from the WELLS base table references features from the feature and spatial index tables:
WELL_ID DEPTH ACTIVE FEATURE-ID 1 30029 Yes 101 2 13939 No 102 3 92891 No 103 … … … FID AREA LEN EMINX,EMINY,… POINTS 101 <compressed feature> 102 <compressed feature> 103 <compressed feature> … … SP_FID GX GY {EMINX,EMINY,EMAXX,EMAXY} 101 70 100 102 70 100 103 71 100 … A business/feature/spatial index key reference
The spatial index table for binary feature classes is related to the LAYER_ID value in the LAYERS table, whereas the spatial index table for ST_Geometry feature classes is related to the INDEX_ID generated in the ST_GEOMETRY_INDEX table.
View a diagram of a feature class using binary storage in Oracle.
You need Adobe Acrobat Reader to open the file.
Dashed lines indicate implicit relationships between columns; solid lines indicate explicit relationships between columns.
Feature class tables in an Oracle database stored with the Oracle Spatial geometry type
Oracle Spatial uses a spatial geometry type—MDSYS.SDO_GEOMETRY. These feature classes also have a base table, but the base table has an SDO_Geometry spatial column that stores the geometry of the feature class. The geometry values are stored directly in this spatial column.
View a diagram of a feature class using SDO_Geometry storage in Oracle..
You need Adobe Acrobat Reader to open the file.
Dashed lines indicate implicit relationships between columns; solid lines indicate explicit relationships between columns.
Feature classes in an XML document
Feature classes are defined within DataElement elements. The DataElement tags for a feature class are set to type esri:DEFeatureClass. Within the feature class DataElement are other elements that define the feature class, such as Field, Domain, ConfigurationKeyword, and SpatialReference elements.
The following is a small portion of the content of an XML document for the Parcels feature class:
<DataElement xsi:type="esri:DEFeatureClass"> <CatalogPath>/V=SDE.DEFAULT/FC=PERRITA.PARCELS</CatalogPath> <Name>PERRITA.PARCELS</Name> <DatasetType>esriDTFeatureClass</DatasetType> <DSID>21</DSID> <Versioned>false</Versioned> <CanVersion>true</CanVersion> <HasOID>true</HasOID> <OIDFieldName>OID</OIDFieldName> <Fields xsi:type="esri:Fields"> <FieldArray xsi:type="esri:ArrayOfField"> <Field xsi:type="esri:Field"> <Name>OID</Name> <Type>esriFieldTypeInteger</Type> <IsNullable>false</IsNullable> <Length>4</Length> <Precision>10</Precision> <Scale>0</Scale> <Required>true</Required> <Editable>false</Editable> <AliasName>OBJECTID</AliasName> <ModelName>OBJECTID</ModelName> </Field>
All other elements defining the feature class
</DataElement>