The ST_Geometry storage type

The ST_Geometry data type implements the SQL 3 specification of user-defined data types (UDTs), allowing you to create columns capable of storing spatial data such as the location of a landmark, a street, or a parcel of land. It provides International Organization for Standards (ISO) and Open Geospatial Consortium, Inc. (OGC) compliant structured query language (SQL) access to the geodatabase and database. This storage extends the capabilities of the database by providing storage for objects (points, lines, and polygons) that represent geographic features. It was designed to make efficient use of database resources; to be compatible with database features such as replication and partitioning; and to provide rapid access to spatial data.

Esri has implemented an Esri-defined ST_Geometry type in Oracle, PostgreSQL, and SQLite. It is this ST_Geometry data type that is explained in the ArcGIS help.

ST_Geometry itself is an abstract, noninstantiated superclass. However, its subclasses can be instantiated. An instantiated data type is one that can be defined as a table column and have values of its type inserted into it.

Although you can define a column as type ST_Geometry, you do not insert ST_Geometry values into the column since it cannot be instantiated. Instead, you insert the subclass values.

The following chart demonstrates the hierarchy of the ST_Geometry data type and its subclasses:

The ST_Geometry superclass and its subclasses

Subclasses

ST_Geometry subclasses are divided into two categories: the base geometry subclasses and the homogeneous collection subclasses. The base geometries include ST_Point, ST_LineString, and ST_Polygon, while the homogeneous collection includes ST_MultiPoint, ST_MultiLineString, and ST_MultiPolygon. As the names imply, the homogeneous collections are collections of base geometries. In addition to sharing base geometry properties, homogeneous collections have some of their own properties.

Each subclass stores the type of geometry implied by its name; for instance, ST_MultiPoint stores multipoints. A list of the subclasses and their descriptions are in the following table:

Subtype	Description
ST_Point	A zero-dimensional geometry that occupies a single location in coordinate space. Has a single x,y coordinate value, is always simple, and has a NULL boundary.
ST_LineString	A one-dimensional object stored as a sequence of points defining a linear interpolated path. ST_LineStrings have length. The ST_LineString is simple if it does not intersect its interior. The endpoints (the boundary) of a closed ST_LineString occupy the same point in space. An ST_LineString is a ring if it is both closed and simple. The endpoints normally form the boundary of an ST_LineString unless the ST_LineString is closed, in which case the boundary is NULL. The interior of an ST_LineString is the connected path that lies between the endpoints, unless it is closed, in which case the interior is continuous.
ST_Polygon	A two-dimensional surface stored as a sequence of points defining its exterior bounding ring and zero or more interior rings. ST_Polygon has area and is always simple. The exterior and any interior rings define the boundary of an ST_Polygon, and the space enclosed between the rings defines the ST_Polygon's interior. The rings of an ST_Polygon can intersect at a tangent point but never cross.
ST_MultiPoint	A collection of ST_Points. Has a dimension of 0. An ST_MultiPoint is simple if none of its elements occupy the same coordinate space. The boundary of an ST_MultiPoint is NULL.
ST_MultiLineString	A collection of ST_LineStrings. ST_MultiLineStrings have length. ST_MultiLineStrings are simple if they only intersect at the endpoints of the ST_LineString elements. ST_MultiLineStrings are nonsimple if the interiors of the ST_LineString elements intersect. The boundary of an ST_MultiLineString is the nonintersected endpoints of the ST_LineString elements. The ST_MultiLineString is closed if all of its ST_LineString elements are closed. The boundary of an ST_MultiLineString is NULL if all the endpoints of all the elements are intersected.
ST_MultiPolygon	A collection of polygons. ST_MultiPolygons have area. The boundary of an ST_MultiPolygon is the cumulative length of its elements' exterior and interior rings. The interior of an ST_MultiPolygon is defined as the cumulative interiors of its element ST_Polygons. The boundary of an ST_MultiPolygon's elements can only intersect at a tangent point.

ST_Geometry subtypes

Note that each subclass inherits the properties of the ST_Geometry superclass but also has properties of its own. Functions that operate on the ST_Geometry data type accept any of the subclass entity types. However, some functions have been defined at the subclass level and only accept certain subclasses. For example, the ST_GeometryN function only takes ST_MultiLinestring, ST_MultiPoint, or ST_MultiPolygon subtype values as input.

To discover the subclass of an ST_Geometry, you can use the ST_GeometryType function. The ST_GeometryType function takes an ST_Geometry and returns the instantiated subclass in the form of a character string. To find out how many base geometry elements are contained in a homogeneous collection, you can use the ST_NumGeometries function, which takes a homogeneous collection and returns the number of base geometry elements it contains.

ST_Geometry function calls

ST_Geometry functions in Oracle and PostgreSQL are implemented in SQL. This is a database-level language. In Oracle, it is Procedural Language Structured Query Language (PL/SQL). In PostgreSQL, it is PL/pgSQL.

When you access ST_Geometry columns in an Oracle or PostgreSQL database using SQL functions, you are accessing the database directly; therefore, the database must be able to access the ST_Geometry functions. In Oracle, the database also spawns an extproc process.

In SQLite, ST_Geometry functions are implemented in C in the ST_Geometry library. You must access the ST_Geometry library to use the ST_Geometry functions.

Oracle

Functions are implemented in PL/SQL, which calls functions in external shared library files written in the C programming language. The functions are called from PL/SQL using an alias name that maps the name of the library—in the case of ST_Geometry in Oracle, st_shapelib—to the name of the library file. (See the Oracle documentation for the CREATE LIBRARY command for details.) The first time a spatial type function is called that requires st_shapelib, the database requests the listener to spawn an extproc process for the SQL session. The extproc is given the location of st_shapelib, the name of the function to be called, and its parameters. The extproc loads st_shapelib and calls the function. When the external function completes, the extproc returns the results and remains active, waiting for additional function calls during this session. The extproc process terminates when the SQL session disconnects.

This requires the following configuration:

• The database needs to know the location of the file containing st_shapelib so it can pass this information to the listener process and on to the extproc.
• If the file_spec for the st_shapelib in the user_libraries table does not match the physical file location of the st_shapelib on the server, ST_Geometry operators and functions will not work. Therefore, you must update the library definition in the Oracle user libraries to include the correct library path to the file containing st_shapelib using the CREATE LIBRARY command.

  Note:

  Altering the definition of the library path invalidates package bodies that refer to it; therefore, the package bodies of some geodatabase stored procedures should be recompiled using Oracle.

• The database must know of the service that handles requests to the extproc. This is configured in the tnsnames.ora file.
• The extproc must be allowed to load the file containing st_shapelib. This is done by defining the environment variable EXTPROC_DLLS in the extproc.ora file.
• The extproc (usually running as the user who owns ORACLE_HOME) must have read permissions on the location of the library files and execute permissions on the files.

PostgreSQL

The st_geometry library must be stored in the PostgreSQL installation directory to allow PostgreSQL to access the ST_Geometry functions. You must copy the st_geometry.dll (Windows) file to the lib folder in the PostgreSQL installation directory. For Linux servers, copy the st_geometry.so (Linux) file to the /usr/lib/pgsql directory on the PostgreSQL server. Both of these files can be found in the DatabaseSupport folder of ArcMap or ArcGIS Server installations, or downloaded from My Esri.

SQLite

You must designate the location of and load the ST_Geometry library so the SQLite client can access the SQL functions. You can set the library location in the client's PATH (Windows) or LIBPATH (Linux) system environment variable then load the library, or you can specify the path when you load ST_Geometry library. See Load the SQLite ST_Geometry library for instructions.

How is ST_Geometry implemented?

ST_Geometry is implemented as a user-defined type that can be used in databases and geodatabases in IBM DB2, IBM Informix, Oracle, and PostgreSQL. ST_Geometry also can be used in SQLite databases.

Each DBMS supports ST_Geometry as follows:

ST_Geometry by DBMS

DBMS	Description
Oracle	The ST_Geometry data type is installed when you create a geodatabase in Oracle and is the default geometry storage type for geodatabases in Oracle. If you do not need geodatabase functionality, you can install the ST_Geometry type in an Oracle database using the Create Spatial Type geoprocessing tool.
IBM DB2	The DB2 Spatial Extender, included by IBM as part of the DB2 product by default, provides ST_Geometry support. ST_Geometry is the only option used to store feature geometry in geodatabases in DB2. It was codeveloped by Esri and IBM. Be aware that there are some differences in SQL syntax between DB2 for z/OS and DB2 for Windows/Linux/UNIX. Consult the DB2 documentation for proper syntax for the DBMS version you are using.
IBM Informix	The Informix Spatial DataBlade, provided by IBM as part of the Informix product, installs the ST_Geometry type in the database and geodatabase. ST_Geometry is the only option used to store feature geometry in geodatabases in Informix. It was codeveloped by Esri and IBM and is a high-performance storage type that provides ISO- and OGC-compliant SQL access to spatial data.
PostgreSQL	The ST_Geometry data type is installed when you create a geodatabase in PostgreSQL and is the default type for storing feature geometry in geodatabases in PostgreSQL. If you do not need geodatabase functionality, you can install the ST_Geometry type in a PostgreSQL database using the Create Spatial Type geoprocessing tool.
SQLite	The ST_Geometry data type in SQLite is implemented using an st_geometry library and a geometryblob column. The ST_Geometry SQL functions are stored in the st_geometry library rather than the database. You can use the Create SQLite Database geoprocessing tool or CreateSQLiteDatabase ArcPy function to create an SQLite database that contains the ST_Geometry type. Alternatively, you can use the CreateOGCTables SQL function to create the ST_Geometry data type in an existing SQLite database.