Show Navigation | Hide Navigation
You are here:
Geodatabases and ArcSDE > Geodatabase data storage and schema > Inside a geodatabase in Oracle

A spatial type for Oracle

Release 9.2
Last modified April 3, 2008
E-mail This Topic Printable Version Give Us Feedback

Print all topics in : "Inside a geodatabase in Oracle"



ArcSDE for Oracle offers an geometry storage type that provides ISO and OGC compliant SQL access to the geodatabase. This storage extends the capabilities of the Oracle database by providing storage for objects (points, lines, and polygons) that represent geographic features. It was designed to make efficient use of Oracle database resources; to be compatible with Oracle database features such as replication and partitioning; and to provide rapid access to spatial data. It allows you to integrate spatial data with other types of business data, so your multiuser database gains the advantage of adding a geographic component to your analyses and data products. Keeping your spatial data together with other business objects also simplifies multiuser access, management, and security of your data, because you will have to manage fewer data storage resources.

You can configure your ArcSDE for Oracle geodatabase to use this ST_Geometry spatial type. It 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. For an explanation of the ST_Geometry spatial type, refer to the Spatial Data section of this document.

Using the ST_Geometry spatial type in an ArcSDE for Oracle geodatabase, you can access your spatial data through SQL functions that implement the ISO SQL/MM Spatial Standard and to the Simple Feature Specification of the Open Geospatial Consortium, Inc. (OGC). You can use SQL commands to store, retrieve, and manipulate spatial features as you would any other type of data. You can use a long list of standards-based functions with SQL commands and stored procedures to retrieve and analyze spatial data. Having SQL access to the data makes it possible for you to use other applications to access data that was created in an ArcSDE for Oracle geodatabase.

To use SQL to access a geodatabase in Oracle that uses the spatial type, you must configure the Oracle Listener. See Configuring Oracle Net Services to use SQL functions for details.

This topic describes:



For information on how to work with tables that use ST_Geometry storage using SQL, see:




How ST_Geometry stores spatial data


The following is the Oracle description of ST_Geometry:

Name Type
ENTITY NUMBER(38)
NUMPTS NUMBER(38)
MINX FLOAT(64)
MINY FLOAT(64)
MAXX FLOAT(64)
MAXY FLOAT(64)
MINZ FLOAT(64)
MAXZ FLOAT(64)
MINM FLOAT(64)
MAXM FLOAT(64)
AREA FLOAT(64)
LEN FLOAT(64)
SRID NUMBER(38)
POINTS BLOB

The attributes of the spatial type represent the following information:



Like other object types, the ST_Geometry data type contains a constructor method and functions. A constructor method is a function that returns a new instance (object) of the data type and sets up the values of its attributes.

The name of the constructor is the same as the type (ST_Geometry). When you instantiate an object of the ST_Geometry type, you invoke the constructor method. For example:

create table hazardous_sites (name        varchar2(128),
                              location    st_geometry);


The following are ST_Geometry accessor functions take a single ST_Geometry as input and return the requested property value as a number.



For example, the following query returns the name and area of the individual states in the United States.

SELECT name, st_area(geometry)
FROM us_states
ORDER BY name;


ST_LineString, ST_MultiLineString, ST_MultiPoint, ST_MultiPolygon, ST_Point, and ST_Polygon are all subtypes (or subclasses) of ST_Geometry. ST_Geometry and its subtypes share common attributes and functions. The constructor definition for ST_LineString, ST_MultiLineString, ST_MultiPoint, ST_MultiPolygon, ST_Point and ST_Polygon is the same. The name of the constructor is the same as the type it contructs/

Since ST_Point is a finite object (a single point value), it can also be created using one of the following methods.

This method utilizes coordinate points and an SRID.

METHOD

 FINAL CONSTRUCTOR FUNCTION ST_POINT RETURNS SELF AS RESULT
 Argument Name                  Type                    In/Out Default?

 PT_X                           NUMBER                  IN
 PT_Y                           NUMBER                  IN
 SRID                           NUMBER                  IN

SQL> insert into sample_pt values (ST_Point (10, 20, 1) );


This method allows a user to specify coordinate points and an elevation value for each point.

METHOD

 FINAL CONSTRUCTOR FUNCTION ST_POINT RETURNS SELF AS RESULT
Argument Name                  Type                    In/Out Default?

 PT_X                           NUMBER                  IN
 PT_Y                           NUMBER                  IN
 PT_Z                           NUMBER                  IN
 SRID                           NUMBER                  IN

SQL> insert into sample_pt values (ST_Point (10, 20, 5, 1) );


This last method for ST_Point additionally allows a measure value to be specified as part of the point object created.

METHOD

 FINAL CONSTRUCTOR FUNCTION ST_POINT RETURNS SELF AS RESULT
Argument Name                  Type                    In/Out Default?

 PT_X                           NUMBER                  IN
 PT_Y                           NUMBER                  IN
 PT_Z                           NUMBER                  IN
 MEASURE                        NUMBER                  IN
 SRID                           NUMBER                  IN

SQL> insert into sample_pt values (ST_Point (10, 20, 5, 401, 1) );


SP_GRID_INFO
SP_Grid_Info is used as the data type for the field GRID in the table ST_Geometry_Index. It contains the grid-level information for spatial indexes.

SQL> desc sp_grid_info
 Name                                      Null?    Type

 GRID1                                              NUMBER
 GRID2                                              NUMBER
 GRID3                                              NUMBER


Schema user
To install ArcSDE and use the ST_Geometry type and domain index in the Oracle DBMS, the SDE user must be granted the proper system privileges to instantiate types, operators, and stored procedures. The following system privileges are required:

CREATE TYPE
UNLIMITED TABLESPACE
CREATE LIBRARY
CREATE OPERATOR
CREATE INDEXTYPE
CREATE PUBLIC SYNONYM
DROP PUBLIC SYNONYM

NOTE: The CONNECT and RESOURCE roles include these privileges.



Metadata schema


The spatial type for Oracle types and metadata tables are owned by the SDE schema. The schema definition is the base table description for metadata tables used to define and describe the type column/table, spatial index, and spatial references information. The term type refers to the ST_Geometry spatial type. Spatial index refers to the ST_Spatial_Index domain index. All type and domain index type definitions, packages, and metadata tables are initially created in the SDE schema.

Views will also be prefixed ST_ including the OpenGIS views on GEOMETRY_COLUMNS and SPATIAL_REFERENCES.

Because the definitions for ST_Geometry are owned by the SDE user, you should never delete the SDE user from the database if you still have tables in the database that contain ST_Geometry columns. Doing so will cause those tables to be inaccessible.

As mentioned in Oracle's Application Developers Guide, when a user is dropped from the database, one of the drop statements executed is DROP TYPE with the FORCE option. This statement removes all types owned by that user, so that user can be removed from the database. DROP TYPE FORCE causes types to be dropped even if they have dependent types or tables associated with them. Once that happens, the associated tables are marked invalid, rendering the data in the tables inaccessible.

For a description of each table, see the tables listed in System tables of a geodatabase stored in Oracle. The tables are as follows:

ST_COORDINATE_SYSTEMS
ST_GEOMETRY_COLUMNS
ST_GEOMETRY_INDEX
ST_SPATIAL_REFERENCES

Top of page


Creating feature classes in Oracle with ST_Geometry storage


When you first install ArcSDE, the ArcSDE compressed binary geometry schema is the default storage type. The default settings for ArcSDE storage are defined in the DBTUNE table by the GEOMETRY_STORAGE parameters.

If you want to store most of your feature class data in the ST_Geometry format, set the GEOMETRY_STORAGE parameter of the DEFAULTS keyword to ST_GEOMETRY. After the default GEOMETRY_STORAGE setting has been changed to ST_GEOMETRY, ArcSDE creates feature classes with ST_GEOMETRY columns when you use the DEFAULTS keyword.

If you change the DEFAULTS GEOMETRY_STORAGE to ST_GEOMETRY, you should also add the ST_GEOM_LOB_STORAGE parameter to the DEFAULTS keyword list. When added to the DEFAULTS keyword, however, the LOB segment name should not be included in this parameter's definition. If it is included, unless you alter the value for the name, feature class creation will fail when a second feature class is created, because each LOB segment name must be unique for a given schema. The following ST_GEOM_LOB_STORAGE parameter example contains no object names, thereby avoiding name collisions within the same schema:

ST_GEOM_LOB_STORAGE  " STORE AS (
  ENABLE STORAGE IN ROW CHUNK 8K RETENTION 1 CACHE")


NOTE: Use the sdedbtune administration command to alter DBTUNE settings. For details on using the sdedbtune command, consult the ArcSDE Administration Command Reference.



ArcSDE for Oracle supports a number of different geometry storage schemas—these different schemas can all be used together in the same database. While there can be only one default geometry schema, individual tables can be created using different geometry schemas.

If you want to store just some of your feature classes with spatial type storage, you can specify the keyword ST_GEOMETRY when you create the feature class. If you do this, that particular feature class will be created with an ST_Geometry column. In the dbtune file, the ST_GEOMETRY keyword appears as follows:

##ST_GEOMETRY
GEOMETRY_STORAGE    "ST_GEOMETRY"
ATTRIBUTE_BINARY    "BLOB"
RASTER_STORAGE	    "BLOB"
ST_GEOM_LOB_STORAGE " STORE AS (
#	TABLESPACE (tablespace_name>
		ENABLE STORAGE IN ROW CHUNK 8K RETENTION CACHE
#	INDEX (TABLESPACE <tablespace_name>)"

UI_TEXT             "User Interface text description for ST_GEOMETRY"

COMMENT             "Any general comment for ST_GEOMETRY keyword"

END


Examples of valid values for the ST_GEOM_LOB_STORAGE parameter include the following:

##ST_GEOMETRY
GEOMETRY_STORAGE    "ST_GEOMETRY"
ATTRIBUTE_BINARY    "BLOB"
RASTER_STORAGE	    "BLOB"
ST_GEOM_LOB_STORAGE  " STORE AS  (TABLESPACE TERRA_NDX ENABLE STORAGE IN ROW CHUNK 8K
 RETENTION CACHE INDEX (TABLESPACE LOBIDX)"

UI_TEXT             "User Interface text description for ST_GEOMETRY"

COMMENT             "Any general comment for ST_GEOMETRY keyword"

END


##ST_GEOMETRY
GEOMETRY_STORAGE    "ST_GEOMETRY"
ATTRIBUTE_BINARY    "BLOB"
RASTER_STORAGE	    "BLOB"
ST_GEOM_LOB_STORAGE  " STORE AS (ENABLE STORAGE IN ROW CHUNK 8K RETENTION CACHE)"

UI_TEXT             "User Interface text description for ST_GEOMETRY"

COMMENT             "Any general comment for ST_GEOMETRY keyword"

END


NOTE: As mentioned earlier in this section, if you define the LOB and LOB index tablespace names, you must alter these values prior to each feature class creation. If you do not, subsequent feature class creations will fail because each segment name must be unique.



For more examples and further information on creating and maintaining Oracle LOB segments, search the ESRI support site for "LOB segment". Several Knowledge Base articles exist on the subject.

Top of page


Converting between other data types and the spatial type for Oracle


The following is a description of spatial data formats and how you can convert between them and the spatial type for Oracle.

OGC well-known text representation


The spatial type has several functions that generate geometries from text descriptions. The functions include:



The text representation is an ASCII text-formatted string that allows geometry to be exchanged in ASCII text form. You can use these functions in a third- or fourth-generation language (3GL or 4GL) program because they don't require the definition of any special program structures.

The ST_AsText function converts an existing geometry into a text representation.

Using the well-known text representation in a C program
The well-known text representation of geometry can be incorporated into a C program. The structure for such an implementation is defined below. The notation {}* indicates zero or more repetitions of the tokens within the braces. The braces do not appear in the output token list.

<Geometry Tagged Text> :=
| <Point Tagged Text> 
| <LineString Tagged Text>
| <Polygon Tagged Text>
| <MultiPoint Tagged Text>
| <MultiLineString Tagged Text>
| <MultiPolygon Tagged Text> 

<Point Tagged Text> := 
POINT <Point Text> 

<LineString Tagged Text> := 
LINESTRING <LineString Text> 

<Polygon Tagged Text> := 
POLYGON <Polygon Text> 

<MultiPoint Tagged Text> :=  
MULTIPOINT <Multipoint Text> 

<MultiLineString Tagged Text> := 
MULTILINESTRING <MultiLineString Text> 

<MultiPolygon Tagged Text> := 
MULTIPOLYGON <MultiPolygon Text> 

<Point Text> := EMPTY 
|    <Point> 
| Z  <PointZ> 
| M  <PointM>
| ZM <PointZM>

<Point> :=  <x>  <y> 
<x> := double precision literal
<y> := double precision literal

<PointZ> :=  <x>  <y>  <z> 	
<x> := double precision literal
<y> := double precision literal
<z> := double precision literal

<PointM> :=  <x>  <y>  <m> 
<x> := double precision literal
<y> := double precision literal
<m> := double precision literal

<PointZM> :=  <x>  <y>  <z>  <m> 
<x> := double precision literal
<y> := double precision literal
<z> := double precision literal
<m> := double precision literal

<LineString Text> := EMPTY
|    ( <Point Text >   {,  <Point Text> }*  )
| Z  ( <PointZ Text >  {,  <PointZ Text> }*  )
| M  ( <PointM Text >  {,  <PointM Text> }*  )
| ZM ( <PointZM Text > {,  <PointZM Text> }*  )

<Polygon Text> := EMPTY 
| ( <LineString Text > {,< LineString Text > }*)

<Multipoint Text> := EMPTY 
| ( <Point Text >   {,  <Point Text > }*  )

<MultiLineString Text> := EMPTY 
| ( <LineString Text > {,< LineString Text>}*  )

<MultiPolygon Text> := EMPTY 
| ( < Polygon Text > {,  < Polygon Text > }*  )


Using well-known text representation in a SQL editor
Since the well-known text representation is text, it can conveniently be typed into a SQL script or directly into a SQL editor. The text is converted to and from a geometry by a function. Functions that convert text to geometry have the following syntax:

function ('<text description>',<SRID>)


For example:
ST_PointFromText('point zm(10.01 20.04 3.2 9.5)', 1)


The spatial reference identifier, SRID—the primary key to the SPATIAL_REFERENCES table—identifies the possible spatial reference systems within an Oracle instance. An SRID is assigned to a spatial column when it is created. Before a geometry can be inserted into a spatial column, its SRID must match the SRID of the spatial column.

The '<text description>' is made up of three basic components enclosed in single quotes:
'<geometry type> [coordinate type] [coordinate list]'


The geometry type is defined as one of the following: point, linestring, polygon, multipoint, multilinestring, or multipolygon.

The coordinate type specifies whether or not the geometry has z-coordinates and/or measures. Leave this argument blank if the geometry has neither; otherwise, set the coordinate type to Z for geometries containing z-coordinates, M for geometries with measures, and ZM for geometries that have both.

The coordinate list defines the double-precision vertices of the geometry. Coordinate lists are comma-delimited and enclosed by parentheses. Geometries having multiple components require sets of parentheses to enclose each component part. If the geometry is empty, the EMPTY keyword replaces the coordinates.

The following examples provide a complete list of all possible permutations of the text description portion of the text representation:

Geometry type Text description Comment
ST_Point 'point empty' empty point
ST_Point 'point z empty' empty point with z-coordinate
ST_Point 'point m empty' empty point with measure
ST_Point 'point zm empty' empty point with z-coordinate and measure
ST_Point 'point ( 10.05 10.28 )' point
ST_Point 'point z( 10.05 10.28 2.51 )' point with z-coordinate
ST_Point 'point m( 10.05 10.28 4.72 )' point with measure
ST_Point 'point zm(10.05 10.28 2.51 4.72 )' point with z-coordinate and measure
ST_LineString 'linestring empty' empty linestring
ST_LineString 'linestring z empty' empty linestring with z-coordinates
ST_LineString 'linestring m empty' empty linestring with measures
ST_LineString 'linestring zm empty' empty linestring with z-coordinates and measures
ST_LineString 'linestring (10.05 10.28 , 20.95 20.89 )' linestring
ST_LineString 'linestring z(10.05 10.28 3.09, 20.95 31.98 4.72, 21.98 29.80 3.51 )' linestring with z-coordinates
ST_LineString 'linestring m(10.05 10.28 5.84, 20.95 31.98 9.01, 21.98 29.80 12.84 )' linestring with measures
ST_LineString 'linestring zm(10.05 10.28 3.09 5.84, 20.95 31.98 4.72 9.01, 21.98 29.80 3.51 12.84)' linestring with z-coordinates and measures
ST_Polygon 'polygon empty' empty polygon
ST_Polygon 'polygon z empty' empty polygon with z-coordinates
ST_Polygon 'polygon m empty' empty polygon with measures
ST_Polygon 'polygon zm empty' empty polygon with z-coordinates and measures
ST_Polygon 'polygon ((10 10, 10 20, 20 20, 20 15, 10 10))' polygon
ST_Polygon 'polygon z((10 10 3, 10 20 3, 20 20 3, 20 15 4, 10 10 3))' polygon with z-coordinates
ST_Polygon 'polygon m((10 10 8, 10 20 9, 20 20 9, 20 15 9, 10 10 8 ))' polygon with measures
ST_Polygon 'polygon zm((10 10 3 8, 10 20 3 9, 20 20 3 9, 20 15 4 9, 10 10 3 8 ))' polygon with z-coordinates and measures
ST_MultiPoint 'multipoint empty' empty multipoint
ST_MultiPoint 'multipoint z empty' empty multipoint with z-coordinates
ST_MultiPoint 'multipoint m empty' empty multipoint with measures
ST_MultiPoint 'multipoint zm empty' empty multipoint with z-coordinates and measures
ST_MultiPoint 'multipoint (10 10, 20 20)' multipoint with two points
ST_MultiPoint 'multipoint z(10 10 2, 20 20 3)' multipoint with z-coordinates
ST_MultiPoint 'multipoint m(10 10 4, 20 20 5)' multipoint with measures
ST_MultiPoint 'multipoint zm(10 10 2 4, 20 20 3 5)' multipoint with z-coordinates and measures
ST_MultiLineString 'multilinestring empty' empty multilinestring
ST_MultiLineString 'multilinestring z empty' empty multilinestring with z-coordinates
ST_MultiLineString 'multilinestring m empty' empty multilinestring with measures
ST_MultiLineString 'multilinestring zm empty' empty multilinestring with z-coordinates and measures
ST_MultiLineString 'multilinestring ((10.05 10.28 , 20.95 20.89 ),( 20.95 20.89, 31.92 21.45))' multilinestring
ST_MultiLineString 'multilinestring z((10.05 10.28 3.4, 20.95 20.89 4.5),( 20.95 20.89 4.5, 31.92 21.45 3.6))' multilinestring with z-coordinates
ST_MultiLineString 'multilinestring m((10.05 10.28 8.4, 20.95 20.89 9.5), (20.95 20.89 9.5, 31.92 21.45 8.6))' multilinestring with measures
ST_MultiLineString 'multilinestring zm((10.05 10.28 3.4 8.4, 20.95 20.89 4.5 9.5), (20.95 20.89 4.5 9.5, 31.92 21.45 3.6 8.6))' multilinestring with z-coordinates and measures
ST_MultiPolygon 'multipolygon empty' empty multipolygon
ST_MultiPolygon 'multipolygon z empty' empty multipolygon with z-coordinates
ST_MultiPolygon 'multipolygon m empty' empty multipolygon with measures
ST_MultiPolygon 'multipolygon zm empty' empty
ST_MultiPolygon 'multipolygon (((10 10, 10 20, 20 20, 20 15 , 10 10), (50 40, 50 50, 60 50, 60 40, 50 40)))' multipolygon
ST_MultiPolygon 'multipolygon z(((10 10 7, 10 20 8, 20 20 7, 20 15 5, 10 10 7), (50 40 6, 50 50 6, 60 50 5, 60 40 6, 50 40 6)))' multipolygon with z-coordinates
ST_MultiPolygon 'multipolygon m(((10 10 2, 10 20 3, 20 20 4, 20 15 5, 10 10 2), (50 40 7, 50 50 3, 60 50 4, 60 40 5, 50 40 7)))' multipolygon with measures
ST_MultiPolygon 'multipolygon zm(((10 10 7 2, 10 20 8 3, 20 20 7 4, 20 15 5 5, 10 10 7 2), (50 40 6 7, 50 50 6 3, 60 50 5 4, 60 40 6 5, 50 40 6 7)))' multipolygon with z-coordinates and measures


OGC well-known binary representation


The well-known binary representation for OGC geometry (WKBGeometry) provides a portable representation of a geometry value as a contiguous stream of bytes. It permits geometry values to be exchanged between an ODBC client and a SQL database in binary form.

The well-known binary representation for geometry is obtained by serializing a geometry instance as a sequence of numeric types drawn from the set {Unsigned Integer, Double}, then serializing each numeric type as a sequence of bytes using one of two well-defined standard binary representations for numeric types-NDR and XDR. The specific binary encoding used for a geometry byte stream is described by a one-byte tag that precedes the serialized bytes. The only difference between the two encodings of geometry is byte order. The XDR encoding is big endian, while the NDR encoding is little endian.

The spatial type for Oracle has several functions that generate geometries from well known binary representations. The functions include:



The well-known binary representation is a contiguous stream of bytes. It permits geometry to be exchanged between an ODBC client and a SQL database in binary form. Because these geometry functions require the definition of C structures to map the binary representation, they are intended for use within a 3GL program and aren't suited to a 4GL environment.

The ST_AsBinary function converts an existing geometry value into well-known binary representation.

For more information on the well-known binary representation, see The OGC Well-Known Binary representation for geometry.

Top of page


Related documentation


You may want to read further about Open Geospatial Consortium (OGC) standards and Oracle database functionality. This section offers some suggestions on where you can find this information.

Where to find OGC documentation


The OGC is a nonprofit organization working to formalize open interface specifications for geoprocessing products and services. Its Web site—www.opengeospatial.org—will provide you with information on adopted and proposed specifications, discussion papers on technology issues, and white papers on open standards in general. The OGC also maintains another site for its OGCNetwork—www.ogcnetwork.org. The OGCNetwork is an online forum that brings together OGC members and the public to engage in discussion, testing, and demonstration of open geospatial specification-based capabilities. Additional OGC documentation sources include the following:



Where to find Oracle documentation


For Oracle documentation, you can visit Oracle's Web site at www.oracle.com/index.html for general information about Oracle products and services. To obtain documentation for Oracle 10g database software, try the Oracle Database Documentation Library, found at www.oracle.com/pls/db102/portal.portal_db?selected=1. (Requires a login.)



Top of page

Please visit the Feedback page to comment or give suggestions on ArcGIS Desktop Help.
Copyright © Environmental Systems Research Institute, Inc.