This chapter contains reference and usage information for the spatial aggregate functions, which are listed in Table 201.
Table 201 Spatial Aggregate Functions
Method  Description 


Returns a geometry object that is the centroid ("center of gravity") of the specified geometry objects. 

Returns a geometry that concatenates the specified line or multiline geometries. 

Returns a geometry object that is the convex hull of the specified geometry objects. 

Returns an LRS geometry object that concatenates specified LRS geometry objects. 

Returns the minimum bounding rectangle of the specified geometries. 

Takes a VARRAY of SDO_GEOMETRY objects as input, and returns the aggregate union of all geometry objects in the array. 

Returns a geometry object that is the topological union (OR operation) of the specified geometry objects. 
See the usage information about spatial aggregate functions in Section 1.10.
Most of these aggregate functions accept a parameter of type SDOAGGRTYPE, which is described in Section 1.10.1.
Note: Spatial aggregate functions are supported for twodimensional geometries only, except for SDO_AGGR_MBR, which is supported for both twodimensional and threedimensional geometries. 
Description
Returns a geometry object that is the centroid ("center of gravity") of the specified geometry objects.
Parameters
An object of type SDOAGGRTYPE (see Section 1.10.1) that specifies the geometry column and dimensional array.
Usage Notes
The behavior of the function depends on whether the geometry objects are all polygons, all points, or a mixture of polygons and points:
If the geometry objects are all polygons, the centroid of all the objects is returned.
If the geometry objects are all points, the centroid of all the objects is returned.
If the geometry objects are a mixture of polygons and points (specifically, if they include at least one polygon and at least one point), any points are ignored, and the centroid of all the polygons is returned.
The result is weighted by the area of each polygon in the geometry objects. If the geometry objects are a mixture of polygons and points, the points are not used in the calculation of the centroid. If the geometry objects are all points, the points have equal weight.
See also the information about the SDO_GEOM.SDO_CENTROID function in Chapter 24.
Examples
The following example returns the centroid of the geometry objects in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
SELECT SDO_AGGR_CENTROID(SDOAGGRTYPE(shape, 0.005)) FROM cola_markets; SDO_AGGR_CENTROID(SDOAGGRTYPE(SHAPE,0.005))(SDO_GTYPE, SDO_SRID, SDO_POINT  SDO_GEOMETRY(2001, NULL, SDO_POINT_TYPE(5.21295938, 5.00744233, NULL), NULL, NUL L)
Usage Notes
Each input geometry must be a twodimensional line or multiline geometry (that is, the SDO_GTYPE value must be 2002 or 2006). This function is not supported for LRS geometries. To perform an aggregate concatenation of LRS geometric segments, use the SDO_AGGR_LRS_CONCAT spatial aggregate function.
The input geometries must be line strings whose vertices are connected by straight line segments. Circular arcs and compound line strings are not supported.
If any input geometry is a multiline geometry, the elements of the geometry must be disjoint. If they are not disjoint, this function may return incorrect results.
The topological relationship between the geometries in each pair of geometries to be concatenated must be DISJOINT or TOUCH; and if the relationship is TOUCH, the geometries must intersect only at two end points.
You can use the SDO_UTIL.CONCAT_LINES function (described in Chapter 32) to concatenate two line or multiline geometries.
An exception is raised if any input geometries are not line or multiline geometries, or if not all input geometries are based on the same coordinate system.
Examples
The following example inserts two line geometries in the COLA_MARKETS table, and then returns the aggregate concatenation of these geometries. (The example uses the data definitions from Section 2.1.)
 First, insert two line geometries. INSERT INTO cola_markets VALUES(1001, 'line_1', SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(1,1, 5,1))); INSERT INTO cola_markets VALUES(1002, 'line_2', SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(5,1, 8,1)));  Perform aggregate concatenation of all line geometries in layer. SELECT SDO_AGGR_CONCAT_LINES(c.shape) FROM cola_markets c WHERE c.mkt_id > 1000; SDO_AGGR_CONCAT_LINES(C.SHAPE)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM  SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 1, 1, 5, 1, 8, 1))
Parameters
An object of type SDOAGGRTYPE (see Section 1.10.1) that specifies the geometry column and dimensional array.
Examples
The following example returns the convex hull of the geometry objects in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
SELECT SDO_AGGR_CONVEXHULL(SDOAGGRTYPE(shape, 0.005)) FROM cola_markets; SDO_AGGR_CONVEXHULL(SDOAGGRTYPE(SHAPE,0.005))(SDO_GTYPE, SDO_SRID, SDO_POI  SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(8, 1, 10, 7, 10, 11, 8, 11, 6, 11, 1, 7, 1, 1, 8, 1))
Parameters
An object of type SDOAGGRTYPE (see Section 1.10.1) that specifies the geometry column and dimensional array.
Usage Notes
This function performs an aggregate concatenation of any number of LRS geometries. If you want to control the order in which the geometries are concatenated, you must use a subquery with the NO_MERGE optimizer hint and the ORDER BY clause. (See the examples.)
The direction of the resulting segment is the same as the direction of the first geometry in the concatenation.
A 3D format of this function (SDO_AGGR_LRS_CONCAT_3D) is available. For information about 3D formats of LRS functions, see Section 7.4.)
For information about the Spatial linear referencing system, see Chapter 7.
Examples
The following example adds an LRS geometry to the LRS_ROUTES table, and then performs two queries that concatenate the LRS geometries in the table. The first query does not control the order of concatenation, and the second query controls the order of concatenation. Notice the difference in direction of the two segments: the segment resulting from the second query has decreasing measure values because the first segment in the concatenation (Route0
) has decreasing measure values. (This example uses the definitions from the example in Section 7.7.)
 Add a segment with route_id less than 1 (here, zero). INSERT INTO lrs_routes VALUES( 0, 'Route0', SDO_GEOMETRY( 3302,  Line string; 3 dimensions (X,Y,M); 3rd is measure dimension. NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1),  One line string, straight segments SDO_ORDINATE_ARRAY( 5,14,5,  Starting point  5 is measure from start. 10,14,0)  Ending point  0 measure (decreasing measure) ) ); 1 row created.  Concatenate all routes (no ordering specified). SELECT SDO_AGGR_LRS_CONCAT(SDOAGGRTYPE(route_geometry, 0.005)) FROM lrs_routes; SDO_AGGR_LRS_CONCAT(SDOAGGRTYPE(ROUTE_GEOMETRY,0.005))(SDO_GTYPE, SDO_SRID  SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 2, 4, 2, 8, 4, 8, 12, 4, 12, 12, 10, 18, 8, 10, 22, 5, 14, 27, 10, 14, 32))  Aggregate concatenation using subquery for ordering. SELECT SDO_AGGR_LRS_CONCAT(SDOAGGRTYPE(route_geometry, 0.005)) FROM ( SELECT /*+ NO_MERGE */ route_geometry FROM lrs_routes ORDER BY route_id); SDO_AGGR_LRS_CONCAT(SDOAGGRTYPE(ROUTE_GEOMETRY,0.005))(SDO_GTYPE, SDO_SRID  SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 32, 2, 4, 30, 8, 4, 24, 12, 4, 20, 12, 10, 14, 8, 10, 10, 5, 14, 5, 10, 14 , 0))
Description
Returns the minimum bounding rectangle (MBR) of the specified geometries, that is, a single rectangle that minimally encloses the geometries.
Usage Notes
This function does not return an MBR geometry if a proper MBR cannot be constructed. Specifically:
If the input geometries are all null, the function returns a null geometry.
If all data in the input geometries is on a single point, the function returns the point.
If all data in the input geometries consists of points on a straight line, the function returns a twopoint line.
The SDO_TUNE.EXTENT_OF function, documented in Chapter 31, also returns the MBR of geometries. The SDO_TUNE.EXTENT_OF function has better performance than the SDO_AGGR_MBR function if a spatial index is defined on the geometry column; however, the SDO_TUNE.EXTENT_OF function is limited to twodimensional geometries, whereas the SDO_AGGR_MBR function is not. In addition, the SDO_TUNE.EXTENT_OF function computes the extent for all geometries in a table; by contrast, the SDO_AGGR_MBR function can operate on subsets of rows.
Examples
The following example returns the minimum bounding rectangle of the geometry objects in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
SELECT SDO_AGGR_MBR(shape) FROM cola_markets; SDO_AGGR_MBR(C.SHAPE)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SD  SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(1, 1, 10, 11))
Description
Takes a VARRAY of SDO_GEOMETRY objects as input, and returns the aggregate union of all geometry objects in the array.
Parameters
An array of geometry objects of object type SDO_GEOMETRY_ARRAY, which is defined as VARRAY OF SDO_GEOMETRY
.
Tolerance value (see Section 1.5.5).
Usage Notes
SDO_AGGR_SET_UNION provides faster performance than SDO_AGG_UNION but less flexibility, and SDO_AGGR_SET_UNION should be considered when performance is especially important and when it satisfies your functional needs.
SDO_AGGR_UNION is a SQL aggregate function, and therefore it very flexible and can be used with complex SQL GROUP BY clauses. However, SDO_AGGR_SET_UNION can be much faster than SDO_AGGR_UNION. SDO_AGGR_SET_UNION is useful when the geometries to be grouped can easily be gathered into a collection (that is, a VARRAY of SDO_GEOMETRY objects).
SDO_AGGR_SET_UNION:
Cannot aggregate a set of overlapping polygons. For overlapping polygons, use SDO_AGGR_UNION.
Can effectively aggregate a set of non overlapping polygons, including polygons that touch.
Can aggregate sets of lines and points, even if they overlap.
Examples
The following example creates a generic routine to build a geometry set to pass to SDO_AGGR_SET_UNION. It takes as input a table name, column name, and optional predicate to apply, and returns an SDO_GEOMETRY_ARRAY ready to use with SDO_AGGR_SET_UNION. (The example uses the definitions and data from Section 2.1.)
CREATE OR REPLACE FUNCTION get_geom_set (table_name VARCHAR2, column_name VARCHAR2, predicate VARCHAR2 := NULL) RETURN SDO_GEOMETRY_ARRAY DETERMINISTIC AS type cursor_type is REF CURSOR; query_crs cursor_type ; g SDO_GEOMETRY; GeometryArr SDO_GEOMETRY_ARRAY; where_clause VARCHAR2(2000); BEGIN IF predicate IS NULL THEN where_clause := NULL; ELSE where_clause := ' WHERE '; END IF; GeometryArr := SDO_GEOMETRY_ARRAY(); OPEN query_crs FOR ' SELECT '  column_name  ' FROM '  table_name  where_clause  predicate; LOOP FETCH query_crs into g; EXIT when query_crs%NOTFOUND ; GeometryArr.extend; GeometryArr(GeometryArr.count) := g; END LOOP; RETURN GeometryArr; END; / SELECT sdo_aggr_set_union (get_geom_set ('COLA_MARKETS', 'SHAPE', 'name <> ''cola_c'''), .0005 ) FROM dual; SDO_AGGR_SET_UNION(GET_GEOM_SET('COLA_MARKETS','SHAPE','NAME<>''COLA_C'''),.0005  SDO_GEOMETRY(2007, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 2, 11, 1003, 1), SDO _ORDINATE_ARRAY(8, 11, 6, 9, 8, 7, 10, 9, 8, 11, 1, 7, 1, 1, 5, 1, 8, 1, 8, 6, 5 , 7, 1, 7))
Description
Returns a geometry object that is the topological union (OR operation) of the specified geometry objects.
Parameters
An object of type SDOAGGRTYPE (see Section 1.10.1) that specifies the geometry column and dimensional array.
Usage Notes
Do not use SDO_AGGR_UNION to merge line string or multiline string geometries; instead, use the SDO_AGGR_CONCAT_LINES spatial aggregate function.
See also the information about the SDO_GEOM.SDO_UNION function in Chapter 24.
Examples
The following example returns the union of all geometries except cola_d
(in this case, cola_a
, cola_b
, and cola_c
). (The example uses the definitions and data from Section 2.1.)
SELECT SDO_AGGR_UNION( SDOAGGRTYPE(c.shape, 0.005)) FROM cola_markets c WHERE c.name <> 'cola_d'; SDO_AGGR_UNION(SDOAGGRTYPE(C.SHAPE,0.005))(SDO_GTYPE, SDO_SRID, SDO_POINT(  SDO_GEOMETRY(2007, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 2, 11, 1003, 1), SDO _ORDINATE_ARRAY(8, 11, 6, 9, 8, 7, 10, 9, 8, 11, 1, 7, 1, 1, 5, 1, 8, 1, 8, 6, 5 , 7, 1, 7))
See also the more complex SDO_AGGR_UNION example in Section C.4.
The MDSYS.SDO_CS package contains subprograms for working with coordinate systems. You can perform explicit coordinate transformations on a single geometry or an entire layer of geometries (that is, all geometries in a specified column in a table).
To use the subprograms in this chapter, you must understand the conceptual information about coordinate systems in Section 1.5.4 and Chapter 6.
Table 211 lists the coordinate system transformation subprograms.
Table 211 Subprograms for Coordinate System Transformation
Subprogram  Description 


Adds a preference for an operation between a source coordinate system and a target coordinate system. 

Converts a NADCON (North American Datum Conversion) grid in ASCII format to an Oracle Spatial XML representation. 

Converts an NTv2 (National Transformation Version 2) grid in ASCII format to an Oracle Spatial XML representation. 

Converts an Oracle Spatial XML representation of a NADCON (North American Datum Conversion) grid to NADCON ASCII format. 

Converts an Oracle Spatial XML representation of an NTv2 (National Transformation Version 2) grid to NTv2 ASCII format. 

Creates a concatenated operation. 
SDO_CS.CREATE_OBVIOUS_EPSG_RULES 
Creates a basic set of EPSG rules to be applied in certain transformations. 
SDO_CS.CREATE_PREF_CONCATENATED_OP 
Creates a concatenated operation, associating it with a transformation plan and making it preferred either systemwide or for a specified use case. 

Deletes the basic set of EPSG rules to be applied in certain transformations. 

Deletes a concatenated operation. 

Returns the query chain, based on the system rule set, to be used in transformations from one coordinate reference system to another coordinate reference system. 
SDO_CS.DETERMINE_DEFAULT_CHAIN 
Returns the default chain of SRID values in transformations from one coordinate reference system to another coordinate reference system. 

Returns the SRID values of geodetic (geographic) coordinate reference systems that have the same wellknown text (WKT) numeric values as the coordinate reference system with the specified reference SRID value. 

Returns the SRID values of projected coordinate reference systems that have the same wellknown text (WKT) numeric values as the coordinate reference system with the specified reference SRID value. 

Finds an SRID value for a coordinate system that matches information that you specify. 
SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS 
Converts a wellknown text string from the Open Geospatial Consortium simple feature format without the 

Converts a point represented in U.S. National Grid format to a spatial point geometry object. 

Gets the version number of the EPSG dataset used by Spatial. 

Converts a threedimensional geometry into a twodimensional geometry. 

Converts a twodimensional geometry into a threedimensional geometry. 
SDO_CS.MAP_EPSG_SRID_TO_ORACLE 
Returns the Oracle Spatial SRID values corresponding to the specified EPSG SRID value. 
SDO_CS.MAP_ORACLE_SRID_TO_EPSG 
Returns the EPSG SRID value corresponding to the specified Oracle Spatial SRID value. 
SDO_CS.REVOKE_PREFERENCE_FOR_OP 
Revokes a preference for an operation between a source coordinate system and a target coordinate system. 
SDO_CS.TO_OGC_SIMPLEFEATURE_SRS 
Converts a wellknown text string from the Open Geospatial Consortium simple feature format that includes the 

Transforms a geometry representation using a coordinate system (specified by SRID or name). 

Transforms an entire layer of geometries (that is, all geometries in a specified column in a table). 
SDO_CS.UPDATE_WKTS_FOR_ALL_EPSG_CRS 
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems. 
SDO_CS.UPDATE_WKTS_FOR_EPSG_CRS 
Updates the wellknown text (WKT) description for the EPSG coordinate reference system associated with a specified SRID. 
SDO_CS.UPDATE_WKTS_FOR_EPSG_DATUM 
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified datum. 
SDO_CS.UPDATE_WKTS_FOR_EPSG_ELLIPS 
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified ellipsoid. 
SDO_CS.UPDATE_WKTS_FOR_EPSG_OP 
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified coordinate transformation operation. 
SDO_CS.UPDATE_WKTS_FOR_EPSG_PARAM 
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified coordinate transformation operation and parameter for transformation operations. 
SDO_CS.UPDATE_WKTS_FOR_EPSG_PM 
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified prime meridian. 

Validates the wellknown text (WKT) description associated with a specified SRID. 
The rest of this chapter provides reference information on the subprograms, listed in alphabetical order.
Format
SDO_CS.ADD_PREFERENCE_FOR_OP(
op_id IN NUMBER,
source_crs IN NUMBER DEFAULT NULL,
target_crs IN NUMBER DEFAULT NULL,
use_case IN VARCHAR2 DEFAULT NULL);
Description
Adds a preference for an operation between a source coordinate system and a target coordinate system.
Parameters
ID number of the operation. Must be a value in the COORD_OP_ID column of the SDO_COORD_OPS table (described in Section 6.7.8).
The SRID of the source coordinate reference system. Must be null or a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
The SRID of the target coordinate reference system. Must be null or a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Name of the use case to be associated with this preference. Must be null or a value from the USE_CASE column of the SDO_PREFERRED_OPS_USER table (described in Section 6.7.25).
Usage Notes
If use_case
is null, the transformation plan associated with the operation is a systemwide preference, and a row is added (or two rows are added if a reverse operation exists) to the SDO_PREFERRED_OPS_SYSTEM table (described in Section 6.7.24). If use_case
is not null, the transformation plan associated with the operation is a preference associated with the specified use case, and a row is added (or two rows are added if a reverse operation exists) to the SDO_PREFERRED_OPS_USER table (described in Section 6.7.25).
To create a concatenated operation and make it preferred either systemwide or for a specified use case, you can use the SDO_CS.CREATE_PREF_CONCATENATED_OP convenience procedure.
To revoke a preference for an operation between a source coordinate system and a target coordinate system, use the SDO_CS.REVOKE_PREFERENCE_FOR_OP procedure.
Description
Converts a NADCON (North American Datum Conversion) grid in ASCII format to an Oracle Spatial XML representation.
Parameters
Latitude values of the NADCON grid in a CLOB object.
Longitude values of the NADCON grid in a CLOB object.
Output XML document containing the Oracle Spatial XML representation of the NADCON grid.
Usage Notes
To convert an Oracle Spatial XML representation to a NADCON grid, use the SDO_CS.CONVERT_XML_TO_NADCON procedure.
Examples
The following example converts a NADCON grid in ASCII format to an Oracle Spatial XML representation, converts the resulting XML representation back to a NADCON ASCII representation, and displays the resulting ASCII representation. (Only part of the output is shown.)
set lines 32000 set long 2000000000 DECLARE laa CLOB; loa CLOB; xml XMLTYPE; laa_file BFILE; loa_file BFILE; BEGIN laa_file := BFILENAME('MY_WORK_DIR', 'samplenadcon.laa'); loa_file := BFILENAME('MY_WORK_DIR', 'samplenadcon.loa'); DBMS_LOB.OPEN(laa_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.OPEN(loa_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.CREATETEMPORARY(laa, TRUE, DBMS_LOB.SESSION); DBMS_LOB.CREATETEMPORARY(loa, TRUE, DBMS_LOB.SESSION); DBMS_LOB.OPEN(laa, DBMS_LOB.LOB_READWRITE); DBMS_LOB.OPEN(loa, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(laa, laa_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.LOADFROMFILE(loa, loa_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(laa); DBMS_LOB.CLOSE(loa); DBMS_LOB.CLOSE(laa_file); DBMS_LOB.CLOSE(loa_file); SDO_CS.convert_NADCON_to_XML(laa, loa, xml); SDO_CS.convert_XML_to_NADCON(xml, laa, loa); DBMS_OUTPUT.PUT_LINE(SUBSTR(laa, 1, 32000)); DBMS_OUTPUT.PUT_LINE(SUBSTR(loa, 1, 32000)); END; / NADCON EXTRACTED REGION NADGRD 33 49 1 107.00000 .25000 25.00000 .25000 .00000 .006731 .006444 .006208 .006036 .005935 .005904 .005932 .006002 .006092 .006174 .006218 .006198 .006087 .005867 .005522 .005045 .004432 .003688 .002818 .001836 .000759 .000385 .001559 .002704 . . . NADCON EXTRACTED REGION NADGRD 33 49 1 107.00000 .25000 25.00000 .25000 .00000 .008509 .007147 .005756 .004331 .002879 .001410 .000060 .001507 .002904 .004222 .005431 .006498 .007395 .008095 .008579 .008832 .008848 .008632 .008200 .007577 .006800 .005911 .004957 .003974 . . .
Description
Converts an NTv2 (National Transformation Version 2) grid in ASCII format to an Oracle Spatial XML representation.
Parameters
NTv2 grid values in a CLOB object.
Output XML document containing the Oracle Spatial XML representation of the NTv2 grid.
Usage Notes
To convert an Oracle Spatial XML representation to an NTv2 grid, use the SDO_CS.CONVERT_XML_TO_NTV2 procedure.
Examples
The following example converts an NTv2 grid in ASCII format to an Oracle Spatial XML representation, converts the resulting XML representation back to an NTv2 ASCII representation, and displays the resulting ASCII representation. (Only part of the output is shown.)
set lines 32000 set long 2000000000 DECLARE ntv2 CLOB; xml XMLTYPE; ntv2_file BFILE; BEGIN ntv2_file := BFILENAME('MY_WORK_DIR', 'samplentv2.gsa'); DBMS_LOB.OPEN(ntv2_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.CREATETEMPORARY(ntv2, TRUE, DBMS_LOB.SESSION); DBMS_LOB.OPEN(ntv2, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(ntv2, ntv2_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(ntv2); DBMS_LOB.CLOSE(ntv2_file); SDO_CS.convert_NTv2_to_XML(ntv2, xml); SDO_CS.convert_XML_to_NTv2(xml, ntv2); DBMS_OUTPUT.PUT_LINE(SUBSTR(ntv2, 1, 32000)); END; / NUM_OREC 11 NUM_SREC 11 NUM_FILE 2 GS_TYPE SECONDS VERSION NTv2.0 DATUM_F NAD27 DATUM_T NAD83 MAJOR_F 6378206.400 MINOR_F 6356583.800 MAJOR_T 6378137.000 MINOR_T 6356752.314 SUB_NAMEALbanff PARENT NONE CREATED 950629 UPDATED 950704 S_LAT 183900.000000 N_LAT 184500.000000 E_LONG 415800.000000 W_LONG 416100.000000 LAT_INC 30.000000 LONG_INC 30.000000 GS_COUNT 231 0.084020 3.737300 0.005000 0.008000 0.083029 3.738740 0.017000 0.011000 0.082038 3.740180 0.029000 0.015000 . . .
Description
Converts an Oracle Spatial XML representation of a NADCON (North American Datum Conversion) grid to NADCON ASCII format.
Parameters
XML document containing the Oracle Spatial XML representation of the NADCON grid.
Output CLOB object containing the latitude values of the NADCON grid.
Output CLOB object containing the longitude values of the NADCON grid.
Usage Notes
To convert a NADCON grid in ASCII format to an Oracle Spatial XML representation, use the SDO_CS.CONVERT_NADCON_TO_XML procedure.
Examples
The following example converts a NADCON grid in ASCII format to an Oracle Spatial XML representation, converts the resulting XML representation back to a NADCON ASCII representation, and displays the resulting ASCII representation. (Only part of the output is shown.)
set lines 32000 set long 2000000000 DECLARE laa CLOB; loa CLOB; xml XMLTYPE; laa_file BFILE; loa_file BFILE; BEGIN laa_file := BFILENAME('MY_WORK_DIR', 'samplenadcon.laa'); loa_file := BFILENAME('MY_WORK_DIR', 'samplenadcon.loa'); DBMS_LOB.OPEN(laa_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.OPEN(loa_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.CREATETEMPORARY(laa, TRUE, DBMS_LOB.SESSION); DBMS_LOB.CREATETEMPORARY(loa, TRUE, DBMS_LOB.SESSION); DBMS_LOB.OPEN(laa, DBMS_LOB.LOB_READWRITE); DBMS_LOB.OPEN(loa, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(laa, laa_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.LOADFROMFILE(loa, loa_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(laa); DBMS_LOB.CLOSE(loa); DBMS_LOB.CLOSE(laa_file); DBMS_LOB.CLOSE(loa_file); SDO_CS.convert_NADCON_to_XML(laa, loa, xml); SDO_CS.convert_XML_to_NADCON(xml, laa, loa); DBMS_OUTPUT.PUT_LINE(SUBSTR(laa, 1, 32000)); DBMS_OUTPUT.PUT_LINE(SUBSTR(loa, 1, 32000)); END; / NADCON EXTRACTED REGION NADGRD 33 49 1 107.00000 .25000 25.00000 .25000 .00000 .006731 .006444 .006208 .006036 .005935 .005904 .005932 .006002 .006092 .006174 .006218 .006198 .006087 .005867 .005522 .005045 .004432 .003688 .002818 .001836 .000759 .000385 .001559 .002704 . . . NADCON EXTRACTED REGION NADGRD 33 49 1 107.00000 .25000 25.00000 .25000 .00000 .008509 .007147 .005756 .004331 .002879 .001410 .000060 .001507 .002904 .004222 .005431 .006498 .007395 .008095 .008579 .008832 .008848 .008632 .008200 .007577 .006800 .005911 .004957 .003974 . . .
Description
Converts an Oracle Spatial XML representation of an NTv2 (National Transformation Version 2) grid to NTv2 ASCII format.
Parameters
XML document containing the Oracle Spatial XML representation of the NTv2 grid.
Output CLOB object containing the values for the NTv2 grid.
Usage Notes
To convert an NTv2 grid in ASCII format to an Oracle Spatial XML representation, use the SDO_CS.CONVERT_NTV2_TO_XML procedure.
Examples
The following example converts an NTv2 grid in ASCII format to an Oracle Spatial XML representation, converts the resulting XML representation back to an NTv2 ASCII representation, and displays the resulting ASCII representation. (Only part of the output is shown.)
set lines 32000 set long 2000000000 DECLARE ntv2 CLOB; xml XMLTYPE; ntv2_file BFILE; BEGIN ntv2_file := BFILENAME('MY_WORK_DIR', 'samplentv2.gsa'); DBMS_LOB.OPEN(ntv2_file, DBMS_LOB.LOB_READONLY); DBMS_LOB.CREATETEMPORARY(ntv2, TRUE, DBMS_LOB.SESSION); DBMS_LOB.OPEN(ntv2, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(ntv2, ntv2_file, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(ntv2); DBMS_LOB.CLOSE(ntv2_file); SDO_CS.convert_NTv2_to_XML(ntv2, xml); SDO_CS.convert_XML_to_NTv2(xml, ntv2); DBMS_OUTPUT.PUT_LINE(SUBSTR(ntv2, 1, 32000)); END; / NUM_OREC 11 NUM_SREC 11 NUM_FILE 2 GS_TYPE SECONDS VERSION NTv2.0 DATUM_F NAD27 DATUM_T NAD83 MAJOR_F 6378206.400 MINOR_F 6356583.800 MAJOR_T 6378137.000 MINOR_T 6356752.314 SUB_NAMEALbanff PARENT NONE CREATED 950629 UPDATED 950704 S_LAT 183900.000000 N_LAT 184500.000000 E_LONG 415800.000000 W_LONG 416100.000000 LAT_INC 30.000000 LONG_INC 30.000000 GS_COUNT 231 0.084020 3.737300 0.005000 0.008000 0.083029 3.738740 0.017000 0.011000 0.082038 3.740180 0.029000 0.015000 . . .
Parameters
ID number of the concatenated operation.
Name to be associated with the concatenated operation.
Transformation plan. The TFM_PLAN object type is explained in Section 6.6.
Usage Notes
A concatenated operation is the concatenation (chaining) of two or more atomic operations.
To create a concatenated operation and make it preferred either systemwide or for a specified use case, you can use the SDO_CS.CREATE_PREF_CONCATENATED_OP convenience procedure.
Parameters
Name of the use case to be associated with the application of the EPSG rules that are created. Must be a value from the USE_CASE column of the SDO_PREFERRED_OPS_USER table (described in Section 6.7.25).
Usage Notes
This procedure creates rules to implement the main EPSGdefined transformations between specific coordinate reference systems. For transformations between some coordinate reference systems, EPSG has specified rules that should be applied. For any given transformation from one coordinate reference system to another, the EPSG rule might be different from the default Oracle Spatial rule. If you execute this procedure, the EPSG rules are applied in any such cases. If you do not execute this procedure, the default Spatial rules are used in such cases.
This procedure inserts many rows into the SDO_PREFERRED_OPS_SYSTEM table (see Section 6.7.24).
To delete the EPSG rules created by this procedure, and thus cause the default Spatial rules to be used in all cases, use the SDO_CS.DELETE_ALL_EPSG_RULES procedure.
Format
SDO_CS.CREATE_PREF_CONCATENATED_OP(
op_id IN NUMBER,
op_name IN VARCHAR2,
use_plan IN TFM_PLAN,
use_case IN VARCHAR2 DEFAULT NULL);
Description
Creates a concatenated operation, associating it with a transformation plan and making it preferred either systemwide or for a specified use case.
Parameters
ID number of the concatenated operation to be created.
Name to be associated with the concatenated operation.
Transformation plan. The TFM_PLAN object type is explained in Section 6.6.
Use case to which this preferred concatenated operation applies. Must be a null or a value from the USE_CASE column of the SDO_PREFERRED_OPS_USER table (described in Section 6.7.25).
Usage Notes
This convenience procedure combines the operations of the SDO_CS.CREATE_CONCATENATED_OP and SDO_CS.ADD_PREFERENCE_FOR_OP procedures.
A concatenated operation is the concatenation (chaining) of two or more atomic operations.
If use_case
is null, the transformation plan associated with the operation is a systemwide preference, and a row is added (or two rows are added if a reverse operation exists) to the SDO_PREFERRED_OPS_SYSTEM table (described in Section 6.7.24). If use_case
is not null, the transformation plan associated with the operation is a preference associated with the specified use case, and a row is added (or two rows are added if a reverse operation exists) to the SDO_PREFERRED_OPS_USER table (described in Section 6.7.25).
To create a concatenation without making it preferred either systemwide or for a specified use case, use the SDO_CS.CREATE_CONCATENATED_OP procedure
To delete a concatenated operation, use the SDO_CS.DELETE_OP procedure.
Examples
The following example creates a concatenation operation with the operation ID 300 and the name MY_CONCATENATION_OPERATION
, and causes Spatial to use the specified transformation plan in all cases (because use_case
is null) when this operation is used.
DECLARE BEGIN SDO_CS.CREATE_PREF_CONCATENATED_OP( 300, 'MY_CONCATENATED_OPERATION', TFM_PLAN(SDO_TFM_CHAIN(4242, 19910, 24200, 1000000000, 24200)), NULL); END; /
Parameters
Name of the use case to be associated with the application of the EPSG rules that are created. Must match the value that was used for the use_case
parameter value (either null or a specified value) when the SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure was called.
Usage Notes
This procedure deletes the EPSG rules that were previously created by the SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure, and thus causes the default Spatial rules to be used in all cases. (See the Usage Notes for the SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure for more information.)
If use_case
is null, this procedure deletes all rows from the SDO_PREFERRED_OPS_SYSTEM table (see Section 6.7.24). If use_case
is not null, this procedure deletes the rows associated with the specified use case from the SDO_PREFERRED_OPS_USER table (see Section 6.7.25).
Usage Notes
To create a concatenated operation and make it preferred systemwide or only for a specified use case, use the SDO_CS.CREATE_CONCATENATED_OP procedure.
Format
SDO_CS.DETERMINE_CHAIN(
transient_rule_set IN SDO_TRANSIENT_RULE_SET,
use_case IN VARCHAR2,
source_srid IN NUMBER,
target_srid IN NUMBER) RETURN TFM_PLAN;
Description
Returns the query chain, based on the system rule set, to be used in transformations from one coordinate reference system to another coordinate reference system.
Parameters
Rule set to be used for the transformation. If you specify a null value, the Oracle system rule set is used.
Use case for which to determine the query chain. Must be a null value or a value from the USE_CASE column of the SDO_PREFERRED_OPS_USER table (described in Section 6.7.25).
The SRID of the source coordinate reference system. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
The SRID of the target coordinate reference system. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Usage Notes
This function returns an object of type TFM_PLAN, which is explained in Section 6.6.
The transient_rule_set
parameter is of type SDO_TRANSIENT_RULE_SET, which has the following definition:
CREATE TYPE sdo_transient_rule_set AS OBJECT ( source_srid NUMBER, target_srid NUMBER, tfm NUMBER);
Examples
The following example returns the query chain based on the system rule set.
SELECT MDSYS.SDO_CS.DETERMINE_CHAIN(NULL, NULL, 4804, 4257) FROM DUAL; MDSYS.SDO_CS.DETERMINE_CHAIN(NULL,NULL,4804,4257)(THE_PLAN)  TFM_PLAN(SDO_TFM_CHAIN(4804, 2, 4257))
The next example creates a preferred concatenated operation (with operation ID 300) with a specified chain for transformations from SRID 4804 to SRID 4257, and then calls the DETERMINE_CHAIN function, returning a different result. (The operation created in this example is not meaningful or useful, and it was created only for illustration.)
CALL SDO_CS.CREATE_PREF_CONCATENATED_OP( 300, 'CONCATENATED OPERATION', TFM_PLAN( SDO_TFM_CHAIN( 4804, 1000000001, 4804, 1000000002, 4804, 1000000001, 4804, 1000000001, 4804, 1000000002, 4804, 1000000002, 4804, 1000000001, 4804, 1000000001, 4804, 1000000001, 4804, 1000000002, 4804, 1000000002, 4804, 1000000002, 4257)), NULL); SELECT MDSYS.SDO_CS.DETERMINE_CHAIN(NULL, NULL, 4804, 4257) FROM DUAL; MDSYS.SDO_CS.DETERMINE_CHAIN(NULL,NULL,4804,4257)(THE_PLAN)  TFM_PLAN(SDO_TFM_CHAIN(4804, 300, 4257))
Format
SDO_CS.DETERMINE_DEFAULT_CHAIN(
source_srid IN NUMBER,
target_srid IN NUMBER) RETURN SDO_SRID_CHAIN;
Description
Returns the default chain of SRID values in transformations from one coordinate reference system to another coordinate reference system.
Parameters
The SRID of the source coordinate reference system. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
The SRID of the target coordinate reference system. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Usage Notes
This function returns an object of type SDO_SRID_CHAIN, which is defined as VARRAY(1048576) OF NUMBER
.
Examples
The following example returns the default chain of SRID values in transformations from SRID 4804 to SRID 4257.
SELECT MDSYS.SDO_CS.DETERMINE_DEFAULT_CHAIN(4804, 4257) FROM DUAL; MDSYS.SDO_CS.DETERMINE_DEFAULT_CHAIN(4804,4257)  SDO_SRID_CHAIN(NULL, 4804, 4257, NULL)
Format
SDO_CS.FIND_GEOG_CRS(
reference_srid IN NUMBER,
is_legacy IN VARCHAR2,
max_rel_num_difference IN NUMBER DEFAULT 0.000001) RETURN SDO_SRID_LIST;
Description
Returns the SRID values of geodetic (geographic) coordinate reference systems that have the same wellknown text (WKT) numeric values as the coordinate reference system with the specified reference SRID value.
Parameters
The SRID of the coordinate reference system for which to find all other geodetic coordinate reference systems that have the same WKT numeric values. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
TRUE
limits the results to geodetic coordinate reference systems for which the IS_LEGACY column value is TRUE
in the SDO_COORD_REF_SYS table (described in Section 6.7.9); FALSE
limits the results to geodetic coordinate reference systems for which the IS_LEGACY column value is FALSE
in the SDO_COORD_REF_SYS table. If you specify a null value for this parameter, the IS_LEGACY column value in the SDO_COORD_REF_SYS table is ignored in determining the results.
A numeric value indicating how closely WKT values must match in order for a projected coordinate reference system to be considered a match. The default value is 0.000001. The value for each numeric WKT item is compared with its corresponding value in the WKT for the reference SRID or in the specified list of parameters to this function; and if the difference in all cases is less than or equal to the max_rel_num_difference
value, the SRID for that coordinate reference system is included in the results.
Usage Notes
This function returns an object of type SDO_SRID_LIST, which is defined as VARRAY(1048576) OF NUMBER
.
The wellknown text (WKT) format is described in Section 6.8.1.1.
Examples
The following examples show the effect of the is_legacy
parameter value on the results. The first example returns the SRID values of all geodetic legacy coordinate reference systems that have the same WKT numeric values as the coordinate reference system with the SRID value of 8307.
SELECT SDO_CS.FIND_GEOG_CRS( 8307, 'TRUE') FROM DUAL; SDO_CS.FIND_GEOG_CRS(8307,'TRUE')  SDO_SRID_LIST(8192, 8265, 8307, 8311, 8320, 524288, 2000002, 2000006, 2000012, 2 000015, 2000023, 2000028)
The next example returns the SRID values of all geodetic nonlegacy coordinate reference systems that have the same WKT numeric values as the coordinate reference system with the SRID value of 8307.
SELECT SDO_CS.FIND_GEOG_CRS( 8307, 'FALSE') FROM DUAL; SDO_CS.FIND_GEOG_CRS(8307,'FALSE')  SDO_SRID_LIST(4019, 4030, 4031, 4032, 4033, 4041, 4121, 4122, 4126, 4130, 4133, 4140, 4141, 4148, 4151, 4152, 4163, 4166, 4167, 4170, 4171, 4172, 4173, 4176, 41 80, 4189, 4190, 4258, 4269, 4283, 4318, 4319, 4326, 4610, 4612, 4617, 4619, 4624 , 4627, 4640, 4659, 4661, 4667, 4669, 4670)
The next example returns the SRID values of all geodetic coordinate reference systems (legacy and nonlegacy) that have the same WKT numeric values as the coordinate reference system with the SRID value of 8307.
SELECT SDO_CS.FIND_GEOG_CRS( 8307, NULL) FROM DUAL; SDO_CS.FIND_GEOG_CRS(8307,NULL)  SDO_SRID_LIST(4019, 4030, 4031, 4032, 4033, 4041, 4121, 4122, 4126, 4130, 4133, 4140, 4141, 4148, 4151, 4152, 4163, 4166, 4167, 4170, 4171, 4172, 4173, 4176, 41 80, 4189, 4190, 4258, 4269, 4283, 4318, 4319, 4326, 4610, 4612, 4617, 4619, 4624 , 4627, 4640, 4659, 4661, 4667, 4669, 4670, 8192, 8265, 8307, 8311, 8320, 524288 , 2000002, 2000006, 2000012, 2000015, 2000023, 2000028)
Format
SDO_CS.FIND_PROJ_CRS(
reference_srid IN NUMBER,
is_legacy IN VARCHAR2,
max_rel_num_difference IN NUMBER DEFAULT 0.000001) RETURN SDO_SRID_LIST;
Description
Returns the SRID values of projected coordinate reference systems that have the same wellknown text (WKT) numeric values as the coordinate reference system with the specified reference SRID value.
Parameters
The SRID of the coordinate reference system for which to find all other projected coordinate reference systems that have the same WKT numeric values. Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
TRUE
limits the results to projected coordinate reference systems for which the IS_LEGACY column value is TRUE
in the SDO_COORD_REF_SYS table (described in Section 6.7.9); FALSE
limits the results to projected coordinate reference systems for which the IS_LEGACY column value is FALSE
in the SDO_COORD_REF_SYS table. If you specify a null value for this parameter, the IS_LEGACY column value in the SDO_COORD_REF_SYS table is ignored in determining the results.
A numeric value indicating how closely WKT values must match in order for a coordinate reference system to be considered a match. The default value is 0.000001. The value for each numeric WKT item is compared with its corresponding value in the WKT for the reference SRID or in the specified list of parameters to this function; and if the difference in all cases is less than or equal to the max_rel_num_difference
value, the SRID for that coordinate reference system is included in the results.
Usage Notes
This function returns an object of type SDO_SRID_LIST, which is defined as VARRAY(1048576) OF NUMBER
.
The wellknown text (WKT) format is described in Section 6.8.1.1.
Examples
The following examples show the effect of the is_legacy
parameter value on the results. The first example returns the SRID values of all projected legacy coordinate reference systems that have the same WKT numeric values as the coordinate reference system with the SRID value of 2007. The returned result list is empty, because there are no legacy projected legacy coordinate reference systems that meet the search criteria.
SELECT SDO_CS.FIND_PROJ_CRS( 2007, 'TRUE') FROM DUAL; SDO_CS.FIND_PROJ_CRS(2007,'TRUE')  SDO_SRID_LIST()
The next example returns the SRID values of all projected nonlegacy coordinate reference systems that have the same WKT numeric values as the coordinate reference system with the SRID value of 2007.
SELECT SDO_CS.FIND_PROJ_CRS( 2007, 'FALSE') FROM DUAL; SDO_CS.FIND_PROJ_CRS(2007,'FALSE')  SDO_SRID_LIST(2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 21291)
The next example returns the SRID values of all projected coordinate reference systems (legacy and nonlegacy) that have the same WKT numeric values as the coordinate reference system with the SRID value of 2007. The returned result list is the same as for the preceding example.
SELECT SDO_CS.FIND_PROJ_CRS( 2007, NULL) FROM DUAL; SDO_CS.FIND_PROJ_CRS(2007,NULL)  SDO_SRID_LIST(2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 21291)
Format
SDO_CS.FIND_SRID(
srid OUT NUMBER,
epsg_srid_geog IN NUMBER DEFAULT NULL,
epsg_srid_proj IN NUMBER DEFAULT NULL,
datum_id IN NUMBER DEFAULT NULL,
pm_id IN NUMBER DEFAULT NULL,
proj_method_id IN NUMBER DEFAULT NULL,
coord_ref_sys_kind IN VARCHAR2 DEFAULT NULL,
semi_major_axis IN NUMBER DEFAULT NULL,
semi_minor_axis IN NUMBER DEFAULT NULL,
inv_flattening IN NUMBER DEFAULT NULL,
params IN EPSG_PARAMS DEFAULT NULL);
or
SDO_CS.FIND_SRID(
srid OUT NUMBER,
epsg_srid_geog IN NUMBER DEFAULT NULL,
epsg_srid_proj IN NUMBER DEFAULT NULL,
datum_id IN NUMBER DEFAULT NULL,
pm_id IN NUMBER DEFAULT NULL,
proj_method_id IN NUMBER DEFAULT NULL,
proj_op_id IN NUMBER DEFAULT NULL,
coord_ref_sys_kind IN VARCHAR2 DEFAULT NULL,
semi_major_axis IN NUMBER DEFAULT NULL,
semi_minor_axis IN NUMBER DEFAULT NULL,
inv_flattening IN NUMBER DEFAULT NULL,
params IN EPSG_PARAMS DEFAULT NULL,
max_rel_num_difference IN NUMBER DEFAULT 0.000001);
Parameters
Output parameter; will contain either a numeric SRID value or a null value, as explained in the Usage Notes.
EPGS SRID value of a geographic coordinate system. Depending on the value of the coord_ref_sys_kind
parameter, this procedure will either verify the existence of a coordinate system with this geographic SRID value, or will find an SRID value of a projected coordinate system based on a coordinate system with this SRID value.
EPGS SRID value of a projected coordinate system.
Datum ID value. Depending on the value of the coord_ref_sys_kind
parameter, this procedure will look for the SRID of a geographic or projected coordinate system based on this datum.
Ellipsoid ID value. Depending on the value of the coord_ref_sys_kind
parameter, this procedure will look for the SRID of a geographic or projected coordinate system based on this ellipsoid.
Prime meridian ID value. Depending on the value of the coord_ref_sys_kind
parameter, this procedure will look for the SRID of a geographic or projected coordinate system based on this prime meridian.
Projection method ID value. This procedure will look for the SRID of a projected coordinate system based on this projection method.
Projection operation ID value. This procedure will look for the SRID of a projected coordinate system based on this projection operation. A projection operation is a projection method combined with specific projection parameters.
The kind or category of coordinate system. Must be a string value in the COORD_REF_SYS_KIND column of the SDO_COORD_REF_SYS table (described in Section 6.7.9). Examples: GEOGRAPHIC2D
and PROJECTED
Semimajor axis ID value. Depending on the value of the coord_ref_sys_kind
parameter, this procedure will loo for the SRID of a geographic or projected coordinate system based on this semimajor axis.
Semiminor axis ID value. Depending on the value of the coord_ref_sys_kind
parameter, this procedure will look for the SRID of a geographic or projected coordinate system based on this semiminor axis.
Inverse flattening (unit "unity"). Depending on the value of the coord_ref_sys_kind
parameter, this procedure will look for the SRID of a geographic or projected coordinate system based on this inverse flattening.
Projection parameters. The parameters depend on the projection method. The EPSG_PARAMS type is defined as VARRAY(1048576) OF EPSG_PARAM
, and the EPSG_PARAM type is defined as (id NUMBER, val NUMBER, uom NUMBER)
. The format includes attributes for the parameter ID, value, and unit of measure ID, as shown in the following example:
epsg_params( epsg_param(8801, 0.0, 9102), epsg_param(8802, 9.0, 9102), epsg_param(8805, 0.9996, 9201), epsg_param(8806, 500000.0, 9001), epsg_param(8807, 0.0, 9001));
A numeric value indicating how closely WKT values must match in order for a coordinate reference system to be considered a match. The default value is 0.000001. The value for each numeric WKT item is compared with its corresponding value in the WKT for the reference SRID or in the specified list of parameters to this procedure; and if the difference in all cases is less than or equal to the max_rel_num_difference
value, the SRID for that coordinate reference system is included in the results.
Usage Notes
This procedure places the result of its operation in the srid
output parameter. The result is either a numeric SRID value or a null value.
This procedure has the following major uses:
To check if a coordinate system with a specific SRID value exists. In this case, you specify a value for epsg_srid_geog
or epsg_srid_proj
(depending on whether the coordinate system is geographic or projected) and enough parameters for a valid PL/SQL statement. If the resulting srid
parameter value is the same number as the value that you specified, the coordinate system with that SRID value exists; however, if the resulting srid
parameter value is null, no coordinate system with that SRID value exists.
To find the SRID value of a coordinate system based on information that you specify about it.
If multiple coordinate systems match the criteria specified in the input parameters, only one SRID value is returned in the srid
parameter. This could be any one of the potential matching SRID values, and it is not guaranteed to be the same value in subsequent executions of this procedure with the same input parameters.
Examples
The following example finds an SRID value for a projected coordinate system that uses datum ID 6267 in its definition.
DECLARE returned_srid NUMBER; BEGIN SDO_CS.FIND_SRID ( srid => returned_srid, epsg_srid_geog => null, epsg_srid_proj => null, datum_id => 6267, ellips_id => null, pm_id => null, proj_method_id => null, proj_op_id => null, coord_ref_sys_kind => 'PROJECTED'); DBMS_OUTPUT.PUT_LINE('SRID = '  returned_srid); END; / SRID = 4267
Description
Converts a wellknown text string from the Open Geospatial Consortium simple feature format without the TOWGS84
keyword to the format that includes the TOWGS84
keyword.
Usage Notes
To convert a wellknown text string from the Open Geospatial Consortium simple feature format that includes the TOWGS84
keyword to the format without the TOWGS84
keyword, use the SDO_CS.TO_OGC_SIMPLEFEATURE_SRS function.
Examples
The following example converts a wellknown text string from the Open Geospatial Consortium simple feature format without the TOWGS84
keyword to the format that includes the TOWGS84
keyword.
SELECT sdo_cs.from_OGC_SimpleFeature_SRS('GEOGCS [ "Longitude / Latitude (DHDN)", DATUM ["", SPHEROID ["Bessel 1841", 6377397.155, 299.1528128], 582.000000, 105.000000, 414.000000, 1.040000, 0.350000, 3.080000, 8.300000 ], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]') FROM DUAL; MDSYS.SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS('GEOGCS["LONGITUDE/LATITUDE(DHDN)",DATUM  GEOGCS [ "Longitude / Latitude (DHDN)", DATUM ["", SPHEROID ["Bessel 1841", 6377 397.155, 299.1528128], TOWGS84[ 582.000000, 105.000000, 414.000000, 1.040000,  0.350000, 3.080000, 8.300000]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]
Format
SDO_CS.FROM_USNG(
usng IN VARCHAR2,
srid IN NUMBER,
datum IN VARCHAR2 DEFAULT 'NAD83') RETURN SDO_GEOMETRY;
Description
Converts a point represented in U.S. National Grid format to a spatial point geometry object.
Parameters
Wellknown text string.
The SRID of the coordinate system to be used for the conversion (that is, the SRID to be used in the returned geometry). Must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
The name of the datum on which the U.S. National Grid coordinate for the point is based. Must be either a value in the DATUM_NAME column of the SDO_DATUMS table (described in Section 6.7.22) or null. The default value is NAD83
.
Usage Notes
For information about Oracle Spatial support for the U.S. National Grid, see Section 6.11.
To convert a spatial point geometry to a point represented in U.S. National Grid format, use the SDO_CS.TO_USNG function.
Examples
The following example converts a point represented in U.S. National Grid format to a spatial geometry point object with longitude/latitude coordinates.
 Convert US National Grid point to SDO_GEMETRY point using SRID 4326  (WGS 84, longitude/latitude). SELECT SDO_CS.FROM_USNG( '18SUJ2348316806479498', 4326) FROM DUAL; WGS84(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(77.03524, 38.8894673, NULL), NULL, NULL)
Format
SDO_CS.MAKE_2D(
geom3d IN SDO_GEOMETRY,
target_srid IN NUMBER DEFAULT NULL) RETURN SDO_GEOMETRY;
Parameters
Threedimensional geometry object.
The SRID of the target coordinate reference system. Must be null or a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Usage Notes
This function returns a twodimensional geometry object that removes the third (height) dimension value from each vertex in the input geometry.
For information about threedimensional coordinate reference system support, see Section 6.5.
Examples
The following example converts a threedimensional geometry to a twodimensional geometry by removing all the third (height) dimension values. (It uses as its input geometry the output geometry from the example for the SDO_CS.MAKE_3D function.)
SELECT SDO_CS.MAKE_2D(SDO_GEOMETRY(3003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(1, 1, 10, 5, 1, 10, 5, 7, 10, 1, 7, 10, 1, 1, 10))) FROM DUAL; SDO_CS.MAKE_2D(SDO_GEOMETRY(3003,8307,NULL,SDO_ELEM_INFO_ARRAY(1,1003,1),SDO_ORD  SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(1, 1, 5, 1, 5, 7, 1, 7, 1, 1))
Format
SDO_CS.MAKE_3D(
geom2d IN SDO_GEOMETRY,
height IN NUMBER DEFAULT 0,
target_srid IN NUMBER DEFAULT NULL) RETURN SDO_GEOMETRY;
Parameters
Twodimensional geometry object.
Height value to be used in the third dimension for all vertices in the returned geometry. If this parameter is null or not specified, a height of 0 (zero) is used for all vertices.
The SRID of the target coordinate reference system. Must be null or a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Usage Notes
For information about using this function to simulate a crossdimensionality transformation, see Section 6.5.4.
For information about threedimensional coordinate reference system support, see Section 6.5.
Examples
The following example converts the cola_a
twodimensional geometry to a threedimensional geometry. (This example uses the definitions from the example in Section 6.13.).
SELECT SDO_CS.MAKE_3D(c.shape, 10, 8307) FROM cola_markets_cs c WHERE c.name = 'cola_a'; SDO_CS.MAKE_3D(C.SHAPE,10,8307)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELE  SDO_GEOMETRY(3003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(1, 1, 10, 5, 1, 10, 5, 7, 10, 1, 7, 10, 1, 1, 10))
Parameters
The SRID of the EPSG coordinate reference system, as indicated in the COORD_REF_SYS_CODE field in the EPSG Coordinate Reference System table.
Usage Notes
This function returns a value that matches a value in the SRID column of the SDO_COORD_REF_SYS table (see Section 6.7.9).
To return the EPSG SRID value corresponding to the specified Oracle Spatial SRID value, use the SDO_CS.MAP_ORACLE_SRID_TO_EPSG function.
Parameters
Oracle Spatial SRID value. Must match a value in the LEGACY_CODE column of the SDO_COORD_REF_SYS table (see Section 6.7.9).
Usage Notes
This function returns the SRID of an EPSG coordinate reference system. The EPSG SRID value for a coordinate reference system is indicated in the COORD_REF_SYS_CODE field in the EPSG Coordinate Reference System table.
To return the Oracle Spatial SRID value corresponding to a specified EPSG SRID value, use the SDO_CS.MAP_EPSG_SRID_TO_ORACLE function.
Format
SDO_CS.REVOKE_PREFERENCE_FOR_OP(
op_id IN NUMBER,
source_crs IN NUMBER DEFAULT NULL,
target_crs IN NUMBER DEFAULT NULL,
use_case IN VARCHAR2 DEFAULT NULL);
Description
Revokes a preference for an operation between a source coordinate system and a target coordinate system.
Parameters
ID number of the operation. Must match an op_id
value that was specified in a call to the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.
The SRID of the source coordinate reference system. Must match the source_crs
value in a source_crs
, target_crs
, and use_case
combination that was specified in a call to the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.
The SRID of the target coordinate reference system. Must match the target_crs
value in a source_crs
, target_crs
, and use_case
combination that was specified in a call to the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.
Name of the use case associated with the preference. Must match the use_case
value in a source_crs
, target_crs
, and use_case
combination that was specified in a call to the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.
Usage Notes
This procedure reverses the effect of the SDO_CS.ADD_PREFERENCE_FOR_OP procedure.
If use_case
is null, this procedure deletes one or more rows from the SDO_PREFERRED_OPS_SYSTEM table (described in Section 6.7.24). If use_case
is not null, this procedure deletes one or more rows from the SDO_PREFERRED_OPS_USER table (described in Section 6.7.25).
Description
Converts a wellknown text string from the Open Geospatial Consortium simple feature format that includes the TOWGS84
keyword to the format without the TOWGS84
keyword.
Usage Notes
To convert a wellknown text string from the Open Geospatial Consortium simple feature format without the TOWGS84
keyword to the format that includes the TOWGS84
keyword, use the SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS procedure.
Examples
The following example converts a wellknown text string from the Open Geospatial Consortium simple feature format that includes the TOWGS84
keyword to the format without the TOWGS84
keyword.
SELECT sdo_cs.to_OGC_SimpleFeature_SRS('GEOGCS [ "Longitude / Latitude (DHDN)", DATUM ["", SPHEROID ["Bessel 1841", 6377397.155, 299.1528128], TOWGS84 [582.000000, 105.000000, 414.000000, 1.040000, 0.350000, 3.080000, 8.300000] ], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]') FROM DUAL; MDSYS.SDO_CS.TO_OGC_SIMPLEFEATURE_SRS('GEOGCS["LONGITUDE/LATITUDE(DHDN)",DATUM["  GEOGCS [ "Longitude / Latitude (DHDN)", DATUM ["", SPHEROID ["Bessel 1841", 6377 397.155, 299.1528128], 582.000000, 105.000000, 414.000000, 1.040000, 0.350000, 3.080000, 8.300000 ], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]
Format
SDO_CS.TO_USNG(
geom IN SDO_GEOMETRY,
accuracy_in_meters IN NUMBER,
datum IN VARCHAR2 DEFAULT 'NAD83') RETURN VARCHAR2;
Description
Converts a spatial point geometry object to a point represented in U.S. National Grid format.
Parameters
Point geometry whose representation is to be converted to a point represented in U.S. National Grid format. The input geometry must have a valid nonnull SRID, that is, a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Accuracy of the point location in meters. Should be 1 raised to a negative or positive power of 10 (for example, 0.001, 0.01, 0.1, 1, 10, 100, or 1000). Any other specified values are adjusted internally by Spatial, and the result might not be what you expect.
The name of the datum on which the U.S. National Grid coordinate for the point is to be based. Must be either NAD83
or NAD27
. The default value is NAD83
.
Usage Notes
For information about Oracle Spatial support for the U.S. National Grid, see Section 6.11.
The accuracy_in_meters
value affects the number of digits used to represent the accuracy in the returned U.S. National Grid string. For example, if you specify 0.000001, the string will contain many digits; however, depending on the source of the data, the digits might not accurately reflect geographical reality. Consider the following scenarios. If you create a U.S. National Grid string from a UTM geometry, you can get perfect accuracy, because no inherently inaccurate transformation is involved. However, transforming from a Lambert projection to the U.S. National Grid format involves an inverse Lambert projection and a forward UTM projection, each of which has some inherent inaccuracy. If you request the resulting U.S. National Grid string with 1 millimeter (0.001) accuracy, the string will contain all the digits, but the millimeterlevel digit will probably be geographically inaccurate.
To convert a point represented in U.S. National Grid format to a spatial point geometry, use the SDO_CS.FROM_USNG function.
Examples
The following example converts a spatial geometry point object with longitude/latitude coordinates to a point represented in U.S. National Grid format using an accuracy of 0.001 meter (1 millimeter).
 Convert longitude/latitude (WGS 84) point to US National Grid. SELECT SDO_CS.TO_USNG( SDO_GEOMETRY(2001, 4326, SDO_POINT_TYPE(77.0352402158258, 38.8894673086544, NULL), NULL, NULL), 0.001) FROM DUAL; SDO_CS.TO_USNG(SDO_GEOMETRY(2001,4326,SDO_POINT_TYPE(77.0352402158258,38.889467  18SUJ2348316806479498
Format
SDO_CS.TRANSFORM(
geom IN SDO_GEOMETRY,
to_srid IN NUMBER
) RETURN SDO_GEOMETRY;
or
SDO_CS.TRANSFORM(
geom IN SDO_GEOMETRY,
to_srname IN VARCHAR2
) RETURN SDO_GEOMETRY;
or
SDO_CS.TRANSFORM(
geom IN SDO_GEOMETRY,
use_case IN VARCHAR2,
to_srid IN NUMBER
) RETURN SDO_GEOMETRY;
or
SDO_CS.TRANSFORM(
geom IN SDO_GEOMETRY,
use_plan IN TFM_PLAN
) RETURN SDO_GEOMETRY;
Description
Transforms a geometry representation using a coordinate system (specified by SRID or name).
You can also associate a use case or a transformation plan with the transformation.
Parameters
Geometry whose representation is to be transformed using another coordinate system. The input geometry must have a valid nonnull SRID, that is, a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
The SRID of the coordinate system to be used for the transformation. It must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
The name of the coordinate system to be used for the transformation. It must be a value (specified exactly) in the COORD_REF_SYS_NAME column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
The name of the use case to be associated with the transformation. If you specify the string USE_SPHERICAL
, the transformation uses spherical math instead of ellipsoidal math, thereby accommodating Google Maps and some other thirdparty tools that use projections based on spherical math. Use cases are explained in Section 6.4. For considerations related to Google Maps, see Section 6.12.
Transformation plan. The TFM_PLAN object type is explained in Section 6.6.
Usage Notes
Transformation can be done only between two different georeferenced coordinate systems or between two different local coordinate systems.
Transformation of circles and arcs is not supported, regardless of the type of coordinate systems involved.
An exception is raised if geom
, to_srid
, or to_srname
is invalid. For geom
to be valid for this function, its definition must include an SRID value matching a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Examples
The following example transforms the cola_c
geometry to a representation that uses SRID value 8199. (This example uses the definitions from the example in Section 6.13.)
 Return the transformation of cola_c using to_srid 8199  ('Longitude / Latitude (Arc 1950)') SELECT c.name, SDO_CS.TRANSFORM(c.shape, 8199) FROM cola_markets_cs c WHERE c.name = 'cola_c'; NAME  SDO_CS.TRANSFORM(C.SHAPE,8199)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM  cola_c SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482))  Same as preceding, but using to_srname parameter. SELECT c.name, SDO_CS.TRANSFORM(c.shape, 'Longitude / Latitude (Arc 1950)') FROM cola_markets_cs c WHERE c.name = 'cola_c'; NAME  SDO_CS.TRANSFORM(C.SHAPE,'LONGITUDE/LATITUDE(ARC1950)')(SDO_GTYPE, SDO_SRID, SDO  cola_c SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482))
Format
SDO_CS.TRANSFORM_LAYER(
table_in IN VARCHAR2,
column_in IN VARCHAR2,
table_out IN VARCHAR2,
to_srid IN NUMBER);
or
SDO_CS.TRANSFORM_LAYER(
table_in IN VARCHAR2,
column_in IN VARCHAR2,
table_out IN VARCHAR2,
use_plan IN TFM_PLAN);
or
SDO_CS.TRANSFORM_LAYER(
table_in IN VARCHAR2,
column_in IN VARCHAR2,
table_out IN VARCHAR2,
use_case IN VARCHAR2,
to_srid IN NUMBER);
Description
Transforms an entire layer of geometries (that is, all geometries in a specified column in a table).
Parameters
Table containing the layer (column_in
) whose geometries are to be transformed.
Column in table_in
that contains the geometries to be transformed.
Table that will be created and that will contain the results of the transformation. See the Usage Notes for information about the format of this table.
The SRID of the coordinate system to be used for the transformation. to_srid
must be a value in the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Transformation plan. The TFM_PLAN object type is explained in Section 6.6.
Name of the use case whose transformation rules are to be applied in performing the transformation. Use cases are explained in Section 6.4.
Usage Notes
Transformation can be done only between two different georeferenced coordinate systems or between two different local coordinate systems.
An exception is raised if any of the following occurs:
table_in
does not exist, or column_in
does not exist in the table.
The geometries in column_in
have a null or invalid SDO_SRID value.
table_out
already exists.
to_srid
is invalid.
The table_out
table is created by the procedure and is filled with one row for each transformed geometry. This table has the columns shown in Table 212.
Table 212 Table to Hold Transformed Layer
Column Name  Data Type  Description 

SDO_ROWID 
ROWID 
Oracle ROWID (row address identifier). For more information about the ROWID data type, see Oracle Database SQL Language Reference. 
GEOMETRY 
SDO_GEOMETRY 
Geometry object with coordinate values in the specified ( 
Examples
The following example transforms the geometries in the shape
column in the COLA_MARKETS_CS table to a representation that uses SRID value 8199. The transformed geometries are stored in the newly created table named COLA_MARKETS_CS_8199. (This example uses the definitions from the example in Section 6.13.)
 Transform the entire SHAPE layer and put results in the table  named cola_markets_cs_8199, which the procedure will create. CALL SDO_CS.TRANSFORM_LAYER('COLA_MARKETS_CS','SHAPE','COLA_MARKETS_CS_8199',8199);
Example 618 in Section 6.13 includes a display of the geometry object coordinates in both tables (COLA_MARKETS_CS and COLA_MARKETS_CS_8199).
Description
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems.
Usage Notes
For information about using procedures to update wellknown text (WKT) description, see Section 6.8.1.3.
Description
Updates the wellknown text (WKT) description for the EPSG coordinate reference system associated with a specified SRID.
Parameters
The SRID of the coordinate system whose wellknown text (WKT) description is to be updated. An entry for the specified value must exist in the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Usage Notes
This procedure updates the WKT descriptions for the specified SRID and all dependent SRIDs. For example, for SRID 4326 (WGS84 geodetic system), all EPSG coordinate systems that use this geodetic system will also be updated.
For information about using procedures to update wellknown text (WKT) descriptions, see Section 6.8.1.3.
Description
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified datum.
Parameters
The ID of the datum. Must match a value in the DATUM_ID column of the SDO_DATUMS table (described in Section 6.7.22).
Usage Notes
For information about using procedures to update wellknown text (WKT) description, see Section 6.8.1.3.
Description
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified ellipsoid.
Parameters
The ID of the ellipsoid. Must match a value in the ELLIPSOID_ID column of the SDO_ELLIPSOIDS table (described in Section 6.7.23).
Usage Notes
For information about using procedures to update wellknown text (WKT) description, see Section 6.8.1.3.
Examples
The following example updates the WKT description for all EPSG coordinate reference systems associated with ellipsoid 7100.
EXECUTE SDO_CS.UPDATE_WKTS_FOR_EPSG_ELLIPS(7001); Updating SRID 4001... Updating SRID 4188... Updating SRID 29901... Updating SRID 61886405... Updating SRID 4277... Updating SRID 27700... Updating SRID 62776405... Updating SRID 4278... Updating SRID 62786405... Updating SRID 4279... Updating SRID 62796405...
Description
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified coordinate transformation operation.
Parameters
The ID of the SRID of the coordinate transformation operation. Must match a value in the COORD_OP_ID column of the SDO_COORD_OP_PARAM_VALS table (described in Section 6.7.5).
Usage Notes
For information about using procedures to update wellknown text (WKT) description, see Section 6.8.1.3.
Description
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified coordinate transformation operation and parameter for transformation operations.
Parameters
The ID of the SRID of the coordinate transformation operation. Must match a value in the COORD_OP_ID column of the SDO_COORD_OP_PARAM_VALS table (described in Section 6.7.5).
The ID of the SRID of the parameter for transformation operations. Must match a value in the PARAMETER_ID column of the SDO_COORD_OP_PARAM_VALS table (described in Section 6.7.5) where the COORD_OP_ID column value is equal to the coord_op_id
parameter value.
Usage Notes
For information about using procedures to update wellknown text (WKT) description, see Section 6.8.1.3.
Description
Updates the wellknown text (WKT) description for all EPSG coordinate reference systems associated with a specified prime meridian.
Parameters
The ID of the prime meridian. Must match a value in the PRIME_MERIDIAN_ID column in the SDO_PRIME_MERIDIANS table (described in Section 6.7.26).
Usage Notes
For information about using procedures to update wellknown text (WKT) description, see Section 6.8.1.3.
Examples
The following example updates the WKT description for all EPSG coordinate reference systems associated with prime meridian 8902.
EXECUTE SDO_CS.UPDATE_WKTS_FOR_EPSG_PM(8902); Updating SRID 4803... Updating SRID 20790... Updating SRID 20791... Updating SRID 68036405... Updating SRID 4904... Updating SRID 2963... Updating SRID 69046405...
Parameters
The SRID of the coordinate system whose wellknown text (WKT) description is to be validated. An entry for the specified value must exist in the SDO_COORD_REF_SYS table (described in Section 6.7.9).
Usage Notes
This function returns the string 'TRUE' if the WKT description is valid. If the WKT description is invalid, this function returns a string in the format 'FALSE (<positionnumber>)', where <positionnumber> is the number of the character position in the WKT description where the first error occurs.
The WKT description is checked to see if it satisfies the requirements described in Section 6.8.1.1.
Examples
The following example validates the WKT description of the coordinate system associated with SRID 81989000. The results show that the cause of the invalidity (or the first cause of the invalidity) starts at character position 181 in the WKT description. (SRID 81989000 is not associated with any established coordinate system. Rather, it is for a deliberately invalid coordinate system that was inserted into a test version of the MDSYS.CS_SRS table, and it is not included in the MDSYS.CS_SRS table that is shipped with Oracle Spatial.)
SELECT SDO_CS.VALIDATE_WKT(81989000) FROM DUAL; SDO_CS.VALIDATE_WKT(81989000)  FALSE (181)
This chapter describes in greater detail the Oracle Spatial coordinate system support, which was introduced in Section 1.5.4. You can store and manipulate SDO_GEOMETRY objects in a variety of coordinate systems.
For reference information about coordinate system transformation functions and procedures in the MDSYS.SDO_CS package, see Chapter 21.
This chapter contains the following major sections:
Section 6.5, "ThreeDimensional Coordinate Reference System Support"
Section 6.9, "Creating a UserDefined Coordinate Reference System"
Section 6.10, "Notes and Restrictions with Coordinate Systems Support"
This section explains important terms and concepts related to coordinate system support in Oracle Spatial.
A coordinate system (also called a spatial reference system) is a means of assigning coordinates to a location and establishing relationships between sets of such coordinates. It enables the interpretation of a set of coordinates as a representation of a position in a real world space.
The term coordinate reference system has the same meaning as coordinate system for Spatial, and the terms are used interchangeably. European Petroleum Survey Group (EPSG) specifications and documentation typically use the term coordinate reference system. (EPSG has its own meaning for the term coordinate system, as noted in Section 6.7.11.)
Cartesian coordinates are coordinates that measure the position of a point from a defined origin along axes that are perpendicular in the represented twodimensional or threedimensional space.
Geodetic coordinates (sometimes called geographic coordinates) are angular coordinates (longitude and latitude), closely related to spherical polar coordinates, and are defined relative to a particular Earth geodetic datum (described in Section 6.1.6). For more information about geodetic coordinate support, see Section 6.2.
Projected coordinates are planar Cartesian coordinates that result from performing a mathematical mapping from a point on the Earth's surface to a plane. There are many such mathematical mappings, each used for a particular purpose.
Local coordinates are Cartesian coordinates in a nonEarth (nongeoreferenced) coordinate system. Section 6.3 describes local coordinate support in Spatial.
A geodetic datum (or datum) is a means of shifting and rotating an ellipsoid to represent the figure of the Earth, usually as an oblate spheroid, that approximates the surface of the Earth locally or globally, and is the reference for the system of geodetic coordinates.
Each geodetic coordinate system is based on a datum.
Transformation is the conversion of coordinates from one coordinate system to another coordinate system.
If the coordinate system is georeferenced, transformation can involve datum transformation: the conversion of geodetic coordinates from one geodetic datum to another geodetic datum, usually involving changes in the shape, orientation, and center position of the reference ellipsoid.
Effective with Oracle9i, Spatial provides a rational and complete treatment of geodetic coordinates. Before Oracle9i, Spatial computations were based solely on flat (Cartesian) coordinates, regardless of the coordinate system specified for the layer of geometries. Consequently, computations for data in geodetic coordinate systems were inaccurate, because they always treated the coordinates as if they were on a flat surface, and they did not consider the curvature of the surface.
Effective with release 9.2, ellipsoidal surface computations consider the curvatures of the Earth in the specified geodetic coordinate system and return correct, accurate results. In other words, Spatial queries return the right answers all the time.
A twodimensional geometry is a surface geometry, but the important question is: What is the surface? A flat surface (plane) is accurately represented by Cartesian coordinates. However, Cartesian coordinates are not adequate for representing the surface of a solid. A commonly used surface for spatial geometry is the surface of the Earth, and the laws of geometry there are different than they are in a plane. For example, on the Earth's surface there are no parallel lines: lines are geodesics, and all geodesics intersect. Thus, closed curved surface problems cannot be done accurately with Cartesian geometry.
Spatial provides accurate results regardless of the coordinate system or the size of the area involved, without requiring that the data be projected to a flat surface. The results are accurate regardless of where on the Earth's surface the query is focused, even in "special" areas such as the poles. Thus, you can store coordinates in any datum and projections that you choose, and you can perform accurate queries regardless of the coordinate system.
For applications that deal with the Earth's surface, the data can be represented using a geodetic coordinate system or a projected plane coordinate system. In deciding which approach to take with the data, consider any needs related to accuracy and performance:
Accuracy
For many spatial applications, the area is sufficiently small to allow adequate computations on Cartesian coordinates in a local projection. For example, the New Hampshire State Plane local projection provides adequate accuracy for most spatial applications that use data for that state.
However, Cartesian computations on a plane projection will never give accurate results for a large area such as Canada or Scandinavia. For example, a query asking if Stockholm, Sweden and Helsinki, Finland are within a specified distance may return an incorrect result if the specified distance is close to the actual measured distance. Computations involving large areas or requiring very precise accuracy must account for the curvature of the Earth's surface.
Performance
Spherical computations use more computing resources than Cartesian computations. Some operations using geodetic coordinates may take longer to complete than the same operations using Cartesian coordinates.
This section discusses guidelines for choosing the appropriate type of height for threedimensional data: nonellipsoidal or ellipsoidal. Although ellipsoidal height is widely used and is the default for many GPS applications, and although ellipsoidal computations incur less performance overhead in many cases, there are applications for which a nonellipsoidal height may be preferable or even necessary.
Also, after any initial decision, you can change the reference height type, because transformations between different height datums are supported.
Nonellipsoidal height is measured from some point other than the reference ellipsoid. Some common nonellipsoidal measurements of height are from ground level, mean sea level (MSL), or the reference geoid.
Ground level: Measuring height from the ground level is conceptually the simplest approach, and it is common in very local or informal applications. For example, when modeling a single building or a cluster of buildings, ground level may be adequate.
Moreover, if you ever need to integrate local ground height with a global height datum, you can achieve this with a transformation (EPSG method 9616) adding a local constant reference height. If you need to model local terrain undulations, you can achieve this with a transformation using an offset matrix (EPSG method 9635), just as you can between the geoid and the ellipsoid.
Mean sea level (MSL): MSL is a common variation of sea level that provides conceptual simplicity, ignoring local variations and changes over time in sea level. It can also be extrapolated to areas covered by land.
Height relative to MSL is useful for a variety of applications, such as those dealing with flooding risk, gravitational potential, and how thin the air is. MSL is commonly used for the heights of aircraft in flight.
Geoid: The geoid, the equipotential surface closest to MSL, provides the most precise measurements of height in terms of gravitational pull, factoring in such things as climate and tectonic changes. The geoid can deviate from MSL by approximately 2 meters (plus or minus).
If an application is affected more by purely gravitational effects than by actual local sea level, you may want to use the geoid as the reference rather than MSL. To perform transformations between MSL, geoid, or ellipsoid, you can use EPSG method 9635 and the appropriate timestamped offset matrix.
Because most nonellipsoidal height references are irregular and undulating surfaces, transformations between them are more complicated than with ellipsoidal heights. One approach is to use an offset grid file to define the transformation. This approach is implemented in EPSG method 9635. The grid file has to be acquired (often available publicly from government websites). Moreover, because most such nonellipsoidal height datums (including the geoid, sea level, and local terrain) change over time, the timestamp of an offset matrix may matter, even if not by much. (Of course, the same principle applies to ellipsoids as well, since they are not static in the long term. After all, they are intended to approximate the changing geoid, MSL, or terrain.)
Regarding performance and memory usage with EPSG method 9635, at runtime the grid must be loaded before the transformation of a dataset. This load operation temporarily increases the footprint in main memory and incurs onetime loading overhead. If an entire dataset is transformed, the overhead can be relatively insignificant; however, if frequent transformations are performed on single geometries, the cumulative overhead can become significant.
Ellipsoidal height is measured from a point on the reference ellipsoid. The ellipsoid is a convenient and relatively faithful approximation of the Earth. Although using an ellipsoid is more complex than using a sphere to represent the Earth, using an ellipsoid is, for most applications, simpler than using a geoid or local heights (although with some sacrifice in precision). Moreover, geoidal and sealevel heights are often not well suited for mathematical analysis, because the undulating and irregular shapes would make certain computations prohibitively complex and expensive.
GPS applications often assume ellipsoidal height as a reference and use it as the default. Because the ellipsoid is chosen to match the geoid (and similar sea level), ellipsoidal height tends not to deviate far from MSL height. For example, the geoid diverges from the NAD83 ellipsoid by only up to 50 meters. Other ellipsoids may be chosen to match a particular country even more closely.
Even if different parties use different ellipsoids, a WKT can conveniently describe such differences. A simple datum transformation can efficiently and accurately perform transformations between ellipsoids. Because no offset matrix is involved, no loading overhead is required. Thus, interoperability is simplified with ellipsoidal height, although future requirements or analysis might necessitate the use of MSL, a geoid, or other nonellipsoidal height datums.
To create a query window for certain operations on geodetic data, use an MBR (minimum bounding rectangle) by specifying an SDO_ETYPE value of 1003 or 2003 (optimized rectangle) and an SDO_INTERPRETATION value of 3, as described in Table 22 in Section 2.2.4. A geodetic MBR can be used with the following operators: SDO_FILTER, SDO_RELATE with the ANYINTERACT
mask, SDO_ANYINTERACT, and SDO_WITHIN_DISTANCE.
Example 61 requests the names of all cola markets that are likely to interact spatially with a geodetic MBR.
Example 61 Using a Geodetic MBR
SELECT c.name FROM cola_markets_cs c WHERE SDO_FILTER(c.shape, SDO_GEOMETRY( 2003, 8307,  SRID for WGS 84 longitude/latitude NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(6,5, 10,10)) ) = 'TRUE';
Example 61 produces the following output (assuming the data as defined in Example 617 in Section 6.13):
NAME  cola_c cola_b cola_d
The following considerations apply to the use of geodetic MBRs:
Do not use a geodetic MBR with spatial objects stored in the database. Use it only to construct a query window.
The lowerleft Y coordinate (minY) must be less than the upperright Y coordinate (maxY). If the lowerleft X coordinate (minX) is greater than the upperright X coordinate (maxX), the window is assumed to cross the date line meridian (that is, the meridian "opposite" the prime meridian, or both 180 and 180 longitude). For example, an MBR of (10,10, 100, 20) with longitude/latitude data goes threefourths of the way around the Earth (crossing the date line meridian), and goes from latitude lines 10 to 20.
When Spatial constructs the MBR internally for the query, lines along latitude lines are densified by adding points at onedegree intervals. This might affect results for objects within a few meters of the edge of the MBR (especially objects in the middle latitudes in both hemispheres).
When an optimized rectangle spans more than 119 degrees in longitude, it is internally divided into three rectangles; and as a result, these three rectangles share an edge that is the common boundary between them. If you validate the geometry of such an optimized rectangle, error code 13351 is returned because the internal rectangles have a shared edge. You can use such an optimized rectangle for queries with only the following: SDO_ANYINTERACT operator, SDO_RELATE operator with the ANYINTERACT mask, or SDO_GEOM.RELATE function with the ANYINTERACT mask. (Any other queries on such an optimized rectangle may return incorrect results.)
The following additional examples show special or unusual cases, to illustrate how a geodetic MBR is interpreted with longitude/latitude data:
(10,0, 110,20) crosses the date line meridian and goes most of the way around the world, and goes from the equator to latitude 20.
(10,90, 40,90) is a band from the South Pole to the North Pole between longitudes 10 and 40.
(10,90, 40,50) is a band from the South Pole to latitude 50 between longitudes 10 and 40.
(180,10, 180,5) is a band that wraps the equator from 10 degrees south to 5 degrees north.
(180,90, 180,90) is the whole Earth.
(180,90, 180,50) is the whole Earth below latitude 50.
(180,50, 180,90) is the whole Earth above latitude 50.
The following geometries are not permitted if a geodetic coordinate system is used or if any transformation is being performed (even if the transformation is from one projected coordinate system to another projected coordinate system):
Circles
Circular arcs
Geodetic coordinate system support is provided only for geometries that consist of points or geodesics (lines on the ellipsoid). If you have geometries containing circles or circular arcs in a projected coordinate system, you can densify them using the SDO_GEOM.SDO_ARC_DENSIFY function (documented in Chapter 24) before transforming them to geodetic coordinates, and then perform Spatial operations on the resulting geometries.
The following size limits apply with geodetic data:
No polygon element can have an area larger than or equal to onehalf the surface of the Earth. Moreover, if the result of a union of two polygons is greater than onehalf the surface of the Earth, the operation will not produce a correct result. For example, if A union B results in a polygon that is greater than onehalf of the area of the Earth, the operations A difference B, A intersection B, and A XOR B are not supported, and only a relate operation with the ANYINTERACT mask is supported between those two polygons.
In a line, the distance between two adjacent coordinates cannot be greater than or equal to onehalf the perimeter (a great circle) of the Earth.
If you need to work with larger elements, first break these elements into multiple smaller elements and work with them. For example, you cannot create a geometry representing the entire ocean surface of the Earth; however, you can create multiple geometries, each representing part of the overall ocean surface. To work with a line string that is greater than or equal to onehalf the perimeter of the Earth, you can add one or more intermediate points on the line so that all adjacent coordinates are less than onehalf the perimeter of the Earth.
Tolerance is specified as meters for geodetic layers. If you use tolerance values that are typical for nongeodetic data, these values are interpreted as meters for geodetic data. For example, if you specify a tolerance value of 0.05 for geodetic data, this is interpreted as precise to 5 centimeters. If this value is more precise than your applications need, performance may be affected because of the internal computational steps taken to implement the specified precision. (For more information about tolerance, see Section 1.5.5.)
For geodetic layers, you must specify the dimensional extents in the index metadata as 180,180 for longitude and 90,90 for latitude. The following statement (from Example 617 in Section 6.13) specifies these extents (with a 10meter tolerance value in each dimension) for a geodetic data layer:
INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES ( 'cola_markets_cs', 'shape', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', 180, 180, 10),  10 meters tolerance SDO_DIM_ELEMENT('Latitude', 90, 90, 10)  10 meters tolerance ), 8307  SRID for 'Longitude / Latitude (WGS 84)' coordinate system );
See Section 6.10 for additional notes and restrictions relating to geodetic data.
Spatial provides a level of support for local coordinate systems. Local coordinate systems are often used in CAD systems, and they can also be used in local surveys where the relationship between the surveyed site and the rest of the world is not important.
Several local coordinate systems are predefined and included with Spatial in the SDO_COORD_REF_SYS table (described in Section 6.7.9). These supplied local coordinate systems, whose names start with NonEarth, define nonEarth Cartesian coordinate systems based on different units of measurement (Meter, Millimeter, Inch, and so on).
In the current release, you cannot perform coordinate system transformation between local and Earthbased coordinate systems; and when transforming a geometry or layer of geometries between local coordinate systems, you can only to convert coordinates in a local coordinate system from one unit of measurement to another (for example, inches to millimeters). However, you can perform all other Spatial operations (for example, using SDO_RELATE, SDO_WITHIN_DISTANCE, and other operators) with local coordinate systems.
The Oracle Spatial coordinate system support is based on, but is not always identical to, the European Petroleum Survey Group (EPSG) data model and dataset. These are described in detail at http://www.epsg.org
, and the download for the EPSG geodetic parameter dataset includes a "Readme" that contains an entityrelationship (ER) diagram. The approach taken by Oracle Spatial provides the benefits of standardization, expanded support, and flexibility:
The EPSG model is a comprehensive and widely accepted standard for data representation, so users familiar with it can more easily understand Spatial storage and operations.
Support is provided for more coordinate systems and their associated datums, ellipsoids, and projections. For example, some of the EPSG geographic and projected coordinate systems had no counterpart among coordinate systems supported for previous Spatial releases. Their addition results in an expanded set of supported coordinate systems.
Data transformations are more flexible. Instead of there being only one possible Oracledefined transformation path between a given source and target coordinate system, you can specify alternative paths to be used for a specific area of applicability (that is, use case) or as the systemwide default.
The rest of this section describes this flexibility.
For data transformations (that is, transforming data from one coordinate system to another), you can now control which transformation rules are to be applied. In previous releases, and in the current release by default, Spatial performs transformations based only on the specified source and target coordinate systems, using predetermined intermediate transformation steps. The assumption behind that default approach is that there is a single correct or preferable transformation chain.
By default, then, Spatial applies certain transformation methods for each supported transformation between specific pairs of source and target coordinate systems. For example, there are over 500 supported transformations from specific coordinate systems to the WGS 84 (longitude/latitude) coordinate system, which has the EPSG SRID value of 4326. As one example, for a transformation from SRID 4605 to SRID 4326, Spatial can use the transformation method with the COORD_OP_ID value 1445, as indicated in the SDO_COORD_OPS table (described in Section 6.7.8), which contains one row for each transformation operation between coordinate systems.
However, you can override the default transformation by specifying a different method (from the set of Oraclesupplied methods) for the transformation for any given source and target SRID combination. You can specify a transformation as the new systemwide default, or you can associate the transformation with a named use case that can be specified when transforming a layer of spatial geometries. (A use case is simply a name given to a usage scenario or area of applicability, such as Project XYZ or Mike's Favorite Transformations; there is no relationship between use cases and database users or schemas.)
To specify a transformation as either the systemwide default or associated with a use case, use the SDO_CS.ADD_PREFERENCE_FOR_OP procedure. To remove a previously specified preference, use the SDO_CS.REVOKE_PREFERENCE_FOR_OP procedure.
When it performs a coordinate system transformation, Spatial follows these general steps to determine the specific transformation to use:
If a use case has been specified, the transformation associated with that use case is applied.
If no use case has been specified and if a userdefined systemwide transformation has been created for the specified source and target coordinate system pair, that transformation is applied.
If no use case has been specified and if no userdefined transformation exists for the specified source and target coordinate system pair, the behavior depends on whether or not EPSG rules have been created, such as by the SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure:
If the EPSG rules have been created and if an EPSG rule is defined for this transformation, the EPSG transformation is applied.
If the EPSG rules have not been created, or if they have been created but no EPSG rule is defined for this transformation, the Oracle Spatial default transformation is applied.
To return the version number of the EPSG dataset used by Spatial, use the SDO_CS.GET_EPSG_DATA_VERSION function.
The Oracle Spatial support for threedimensional coordinate reference systems complies with the EPSG model (described in Section 6.4), which provides the following types of coordinate reference systems:
Geographic 2D
Projected 2D
Geographic 3D, which consists of Geographic 2D plus ellipsoidal height, with longitude, latitude, and height based on the same ellipsoid and datum
Compound, which consists of either Geographic 2D plus gravityrelated height or Projected 2D plus gravityrelated height
Thus, there are two categories of threedimensional coordinate reference systems: those based on ellipsoidal height (geographic 3D, described in Section 6.5.1) and those based on gravityrelated height (compound, described in Section 6.5.2).
Threedimensional computations are more accurate than their twodimensional equivalents, particularly when they are chained: For example, datum transformations internally always are performed in three dimensions, regardless of the dimensionality of the source and target CRS and geometries. When twodimensional geometries are involved, one or more of the following can occur:
When the input or output geometries and CRS are twodimensional, the (unspecified) input height defaults to zero (above the ellipsoid, depending on the CRS) for any internal threedimensional computations. This is a potential source of inaccuracy, unless the height was intended to be exactly zero. (Data can be twodimensional because height values were originally either unavailable or not considered important; this is different from representing data in two dimensions because heights are known to be exactly zero.
The transformation might then internally result in a nonzero height. Since the twodimensional target CRS cannot accommodate the height value, the height value must be truncated, resulting in further inaccuracy.
If further transformations are chained, the repeated truncation of height values can result in increasing inaccuracies. Note that an inaccurate input height can affect not only the output height of a transformation, but also the longitude and latitude.
However, if the source and target CRS are threedimensional, there is no repeated truncation of heights. Consequently, accuracy is increased, particularly for transformation chains.
For an introduction to support in Spatial for threedimensional geometries, see Section 1.11.
A geographic threedimensional coordinate reference system is based on longitude and latitude, plus ellipsoidal height. The ellipsoidal height is the height relative to a reference ellipsoid, which is an approximation of the real Earth. All three dimensions of the CRS are based on the same ellipsoid.
Using ellipsoidal heights enables Spatial to perform internal operations with great mathematical regularity and efficiency. Compound coordinate reference systems, on the other hand, require more complex transformations, often based on offset matrixes. Some of these matrixes have to be downloaded and configured. Furthermore, they might have a significant footprint, on disk and in main memory.
The supported geographic 3D coordinate reference systems are listed in the SDO_CRS_GEOGRAPHIC3D view, described in Section 6.7.16.
A compound threedimensional coordinate reference system is based on a geographic or projected twodimensional system, plus gravityrelated height. Gravityrelated height is the height as influenced by the Earth's gravitational force, where the base height (zero) is often an equipotential surface, and might be defined as above or below "sea level."
Gravityrelated height is a more complex representation than ellipsoidal height, because of gravitational irregularities such as the following:
Orthometric height is also referred to as the height above the geoid. The geoid is an equipotential surface that most closely (but not exactly) matches mean sea level. An equipotential surface is a surface on which each point is at the same gravitational potential level. Such a surface tends to undulate slightly, because the Earth has regions of varying density. There are multiple equipotential surfaces, and these might not be parallel to each other due to the irregular density of the Earth.
Height relative to mean sea level, to sea level at a specific location, or to a vertical network warped to fit multiple tidal stations (for example, NGVD 29)
Sea level is close to, but not identical to, the geoid. The sea level at a given location is often defined based on the "average sea level" at a specific port.
The supported compound coordinate reference systems are listed in the SDO_CRS_COMPOUND view, described in Section 6.7.12.
You can create a customized compound coordinate reference system, which combines a horizontal CRS with a vertical CRS. (The horizontal CRS contains two dimensions, such as X and Y or longitude and latitude, and the vertical CRS contains the third dimension, such as Z or height or altitude.) Section 6.9.4 explains how to create a compound CRS.
Spatial supports threedimensional coordinate transformations for SDO_GEOMETRY objects directly, and indirectly for point clouds and TINs. (For example, a point cloud must be transformed to a table with an SDO_GEOMETRY column.) The supported transformations include the following:
Threedimensional datum transformations
Transformations between ellipsoidal and gravityrelated height
For threedimensional datum transformations, the datum transformation between the two ellipsoids is essentially the same as for twodimensional coordinate reference systems, except that the third dimension is considered instead of ignored. Because height values are not ignored, the accuracy of the results increases, especially for transformation chains.
For transformations between ellipsoidal and gravityrelated height, computations are complicated by the fact that equipotential and other gravityrelated surfaces tend to undulate, compared to any ellipsoid and to each other. Transformations might be based on higherdegree polynomial functions or bilinear interpolation. In either case, a significant parameter matrix is required to define the transformation.
For transforming between gravityrelated and ellipsoidal height, the process usually involves a transformation, based on an offset matrix, between geoidal and ellipsoidal height. Depending on the source or target definition of the offset matrix, a common datum transformation might have to be appended or prefixed.
Example 62 shows a threedimensional datum transformation.
Example 62 ThreeDimensional Datum Transformation
set numwidth 9 CREATE TABLE source_geoms ( mkt_id NUMBER PRIMARY KEY, name VARCHAR2(32), GEOMETRY SDO_GEOMETRY); INSERT INTO source_geoms VALUES( 1, 'reference geom', SDO_GEOMETRY( 3001, 4985, SDO_POINT_TYPE( 4.0, 55.0, 1.0), NULL, NULL)); INSERT INTO USER_SDO_GEOM_METADATA VALUES ( 'source_geoms', 'GEOMETRY', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', 180, 180, 10), SDO_DIM_ELEMENT('Latitude', 90, 90, 10), SDO_DIM_ELEMENT('Height', 1000,1000, 10)), 4985); commit;  CALL SDO_CS.TRANSFORM_LAYER( 'source_geoms', 'GEOMETRY', 'GEO_CS_4979', 4979); INSERT INTO USER_SDO_GEOM_METADATA VALUES ( 'GEO_CS_4979', 'GEOMETRY', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', 180, 180, 10), SDO_DIM_ELEMENT('Latitude', 90, 90, 10), SDO_DIM_ELEMENT('Height', 1000,1000, 10)), 4979); set lines 210;  CALL SDO_CS.TRANSFORM_LAYER( 'GEO_CS_4979', 'GEOMETRY', 'source_geoms2', 4985); INSERT INTO USER_SDO_GEOM_METADATA VALUES ( 'source_geoms2', 'GEOMETRY', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', 180, 180, 10), SDO_DIM_ELEMENT('Latitude', 90, 90, 10), SDO_DIM_ELEMENT('Height', 1000,1000, 10)), 4985);  DELETE FROM USER_SDO_GEOM_METADATA WHERE table_name = 'GEO_CS_4979'; DELETE FROM USER_SDO_GEOM_METADATA WHERE table_name = 'SOURCE_GEOMS'; DELETE FROM USER_SDO_GEOM_METADATA WHERE table_name = 'SOURCE_GEOMS2'; drop table GEO_CS_4979; drop table source_geoms; drop table source_geoms2;
As a result of the transformation in Example 62, (4, 55, 1) is transformed to (4.0001539, 55.0000249, 4.218).
Example 63 configures a transformation between geoidal and ellipsoidal height, using a Hawaii offset grid. Note that without the initial creation of a rule (using the SDO_CS.CREATE_PREF_CONCATENATED_OP procedure), the grid would not be used.
Example 63 Transformation Between Geoidal And Ellipsoidal Height
 Create Sample operation: insert into mdsys.sdo_coord_ops ( COORD_OP_ID, COORD_OP_NAME, COORD_OP_TYPE, SOURCE_SRID, TARGET_SRID, COORD_TFM_VERSION, COORD_OP_VARIANT, COORD_OP_METHOD_ID, UOM_ID_SOURCE_OFFSETS, UOM_ID_TARGET_OFFSETS, INFORMATION_SOURCE, DATA_SOURCE, SHOW_OPERATION, IS_LEGACY, LEGACY_CODE, REVERSE_OP, IS_IMPLEMENTED_FORWARD, IS_IMPLEMENTED_REVERSE) values ( 1000000005, 'Test Bilinear Interpolation', 'CONVERSION', null, null, null, null, 9635, null, null, 'Oracle', 'Oracle', 1, 'FALSE', null, 1, 1, 1); Create sample parameters, pointing to the offset file (in this case reusing values from an existing operation): insert into mdsys.sdo_coord_op_param_vals ( coord_op_id, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, PARAM_VALUE_FILE, PARAM_VALUE_XML, UOM_ID) ( select 1000000005, 9635, 8666, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, PARAM_VALUE_FILE, PARAM_VALUE_XML, UOM_ID from mdsys.sdo_coord_op_param_vals where coord_op_id = 999998 and parameter_id = 8666); Create a rule to use this operation between SRIDs 7406 and 4359: call sdo_cs.create_pref_concatenated_op( 300, 'CONCATENATED OPERATION', TFM_PLAN(SDO_TFM_CHAIN(7406, 1000000005, 4359)), NULL);  Now, actually perform the transformation: set numformat 999999.99999999  Create the source table CREATE TABLE source_geoms ( mkt_id NUMBER PRIMARY KEY, name VARCHAR2(32), GEOMETRY SDO_GEOMETRY); INSERT INTO source_geoms VALUES( 1, 'reference geom', SDO_GEOMETRY( 3001, 7406, SDO_POINT_TYPE( 161, 18, 0), NULL, NULL)); INSERT INTO USER_SDO_GEOM_METADATA VALUES ( 'source_geoms', 'GEOMETRY', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', 180, 180, 10), SDO_DIM_ELEMENT('Latitude', 90, 90, 10), SDO_DIM_ELEMENT('Height', 100, 100, 10)), 7406); commit; SELECT GEOMETRY "Source" FROM source_geoms;  Perform the transformation: CALL SDO_CS.TRANSFORM_LAYER( 'source_geoms', 'GEOMETRY', 'GEO_CS_4359', 4359); INSERT INTO USER_SDO_GEOM_METADATA VALUES ( 'GEO_CS_4359', 'GEOMETRY', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', 180, 180, 10), SDO_DIM_ELEMENT('Latitude', 90, 90, 10), SDO_DIM_ELEMENT('Height', 100, 100, 10)), 4359); set lines 210; SELECT GEOMETRY "Target" FROM GEO_CS_4359;  Transform back: CALL SDO_CS.TRANSFORM_LAYER( 'GEO_CS_4359', 'GEOMETRY', 'source_geoms2', 7406); INSERT INTO USER_SDO_GEOM_METADATA VALUES ( 'source_geoms2', 'GEOMETRY', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', 180, 180, 10), SDO_DIM_ELEMENT('Latitude', 90, 90, 10), SDO_DIM_ELEMENT('Height', 100, 100, 10)), 7406); SELECT GEOMETRY "Source2" FROM source_geoms2;  Clean up (regarding the transformation): DELETE FROM USER_SDO_GEOM_METADATA WHERE table_name = 'GEO_CS_4359'; DELETE FROM USER_SDO_GEOM_METADATA WHERE table_name = 'SOURCE_GEOMS'; DELETE FROM USER_SDO_GEOM_METADATA WHERE table_name = 'SOURCE_GEOMS2'; drop table GEO_CS_4359; drop table source_geoms; drop table source_geoms2; Clean up (regarding the rule): CALL sdo_cs.delete_op(300); delete from mdsys.sdo_coord_op_param_vals where coord_op_id = 1000000005; delete from mdsys.sdo_coord_ops where coord_op_id = 1000000005; COMMIT;
With the configuration in Example 63:
Without the rule, (161.00000000, 18.00000000, .00000000) is transformed to (161.00127699, 18.00043360, 62.03196364), based simply on a datum transformation.
With the rule, (161.00000000, 18.00000000, .00000000) is transformed to (161.00000000, 18.00000000, 6.33070000).
You cannot directly perform a crossdimensionality transformation (for example, from a twodimensional geometry to a threedimensional geometry) using the SDO_CS.TRANSFORM function or the SDO_CS.TRANSFORM_LAYER procedure. However, you can use the SDO_CS.MAKE_3D function to convert a twodimensional geometry to a threedimensional geometry, or the SDO_CS.MAKE_2D function to convert a threedimensional geometry to a twodimensional geometry; and you can use the resulting geometry to perform a transformation into a geometry with the desired number of dimensions.
For example, transforming a twodimensional geometry into a threedimensional geometry involves using the SDO_CS.MAKE_3D function. This function does not itself perform any coordinate transformation, but simply adds a height value and sets the target SRID. You must choose an appropriate target SRID, which should be the threedimensional equivalent of the source SRID. For example, threedimensional WGS84 (4327) is the equivalent of twodimensional WGS84 (4326). If necessary, modify height values of vertices in the returned geometry.
There are many options for how to use the SDO_CS.MAKE_3D function, but the simplest is the following:
Transform from the twodimensional source SRID to twodimensional WGS84 (4326).
Call SDO_CS.MAKE_3D to convert the geometry to threedimensional WGS84 (4327)
Transform from threedimensional WGS84 (4327) to the threedimensional target SRID.
Example 64 transforms a twodimensional point from SRID 27700 to twodimensional SRID 4326, converts the result of the transformation to a threedimensional point with SRID 4327, and transforms the converted point to threedimensional SRID 4327.
Example 64 CrossDimensionality Transformation
SELECT SDO_CS.TRANSFORM( SDO_CS.MAKE_3D( SDO_CS.TRANSFORM( SDO_GEOMETRY( 2001, 27700, SDO_POINT_TYPE(577274.984, 69740.4923, NULL), NULL, NULL), 4326), height => 0, target_srid => 4327), 4327) "27700 > 4326 > 4327 > 4327" FROM DUAL; 27700 > 4326 > 4327 > 4327(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INF  SDO_GEOMETRY(3001, 4327, SDO_POINT_TYPE(.498364058, 50.5006366, 0), NULL, NULL)
There are two possible answers to the question What is 3D equivalent for the WGS 84 coordinate system? (that is, 2D Oracle SRID 8308 or EPSG SRID 4326):
4979 (in many or most cases), or
It depends on what you mean by height (for example, above ground level, above or below sea level, or something else).
There are many different height datums. Height can be relative to:
The ellipsoid, which requires the use of a coordinate system of type GEOGRAPHIC3d, for which SRID values 4327, 43229, and 4979 are predefined in Oracle Spatial.
A nonellipsoidal height datum, which requires the use of a coordinate system of type COMPOUND, for which a custom SRID must usually be defined. The nonellipsoidal height may be specified in relation to the geoid, to some local or mean sea level (or a network of local sea levels), or to some other definition of height (such as above ground surface).
To define a compound coordinate system (see Section 6.5.2, "Compound Coordinate Reference Systems") based on the two dimensions of the WGS 84 coordinate system, you must first select a predefined or custom vertical coordinate reference system (see Section 6.9.3, "Creating a Vertical CRS"). To find the available vertical coordinate reference systems, enter the following statement:
SELECT srid, COORD_REF_SYS_NAME from sdo_coord_ref_sys WHERE COORD_REF_SYS_KIND = 'VERTICAL' order by srid; SRID COORD_REF_SYS_NAME   3855 EGM2008 geoid height 3886 Fao 1979 height 4440 NZVD2009 height 4458 DunedinBluff 1960 height 5600 NGPF height 5601 IGN 1966 height 5602 Moorea SAU 1981 height . . . 5795 Guadeloupe 1951 height 5796 Lagos 1955 height 5797 AIOC95 height 5798 EGM84 geoid height 5799 DVR90 height 123 rows selected.
After selecting a vertical coordinate reference system, create the compound SRID by entering a statement in the following form:
INSERT INTO sdo_coord_ref_system ( SRID, COORD_REF_SYS_NAME, COORD_REF_SYS_KIND, COORD_SYS_ID, DATUM_ID, GEOG_CRS_DATUM_ID, SOURCE_GEOG_SRID, PROJECTION_CONV_ID, CMPD_HORIZ_SRID, CMPD_VERT_SRID, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY, LEGACY_CODE, LEGACY_WKTEXT, LEGACY_CS_BOUNDS, IS_VALID, SUPPORTS_SDO_GEOMETRY) values ( customSRID, 'customname', 'COMPOUND', NULL, NULL, 6326, NULL, NULL, 4326, verticalSRID, 'custominformationsource', 'customdatasource', 'FALSE', NULL, NULL, NULL, 'TRUE', 'TRUE');
You can check the definition, based on the generated WKT, by entering a statement in the following form:
SELECT wktext3d FROM cs_srs WHERE srid = customSRID;
WKTEXT3D

COMPD_CS[
"NTF (Paris) + NGF IGN69",
GEOGCS["NTF (Paris)",
DATUM["Nouvelle Triangulation Francaise (Paris)",
SPHEROID[
"Clarke 1880 (IGN)",
6378249.2,
293.4660212936293951,
AUTHORITY["EPSG", "7011"]],
TOWGS84[168.0, 60.0, 320.0, 0.0, 0.0, 0.0, 0.0],
AUTHORITY["EPSG", "6807"]],
PRIMEM["Paris", 2.337229, AUTHORITY["EPSG","8903"]],
UNIT["grad", 0.015707963267949, AUTHORITY["EPSG", "9105"]],
AXIS["Lat", NORTH],
AXIS["Long", EAST],
AUTHORITY["EPSG", "4807"]],
VERT_CS["NGF IGN69",
VERT_DATUM["Nivellement general de la France  IGN69", 2005,
AUTHORITY["EPSG", "5119"]],
UNIT["metre", 1.0, AUTHORITY["EPSG", "9001"]],
AXIS["H", UP],
AUTHORITY["EPSG", "5720"]],
AUTHORITY["EPSG","7400"]]
When transforming between different height datums, you might use a VERTCON matrix. For example, between the WGS 84 ellipsoid and geoid, there is an offset matrix that allows height transformation. For more information, see the following:
The object type TFM_PLAN is used is by several SDO_CS package subprograms to specify a transformation plan. For example, to create a concatenated operation that consists of two operations specified by a parameter of type TFM_PLAN, use the SDO_CS.CREATE_CONCATENATED_OP procedure.
Oracle Spatial defines the object type TFM_PLAN as:
CREATE TYPE tfm_plan AS OBJECT ( THE_PLAN SDO_TFM_CHAIN);
The SDO_TFM_CHAIN type is defined as VARRAY(1048576) OF NUMBER
.
Within the SDO_TFM_CHAIN array:
The first element specifies the SRID of the source coordinate system.
Each pair of elements after the first element specifies an operation ID and the SRID of a target coordinate system.
The coordinate systems functions and procedures use information provided in the tables and views supplied with Oracle Spatial. The tables and views are part of the MDSYS schema; however, public synonyms are defined, so you do not need to specify MDSYS. before the table or view name. The definitions and data in these tables and views are based on the EPSG data model and dataset, as explained in Section 6.4.
The coordinate system tables fit into several general categories:
Coordinate system general information: SDO_COORD_SYS, SDO_COORD_REF_SYS
Elements or aspects of a coordinate system definition: SDO_DATUMS, SDO_ELLIPSOIDS, SDO_PRIME_MERIDIANS
Datum transformation support: SDO_COORD_OPS, SDO_COORD_OP_METHODS, SDO_COORD_OP_PARAM_USE, SDO_COORD_OP_PARAM_VALS, SDO_COORD_OP_PARAMS, SDO_COORD_OP_PATHS, SDO_PREFERRED_OPS_SYSTEM, SDO_PREFERRED_OPS_USER
Others related to coordinate system definition: SDO_COORD_AXES, SDO_COORD_AXIS_NAMES, SDO_UNITS_OF_MEASURE
Several views are provided that are identical to or subsets of coordinate system tables:
SDO_COORD_REF_SYSTEM, which contains the same columns as the SDO_COORD_REF_SYS table. Use the SDO_COORD_REF_SYSTEM view instead of the COORD_REF_SYS table for any insert, update, or delete operations.
Subsets of SDO_DATUMS, selected according to the value in the DATUM_TYPE column: SDO_DATUM_ENGINEERING, SDO_DATUM_GEODETIC, SDO_DATUM_VERTICAL.
Subsets of SDO_COORD_REF_SYS, selected according to the value in the COORD_REF_SYS_KIND column: SDO_CRS_COMPOUND, SDO_CRS_ENGINEERING, SDO_CRS_GEOCENTRIC, SDO_CRS_GEOGRAPHIC2D, SDO_CRS_GEOGRAPHIC3D, SDO_CRS_PROJECTED, SDO_CRS_VERTICAL.
Most of the rest of this section explains these tables and views, in alphabetical order. (Many column descriptions are adapted or taken from EPSG descriptions.) Section 6.7.28 describes relationships among the tables and views, and it lists EPSG table names and their corresponding Oracle Spatial names. Section 6.7.29 describes how to find information about EPSGbased coordinate systems, and it provides several examples.
In addition to the tables and views in this section, Spatial provides several legacy tables whose definitions and data match those of certain Spatial system tables used in previous releases. Section 6.8 describes the legacy tables.
Note: You should not modify or delete any Oraclesupplied information in any of the tables or views that are used for coordinate system support.If you want to create a userdefined coordinate system, see Section 6.9. 
The SDO_COORD_AXES table contains one row for each coordinate system axis definition. This table contains the columns shown in Table 61.
Table 61 SDO_COORD_AXES Table
Column Name  Data Type  Description 

COORD_SYS_ID 
NUMBER(10) 
ID number of the coordinate system to which this axis applies. 
COORD_AXIS_NAME_ID 
NUMBER(10) 
ID number of a coordinate system axis name. Matches a value in the COORD_AXIS_NAME_ID column of the SDO_COORD_AXIS_NAMES table (described in Section 6.7.2). Example: 
COORD_AXIS_ORIENTATION 
VARCHAR2(24) 
The direction of orientation for the coordinate system axis. Example: 
COORD_AXIS_ABBREVIATION 
VARCHAR2(24) 
The abbreviation for the coordinate system axis orientation. Example: 
UOM_ID 
NUMBER(10) 
ID number of the unit of measurement associated with the axis. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27). 
ORDER 
NUMBER(5) 
Position of this axis within the coordinate system (1, 2, or 3). 
The SDO_COORD_AXIS_NAMES table contains one row for each axis that can be used in a coordinate system definition. This table contains the columns shown in Table 62.
The SDO_COORD_OP_METHODS table contains one row for each coordinate systems transformation method. This table contains the columns shown in Table 63.
Table 63 SDO_COORD_OP_METHODS Table
Column Name  Data Type  Description 

COORD_OP_METHOD_ID 
NUMBER(10) 
ID number of the coordinate system transformation method. Example: 
COORD_OP_METHOD_NAME 
VARCHAR2(50) 
Name of the method. Example: 
LEGACY_NAME 
VARCHAR2(50) 
Name for this transformation method in the legacy WKT strings. This name might differ syntactically from the name used by EPSG. 
REVERSE_OP 
NUMBER(1) 
Contains 
INFORMATION_SOURCE 
VARCHAR2(254) 
Origin of this information. Example: 
DATA_SOURCE 
VARCHAR2(40) 
Organization providing the data for this record. Example: 
IS_IMPLEMENTED_FORWARD 
NUMBER(1) 
Contains 
IS_IMPLEMENTED_REVERSE 
NUMBER(1) 
Contains 
The SDO_COORD_OP_PARAM_USE table contains one row for each combination of transformation method and transformation operation parameter that is available for use. This table contains the columns shown in Table 64.
Table 64 SDO_COORD_OP_PARAM_USE Table
Column Name  Data Type  Description 

COORD_OP_METHOD_ID 
NUMBER(10) 
ID number of the coordinate system transformation method. Matches a value in the COORD_OP_METHOD_ID column of the COORD_OP_METHODS table (described in Section 6.7.3). 
PARAMETER_ID 
NUMBER(10) 
ID number of the parameter for transformation operations. Matches a value in the PARAMETER_ID column of the SDO_COORD_OP_PARAMS table (described in Section 6.7.6). 
LEGACY_PARAM_NAME 
VARCHAR2(80) 
Open GeoSpatial Consortium (OGC) name for the parameter. 
SORT_ORDER 
NUMBER(5) 
A number indicating the position of this parameter in the sequence of parameters for this method. Example: 
PARAM_SIGN_REVERSAL 
VARCHAR2(3) 

The SDO_COORD_OP_PARAM_VALS table contains information about parameter values for each coordinate system transformation method. This table contains the columns shown in Table 65.
Table 65 SDO_COORD_OP_PARAM_VALS Table
Column Name  Data Type  Description 

COORD_OP_ID 
NUMBER(10) 
ID number of the coordinate transformation operation. Matches a value in the COORD_OP_ID column of the SDO_COORD_OPS table (described in Section 6.7.8). 
COORD_OP_METHOD_ID 
NUMBER(10) 
Coordinate operation method ID. Must match a COORD_OP_METHOD_ID value in the SDO_COORD_OP_METHODS table (see Section 6.7.3). 
PARAMETER_ID 
NUMBER(10) 
ID number of the parameter for transformation operations. Matches a value in the PARAMETER_ID column of the SDO_COORD_OP_PARAMS table (described in Section 6.7.6). 
PARAMETER_VALUE 
FLOAT(49) 
Value of the parameter for this operation. 
PARAM_VALUE_FILE_REF 
VARCHAR2(254) 
Name of the file (as specified in the original EPSG database) containing the value data, if a single value for the parameter is not sufficient. 
PARAM_VALUE_FILE 
CLOB 
The ASCII content of the file specified in the PARAM_VALUE_FILE_REF column. Used only for grid file parameters (for NADCON, NTv2, and height transformations "Geographic3D to Geographic2D+GravityRelatedHeight"). 
PARAM_VALUE_XML 
XMLTYPE 
An XML representation of the content of the file specified in the PARAM_VALUE_FILE_REF column. (Optional, and currently only used for documentation.) 
UOM_ID 
NUMBER(10) 
ID number of the unit of measurement associated with the operation. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27). 
The SDO_COORD_OP_PARAMS table contains one row for each available parameter for transformation operations. This table contains the columns shown in Table 66.
Table 66 SDO_COORD_OP_PARAMS Table
Column Name  Data Type  Description 

PARAMETER_ID 
NUMBER(10) 
ID number of the parameter. Example: 
PARAMETER_NAME 
VARCHAR2(80) 
Name of the operation. Example: 
INFORMATION_SOURCE 
VARCHAR2(254) 
Origin of this information. Example: 
DATA_SOURCE 
VARCHAR2(40) 
Organization providing the data for this record. Example: 
The SDO_COORD_OP_PATHS table contains one row for each atomic step in a concatenated operation. This table contains the columns shown in Table 67.
Table 67 SDO_COORD_OP_PATHS Table
Column Name  Data Type  Description 

CONCAT_OPERATION_ID 
NUMBER(10) 
ID number of the concatenation operation. Must match a COORD_OP_ID value in the SDO_COORD_OPS table (described in Section 6.7.8) for which the COORD_OP_TYPE value is 
SINGLE_OPERATION_ID 
NUMBER(10) 
ID number of the single coordinate operation for this step (atomic operation) in a concatenated operation. Must match a COORD_OP_ID value in the SDO_COORD_OPS table (described in Section 6.7.8). 
SINGLE_OP_SOURCE_ID 
NUMBER(10) 
ID number of source coordinate reference system for the single coordinate operation for this step. Must match an SRID value in the SDO_COORD_REF_SYS table (described in Section 6.7.9). 
SINGLE_OP_TARGET_ID 
NUMBER(10) 
ID number of target coordinate reference system for the single coordinate operation for this step. Must match an SRID value in the SDO_COORD_REF_SYS table (described in Section 6.7.9). 
OP_PATH_STEP 
NUMBER(5) 
Sequence number of this step (atomic operation) within this concatenated operation. 
The SDO_COORD_OPS table contains one row for each transformation operation between coordinate systems. This table contains the columns shown in Table 68.
Table 68 SDO_COORD_OPS Table
Column Name  Data Type  Description 

COORD_OP_ID 
NUMBER(10) 
ID number of the coordinate transformation operation. Example: 
COORD_OP_NAME 
VARCHAR2(80) 
Name of the operation. Example: 
COORD_OP_TYPE 
VARCHAR2(24) 
Type of operation. One of the following: 
SOURCE_SRID 
NUMBER(10) 
SRID of the coordinate system from which to perform the transformation. Example: 
TARGET_SRID 
NUMBER(10) 
SRID of the coordinate system into which to perform the transformation. Example: 
COORD_TFM_VERSION 
VARCHAR2(24) 
Name assigned by EPSG to the coordinate transformation. Example: 
COORD_OP_VARIANT 
NUMBER(5) 
A variant of the more generic method specified in COORD_OP_METHOD_ID. Example: 
COORD_OP_METHOD_ID 
NUMBER(10) 
Coordinate operation method ID. Must match a COORD_OP_METHOD_ID value in the SDO_COORD_OP_METHODS table (see Section 6.7.3). Several operations can use a method. Example: 
UOM_ID_SOURCE_OFFSETS 
NUMBER(10) 
ID number of the unit of measurement for offsets in the source coordinate system. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27). 
UOM_ID_TARGET_OFFSETS 
NUMBER(10) 
ID number of the unit of measurement for offsets in the target coordinate system. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27). 
INFORMATION_SOURCE 
VARCHAR2(254) 
Origin of this information. Example: 
DATA_SOURCE 
VARCHAR2(40) 
Organization providing the data for this record. Example: 
SHOW_OPERATION 
NUMBER(3) 
(Not currently used.) 
IS_LEGACY 
VARCHAR2(5) 
TRUE if the operation was included in Oracle Spatial before release 10.2; FALSE if the operation is new in Oracle Spatial release 10.2. 
LEGACY_CODE 
NUMBER(10) 
For any EPSG coordinate transformation operation that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the COORD_OP_ID value of the legacy coordinate transformation operation. 
REVERSE_OP 
NUMBER(1) 
Contains 
IS_IMPLEMENTED_FORWARD 
NUMBER(1) 
Contains 
IS_IMPLEMENTED_REVERSE 
NUMBER(1) 
Contains 
The SDO_COORD_REF_SYS table contains one row for each coordinate reference system. This table contains the columns shown in Table 69. (The SDO_COORD_REF_SYS table is roughly patterned after the EPSG Coordinate Reference System table.)
Note: If you need to perform an insert, update, or delete operation, you must perform it on the SDO_COORD_REF_SYSTEM view, which contains the same columns as the SDO_COORD_REF_SYS table. The SDO_COORD_REF_SYSTEM view is described in Section 6.7.10. 
Table 69 SDO_COORD_REF_SYS Table
Column Name  Data Type  Description 

SRID 
NUMBER(10) 
ID number of the coordinate reference system. Example: 
COORD_REF_SYS_NAME 
VARCHAR2(80) 
Name of the coordinate reference system. Example: 
COORD_REF_SYS_KIND 
VARCHAR2(24) 
Category for the coordinate system. Example: 
COORD_SYS_ID 
NUMBER(10) 
ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.7.11). 
DATUM_ID 
NUMBER(10) 
ID number of the datum used for the coordinate reference system. Null for a projected coordinate system. For a geodetic coordinate system, must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.7.22). Example: 
GEOG_CRS_DATUM_ID 
NUMBER(10) 
ID number of the datum used for the coordinate reference system. For a projected coordinate system, must match the DATUM_ID value (in the SDO_DATUMS table, described in Section 6.7.22) of the geodetic coordinate system on which the projected coordinate system is based. For a geodetic coordinate system, must match the DATUM_ID value. Example: 
SOURCE_GEOG_SRID 
NUMBER(10) 
For a projected coordinate reference system, the ID number for the associated geodetic coordinate system. 
PROJECTION_CONV_ID 
NUMBER(10) 
For a projected coordinate reference system, the COORD_OP_ID value of the conversion operation used to convert the projected coordinated system to and from the source geographic coordinate system. 
CMPD_HORIZ_SRID 
NUMBER(10) 
(EPSGassigned value; not used by Oracle Spatial. The EPSG description is: "For compound CRS only, the code of the horizontal component of the Compound CRS.") 
CMPD_VERT_SRID 
NUMBER(10) 
(EPSGassigned value; not used by Oracle Spatial. The EPSG description is: "For compound CRS only, the code of the vertical component of the Compound CRS.") 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition for the coordinate system ( 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
IS_LEGACY 
VARCHAR2(5) 

LEGACY_CODE 
NUMBER(10) 
For any EPSG coordinate reference system that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the SRID value of the legacy coordinate system. 
LEGACY_WKTEXT 
VARCHAR2(2046) 
If IS_LEGACY is 
LEGACY_CS_BOUNDS 
SDO_GEOMETRY 
For a legacy coordinate system, the dimensional boundary (if any). 
IS_VALID 
VARCHAR2(5) 

SUPPORTS_SDO_GEOMETRY 
VARCHAR2(5) 

See also the information about the following views that are defined based on the value of the COORD_REF_SYS_KIND column:
SDO_CRS_COMPOUND (Section 6.7.12)
SDO_CRS_ENGINEERING (Section 6.7.13)
SDO_CRS_GEOCENTRIC (Section 6.7.14)
SDO_CRS_GEOGRAPHIC2D (Section 6.7.15)
SDO_CRS_GEOGRAPHIC3D (Section 6.7.16)
SDO_CRS_PROJECTED (Section 6.7.17)
SDO_CRS_VERTICAL (Section 6.7.18)
The SDO_COORD_REF_SYSTEM view contains the same columns as the SDO_COORD_REF_SYS table, which is described in Section 6.7.9. However, the SDO_COORD_REF_SYSTEM view has a trigger defined on it, so that any insert, update, or delete operations performed on the view cause all relevant Spatial system tables to have the appropriate operations performed on them.
Therefore, if you need to perform an insert, update, or delete operation, you must perform it on the SDO_COORD_REF_SYSTEM view, not the SDO_COORD_REF_SYS table.
The SDO_COORD_SYS table contains rows with information about coordinate systems. This table contains the columns shown in Table 610. (The SDO_COORD_SYS table is roughly patterned after the EPSG Coordinate System table, where a coordinate system is described as "a pair of reusable axes.")
Table 610 SDO_COORD_SYS Table
Column Name  Data Type  Description 

COORD_SYS_ID 
NUMBER(10) 
ID number of the coordinate system. Example: 
COORD_SYS_NAME 
VARCHAR2(254) 
Name of the coordinate system. Example: 
COORD_SYS_TYPE 
VARCHAR2(24) 
Type of coordinate system. Example: 
DIMENSION 
NUMBER(5) 
Number of dimensions represented by the coordinate system. 
INFORMATION_SOURCE 
VARCHAR2(254) 
Origin of this information. 
DATA_SOURCE 
VARCHAR2(50) 
Organization providing the data for this record. 
The SDO_CRS_COMPOUND view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.7.9) where the COORD_REF_SYS_KIND column value is COMPOUND
. (For an explanation of compound coordinate reference systems, see Section 6.5.2.) This view contains the columns shown in Table 611.
Table 611 SDO_CRS_COMPOUND View
Column Name  Data Type  Description 

SRID 
NUMBER(10) 
ID number of the coordinate reference system. 
COORD_REF_SYS_NAME 
VARCHAR2(80) 
Name of the coordinate reference system. 
CMPD_HORIZ_SRID 
NUMBER(10) 
(EPSGassigned value; not used by Oracle Spatial. The EPSG description is: "For compound CRS only, the code of the horizontal component of the Compound CRS.") 
CMPD_VERT_SRID 
NUMBER(10) 
(EPSGassigned value; not used by Oracle Spatial. The EPSG description is: "For compound CRS only, the code of the vertical component of the Compound CRS.") 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition for the coordinate system ( 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
The SDO_CRS_ENGINEERING view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.7.9) where the COORD_REF_SYS_KIND column value is ENGINEERING
. This view contains the columns shown in Table 612.
Table 612 SDO_CRS_ENGINEERING View
Column Name  Data Type  Description 

SRID 
NUMBER(10) 
ID number of the coordinate reference system. 
COORD_REF_SYS_NAME 
VARCHAR2(80) 
Name of the coordinate reference system. 
COORD_SYS_ID 
NUMBER(10) 
ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.7.11). 
DATUM_ID 
NUMBER(10) 
ID number of the datum used for the coordinate reference system. Must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.7.22). 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition for the coordinate system ( 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
The SDO_CRS_GEOCENTRIC view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.7.9) where the COORD_REF_SYS_KIND column value is GEOCENTRIC
. This view contains the columns shown in Table 613.
Table 613 SDO_CRS_GEOCENTRIC View
Column Name  Data Type  Description 

SRID 
NUMBER(10) 
ID number of the coordinate reference system. 
COORD_REF_SYS_NAME 
VARCHAR2(80) 
Name of the coordinate reference system. 
COORD_SYS_ID 
NUMBER(10) 
ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.7.11). 
DATUM_ID 
NUMBER(10) 
ID number of the datum used for the coordinate reference system. Must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.7.22). 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition for the coordinate system ( 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
The SDO_CRS_GEOGRAPHIC2D view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.7.9) where the COORD_REF_SYS_KIND column value is GEOGRAPHIC2D
. This view contains the columns shown in Table 614.
Table 614 SDO_CRS_GEOGRAPHIC2D View
Column Name  Data Type  Description 

SRID 
NUMBER(10) 
ID number of the coordinate reference system. 
COORD_REF_SYS_NAME 
VARCHAR2(80) 
Name of the coordinate reference system. 
COORD_SYS_ID 
NUMBER(10) 
ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.7.11). 
DATUM_ID 
NUMBER(10) 
ID number of the datum used for the coordinate reference system. Must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.7.22). 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition for the coordinate system ( 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
The SDO_CRS_GEOGRAPHIC3D view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.7.9) where the COORD_REF_SYS_KIND column value is GEOGRAPHIC3D
. (For an explanation of geographic 3D coordinate reference systems, see Section 6.5.1.) This view contains the columns shown in Table 615.
Table 615 SDO_CRS_GEOGRAPHIC3D View
Column Name  Data Type  Description 

SRID 
NUMBER(10) 
ID number of the coordinate reference system. 
COORD_REF_SYS_NAME 
VARCHAR2(80) 
Name of the coordinate reference system. 
COORD_SYS_ID 
NUMBER(10) 
ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.7.11). 
DATUM_ID 
NUMBER(10) 
ID number of the datum used for the coordinate reference system. Must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.7.22). 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition for the coordinate system ( 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
The SDO_CRS_PROJECTED view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.7.9) where the COORD_REF_SYS_KIND column value is PROJECTED
. This view contains the columns shown in Table 616.
Table 616 SDO_CRS_PROJECTED View
Column Name  Data Type  Description 

SRID 
NUMBER(10) 
ID number of the coordinate reference system. 
COORD_REF_SYS_NAME 
VARCHAR2(80) 
Name of the coordinate reference system. 
COORD_SYS_ID 
NUMBER(10) 
ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.7.11). 
SOURCE_GEOG_SRID 
NUMBER(10) 
ID number for the associated geodetic coordinate system. 
PROJECTION_CONV_ID 
NUMBER(10) 
COORD_OP_ID value of the conversion operation used to convert the projected coordinated system to and from the source geographic coordinate system. 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition for the coordinate system ( 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
The SDO_CRS_VERTICAL view contains selected information from the SDO_COORD_REF_SYS table (described in Section 6.7.9) where the COORD_REF_SYS_KIND column value is VERTICAL
. This view contains the columns shown in Table 617.
Table 617 SDO_CRS_VERTICAL View
Column Name  Data Type  Description 

SRID 
NUMBER(10) 
ID number of the coordinate reference system. 
COORD_REF_SYS_NAME 
VARCHAR2(80) 
Name of the coordinate reference system. 
COORD_SYS_ID 
NUMBER(10) 
ID number of the coordinate system used for the coordinate reference system. Must match a COORD_SYS_ID value in the SDO_COORD_SYS table (see Section 6.7.11). 
DATUM_ID 
NUMBER(10) 
ID number of the datum used for the coordinate reference system. Must match a DATUM_ID value in the SDO_DATUMS table (see Section 6.7.22). 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition for the coordinate system ( 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
The SDO_DATUM_ENGINEERING view contains selected information from the SDO_DATUMS table (described in Section 6.7.22) where the DATUM_TYPE column value is ENGINEERING
. This view contains the columns shown in Table 618.
Table 618 SDO_DATUM_ENGINEERING View
Column Name  Data Type  Description 

DATUM_ID 
NUMBER(10) 
ID number of the datum. 
DATUM_NAME 
VARCHAR2(80) 
Name of the datum. 
ELLIPSOID_ID 
NUMBER(10) 
ID number of the ellipsoid used in the datum definition. Must match an ELLIPSOID_ID value in the SDO_ELLIPSOIDS table (see Section 6.7.23). Example: 
PRIME_MERIDIAN_ID 
NUMBER(10) 
ID number of the prime meridian used in the datum definition. Must match a PRIME_MERIDIAN_ID value in the SDO_PRIME_MERIDIANS table (see Section 6.7.26). Example: 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition of the datum. Example: 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
SHIFT_X 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the xaxis. 
SHIFT_Y 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the yaxis. 
SHIFT_Z 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the zaxis. 
ROTATE_X 
NUMBER 
Number of arcseconds of rotation about the xaxis. 
ROTATE_Y 
NUMBER 
Number of arcseconds of rotation about the yaxis. 
ROTATE_Z 
NUMBER 
Number of arcseconds of rotation about the zaxis. 
SCALE_ADJUST 
NUMBER 
A value to be used in adjusting the X, Y, and Z values after any shifting and rotation, according to the formula: 1.0 + (SCALE_ADJUST * 10^{6}) 
The SDO_DATUM_GEODETIC view contains selected information from the SDO_DATUMS table (described in Section 6.7.22) where the DATUM_TYPE column value is GEODETIC
. This view contains the columns shown in Table 619.
Table 619 SDO_DATUM_GEODETIC View
Column Name  Data Type  Description 

DATUM_ID 
NUMBER(10) 
ID number of the datum. 
DATUM_NAME 
VARCHAR2(80) 
Name of the datum. 
ELLIPSOID_ID 
NUMBER(10) 
ID number of the ellipsoid used in the datum definition. Must match an ELLIPSOID_ID value in the SDO_ELLIPSOIDS table (see Section 6.7.23). Example: 
PRIME_MERIDIAN_ID 
NUMBER(10) 
ID number of the prime meridian used in the datum definition. Must match a PRIME_MERIDIAN_ID value in the SDO_PRIME_MERIDIANS table (see Section 6.7.26). Example: 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition of the datum. Example: 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
SHIFT_X 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the xaxis. 
SHIFT_Y 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the yaxis. 
SHIFT_Z 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the zaxis. 
ROTATE_X 
NUMBER 
Number of arcseconds of rotation about the xaxis. 
ROTATE_Y 
NUMBER 
Number of arcseconds of rotation about the yaxis. 
ROTATE_Z 
NUMBER 
Number of arcseconds of rotation about the zaxis. 
SCALE_ADJUST 
NUMBER 
A value to be used in adjusting the X, Y, and Z values after any shifting and rotation, according to the formula: 1.0 + (SCALE_ADJUST * 10^{6}) 
The SDO_DATUM_VERTICAL view contains selected information from the SDO_DATUMS table (described in Section 6.7.22) where the DATUM_TYPE column value is VERTICAL
. This view contains the columns shown in Table 620.
Table 620 SDO_DATUM_VERTICAL View
Column Name  Data Type  Description 

DATUM_ID 
NUMBER(10) 
ID number of the datum. 
DATUM_NAME 
VARCHAR2(80) 
Name of the datum. 
ELLIPSOID_ID 
NUMBER(10) 
ID number of the ellipsoid used in the datum definition. Must match an ELLIPSOID_ID value in the SDO_ELLIPSOIDS table (see Section 6.7.23). Example: 
PRIME_MERIDIAN_ID 
NUMBER(10) 
ID number of the prime meridian used in the datum definition. Must match a PRIME_MERIDIAN_ID value in the SDO_PRIME_MERIDIANS table (see Section 6.7.26). Example: 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition of the datum. Example: 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). 
SHIFT_X 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the xaxis. 
SHIFT_Y 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the yaxis. 
SHIFT_Z 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the zaxis. 
ROTATE_X 
NUMBER 
Number of arcseconds of rotation about the xaxis. 
ROTATE_Y 
NUMBER 
Number of arcseconds of rotation about the yaxis. 
ROTATE_Z 
NUMBER 
Number of arcseconds of rotation about the zaxis. 
SCALE_ADJUST 
NUMBER 
A value to be used in adjusting the X, Y, and Z values after any shifting and rotation, according to the formula: 1.0 + (SCALE_ADJUST * 10^{6}) 
The SDO_DATUMS table contains one row for each datum. This table contains the columns shown in Table 621.
Table 621 SDO_DATUMS Table
Column Name  Data Type  Description 

DATUM_ID 
NUMBER(10) 
ID number of the datum. Example: 
DATUM_NAME 
VARCHAR2(80) 
Name of the datum. Example: 
DATUM_TYPE 
VARCHAR2(24) 
Type of the datum. Example: 
ELLIPSOID_ID 
NUMBER(10) 
ID number of the ellipsoid used in the datum definition. Must match an ELLIPSOID_ID value in the SDO_ELLIPSOIDS table (see Section 6.7.23). Example: 
PRIME_MERIDIAN_ID 
NUMBER(10) 
ID number of the prime meridian used in the datum definition. Must match a PRIME_MERIDIAN_ID value in the SDO_PRIME_MERIDIANS table (see Section 6.7.26). Example: 
INFORMATION_SOURCE 
VARCHAR2(254) 
Provider of the definition of the datum. Example: 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). Example: 
SHIFT_X 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the xaxis. 
SHIFT_Y 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the yaxis. 
SHIFT_Z 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the zaxis. 
ROTATE_X 
NUMBER 
Number of arcseconds of rotation about the xaxis. 
ROTATE_Y 
NUMBER 
Number of arcseconds of rotation about the yaxis. 
ROTATE_Z 
NUMBER 
Number of arcseconds of rotation about the zaxis. 
SCALE_ADJUST 
NUMBER 
A value to be used in adjusting the X, Y, and Z values after any shifting and rotation, according to the formula: 1.0 + (SCALE_ADJUST * 10^{6}) 
IS_LEGACY 
VARCHAR2(5) 

LEGACY_CODE 
NUMBER(10) 
For any EPSG datum that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the DATUM_ID value of the legacy datum. 
See also the information about the following views that are defined based on the value of the DATUM_TYPE column: SDO_DATUM_ENGINEERING (Section 6.7.19), SDO_DATUM_GEODETIC (Section 6.7.20), and SDO_DATUM_VERTICAL (Section 6.7.21).
The SDO_ELLIPSOIDS table contains one row for each ellipsoid. This table contains the columns shown in Table 622.
Table 622 SDO_ELLIPSOIDS Table
Column Name  Data Type  Description 

ELLIPSOID_ID 
NUMBER 
ID number of the ellipsoid (spheroid). Example: 
ELLIPSOID_NAME 
VARCHAR2(80) 
Name of the ellipsoid. Example: 
NUMBER 
Radius in meters along the semimajor axis (onehalf of the long axis of the ellipsoid).  
UOM_ID 
NUMBER 
ID number of the unit of measurement for the ellipsoid. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27). Example: 
NUMBER 
Inverse flattening of the ellipsoid. That is,  
NUMBER 
Radius in meters along the semiminor axis (onehalf of the short axis of the ellipsoid).  
INFORMATION_SOURCE 
VARCHAR2(254) 
Origin of this information. Example: 
DATA_SOURCE 
VARCHAR2(40) 
Organization that supplied the data for this record (if not Oracle). Example: 
IS_LEGACY 
VARCHAR2(5) 

LEGACY_CODE 
NUMBER 
For any EPSG ellipsoid that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the ELLIPSOID_ID value of the legacy ellipsoid. 
The SDO_PREFERRED_OPS_SYSTEM table contains one row for each specification of the userdefined default preferred coordinate transformation operation for a source and target SRID combination. If you insert a row into the SDO_PREFERRED_OPS_SYSTEM table, you are overriding the Oracle default operation for transformations between the specified source and target coordinate systems. The SDO_CS.CREATE_OBVIOUS_EPSG_RULES procedure inserts many rows into this table. The SDO_CS.DELETE_ALL_EPSG_RULES procedure deletes all rows from this table if the use_case
parameter is null. This table contains the columns shown in Table 623.
Table 623 SDO_PREFERRED_OPS_SYSTEM Table
Column Name  Data Type  Description 

SOURCE_SRID 
NUMBER(10) 
ID number of the coordinate system (spatial reference system) from which to perform coordinate transformation, using the operation specified by COORD_OP_ID as the default preferred method for transforming to the specified target SRID. 
COORD_OP_ID 
NUMBER(10) 
ID number of the coordinate transformation operation. Matches a value in the COORD_OP_ID column of the SDO_COORD_OPS table (described in Section 6.7.8). 
TARGET_SRID 
NUMBER(10) 
ID number of coordinate system (spatial reference system) into which to perform coordinate transformation using the operation specified by COORD_OP_ID. 
The SDO_PREFERRED_OPS_USER table contains one row for each specification of a userdefined source and target SRID and coordinate transformation operation. If you insert a row into the SDO_PREFERRED_OPS_USER table, you create a custom transformation between the source and target coordinate systems, and you can specify the name (the USE_CASE column value) of the transformation operation as the use_case
parameter value with several SDO_CS functions and procedures. If you specify a use case with the SDO_CS.DELETE_ALL_EPSG_RULES procedure, rows associated with that use case are deleted from this table. This table contains the columns shown in Table 624.
Table 624 SDO_PREFERRED_OPS_USER Table
Column Name  Data Type  Description 

USE_CASE 
VARCHAR2(32) 
Name of this specification of a source and target SRID and coordinate transformation operation. 
SOURCE_SRID 
NUMBER(10) 
ID number of the coordinate system (spatial reference system) from which to perform the transformation. 
COORD_OP_ID 
NUMBER(10) 
ID number of the coordinate transformation operation. Matches a value in the COORD_OP_ID column of the SDO_COORD_OPS table (described in Section 6.7.8). 
TARGET_SRID 
NUMBER(10) 
ID number of the coordinate system (spatial reference system) into which to perform the transformation. 
The SDO_PRIME_MERIDIANS table contains one row for each prime meridian that can be used in a datum specification. This table contains the columns shown in Table 625.
Table 625 SDO_PRIME_MERIDIANS Table
Column Name  Data Type  Description 

PRIME_MERIDIAN_ID 
NUMBER(10) 
ID number of the prime meridian. Example: 
PRIME_MERIDIAN_NAME 
VARCHAR2(80) 
Name of the prime meridian. Example: 
GREENWICH_LONGITUDE 
FLOAT(49) 
Longitude of the prime meridian as an offset from the Greenwich meridian. Example: 
UOM_ID 
NUMBER(10) 
ID number of the unit of measurement for the prime meridian. Matches a value in the UOM_ID column of the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27). Example: 
INFORMATION_SOURCE 
VARCHAR2(254) 
Origin of this information. Example: 
DATA_SOURCE 
VARCHAR2(254) 
Organization that supplied the data for this record (if not Oracle). Example: 
The SDO_UNITS_OF_MEASURE table contains one row for each unit of measurement. This table contains the columns shown in Table 626.
Table 626 SDO_UNITS_OF_MEASURE Table
Column Name  Data Type  Description 

UOM_ID 
NUMBER(10) 
ID number of the unit of measurement. Example: 
UNIT_OF_MEAS_NAME 
VARCHAR2(2083) 
Name of the unit of measurement; can also be a URL or URI. Example: 
SHORT_NAME 
VARCHAR2(80) 
Short name (if any) of the unit of measurement. Example: 
UNIT_OF_MEAS_TYPE 
VARCHAR2(50) 
Type of measure for which the unit is used: 
TARGET_UOM_ID 
NUMBER(10) 
ID number of a target unit of measurement. Corresponds to the TARGET_UOM_CODE column in the EPSG Unit of Measure table, which has the following description: "Other UOM of the same type into which the current UOM can be converted using the formula (POSC); POSC factors A and D always equal zero for EPSG supplied units of measure." 
FACTOR_B 
NUMBER 
Corresponds to the FACTOR_B column in the EPSG Unit of Measure table, which has the following description: "A quantity in the target UOM (y) is obtained from a quantity in the current UOM (x) through the conversion: y = (B/C).x" In a userdefined unit of measurement, FACTOR_B is usually the number of square meters or meters equal to one of the unit. For information about userdefined units, see Section 2.10.1. 
FACTOR_C 
NUMBER 
Corresponds to the FACTOR_C column in the EPSG Unit of Measure table. For FACTOR_C in a userdefined unit of measurement, see Section 2.10.1. 
INFORMATION_SOURCE 
VARCHAR2(254) 
Origin of this information. Example: 
DATA_SOURCE 
VARCHAR2(40) 
Organization providing the data for this record. Example: 
IS_LEGACY 
VARCHAR2(5) 
TRUE if the unit of measurement definition was included in Oracle Spatial before release 10.2; FALSE if the unit of measurement definition is new in Oracle Spatial release 10.2. 
LEGACY_CODE 
NUMBER(10) 
For any EPSG unit of measure that has a semantically identical legacy (in Oracle Spatial before release 10.2) counterpart, the UOM_ID value of the legacy unit of measure. 
Because the definitions in Spatial system tables and views are based on the EPSG data model and dataset, the EPSG entityrelationship (ER) diagram provides a good overview of the relationships among the Spatial coordinate system data structures. The EPSG ER diagram is included in the following document: http://www.epsg.org/CurrentDB.html
However, Oracle Spatial does not use the following from the EPSG ER diagram:
Area of Use (yellow box in the upper center of the diagram)
Deprecation, Alias, and others represented by pink boxes in the lower right corner of the diagram
In addition, Spatial changes the names of some tables to conform to its own naming conventions, and it does not use some tables, as shown in Table 627
Table 627 EPSG Table Names and Oracle Spatial Names
EPSG Name  Oracle Name 

Coordinate System 
SDO_COORD_SYS 
Coordinate Axis 
SDO_COORD_AXES 
Coordinate Reference System 
SDO_COORD_REF_SYSTEM 
Area Of Use 
(Not used) 
Datum 
SDO_DATUMS 
Prime Meridian 
SDO_PRIME_MERIDIANS 
Ellipsoid 
SDO_ELLIPSOIDS 
Unit Of Measure 
SDO_UNITS_OF_MEASURE 
Coordinate Operation 
SDO_COORD_OPS 
Coord. Operation Parameter ValueCoord 
SDO_COORD_OP_PARAM_VALS 
Operation Parameter UsageCoord. 
SDO_COORD_OP_PARAM_USE 
Operation Parameter 
SDO_COORD_OP_PARAMS 
Coordinate Operation Path 
SDO_COORD_OP_PATHS 
Coordinate Operation Method 
SDO_COORD_OP_METHODS 
Change 
(Not used) 
Deprecation 
(Not used) 
Supersession 
(Not used) 
Naming System 
(Not used) 
Alias 
(Not used) 
Any Entity 
(Not used) 
This section explains how to query the Spatial coordinate systems data structures for information about geodetic and projected EPSGbased coordinate systems.
A humanreadable summary of a CRS is the WKT string. For example:
SQL> select wktext from cs_srs where srid = 4326; WKTEXT  GEOGCS [ "WGS 84", DATUM ["World Geodetic System 1984 (EPSG ID 6326)", SPHEROID ["WGS 84 (EPSG ID 7030)", 6378137, 298.257223563]], PRIMEM [ "Greenwich", 0.0000 00 ], UNIT ["Decimal Degree", 0.01745329251994328]]
EPSG WKTs have been automatically generated by Spatial, for backward compatibility. Note that EPSG WKTs also contain numeric ID values (such as EPSG ID 6326 in the preceding example) for convenience. However, for more detailed information you should access the EPSG data stored in the coordinate systems data structures. The following example returns information about the ellipsoid, datum shift, rotation, and scale adjustment for SRID 4123:
SQL> select ell.semi_major_axis, ell.inv_flattening, ell.semi_minor_axis, ell.uom_id, dat.shift_x, dat.shift_y, dat.shift_z, dat.rotate_x, dat.rotate_y, dat.rotate_z, dat.scale_adjust from sdo_coord_ref_system crs, sdo_datums dat, sdo_ellipsoids ell where crs.srid = 4123 and dat.datum_id = crs.datum_id and ell.ellipsoid_id = dat.ellipsoid_id; SEMI_MAJOR_AXIS INV_FLATTENING SEMI_MINOR_AXIS UOM_ID SHIFT_X SHIFT_Y SHIFT_Z ROTATE_X ROTATE_Y ROTATE_Z SCALE_ADJUST            6378388 297 6356911.95 9001 90.7 106.1 119.2 4.09 .218 1.05 1.37
In the preceding example, the UOM_ID represents the unit of measure for SEMI_MAJOR_AXIS (a
) and SEMI_MINOR_AXIS (b
). INV_FLATTENING is a/(ab)
and has no associated unit. Shifts are in meters, rotation angles are given in arc seconds, and scale adjustment in parts per million.
To interpret the UOM_ID, you can query the units table, as shown in the following example:
SQL> select UNIT_OF_MEAS_NAME from sdo_units_of_measure where UOM_ID = 9001; UNIT_OF_MEAS_NAME  metre
Conversion factors for units of length are given relative to meters, as shown in the following example:
SQL> select UNIT_OF_MEAS_NAME, FACTOR_B/FACTOR_C from sdo_units_of_measure where UOM_ID = 9002; UNIT_OF_MEAS_NAME  FACTOR_B/FACTOR_C  foot .3048
Conversion factors for units of angle are given relative to radians, as shown in the following example:
SQL> select UNIT_OF_MEAS_NAME, FACTOR_B/FACTOR_C from sdo_units_of_measure where UOM_ID = 9102; UNIT_OF_MEAS_NAME  FACTOR_B/FACTOR_C  degree .017453293
As mentioned in Section 6.7.29.1, the WKT is a humanreadable summary of a CRS, but the actual EPSG data is stored in the Spatial coordinate systems data structures. The following example shows the WKT string for a projected coordinate system:
SQL> select wktext from cs_srs where srid = 32040; WKTEXT  PROJCS["NAD27 / Texas South Central", GEOGCS [ "NAD27", DATUM ["North American D atum 1927 (EPSG ID 6267)", SPHEROID ["Clarke 1866 (EPSG ID 7008)", 6378206.4, 29 4.978698213905820761610537123195175418]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994328]], PROJECTION ["Texas CS27 South Central zone (EPSG OP 14204)"], PARAMETER ["Latitude_Of_Origin", 27.8333333333333333333 3333333333333333333], PARAMETER ["Central_Meridian", 98.99999999999999999999999 999999999999987], PARAMETER ["Standard_Parallel_1", 28.3833333333333333333333333 3333333333333], PARAMETER ["Standard_Parallel_2", 30.283333333333333333333333333 33333333333], PARAMETER ["False_Easting", 2000000], PARAMETER ["False_Northing", 0], UNIT ["U.S. Foot", .3048006096012192024384048768097536195072]]
To determine the base geographic CRS for a projected CRS, you can query the SDO_COORD_REF_SYSTEM table, as in the following example:
SQL> select SOURCE_GEOG_SRID from sdo_coord_ref_system where srid = 32040; SOURCE_GEOG_SRID  4267
The following example returns the projection method for the projected CRS 32040:
SQL> select m.coord_op_method_name from sdo_coord_ref_sys crs, sdo_coord_ops ops, sdo_coord_op_methods m where crs.srid = 32040 and ops.coord_op_id = crs.projection_conv_id and m.coord_op_method_id = ops.coord_op_method_id; COORD_OP_METHOD_NAME  Lambert Conic Conformal (2SP)
The following example returns the projection parameters for the projected CRS 32040:
SQL> select params.parameter_name  ' = '  vals.parameter_value  ' '  uom.unit_of_meas_name "Projection parameters" from sdo_coord_ref_sys crs, sdo_coord_op_param_vals vals, sdo_units_of_measure uom, sdo_coord_op_params params where crs.srid = 32040 and vals.coord_op_id = crs.projection_conv_id and uom.uom_id = vals.uom_id and params.parameter_id = vals.parameter_id; Projection parameters  Latitude of false origin = 27.5 sexagesimal DMS Longitude of false origin = 99 sexagesimal DMS Latitude of 1st standard parallel = 28.23 sexagesimal DMS Latitude of 2nd standard parallel = 30.17 sexagesimal DMS Easting at false origin = 2000000 US survey foot Northing at false origin = 0 US survey foot
The following example is essentially the same query as the preceding example, but it also converts the values to the base unit:
SQL> select params.parameter_name  ' = '  vals.parameter_value  ' '  uom.unit_of_meas_name  ' = '  sdo_cs.transform_to_base_unit(vals.parameter_value, vals.uom_id)  ' '  decode( uom.unit_of_meas_type, 'area', 'square meters', 'angle', 'radians', 'length', 'meters', 'scale', '', '') "Projection parameters" from sdo_coord_ref_sys crs, sdo_coord_op_param_vals vals, sdo_units_of_measure uom, sdo_coord_op_params params where crs.srid = 32040 and vals.coord_op_id = crs.projection_conv_id and uom.uom_id = vals.uom_id and params.parameter_id = vals.parameter_id; Projection parameters  Latitude of false origin = 27.5 sexagesimal DMS = .485783308471754564814814814814814814815 radians Longitude of false origin = 99 sexagesimal DMS = 1.7278759594743845 radians Latitude of 1st standard parallel = 28.23 sexagesimal DMS = .495382619357723367592592592592592592593 radians Latitude of 2nd standard parallel = 30.17 sexagesimal DMS = .528543875145615595370370370370370370371 radians Easting at false origin = 2000000 US survey foot = 609601.219202438404876809753619507239014 meters Northing at false origin = 0 US survey foot = 0 meters
The following example returns the projection unit of measure for the projected CRS 32040. (The projection unit might be different from the length unit used for the projection parameters.)
SQL> select axes.coord_axis_abbreviation  ': '  uom.unit_of_meas_name "Projection units" from sdo_coord_ref_sys crs, sdo_coord_axes axes, sdo_units_of_measure uom where crs.srid = 32040 and axes.coord_sys_id = crs.coord_sys_id and uom.uom_id = axes.uom_id; Projection units  X: US survey foot Y: US survey foot
In releases of Spatial before 10.2, the coordinate systems functions and procedures used information provided in the following tables, some of which have new names or are now views instead of tables:
MDSYS.CS_SRS (see Section 6.8.1) defined the valid coordinate systems. It associates each coordinate system with its wellknown text description, which is in conformance with the standard published by the Open Geospatial Consortium (http://www.opengeospatial.org
).
MDSYS.SDO_ANGLE_UNITS (see Section 6.8.2) defines the valid angle units.
MDSYS.SDO_AREA_UNITS (see Section 6.8.3) defines the valid area units.
MDSYS.SDO_DIST_UNITS (see Section 6.8.5) defines the valid distance units.
MDSYS.SDO_DATUMS_OLD_FORMAT and MDSYS.SDO_DATUMS_OLD_SNAPSHOT (see Section 6.8.4) are based on the MDSYS.SDO_DATUMS table before release 10.2, which defined valid datums.
MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT and MDSYS.SDO_ELLIPSOIDS_OLD_SNAPSHOT (see Section 6.8.6) are based on the MDSYS.SDO_ELLIPSOIDS table before release 10.2, which defined valid ellipsoids.
MDSYS.SDO_PROJECTIONS_OLD_FORMAT and MDSYS.SDO_PROJECTIONS_OLD_SNAPSHOT (see Section 6.8.7) are based on the MDSYS.SDO_PROJECTIONS table before release 10.2, which defined the valid map projections.
Note: You should not modify or delete any Oraclesupplied information in these legacy tables.If you refer to a legacy table in a SQL statement, you must include the MDSYS. before the table name. 
The MDSYS.CS_SRS reference table contains over 4000 rows, one for each valid coordinate system. This table contains the columns shown in Table 628.
Table 628 MDSYS.CS_SRS Table
Column Name  Data Type  Description 

CS_NAME 
VARCHAR2(68) 
A wellknown name, often mnemonic, by which a user can refer to the coordinate system. 
SRID 
NUMBER(38) 
The unique ID number (Spatial Reference ID) for a coordinate system. Currently, SRID values 1999999 are reserved for use by Oracle Spatial, and values 1000000 (1 million) and higher are available for userdefined coordinate systems. 
AUTH_SRID 
NUMBER(38) 
An optional ID number that can be used to indicate how the entry was derived; it might be a foreign key into another coordinate table, for example. 
AUTH_NAME 
VARCHAR2(256) 
An authority name for the coordinate system. Contains 
WKTEXT 
VARCHAR2(2046) 
The wellknown text (WKT) description of the SRS, as defined by the Open Geospatial Consortium. For more information, see Section 6.8.1.1. 
CS_BOUNDS 
SDO_GEOMETRY 
An optional SDO_GEOMETRY object that is a polygon with WGS 84 longitude and latitude vertices, representing the spheroidal polygon description of the zone of validity for a projected coordinate system. Must be null for a geographic or nonEarth coordinate system. Is null in all supplied rows. 
The WKTEXT column of the MDSYS.CS_SRS table contains the wellknown text (WKT) description of the SRS, as defined by the Open Geospatial Consortium. The following is the WKT EBNF syntax.
<coordinate system> ::= <horz cs>  <local cs> <horz cs> ::= <geographic cs>  <projected cs> <projected cs> ::= PROJCS [ "<name>", <geographic cs>, <projection>, {<parameter>,}* <linear unit> ] <projection> ::= PROJECTION [ "<name>" ] <parameter> ::= PARAMETER [ "<name>", <number> ] <geographic cs> ::= GEOGCS [ "<name>", <datum>, <prime meridian>, <angular unit> ] <datum> ::= DATUM [ "<name>", <spheroid> {, <shiftx>, <shifty>, <shiftz> , <rotx>, <roty>, <rotz>, <scale_adjust>} ] <spheroid> ::= SPHEROID ["<name>", <semi major axis>, <inverse flattening> ] <prime meridian> ::= PRIMEM ["<name>", <longitude> ] <longitude> ::= <number> <semimajor axis> ::= <number> <inverse flattening> ::= <number> <angular unit> ::= <unit> <linear unit> ::= <unit> <unit> ::= UNIT [ "<name>", <conversion factor> ] <local cs> ::= LOCAL_CS [ "<name>", <local datum>, <linear unit>, <axis> {, <axis>}* ] <local datum> ::= LOCAL_DATUM [ "<name>", <datum type> {, <shiftx>, <shifty>, <shiftz> , <rotx>, <roty>, <rotz>, <scale_adjust>} ] <datum type> ::= <number> <axis> ::= AXIS [ "<name>", NORTH  SOUTH  EAST  WEST  UP  DOWN  OTHER ]
Each <parameter>
specification is one of the following:
Standard_Parallel_1
(in decimal degrees)
Standard_Parallel_2
(in decimal degrees)
Central_Meridian
(in decimal degrees)
Latitude_of_Origin
(in decimal degrees)
Azimuth
(in decimal degrees)
False_Easting
(in the unit of the coordinate system; for example, meters)
False_Northing
(in the unit of the coordinate system; for example, meters)
Perspective_Point_Height
(in the unit of the coordinate system; for example, meters)
Landsat_Number
(must be 1, 2, 3, 4, or 5)
Path_Number
Scale_Factor
Note: If the WKT uses European rather than USAmerican notation for datum rotation parameters, or if the transformation results do not seem correct, see Section 6.8.1.2. 
The default value for each <parameter>
specification is 0 (zero). That is, if a specification is needed for a projection but no value is specified in the WKT, Spatial uses a value of 0.
The prime meridian (PRIMEM
) is specified in decimal degrees of longitude.
An example of the WKT for a geodetic (geographic) coordinate system is:
'GEOGCS [ "Longitude / Latitude (Old Hawaiian)", DATUM ["Old Hawaiian", SPHEROID ["Clarke 1866", 6378206.400000, 294.978698]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]]'
The WKT definition of the coordinate system is hierarchically nested. The Old Hawaiian geographic coordinate system (GEOGCS) is composed of a named datum (DATUM), a prime meridian (PRIMEM), and a unit definition (UNIT). The datum is in turn composed of a named spheroid and its parameters of semimajor axis and inverse flattening.
An example of the WKT for a projected coordinate system (a Wyoming State Plane) is:
'PROJCS["Wyoming 4901, Eastern Zone (1983, meters)", GEOGCS [ "GRS 80", DATUM ["GRS 80", SPHEROID ["GRS 80", 6378137.000000, 298.257222]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994330]], PROJECTION ["Transverse Mercator"], PARAMETER ["Scale_Factor", 0.999938], PARAMETER ["Central_Meridian", 105.166667], PARAMETER ["Latitude_Of_Origin", 40.500000], PARAMETER ["False_Easting", 200000.000000], UNIT ["Meter", 1.000000000000]]'
The projected coordinate system contains a nested geographic coordinate system as its basis, as well as parameters that control the projection.
Oracle Spatial supports all common geodetic datums and map projections.
An example of the WKT for a local coordinate system is:
LOCAL_CS [ "NonEarth (Meter)", LOCAL_DATUM ["Local Datum", 0], UNIT ["Meter", 1.0], AXIS ["X", EAST], AXIS["Y", NORTH]]
For more information about local coordinate systems, see Section 6.3.
You can use the SDO_CS.VALIDATE_WKT function, described in Chapter 21, to validate the WKT of any coordinate system defined in the MDSYS.CS_SRS table.
The datumrelated WKT parameters are a list of up to seven Bursa Wolf transformation parameters. Rotation parameters specify arc seconds, and shift parameters specify meters.
Two different notations, USAmerican and European, are used for the three rotation parameters that are in general use, and these two notations use opposite signs. Spatial uses and expects the USAmerican notation. Therefore, if your WKT uses the European notation, you must convert it to the USAmerican notation by inverting the signs of the rotation parameters.
If you do not know if a parameter set uses the USAmerican or European notation, perform the following test:
Select a single point for which you know the correct result.
Perform the transformation using the current WKT.
If the computed result does not match the known correct result, invert signs of the rotation parameters, perform the transformation, and check if the computed result matches the known correct result.
If you insert or delete a row in the SDO_COORD_REF_SYSTEM view (described in Section 6.7.10), Spatial automatically updates the WKTEXT column in the MDSYS.CS_SRS table. (The format of the WKTEXT column is described in Section 6.8.1.1.) However, if you update an existing row in the SDO_COORD_REF_SYSTEM view, the wellknown text (WKT) value is not automatically updated.
In addition, information relating to coordinate reference systems is also stored in several other system tables, including SDO_DATUMS (described in Section 6.7.22), SDO_ELLIPSOIDS (described in Section 6.7.23), and SDO_PRIME_MERIDIANS (described in Section 6.7.26). If you add, delete, or modify information in these tables, the WKTEXT values in the MDSYS.CS_SRS table are not automatically updated. For example, if you update an ellipsoid flattening value in the SDO_ELLIPSOIDS table, the wellknown text string for the associated coordinate system is not updated.
However, you can manually update the WKTEXT values in the in the MDSYS.CS_SRS table by using any of several procedures whose names start with UPDATE_WKTS_FOR (for example, SDO_CS.UPDATE_WKTS_FOR_ALL_EPSG_CRS and SDO_CS.UPDATE_WKTS_FOR_EPSG_DATUM). If the display of SERVEROUTPUT information is enabled, these procedures display a message identifying the SRID value for each row in the MDSYS.CS_SRS table whose WKTEXT value is being updated. These procedures are described in Chapter 21.
The MDSYS.SDO_ANGLE_UNITS reference view contains one row for each valid angle UNIT specification in the wellknown text (WKT) description in the coordinate system definition. The WKT is described in Section 6.8.1.1.
The MDSYS.SDO_ANGLE_UNITS view is based on the SDO_UNITS_OF MEASURE table (described in Section 6.7.27), and it contains the columns shown in Table 629.
Table 629 MDSYS.SDO_ANGLE_UNITS View
Column Name  Data Type  Description 

SDO_UNIT 
VARCHAR2(32) 
Name of the angle unit (often a shortened form of the UNIT_NAME value). Use the SDO_UNIT value with the 
VARCHAR2(100) 
Name of the angle unit. Specify a value from this column in the UNIT specification of the WKT for any userdefined coordinate system. Examples:  
NUMBER 
The ratio of the specified unit to one radian. For example, the ratio of 
The MDSYS.SDO_AREA_UNITS reference view contains one row for each valid area UNIT specification in the wellknown text (WKT) description in the coordinate system definition. The WKT is described in Section 6.8.1.1.
The MDSYS.SDO_AREA_UNITS view is based on the SDO_UNITS_OF MEASURE table (described in Section 6.7.27), and it contains the columns shown in Table 630.
Table 630 SDO_AREA_UNITS View
Column Name  Data Type  Purpose 

VARCHAR2 
Values are taken from the SHORT_NAME column of the SDO_UNITS_OF MEASURE table.  
VARCHAR2 
Values are taken from the UNIT_OF_MEAS_NAME column of the SDO_UNITS_OF MEASURE table.  
NUMBER 
Ratio of the unit to 1 square meter. For example, the conversion factor for a square meter is 1.0, and the conversion factor for a square mile is 2589988. 
The MDSYS.SDO_DATUMS_OLD_FORMAT and MDSYS.SDO_DATUMS_OLD_SNAPSHOT reference tables contain one row for each valid DATUM specification in the wellknown text (WKT) description in the coordinate system definition. (The WKT is described in Section 6.8.1.1.)
MDSYS.SDO_DATUMS_OLD_FORMAT contains the new data in the old format (that is, EPSGbased datum specifications in a table using the format from before release 10.2).
MDSYS.SDO_DATUMS_OLD_SNAPSHOT contains the old data in the old format (that is, datum specifications and table format from before release 10.2).
These tables contain the columns shown in Table 631.
Table 631 MDSYS.SDO_DATUMS_OLD_FORMAT and SDO_DATUMS_OLD_SNAPSHOT Tables
Column Name  Data Type  Description 

NAME 
VARCHAR2(80) for OLD_FORMAT VARCHAR2(64) for OLD_SNAPSHOT 
Name of the datum. Specify a value (Oraclesupplied or userdefined) from this column in the DATUM specification of the WKT for any userdefined coordinate system. Examples: 
SHIFT_X 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the xaxis. 
SHIFT_Y 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the yaxis. 
SHIFT_Z 
NUMBER 
Number of meters to shift the ellipsoid center relative to the center of the WGS 84 ellipsoid on the zaxis. 
ROTATE_X 
NUMBER 
Number of arcseconds of rotation about the xaxis. 
ROTATE_Y 
NUMBER 
Number of arcseconds of rotation about the yaxis. 
ROTATE_Z 
NUMBER 
Number of arcseconds of rotation about the zaxis. 
SCALE_ADJUST 
NUMBER 
A value to be used in adjusting the X, Y, and Z values after any shifting and rotation, according to the formula: 1.0 + (SCALE_ADJUST * 10^{6}) 
The following are the names (in tabular format) of the datums in these tables:
Adindan  Afgooye  Ain el Abd 1970 
Anna 1 Astro 1965  Arc 1950  Arc 1960 
Ascension Island 1958  Astro B4 Sorol Atoll  Astro Beacon E 
Astro DOS 71/4  Astronomic Station 1952  Australian Geodetic 1966 
Australian Geodetic 1984  Belgium Hayford  Bellevue (IGN) 
Bermuda 1957  Bogota Observatory  CH 1903 (Switzerland) 
Campo Inchauspe  Canton Astro 1966  Cape 
Cape Canaveral  Carthage  Chatham 1971 
Chua Astro  Corrego Alegre  DHDN (Potsdam/Rauenberg) 
DOS 1968  Djakarta (Batavia)  Easter Island 1967 
European 1950  European 1979  European 1987 
GRS 67  GRS 80  GUX 1 Astro 
Gandajika Base  Geodetic Datum 1949  Guam 1963 
Hito XVIII 1963  Hjorsey 1955  Hong Kong 1963 
HuTzuShan  ISTS 073 Astro 1969  Indian (Bangladesh, etc.) 
Indian (Thailand/Vietnam)  Ireland 1965  Johnston Island 1961 
Kandawala  Kerguelen Island  Kertau 1948 
L.C. 5 Astro  Liberia 1964  Lisboa (DLx) 
Luzon (Mindanao Island)  Luzon (Philippines)  Mahe 1971 
Marco Astro  Massawa  Melrica 1973 (D73) 
Merchich  Midway Astro 1961  Minna 
NAD 27 (Alaska)  NAD 27 (Bahamas)  NAD 27 (Canada) 
NAD 27 (Canal Zone)  NAD 27 (Caribbean)  NAD 27 (Central America) 
NAD 27 (Continental US)  NAD 27 (Cuba)  NAD 27 (Greenland) 
NAD 27 (Mexico)  NAD 27 (Michigan)  NAD 27 (San Salvador) 
NAD 83  NTF (Greenwich meridian)  NTF (Paris meridian) 
NWGL 10  Nahrwan (Masirah Island)  Nahrwan (Saudi Arabia) 
Nahrwan (Un. Arab Emirates)  Naparima, BWI  Netherlands Bessel 
Observatorio 1966  Old Egyptian  Old Hawaiian 
Oman  Ordinance Survey Great Brit  Pico de las Nieves 
Pitcairn Astro 1967  Provisional South American  Puerto Rico 
Pulkovo 1942  Qatar National  Qornoq 
RT 90 (Sweden)  Reunion  Rome 1940 
Santo (DOS)  Sao Braz  Sapper Hill 1943 
Schwarzeck  South American 1969  South Asia 
Southeast Base  Southwest Base  Timbalai 1948 
Tokyo  Tristan Astro 1968  Viti Levu 1916 
WGS 60  WGS 66  WGS 72 
WGS 84  WakeEniwetok 1960  Yacare 
Zanderij 
The MDSYS.SDO_DIST_UNITS reference view contains one row for each valid distance UNIT specification in the wellknown text (WKT) description in the coordinate system definition. The WKT is described in Section 6.8.1.1.
The MDSYS.SDO_DIST_UNITS view is based on the SDO_UNITS_OF MEASURE table (described in Section 6.7.27), and it contains the columns shown in Table 632.
Table 632 MDSYS.SDO_DIST_UNITS View
Column Name  Data Type  Description 

VARCHAR2 
Values are taken from the SHORT_NAME column of the SDO_UNITS_OF MEASURE table.  
VARCHAR2 
Values are taken from the UNIT_OF_MEAS_NAME column of the SDO_UNITS_OF MEASURE table.  
NUMBER 
Ratio of the unit to 1 meter. For example, the conversion factor for a meter is 1.0, and the conversion factor for a mile is 1609.344. 
The MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT and MDSYS.SDO_ELLIPSOIDS_OLD_SNAPSHOT reference tables contain one row for each valid SPHEROID specification in the wellknown text (WKT) description in the coordinate system definition. (The WKT is described in Section 6.8.1.1.)
MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT contains the new data in the old format (that is, EPSGbased ellipsoid specifications in a table using the format from before release 10.2).
MDSYS.SDO_ELLIPSOIDS_OLD_SNAPSHOT contains the old data in the old format (that is, ellipsoid specifications and table format from before release 10.2).
These tables contain the columns shown in Table 633.
Table 633 MDSYS.SDO_ELLIPSOIDS_OLD_FORMAT and SDO_ELLIPSOIDS_OLD_SNAPSHOT Tables
Column Name  Data Type  Description 

NAME 
VARCHAR2(80) for OLD_FORMAT VARCHAR2(64) for OLD_SNAPSHOT 
Name of the ellipsoid (spheroid). Specify a value from this column in the SPHEROID specification of the WKT for any userdefined coordinate system. Examples: 
NUMBER 
Radius in meters along the semimajor axis (onehalf of the long axis of the ellipsoid).  
NUMBER 
Inverse flattening of the ellipsoid. That is, 
The following are the names (in tabular format) of the ellipsoids in these tables:
Airy 1830  Airy 1830 (Ireland 1965)  Australian 
Bessel 1841  Bessel 1841 (NGO 1948)  Bessel 1841 (Schwarzeck) 
Clarke 1858  Clarke 1866  Clarke 1866 (Michigan) 
Clarke 1880  Clarke 1880 (Arc 1950)  Clarke 1880 (IGN) 
Clarke 1880 (Jamaica)  Clarke 1880 (Merchich)  Clarke 1880 (Palestine) 
Everest  Everest (Kalianpur)  Everest (Kertau) 
Everest (Timbalai)  Fischer 1960 (Mercury)  Fischer 1960 (South Asia) 
Fischer 1968  GRS 67  GRS 80 
Hayford  Helmert 1906  Hough 
IAG 75  Indonesian  International 1924 
Krassovsky  MERIT 83  NWL 10D 
NWL 9D  New International 1967  OSU86F 
OSU91A  Plessis 1817  South American 1969 
Sphere (6370997m)  Struve 1860  WGS 60 
WGS 66  WGS 72  WGS 84 
Walbeck  War Office 
The MDSYS.SDO_PROJECTIONS_OLD_FORMAT and MDSYS.SDO_PROJECTIONS_OLD_SNAPSHOT reference tables contain one row for each valid PROJECTION specification in the wellknown text (WKT) description in the coordinate system definition. (The WKT is described in Section 6.8.1.1.)
MDSYS.SDO_PROJECTIONS_OLD_FORMAT contains the new data in the old format (that is, EPSGbased projection specifications in a table using the format from before release 10.2).
MDSYS.SDO_PROJECTIONS_OLD_SNAPSHOT contains the old data in the old format (that is, projection specifications and table format from before release 10.2).
These tables contains the column shown in Table 634.
Table 634 MDSYS.SDO_PROJECTIONS_OLD_FORMAT and SDO_PROJECTIONS_OLD_SNAPSHOT Tables
Column Name  Data Type  Description 

NAME 
VARCHAR2(80) for OLD_FORMAT VARCHAR2(64) for OLD_SNAPSHOT 
Name of the map projection. Specify a value from this column in the PROJECTION specification of the WKT for any userdefined coordinate system. Examples: 
The following are the names (in tabular format) of the projections in these tables:
Alaska Conformal  Albers Conical Equal Area 
Azimuthal Equidistant  Bonne 
Cassini  Cylindrical Equal Area 
Eckert IV  Eckert VI 
Equidistant Conic  Equirectangular 
Gall  General Vertical NearSide Perspective 
Geographic (Lat/Long)  Gnomonic 
Hammer  Hotine Oblique Mercator 
Interrupted Goode Homolosine  Interrupted Mollweide 
Lambert Azimuthal Equal Area  Lambert Conformal Conic 
Lambert Conformal Conic (Belgium 1972)  Mercator 
Miller Cylindrical  Mollweide 
New Zealand Map Grid  Oblated Equal Area 
Orthographic  Polar Stereographic 
Polyconic  Robinson 
Sinusoidal  Space Oblique Mercator 
State Plane Coordinates  Stereographic 
Swiss Oblique Mercator  Transverse Mercator 
Transverse Mercator Danish System 34 JyllandFyn  Transverse Mercator Danish System 45 Bornholm 
Transverse Mercator Finnish KKJ  Transverse Mercator Sjaelland 
Universal Transverse Mercator  Van der Grinten 
Wagner IV  Wagner VII 
If the coordinate systems supplied by Oracle are not sufficient for your needs, you can create userdefined coordinate reference systems.
Note: As mentioned in Section 6.1.1, the terms coordinate system and coordinate reference system (CRS) are often used interchangeably, although coordinate reference systems must be Earthbased. 
The exact steps for creating a userdefined CRS depend on whether it is geodetic or projected. In both cases, supply information about the coordinate system (coordinate axes, axis names, unit of measurement, and so on). For a geodetic CRS, supply information about the datum (ellipsoid, prime meridian, and so on), as explained in Section 6.9.1. For a projected CRS, supply information about the source (geodetic) CRS and the projection (operation and parameters), as explained in Section 6.9.2.
For any userdefined coordinate system, the SRID value should be 1000000 (1 million) or higher.
If the necessary unit of measurement, coordinate axes, SDO_COORD_SYS table row, ellipsoid, prime meridian, and datum are already defined, insert a row into the SDO_COORD_REF_SYSTEM view (described in Section 6.7.10) to define the new geodetic CRS.
Example 65 inserts the definition for a hypothetical geodetic CRS named My Own NAD27
(which, except for its SRID and name, is the same as the NAD27
CRS supplied by Oracle).
Example 65 Creating a UserDefined Geodetic Coordinate Reference System
INSERT INTO SDO_COORD_REF_SYSTEM ( SRID, COORD_REF_SYS_NAME, COORD_REF_SYS_KIND, COORD_SYS_ID, DATUM_ID, GEOG_CRS_DATUM_ID, SOURCE_GEOG_SRID, PROJECTION_CONV_ID, CMPD_HORIZ_SRID, CMPD_VERT_SRID, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY, LEGACY_CODE, LEGACY_WKTEXT, LEGACY_CS_BOUNDS, IS_VALID, SUPPORTS_SDO_GEOMETRY) VALUES ( 9994267, 'My Own NAD27', 'GEOGRAPHIC2D', 6422, 6267, 6267, NULL, NULL, NULL, NULL, NULL, 'EPSG', 'FALSE', NULL, NULL, NULL, 'TRUE', 'TRUE');
If the necessary information for the definition does not already exist, follow these steps, as needed, to define the information before you insert the row into the SDO_COORD_REF_SYSTEM view:
If the unit of measurement is not already defined in the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27), insert a row into that table to define the new unit of measurement.
If the coordinate axes are not already defined in the SDO_COORD_AXES table (described in Section 6.7.1), insert one row into that table for each new coordinate axis.
If an appropriate entry for the coordinate system does not already exist in the SDO_COORD_SYS table (described in Section 6.7.11), insert a row into that table. Example 66 inserts the definition for a fictitious coordinate system.
Example 66 Inserting a Row into the SDO_COORD_SYS Table
INSERT INTO SDO_COORD_SYS ( COORD_SYS_ID, COORD_SYS_NAME, COORD_SYS_TYPE, DIMENSION, INFORMATION_SOURCE, DATA_SOURCE) VALUES ( 9876543, 'My custom CS. Axes: lat, long. Orientations: north, east. UoM: deg', 'ellipsoidal', 2, 'Myself', 'Myself');
If the ellipsoid is not already defined in the SDO_ELLIPSOIDS table (described in Section 6.7.23), insert a row into that table to define the new ellipsoid.
If the prime meridian is not already defined in the SDO_PRIME_MERIDIANS table (described in Section 6.7.26), insert a row into that table to define the new prime meridian.
If the datum is not already defined in the SDO_DATUMS table (described in Section 6.7.22), insert a row into that table to define the new datum.
If the necessary unit of measurement, coordinate axes, SDO_COORD_SYS table row, source coordinate system, projection operation, and projection parameters are already defined, insert a row into the SDO_COORD_REF_SYSTEM view (described in Section 6.7.10) to define the new projected CRS.
Example 67 inserts the definition for a hypothetical projected CRS named My Own NAD27 / Cuba Norte
(which, except for its SRID and name, is the same as the NAD27 / Cuba Norte
CRS supplied by Oracle).
Example 67 Creating a UserDefined Projected Coordinate Reference System
INSERT INTO SDO_COORD_REF_SYSTEM ( SRID, COORD_REF_SYS_NAME, COORD_REF_SYS_KIND, COORD_SYS_ID, DATUM_ID, GEOG_CRS_DATUM_ID, SOURCE_GEOG_SRID, PROJECTION_CONV_ID, CMPD_HORIZ_SRID, CMPD_VERT_SRID, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY, LEGACY_CODE, LEGACY_WKTEXT, LEGACY_CS_BOUNDS, IS_VALID, SUPPORTS_SDO_GEOMETRY) VALUES ( 9992085, 'My Own NAD27 / Cuba Norte', 'PROJECTED', 4532, NULL, 6267, 4267, 18061, NULL, NULL, 'Institut Cubano di Hidrografia (ICH)', 'EPSG', 'FALSE', NULL, NULL, NULL, 'TRUE', 'TRUE');
If the necessary information for the definition does not already exist, follow these steps, as needed, to define the information before you insert the row into the SDO_COORD_REF_SYSTEM view:
If the unit of measurement is not already defined in the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27), insert a row into that table to define the new unit of measurement.
If the coordinate axes are not already defined in the SDO_COORD_AXES table (described in Section 6.7.1), insert one row into that table for each new coordinate axis.
If an appropriate entry for the coordinate system does not already exist in SDO_COORD_SYS table (described in Section 6.7.11), insert a row into that table. (See Example 66 in Section 6.9.1).
If the projection operation is not already defined in the SDO_COORD_OPS table (described in Section 6.7.8), insert a row into that table to define the new projection operation. Example 68 shows the statement used to insert information about coordinate operation ID 18061, which is supplied by Oracle.
Example 68 Inserting a Row into the SDO_COORD_OPS Table
INSERT INTO SDO_COORD_OPS ( COORD_OP_ID, COORD_OP_NAME, COORD_OP_TYPE, SOURCE_SRID, TARGET_SRID, COORD_TFM_VERSION, COORD_OP_VARIANT, COORD_OP_METHOD_ID, UOM_ID_SOURCE_OFFSETS, UOM_ID_TARGET_OFFSETS, INFORMATION_SOURCE, DATA_SOURCE, SHOW_OPERATION, IS_LEGACY, LEGACY_CODE, REVERSE_OP, IS_IMPLEMENTED_FORWARD, IS_IMPLEMENTED_REVERSE) VALUES ( 18061, 'Cuba Norte', 'CONVERSION', NULL, NULL, NULL, NULL, 9801, NULL, NULL, NULL, 'EPSG', 1, 'FALSE', NULL, 1, 1, 1);
If the parameters for the projection operation are not already defined in the SDO_COORD_OP_PARAM_VALS table (described in Section 6.7.5), insert one row into that table for each new parameter. Example 69 shows the statement used to insert information about parameters with ID values 8801, 8802, 8805, 8806, and 8807, which are supplied by Oracle.
Example 69 Inserting a Row into the SDO_COORD_OP_PARAM_VALS Table
INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8801, 22.21, NULL, 9110); INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8802, 81, NULL, 9110); INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8805, .99993602, NULL, 9201); INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8806, 500000, NULL, 9001); INSERT INTO SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 18061, 9801, 8807, 280296.016, NULL, 9001);
Example 610 provides an extended, annotated example of creating a userdefined projected coordinate system
Example 610 Creating a UserDefined Projected CRS: Extended Example
 Create an EPSG equivalent for the following CRS:   CS_NAME: VDOT_LAMBERT  SRID: 51000000  AUTH_SRID: 51000000  AUTH_NAME: VDOT Custom Lambert Conformal Conic  WKTEXT:   PROJCS[  "VDOT_Lambert",  GEOGCS[  "GCS_North_American_1983",  DATUM[  "D_North_American_1983",  SPHEROID["GRS_1980", 6378137.0, 298.257222101]],  PRIMEM["Greenwich", 0.0],  UNIT["Decimal Degree",0.0174532925199433]],  PROJECTION["Lambert_Conformal_Conic"],  PARAMETER["False_Easting", 0.0],  PARAMETER["False_Northing", 0.0],  PARAMETER["Central_Meridian", 79.5],  PARAMETER["Standard_Parallel_1", 37.0],  PARAMETER["Standard_Parallel_2", 39.5],  PARAMETER["Scale_Factor", 1.0],  PARAMETER["Latitude_Of_Origin", 36.0],  UNIT["Meter", 1.0]]  First, the base geographic CRS (GCS_North_American_1983) already exists in EPSG.  It is 4269:  Next, find the EPSG equivalent for PROJECTION["Lambert_Conformal_Conic"]: select coord_op_method_id, legacy_name from sdo_coord_op_methods where not legacy_name is null order by coord_op_method_id;  Result:  COORD_OP_METHOD_ID LEGACY_NAME     9802 Lambert Conformal Conic  9803 Lambert Conformal Conic (Belgium 1972)  9805 Mercator  9806 Cassini  9807 Transverse Mercator  9829 Polar Stereographic   6 rows selected.   It is EPSG method 9802. Create a projection operation 510000001, based on it: insert into MDSYS.SDO_COORD_OPS ( COORD_OP_ID, COORD_OP_NAME, COORD_OP_TYPE, SOURCE_SRID, TARGET_SRID, COORD_TFM_VERSION, COORD_OP_VARIANT, COORD_OP_METHOD_ID, UOM_ID_SOURCE_OFFSETS, UOM_ID_TARGET_OFFSETS, INFORMATION_SOURCE, DATA_SOURCE, SHOW_OPERATION, IS_LEGACY, LEGACY_CODE, REVERSE_OP, IS_IMPLEMENTED_FORWARD, IS_IMPLEMENTED_REVERSE) VALUES ( 510000001, 'VDOT_Lambert', 'CONVERSION', NULL, NULL, NULL, NULL, 9802, NULL, NULL, NULL, NULL, 1, 'FALSE', NULL, 1, 1, 1);  Now, set the parameters. See which are required: select use.parameter_id  ': '  use.legacy_param_name from sdo_coord_op_param_use use where use.coord_op_method_id = 9802;  result:  8821: Latitude_Of_Origin  8822: Central_Meridian  8823: Standard_Parallel_1  8824: Standard_Parallel_2  8826: False_Easting  8827: False_Northing   6 rows selected.  Also check the most common units we will need: select UOM_ID  ': '  UNIT_OF_MEAS_NAME from sdo_units_of_measure where uom_id in (9001, 9101, 9102, 9201) order by uom_id;  result:  9001: metre  9101: radian  9102: degree  9201: unity  Now, configure the projection parameters:  8821: Latitude_Of_Origin insert into MDSYS.SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 510000001, 9802, 8821, 36.0, NULL, 9102);  8822: Central_Meridian insert into MDSYS.SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 510000001, 9802, 8822, 79.5, NULL, 9102);  8823: Standard_Parallel_1 insert into MDSYS.SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 510000001, 9802, 8823, 37.0, NULL, 9102);  8824: Standard_Parallel_2 insert into MDSYS.SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 510000001, 9802, 8824, 39.5, NULL, 9102);  8826: False_Easting insert into MDSYS.SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 510000001, 9802, 8826, 0.0, NULL, 9001);  8827: False_Northing insert into MDSYS.SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 510000001, 9802, 8827, 0.0, NULL, 9001);  Now, create the actual projected CRS.Look at the GEOG_CRS_DATUM_ID  and COORD_SYS_ID first. The GEOG_CRS_DATUM_ID is the datum of  the base geog_crs (4269): select datum_id from sdo_coord_ref_sys where srid = 4269;  DATUM_ID    6269  And the COORD_SYS_ID is the Cartesian CS used for the projected CRS.  We can use 4400, if meters will be the unit: select COORD_SYS_NAME from sdo_coord_sys where COORD_SYS_ID = 4400;  Cartesian 2D CS. Axes: easting, northing (E,N). Orientations: east, north.  UoM: m.  Now create the projected CRS: insert into MDSYS.SDO_COORD_REF_SYSTEM ( SRID, COORD_REF_SYS_NAME, COORD_REF_SYS_KIND, COORD_SYS_ID, DATUM_ID, SOURCE_GEOG_SRID, PROJECTION_CONV_ID, CMPD_HORIZ_SRID, CMPD_VERT_SRID, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY, LEGACY_CODE, LEGACY_WKTEXT, LEGACY_CS_BOUNDS, GEOG_CRS_DATUM_ID) VALUES ( 51000000, 'VDOT_LAMBERT', 'PROJECTED', 4400, NULL, 4269, 510000001, NULL, NULL, NULL, NULL, 'FALSE', NULL, NULL, NULL, 6269);  To see the result: select srid, wktext from cs_srs where srid = 51000000;  51000000  PROJCS[  "VDOT_LAMBERT",  GEOGCS [  "NAD83",  DATUM [  "North American Datum 1983 (EPSG ID 6269)",  SPHEROID [  "GRS 1980 (EPSG ID 7019)",  6378137,  298.257222101]],  PRIMEM [ "Greenwich", 0.000000 ],  UNIT ["Decimal Degree", 0.01745329251994328]],  PROJECTION ["VDOT_Lambert"],  PARAMETER ["Latitude_Of_Origin", 36],  PARAMETER ["Central_Meridian", 79.50000000000000000000000000000000000028],  PARAMETER ["Standard_Parallel_1", 37],  PARAMETER ["Standard_Parallel_2", 39.5],  PARAMETER ["False_Easting", 0],  PARAMETER ["False_Northing", 0],  UNIT ["Meter", 1]]
A vertical CRS has only one dimension, usually height. On its own, a vertical CRS is of little use, but it can be combined with a twodimensional CRS (geodetic or projected), to result in a compound CRS. Example 611 shows the statement that created the vertical CRS with SRID 5701, which is included with Spatial. This definition refers to an existing (onedimensional) coordinate system (ID 6499; see Section 6.7.11, "SDO_COORD_SYS Table") and vertical datum (ID 5101; see Section 6.7.22, "SDO_DATUMS Table").
Example 611 Creating a Vertical Coordinate Reference System
INSERT INTO MDSYS.SDO_COORD_REF_SYSTEM ( SRID, COORD_REF_SYS_NAME, COORD_REF_SYS_KIND, COORD_SYS_ID, DATUM_ID, SOURCE_GEOG_SRID, PROJECTION_CONV_ID, CMPD_HORIZ_SRID, CMPD_VERT_SRID, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY, LEGACY_CODE, LEGACY_WKTEXT, LEGACY_CS_BOUNDS) VALUES ( 5701, 'Newlyn', 'VERTICAL', 6499, 5101, NULL, NULL, NULL, NULL, NULL, 'EPSG', 'FALSE', NULL, NULL, NULL);
A vertical CRS might define some undulating equipotential surface. The shape of that surface, and its offset from some ellipsoid, is not actually defined in the vertical CRS record itself (other than textually). Instead, that definition is included in an operation between the vertical CRS and another CRS. Consequently, you can define several alternative operations between the same pair of geoidal and WGS84ellipsoidal heights. For example, there are geoid offset matrixes GEOID90, GEOID93, GEOID96, GEOID99, GEOID03, GEOID06, and others, and for each of these variants there can be a separate operation. Section 6.9.6 describes such an operation.
A compound CRS combines an existing horizontal (twodimensional) CRS and a vertical (onedimensional) CRS. The horizontal CRS can be geodetic or projected. Example 612 shows the statement that created the compound CRS with SRID 7405, which is included with Spatial. This definition refers to an existing projected CRS and vertical CRS (IDs 27700 and 5701, respectively; see Section 6.7.9, "SDO_COORD_REF_SYS Table").
Example 612 Creating a Compound Coordinate Reference System
INSERT INTO MDSYS.SDO_COORD_REF_SYSTEM ( SRID, COORD_REF_SYS_NAME, COORD_REF_SYS_KIND, COORD_SYS_ID, DATUM_ID, SOURCE_GEOG_SRID, PROJECTION_CONV_ID, CMPD_HORIZ_SRID, CMPD_VERT_SRID, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY, LEGACY_CODE, LEGACY_WKTEXT, LEGACY_CS_BOUNDS) VALUES ( 7405, 'OSGB36 / British National Grid + ODN', 'COMPOUND', NULL, NULL, NULL, NULL, 27700, 5701, NULL, 'EPSG', 'FALSE', NULL, NULL, NULL);
A geographic 3D CRS is the combination of a geographic 2D CRS with ellipsoidal height. Example 613 shows the statement that created the geographic 3D CRS with SRID 4327, which is included with Spatial. This definition refers to an existing projected coordinate system (ID 6401; see Section 6.7.11, "SDO_COORD_SYS Table") and datum (ID 6326; see Section 6.7.22, "SDO_DATUMS Table").
Example 613 Creating a Geographic 3D Coordinate Reference System
INSERT INTO MDSYS.SDO_COORD_REF_SYSTEM ( SRID, COORD_REF_SYS_NAME, COORD_REF_SYS_KIND, COORD_SYS_ID, DATUM_ID, GEOG_CRS_DATUM_ID, SOURCE_GEOG_SRID, PROJECTION_CONV_ID, CMPD_HORIZ_SRID, CMPD_VERT_SRID, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY, LEGACY_CODE, LEGACY_WKTEXT, LEGACY_CS_BOUNDS, IS_VALID, SUPPORTS_SDO_GEOMETRY) VALUES ( 4327, 'WGS 84 (geographic 3D)', 'GEOGRAPHIC3D', 6401, 6326, 6326, NULL, NULL, NULL, NULL, 'NIMA TR8350.2 January 2000 revision. http://164.214.2.59/GandG/tr8350_2.html', 'EPSG', 'FALSE', NULL, NULL, NULL, 'TRUE', 'TRUE');
Section 6.9.2 described the creation of a projection operation, for the purpose of then creating a projected CRS. A similar requirement can arise when using a compound CRS based on orthometric height: you may want to transform from and to ellipsoidal height. The offset between the two heights is undulating and irregular.
By default, Spatial transforms between ellipsoidal and orthometric height using an identity transformation. (Between different ellipsoids, the default would instead be a datum transformation.) The identity transformation is a reasonable approximation; however, a more accurate approach involves an EPSG type 9635 operation, involving an offset matrix. Example 614 is a declaration of such an operation:
Example 614 Creating a Transformation Operation
INSERT INTO MDSYS.SDO_COORD_OPS ( COORD_OP_ID, COORD_OP_NAME, COORD_OP_TYPE, SOURCE_SRID, TARGET_SRID, COORD_TFM_VERSION, COORD_OP_VARIANT, COORD_OP_METHOD_ID, UOM_ID_SOURCE_OFFSETS, UOM_ID_TARGET_OFFSETS, INFORMATION_SOURCE, DATA_SOURCE, SHOW_OPERATION, IS_LEGACY, LEGACY_CODE, REVERSE_OP, IS_IMPLEMENTED_FORWARD, IS_IMPLEMENTED_REVERSE) VALUES ( 999998, 'Test operation, based on GEOID03 model, using Hawaii grid', 'TRANSFORMATION', NULL, NULL, NULL, NULL, 9635, NULL, NULL, 'NGS', 'NGS', 1, 'FALSE', NULL, 1, 1, 1); INSERT INTO MDSYS.SDO_COORD_OP_PARAM_VALS ( COORD_OP_ID, COORD_OP_METHOD_ID, PARAMETER_ID, PARAMETER_VALUE, PARAM_VALUE_FILE_REF, UOM_ID) VALUES ( 999998, 9635, 8666, NULL, 'g2003h01.asc', NULL);
The second INSERT statement in Example 614 specifies the file name g2003h01.asc
, but not yet its actual CLOB content with the offset matrix. As with NADCON and NTv2 matrixes, geoid matrixes have to be loaded into the PARAM_VALUE_FILE column. Due to space and copyright considerations, Oracle does not supply most of these matrixes; however, they are usually available for download on the Web. Good sources are the relevant government websites, and you can search by file name (such as g2003h01
in this example). Although some of these files are available in both binary format (such as .gsb) and ASCII format (such as .gsa or .asc), only the ASCII variant can be used with Spatial. The existing EPSG operations include file names in standard use.
Example 615 is a script for loading a set of such matrixes. It loads specified physical files (such as ntv20.gsa
) into database CLOBs, based on the official file name reference (such as NTV2_0.GSB
).
Example 615 Loading Offset Matrixes
DECLARE ORCL_HOME_DIR VARCHAR2(128); ORCL_WORK_DIR VARCHAR2(128); Src_loc BFILE; Dest_loc CLOB; CURSOR PARAM_FILES IS SELECT COORD_OP_ID, PARAMETER_ID, PARAM_VALUE_FILE_REF FROM MDSYS.SDO_COORD_OP_PARAM_VALS WHERE PARAMETER_ID IN (8656, 8657, 8658, 8666); PARAM_FILE PARAM_FILES%ROWTYPE; ACTUAL_FILE_NAME VARCHAR2(128); platform NUMBER; BEGIN EXECUTE IMMEDIATE 'CREATE OR REPLACE DIRECTORY work_dir AS ''define_your_source_directory_here'''; FOR PARAM_FILE IN PARAM_FILES LOOP CASE UPPER(PARAM_FILE.PARAM_VALUE_FILE_REF) /* NTv2, fill in your files here */ WHEN 'NTV2_0.GSB' THEN ACTUAL_FILE_NAME := 'ntv20.gsa'; /* GEOID03, fill in your files here */ WHEN 'G2003H01.ASC' THEN ACTUAL_FILE_NAME := 'g2003h01.asc'; ELSE ACTUAL_FILE_NAME := NULL; END CASE; IF(NOT (ACTUAL_FILE_NAME IS NULL)) THEN BEGIN dbms_output.put_line('Loading file '  actual_file_name  '...'); Src_loc := BFILENAME('WORK_DIR', ACTUAL_FILE_NAME); DBMS_LOB.OPEN(Src_loc, DBMS_LOB.LOB_READONLY); END; UPDATE MDSYS.SDO_COORD_OP_PARAM_VALS SET PARAM_VALUE_FILE = EMPTY_CLOB() WHERE COORD_OP_ID = PARAM_FILE.COORD_OP_ID AND PARAMETER_ID = PARAM_FILE.PARAMETER_ID RETURNING PARAM_VALUE_FILE INTO Dest_loc; DBMS_LOB.OPEN(Dest_loc, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(Dest_loc, Src_loc, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(Dest_loc); DBMS_LOB.CLOSE(Src_loc); DBMS_LOB.FILECLOSE(Src_loc); END IF; END LOOP; END; /
To use British Grid Transformation OSTN02/OSGM02 (EPSG method 9633) in a projected coordinate reference system, you must first insert a modified version of the OSTN02_OSGM02_GB.txt
grid file into the PARAM_VALUE_FILE column (type CLOB) of the SDO_COORD_OP_PARAM_VALS table (described in Section 6.7.5). The OSTN02_OSGM02_GB.txt
file contains the offset matrix on which EPSG transformation method 9633 is based.
Follow these steps:
Download the following file: http://www.ordnancesurvey.co.uk/docs/gps/ostn02osgm02files.zip
From this .zip file, extract the following file: OSTN02_OSGM02_GB.txt
Edit your copy of OSTN02_OSGM02_GB.txt
, and insert the following lines before the first line of the current file:
SDO Header x: 0.0  700000.0 y: 0.0  1250000.0 xintervals: 1000.0 yintervals: 1000.0 End of SDO Header
The is, after the editing operation, the contents of the file will look like this:
SDO Header x: 0.0  700000.0 y: 0.0  1250000.0 xintervals: 1000.0 yintervals: 1000.0 End of SDO Header 1,0,0,0.000,0.000,0.000,0 2,1000,0,0.000,0.000,0.000,0 3,2000,0,0.000,0.000,0.000,0 4,3000,0,0.000,0.000,0.000,0 5,4000,0,0.000,0.000,0.000,0 . . . 876949,698000,1250000,0.000,0.000,0.000,0 876950,699000,1250000,0.000,0.000,0.000,0 876951,700000,1250000,0.000,0.000,0.000,0
Save the edited file, perhaps using a different name (for example, my_OSTN02_OSGM02_GB.txt
).
In the SDO_COORD_OP_PARAM_VALS table, for each operation of EPSG method 9633 that has PARAM_VALUE_FILE_REF value OSTN02_OSGM02_GB.TXT
, update the PARAM_VALUE_FILE column to be the contents of the saved file (for example, the contents of my_OSTN02_OSGM02_GB.txt
). You can use coding similar to that in Example 616.
Example 616 Using British Grid Transformation OSTN02/OSGM02 (EPSG Method 9633)
DECLARE ORCL_HOME_DIR VARCHAR2(128); ORCL_WORK_DIR VARCHAR2(128); Src_loc BFILE; Dest_loc CLOB; CURSOR PARAM_FILES IS SELECT COORD_OP_ID, PARAMETER_ID, PARAM_VALUE_FILE_REF FROM MDSYS.SDO_COORD_OP_PARAM_VALS WHERE PARAMETER_ID IN (8656, 8657, 8658, 8664, 8666) order by COORD_OP_ID, PARAMETER_ID; PARAM_FILE PARAM_FILES%ROWTYPE; ACTUAL_FILE_NAME VARCHAR2(128); platform NUMBER; BEGIN EXECUTE IMMEDIATE 'CREATE OR REPLACE DIRECTORY work_dir AS '''  system.geor_dir  ''''; FOR PARAM_FILE IN PARAM_FILES LOOP CASE UPPER(PARAM_FILE.PARAM_VALUE_FILE_REF) /* NTv2 */ WHEN 'NTV2_0.GSB' THEN ACTUAL_FILE_NAME := 'ntv20.gsa'; /* GEOID03 */ WHEN 'G2003H01.ASC' THEN ACTUAL_FILE_NAME := 'g2003h01.asc'; /* British Ordnance Survey (9633) */ WHEN 'OSTN02_OSGM02_GB.TXT' THEN ACTUAL_FILE_NAME := 'my_OSTN02_OSGM02_GB.txt'; ELSE ACTUAL_FILE_NAME := NULL; END CASE; IF(NOT (ACTUAL_FILE_NAME IS NULL)) THEN BEGIN dbms_output.put_line('Loading file '  actual_file_name  '...'); Src_loc := BFILENAME('WORK_DIR', ACTUAL_FILE_NAME); DBMS_LOB.OPEN(Src_loc, DBMS_LOB.LOB_READONLY); END; UPDATE MDSYS.SDO_COORD_OP_PARAM_VALS SET PARAM_VALUE_FILE = EMPTY_CLOB() WHERE COORD_OP_ID = PARAM_FILE.COORD_OP_ID AND PARAMETER_ID = PARAM_FILE.PARAMETER_ID RETURNING PARAM_VALUE_FILE INTO Dest_loc; DBMS_LOB.OPEN(Dest_loc, DBMS_LOB.LOB_READWRITE); DBMS_LOB.LOADFROMFILE(Dest_loc, Src_loc, DBMS_LOB.LOBMAXSIZE); DBMS_LOB.CLOSE(Dest_loc); DBMS_LOB.CLOSE(Src_loc); DBMS_LOB.FILECLOSE(Src_loc); END IF; END LOOP; END; /
Note that adding "header" information to a grid file is required only for British Grid Transformation OSTN02/OSGM02. It is not required for NADCON, NTv2, or VERTCON matrixes, because they already have headers of varying formats.
See also the following for related information:
The following notes and restrictions apply to coordinate systems support in the current release of Oracle Spatial.
If you have geodetic data, see Section 6.2 for additional considerations, guidelines, and restrictions.
For Spatial operators (described in Chapter 19) that take two geometries as input parameters, if the geometries are based on different coordinate systems, the query window (the second geometry) is transformed to the coordinate system of the first geometry before the operation is performed. This transformation is a temporary internal operation performed by Spatial; it does not affect any stored querywindow geometry.
For SDO_GEOM package geometry functions (described in Chapter 24) that take two geometries as input parameters, both geometries must be based on the same coordinate system.
In the current release, the 3D formats of LRS functions (explained in Section 7.4) are not supported with geodetic data.
In the current release, the following functions are supported by approximations with geodetic data:
When these functions are used on data with geodetic coordinates, they internally perform the operations in an implicitly generated localtangentplane Cartesian coordinate system and then transform the results to the geodetic coordinate system. For SDO_GEOM.SDO_BUFFER, generated arcs are approximated by line segments before the backtransform.
The following coordinate reference systems are provided for Oracle internal use and for other possible special uses:
unknown CRS
(SRID 999999) means that the coordinate system is unknown, and its space could be geodetic or Cartesian. Contrast this with specifying a null coordinate reference system, which indicates an unknown coordinate system with a Cartesian space.
NaC
(SRID 999998) means NotaCRS. Its name is patterned after the NaN
(NotaNumber) value in Java. It is intended for potential use with nonspatial geometries.
The following restrictions apply to geometries based on the unknown CRS
and NaC
coordinate reference systems:
You cannot perform coordinate system transformations on these geometries.
Operations that require a coordinate system will return a null value when performed on these geometries. These operations include finding the area or perimeter of a geometry, creating a buffer, densifying an arc, and computing the aggregate centroid.
The U.S. National Grid is a point coordinate representation using a single alphanumeric coordinate (for example, 18SUJ2348316806479498). This approach contrasts with the use of numeric coordinates to represent3L̳ the location of a point, as is done with Oracle Spatial and EPSG. A good description of the U.S. National Grid is available at http://www.ngs.noaa.gov/TOOLS/usng.html
.
To support the U.S. National Grid in Spatial, the SDO_GEOMETRY type cannot be used because it is based on numeric coordinates. Instead, a point in U.S. National Grid format is represented as a single string of type VARCHAR2. To allow conversion between the SDO_GEOMETRY format and the U.S. National grid format, the SDO_CS package (documented in Chapter 21) contains the following functions:
Google Maps uses spherical math in its projections, as opposed to the ellipsoidal math used by Oracle Spatial. This difference can lead to inconsistencies in applications, such as when overlaying a map based on Google Maps with a map based on an Oracle Spatial ellipsoidal projection. For example, an Oracle Spatial transformation from the ellipsoidal SRID 8307 to the spherical SRID 3785 accounts, by default, for the different ellipsoidal shapes, whereas Google Maps does not consider ellipsoidal shapes.
If you want Oracle Spatial to accommodate the Google Maps results, consider the following options:
Use the spherical SRID 4055 instead of the ellipsoidal SRID 8307. This may be the simplest approach; however, if you need to accommodate SRID 8307based data (such as from a thirdparty tool) as if it were spherical, you must use another option.
Use SRID 3857 instead of SRID 3785. This more convenient than the next two options, because using SRID 3857 does not require that you declare an EPSG rule or that you specify the USE_SPHERICAL
use case name in order to produce Googlecompatible results.
Declare an EPSG rule between the ellipsoidal and spherical coordinate systems. For example, declare an EPSG rule between SRIDs 8307 and 3785, ignoring the ellipsoidal shape of SRID 8307, as in the following example:
CALL sdo_cs.create_pref_concatenated_op( 302, 'CONCATENATED OPERATION', TFM_PLAN(SDO_TFM_CHAIN(8307, 1000000000, 4055, 19847, 3785)), NULL);
In this example, operation 1000000000
represents nooperation, causing the datum transformation between ellipsoid and sphere to be ignored.
With this approach, you must declare a rule for each desired SRID pair (ellipsoidal and spherical).
Specify a use case name of USE_SPHERICAL
with the SDO_CS.TRANSFORM function or the SDO_CS.TRANSFORM_LAYER procedure, as in the following examples:
SELECT SDO_CS.TRANSFORM( sdo_geometry( 2001, 4326, sdo_point_type(1, 1, null), null, null), 'USE_SPHERICAL', 3785) FROM DUAL; CALL SDO_CS.TRANSFORM_LAYER( 'source_geoms', 'GEOMETRY', 'GEO_CS_3785_SPHERICAL', 'USE_SPHERICAL', 3785);
If you specify a use_case
parameter value of USE_SPHERICAL
in such cases, the transformation defaults to using spherical math instead of ellipsoidal math, thereby accommodating Google Maps and some other thirdparty tools that use spherical math.
If you use this approach (specifying 'USE_SPHERICAL'
) but you have also declared an EPSG rule requiring that ellipsoidal math be used in transformations between two specified SRIDs, then the declared EPSG rule takes precedence and ellipsoidal math is used for transformations between those two SRIDs.
This section presents a simplified example that uses coordinate system transformation functions and procedures. It refers to concepts that are explained in this chapter and uses functions documented in Chapter 21.
Example 617 uses mostly the same geometry data (cola markets) as in Section 2.1, except that instead of null SDO_SRID values, the SDO_SRID value 8307 is used. That is, the geometries are defined as using the coordinate system whose SRID is 8307 and whose wellknown name is "Longitude / Latitude (WGS 84)". This is probably the most widely used coordinate system, and it is the one used for global positioning system (GPS) devices. The geometries are then transformed using the coordinate system whose SRID is 8199 and whose wellknown name is "Longitude / Latitude (Arc 1950)".
Example 617 uses the geometries illustrated in Figure 21 in Section 2.1, except that cola_d
is a rectangle (here, a square) instead of a circle, because arcs are not supported with geodetic coordinate systems.
Example 617 does the following:
Creates a table (COLA_MARKETS_CS) to hold the spatial data
Inserts rows for four areas of interest (cola_a
, cola_b
, cola_c
, cola_d
), using the SDO_SRID value 8307
Updates the USER_SDO_GEOM_METADATA view to reflect the dimension of the areas, using the SDO_SRID value 8307
Creates a spatial index (COLA_SPATIAL_IDX_CS)
Performs some transformation operations (single geometry and entire layer)
Example 618 includes the output of the SELECT statements in Example 617.
Example 617 Simplified Example of Coordinate System Transformation
 Create a table for cola (soft drink) markets in a  given geography (such as city or state). CREATE TABLE cola_markets_cs ( mkt_id NUMBER PRIMARY KEY, name VARCHAR2(32), shape SDO_GEOMETRY);  The next INSERT statement creates an area of interest for  Cola A. This area happens to be a rectangle.  The area could represent any userdefined criterion: for  example, where Cola A is the preferred drink, where  Cola A is under competitive pressure, where Cola A  has strong growth potential, and so on. INSERT INTO cola_markets_cs VALUES( 1, 'cola_a', SDO_GEOMETRY( 2003,  twodimensional polygon 8307,  SRID for 'Longitude / Latitude (WGS 84)' coordinate system NULL, SDO_ELEM_INFO_ARRAY(1,1003,1),  polygon SDO_ORDINATE_ARRAY(1,1, 5,1, 5,7, 1,7, 1,1)  All vertices must  be defined for rectangle with geodetic data. ) );  The next two INSERT statements create areas of interest for  Cola B and Cola C. These areas are simple polygons (but not  rectangles). INSERT INTO cola_markets_cs VALUES( 2, 'cola_b', SDO_GEOMETRY( 2003,  twodimensional polygon 8307, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1),  one polygon (exterior polygon ring) SDO_ORDINATE_ARRAY(5,1, 8,1, 8,6, 5,7, 5,1) ) ); INSERT INTO cola_markets_cs VALUES( 3, 'cola_c', SDO_GEOMETRY( 2003,  twodimensional polygon 8307, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1), one polygon (exterior polygon ring) SDO_ORDINATE_ARRAY(3,3, 6,3, 6,5, 4,5, 3,3) ) );  Insert a rectangle (here, square) instead of a circle as in the original,  because arcs are not supported with geodetic coordinate systems. INSERT INTO cola_markets_cs VALUES( 4, 'cola_d', SDO_GEOMETRY( 2003,  twodimensional polygon 8307,  SRID for 'Longitude / Latitude (WGS 84)' coordinate system NULL, SDO_ELEM_INFO_ARRAY(1,1003,1),  polygon SDO_ORDINATE_ARRAY(10,9, 11,9, 11,10, 10,10, 10,9)  All vertices must  be defined for rectangle with geodetic data. ) );   UPDATE METADATA VIEW    Update the USER_SDO_GEOM_METADATA view. This is required  before the Spatial index can be created. Do this only once for each  layer (tablecolumn combination; here: cola_markets_cs and shape). INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES ( 'cola_markets_cs', 'shape', SDO_DIM_ARRAY( SDO_DIM_ELEMENT('Longitude', 180, 180, 10),  10 meters tolerance SDO_DIM_ELEMENT('Latitude', 90, 90, 10)  10 meters tolerance ), 8307  SRID for 'Longitude / Latitude (WGS 84)' coordinate system );   CREATE THE SPATIAL INDEX   CREATE INDEX cola_spatial_idx_cs ON cola_markets_cs(shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX;   TEST COORDINATE SYSTEM TRANSFORMATION    Return the transformation of cola_c using to_srid 8199  ('Longitude / Latitude (Arc 1950)') SELECT c.name, SDO_CS.TRANSFORM(c.shape, 8199) FROM cola_markets_cs c WHERE c.name = 'cola_c';  Same as preceding, but using to_srname parameter. SELECT c.name, SDO_CS.TRANSFORM(c.shape, 'Longitude / Latitude (Arc 1950)') FROM cola_markets_cs c WHERE c.name = 'cola_c';  Transform the entire SHAPE layer and put results in the table  named cola_markets_cs_8199, which the procedure will create. CALL SDO_CS.TRANSFORM_LAYER('COLA_MARKETS_CS','SHAPE','COLA_MARKETS_CS_8199',8199);  Select all from the old (existing) table. SELECT * from cola_markets_cs;  Select all from the new (layer transformed) table. SELECT * from cola_markets_cs_8199;  Show metadata for the new (layer transformed) table. DESCRIBE cola_markets_cs_8199;  Use a geodetic MBR with SDO_FILTER. SELECT c.name FROM cola_markets_cs c WHERE SDO_FILTER(c.shape, SDO_GEOMETRY( 2003, 8307,  SRID for WGS 84 longitude/latitude NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(6,5, 10,10)) ) = 'TRUE';
Example 618 shows the output of the SELECT statements in Example 617. Notice the slight differences between the coordinates in the original geometries (SRID 8307) and the transformed coordinates (SRID 8199)  for example, (1, 1, 5, 1, 5, 7, 1, 7, 1, 1) and (1.00078604, 1.00274579, 5.00069354, 1.00274488, 5.0006986, 7.00323528, 1.00079179, 7.00324162, 1.00078604, 1.00274579) for cola_a
.
Example 618 Output of SELECT Statements in Coordinate System Transformation Example
SQL>  Return the transformation of cola_c using to_srid 8199 SQL>  ('Longitude / Latitude (Arc 1950)') SQL> SELECT c.name, SDO_CS.TRANSFORM(c.shape, 8199) 2 FROM cola_markets_cs c WHERE c.name = 'cola_c'; NAME  SDO_CS.TRANSFORM(C.SHAPE,8199)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM  cola_c SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482)) SQL> SQL>  Same as preceding, but using to_srname parameter. SQL> SELECT c.name, SDO_CS.TRANSFORM(c.shape, 'Longitude / Latitude (Arc 1950)') 2 FROM cola_markets_cs c WHERE c.name = 'cola_c'; NAME  SDO_CS.TRANSFORM(C.SHAPE,'LONGITUDE/LATITUDE(ARC1950)')(SDO_GTYPE, SDO_SRID, SDO  cola_c SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482)) SQL> SQL>  Transform the entire SHAPE layer and put results in the table SQL>  named cola_markets_cs_8199, which the procedure will create. SQL> CALL SDO_CS.TRANSFORM_LAYER('COLA_MARKETS_CS','SHAPE','COLA_MARKETS_CS_8199',8199); Call completed. SQL> SQL>  Select all from the old (existing) table. SQL> SELECT * from cola_markets_cs; MKT_ID NAME   SHAPE(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  1 cola_a SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(1, 1, 5, 1, 5, 7, 1, 7, 1, 1)) 2 cola_b SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1)) 3 cola_c MKT_ID NAME   SHAPE(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3, 3, 6, 3, 6, 5, 4, 5, 3, 3)) 4 cola_d SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(10, 9, 11, 9, 11, 10, 10, 10, 10, 9)) SQL> SQL>  Select all from the new (layer transformed) table. SQL> SELECT * from cola_markets_cs_8199; SDO_ROWID  GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  AAABZzAABAAAOa6AAA SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(1.00078604, 1.00274579, 5.00069354, 1.00274488, 5.0006986, 7.00323528, 1.0007 9179, 7.00324162, 1.00078604, 1.00274579)) AAABZzAABAAAOa6AAB SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(5.00069354, 1.00274488, 8.00062191, 1.00274427, 8.00062522, 6.00315345, 5.000 6986, 7.00323528, 5.00069354, 1.00274488)) SDO_ROWID  GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  AAABZzAABAAAOa6AAC SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.00074114, 3.00291482, 6.00067068, 3.00291287, 6.0006723, 5.00307625, 4.0007 1961, 5.00307838, 3.00074114, 3.00291482)) AAABZzAABAAAOa6AAD SDO_GEOMETRY(2003, 8199, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(10.0005802, 9.00337775, 11.0005553, 9.00337621, 11.0005569, 10.0034478, 10.00 SDO_ROWID  GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  05819, 10.0034495, 10.0005802, 9.00337775)) SQL> SQL>  Show metadata for the new (layer transformed) table. SQL> DESCRIBE cola_markets_cs_8199; Name Null? Type    SDO_ROWID ROWID GEOMETRY SDO_GEOMETRY SQL> SQL>  Use a geodetic MBR with SDO_FILTER SQL> SELECT c.name FROM cola_markets_cs c WHERE 2 SDO_FILTER(c.shape, 3 SDO_GEOMETRY( 4 2003, 5 8307,  SRID for WGS 84 longitude/latitude 6 NULL, 7 SDO_ELEM_INFO_ARRAY(1,1003,3), 8 SDO_ORDINATE_ARRAY(6,5, 10,10)) 9 ) = 'TRUE'; NAME  cola_c cola_b cola_d
The MDSYS.SDO_CSW_PROCESS package contains subprograms for various processing operations related to support for Catalog Services for the Web (CSW).
To use the subprograms in this chapter, you must understand the conceptual and usage information about Catalog Services for the Web in Chapter 16.
Table 221 lists the CSW processing subprograms.
Table 221 Subprograms for CSW Processing Operations
Subprogram  Description 

SDO_CSW_PROCESS.DeleteCapabilitiesInfo 
Deletes the capabilities information that had been set by the SDO_CSW_PROCESS.InsertCapabilitiesInfo procedure. 
SDO_CSW_PROCESS.DeleteDomainInfo 
Deletes domain information related to a record type. 
SDO_CSW_PROCESS.DeletePluginMap 
Unregisters a plugin for processing and extracting spatial content for a record type. 
SDO_CSW_PROCESS.DeleteRecordViewMap 
Deletes information related to record view transformation. 
SDO_CSW_PROCESS.GetRecordTypeId 
Gets the record type ID for a type (specified by namespace and type name). 
SDO_CSW_PROCESS.InsertCapabilitiesInfo 
Inserts the capabilities template information. 
SDO_CSW_PROCESS.InsertDomainInfo 
Inserts domain information related to a record type. 
SDO_CSW_PROCESS.InsertPluginMap 
Registers a plugin for processing and extracting spatial content for a record type. 
SDO_CSW_PROCESS.InsertRecordViewMap 
Inserts information related to record view transformation. 
SDO_CSW_PROCESS.InsertRtDataUpdated 
Inserts a notification that the data for a record type was updated in the database. 
SDO_CSW_PROCESS.InsertRtMDUpdated 
Inserts a notification that the metadata for a record type was updated in the database. 
The rest of this chapter provides reference information on the subprograms, listed in alphabetical order.
Description
Deletes the capabilities information that had been set by the SDO_CSW_PROCESS.InsertCapabilitiesInfo procedure.
Examples
The following example deletes the capabilities information that had been set by the SDO_CSW_PROCESS.InsertCapabilitiesInfo procedure.
BEGIN SDO_CSW_PROCESS.DeleteCapabilitiesInfo; END; /
Format
SDO_CSW_PROCESS.DeleteDomainInfo(
recordTypeId IN NUMBER,
propertyName IN VARCHAR2,
parameterName IN VARCHAR2);
Parameters
ID of the record type.
Name of the property.
Name of domain parameter to be deleted.
Examples
The following example deletes domain information about the resultType
parameter for a specified record type.
DECLARE rtId NUMBER; BEGIN rtId := sdo_csw_process.getRecordTypeId('http://www.opengis.net/cat/csw', 'Record'); sdo_csw_process.deleteDomainInfo(rtId, null, 'GetRecords.resultType'); END; /
Description
Unregisters a plugin for processing and extracting nonGML spatial content for a record type.
Parameters
Uniform resource locator of namespace of the record type.
Name of the record type.
Usage Notes
To register a plugin, which is a userdefined implementation of the extractSDO
function, use the SDO_CSW_PROCESS.InsertPluginMap procedure.
For information about creating and using the extractSDO
function, see Section 16.2.2.
For information about support for Catalog Services for the Web, see Chapter 16.
Format
SDO_CSW_PROCESS.DeleteRecordViewMap(
recordTypeNs IN VARCHAR2,
viewSrcName IN VARCHAR2,
targetTypeName IN VARCHAR2);
Parameters
XML document for the capabilities template, which is used at runtime to generate capabilities documents.
Usage Notes
At runtime, the capabilities document is dynamically generated by binding feature type information from the CSW metadata with the capabilities template. For information about capabilities documents, see Section 16.2.1.
For information about support for Catalog Services for the Web, see Chapter 16.
Format
SDO_CSW_PROCESS.InsertDomainInfo(
recordTypeId IN NUMBER,
propertyName IN VARCHAR2,
parameterName IN VARCHAR2,
pValue IN MDSYS.STRINGLIST);
Parameters
ID of the record type
Name of a domain property.
Name of a domain parameter
An array of strings containing parameter values for parameterName
. The MDSYS.STRINGLIST type is defined as VARRAY(1000000) OF VARCHAR2(4000)
.
Examples
The following example inserts domain information for the record type named Record
.
DECLARE rtId NUMBER; BEGIN rtId := SDO_CSW_PROCESS.getRecordTypeId( 'http://www.opengis.net/cat/csw', 'Record'); SDO_CSW_PROCESS.insertDomainInfo(rtId, null, 'GetRecords.resultType', MDSYS.STRINGLIST('hits', 'results', 'validate')); END; /
Format
SDO_CSW_PROCESS.InsertPluginMap(
rtnsUrl IN VARCHAR2,
rtName IN VARCHAR2,
pluginPackageName IN VARCHAR2);
Description
Registers a plugin for processing and extracting nonGML spatial content for a record type.
Parameters
Uniform resource locator of the namespace of the record type.
Name of the record type.
Name of the PL/SQL package object for the plugin.
Usage Notes
The plugin must contain the userdefined implementation of the extractSDO
function. A plugin is needed if the records are not in GML format. For detailed information about creating and using the extractSDO
function, see Section 16.2.2.
You must grant EXECUTE access on the plugin package (pluginPackageName
parameter) to user MDSYS and to the CSW administrative user.
For information about support for Catalog Services for the Web, see Chapter 16.
Format
SDO_CSW_PROCESS.InsertRecordViewMap(
recordTypeNs IN VARCHAR2,
viewSrcName IN VARCHAR2,
targetTypeName IN VARCHAR2,
mapInfo IN XMLTYPE,
mapType IN VARCHAR2);
Parameters
URL of the namespace of the record type.
Name of the source record type (for example, BriefRecord
, DCMIRecord
, Record
, or SummaryRecord
).
Name of the destination of the record type (for example, BriefRecord
, DCMIRecord
, Record
, or SummaryRecord
).
XSLT definition of the mapping. (See the comments in the example at the end of this section for a transformation from BriefRecord
type to Record
type.)
Map type (brief, summary, and so on)
Examples
The following example inserts information related to transformation from BriefRecord
type to Record
type.
create or replace directory CSWUSERDIR as 'dir_path_where_mapinfo.xsl_file_is_located' ; /* // Content of mapinfo.xsl could be that which transforms // all <csw:BriefRecord> node to <csw:Record> node, where csw is // the namespace alias for "http://www.opengis.net/cat/csw" <?xml version="1.0" encoding="UTF8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:csw="http://www.opengis.net/cat/csw"> <xsl:output method="xml" version="1.0" encoding="UTF8" indent="yes" /> <xsl:template match="/"> <csw:Record xmlns:csw="http://www.opengis.net/cat/csw" xmlns:dc="http://www.purl.org/dc/elements/1.1/" xmlns:ows="http://www.opengis.net/ows" xmlns:dct="http://www.purl.org/dc/terms/"> <xsl:applytemplates select="@*node()"/> </csw:Record> </xsl:template> <xsl:template match="csw:BriefRecord"> <xsl:applytemplates select="@*node()"/> </xsl:template> <xsl:template match="@*node()"> <xsl:copy> <xsl:applytemplates select="@*node()"/> </xsl:copy> </xsl:template> </xsl:stylesheet> */ DECLARE rtId NUMBER; BEGIN SDO_CSW_PROCESS.insertRecordViewMap('http://www.opengis.net/cat/csw', 'BriefRecord', 'Record', xmltype(bfilename('CSWUSERDIR', 'mapinfo.xsl'), nls_charset_id('AL32UTF8')), 'brief'); END; /
Format
SDO_CSW_PROCESS.InsertRtDataUpdated(
ns IN VARCHAR2,
name IN VARCHAR2,
updatedRowList IN ROWPOINTERLIST,
updateTs IN TIMESTAMP);
Parameters
Namespace of the record type.
Name of the record type.
List of rowids of rows that have been updated.
Timestamp value indicating when the data was updated.
Usage Notes
This procedure is used for CSW cache data synchronization. It queries the MDSYS.CSW_RECORD_TYPES$ system table.
For information about support for Catalog Services for the Web, see Chapter 16.
Examples
The following example inserts a notification for a specified record type that the data was updated for the rows associated with specific rowids.
BEGIN updatedRowIdList:= . . .  list of rowIds that have been updated  in the table referred to by the dataPointer column of the  mdsys.CSW_Record_Types$ table for the row whose  typeNameNS column value is 'http://www.opengis.net/cat/csw' and  typeName column value is 'Record' . . . SDO_CSW_PROCESS.insertRtDataUpdated('http://www.opengis.net/cat/csw', 'Record', updatedRowIdList, sysdate); . . . END; /
Parameters
Namespace of the record type.
Name of the record type.
Date and time when the metadata was updated.
Usage Notes
This procedure is used for WFS cache metadata synchronization.
For information about support for Catalog Services for the Web, see Chapter 16.
Developer's Guide
11g Release 2 (11.2)
E1183015
November 2013
Provides usage and reference information for indexing and storing spatial data and for developing spatial applications using Oracle Spatial and Graph and Oracle Locator.
Oracle Spatial Developer's Guide, 11g Release 2 (11.2)
E1183015
Copyright © 1999, 2013, Oracle and/or its affiliates. All rights reserved.
Primary Author: Chuck Murray
Contributors: Dan Abugov, Nicole Alexander, Bruce Blackwell, Raja Chatterjee, Dan Geringer, Mike Horhammer, Ying Hu, Baris Kazar, Ravi Kothuri, Siva Ravada, Jack Wang, Ji Yang
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be errorfree. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agencyspecific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate failsafe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to thirdparty content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of thirdparty content, products, or services.
After you have loaded spatial data (discussed in Chapter 4), you should create a spatial index on it to enable efficient query performance using the data. This chapter describes how to:
Create a spatial index (see Section 5.1)
Query spatial data efficiently, based on an understanding of the Oracle Spatial query model and primary and secondary filtering (see Section 5.2)
Once data has been loaded into the spatial tables through either bulk or transactional loading, a spatial index (that is, a spatial Rtree index) must be created on each geometry column in the tables for efficient access to the data. For example, the following statement creates a spatial index named territory_idx
using default values for all parameters:
CREATE INDEX territory_idx ON territories (territory_geom) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
For detailed information about options for creating a spatial index, see the documentation for the CREATE INDEX statement in Chapter 18.
If the index creation does not complete for any reason, the index is invalid and must be deleted with the DROP INDEX <index_name> [FORCE] statement.
Within each geometry column to be indexed, all the geometries must have the same SDO_SRID value.
Spatial indexes can be built on two, three, or four dimensions of data. The default number of dimensions is two, but if the data has more than two dimensions, you can use the sdo_indx_dims
parameter keyword to specify the number of dimensions on which to build the index. (For information about support for threedimensional geometries, see Section 1.11. For an explanation of support for various combinations of dimensionality in query elements, see Section 5.2.3.)
If you are not using the automatic undo management feature or the PGA memory management feature, or both, of Oracle Database, see Section 5.1.7 for information about initialization parameter values that you may need to set. Both automatic undo management and PGA memory management are enabled by default, and their use is highly recommended.
The tablespace specified with the tablespace
keyword in the CREATE INDEX statement (or the default tablespace if the tablespace
keyword is not specified) is used to hold both the index data table and some transient tables that are created for internal computations. If you specify WORK_TABLESPACE as the tablespace, the transient tables are stored in the work tablespace.
For large tables (over 1 million rows), a temporary tablespace may be needed to perform internal sorting operations. The recommended size for this temporary tablespace is 100*n bytes, where n is the number of rows in the table, up to a maximum requirement of 1 gigabyte of temporary tablespace.
To estimate the space that will be needed to create a spatial index, use the SDO_TUNE.ESTIMATE_RTREE_INDEX_SIZE function, described in Chapter 31.
When you create or rebuild a spatial index, you can ensure that all geometries that are in the table or that are inserted later are of a specified geometry type. To constrain the data to a geometry type in this way, use the layer_gtype
keyword in the PARAMETERS clause of the CREATE INDEX or ALTER INDEX REBUILD statement, and specify a value from the Geometry Type column of Table 21 in Section 2.2.1. For example, to constrain spatial data in a layer to polygons:
CREATE INDEX cola_spatial_idx ON cola_markets(shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=POLYGON');
The geometry types in Table 21 are considered as a hierarchy when data is checked:
The MULTI forms include the regular form also. For example, specifying 'layer_gtype=
MULTIPOINT'
allows the layer to include both POINT and MULTIPOINT geometries.
COLLECTION allows the layer to include all types of geometries.
You can create a spatial index on a table that is not in your schema. Assume that user B wants to create a spatial index on column GEOMETRY in table T1 under user A's schema. Follow these steps:
Connect to the database as a privileged user (for example, as SYSTEM), and execute the following statement:
GRANT create table, create sequence to B;
Connect as a privileged user or as user A (or have user A connect), and execute the following statement:
GRANT select, index on A.T1 to B;
Connect as user B and execute a statement such as the following:
CREATE INDEX t1_spatial_idx on A.T1(geometry) INDEXTYPE IS mdsys.spatial_index;
You can create a partitioned spatial index on a partitioned table. This section describes usage considerations specific to Oracle Spatial. For a detailed explanation of partitioned tables and partitioned indexes, see Oracle Database Administrator's Guide.
A partitioned spatial index can provide the following benefits:
Reduced response times for longrunning queries, because partitioning reduces disk I/O operations
Reduced response times for concurrent queries, because I/O operations run concurrently on each partition
Easier index maintenance, because of partitionlevel create and rebuild operations
Indexes on partitions can be rebuilt without affecting the queries on other partitions, and storage parameters for each local index can be changed independent of other partitions.
Parallel query on multiple partition searching
The degree of parallelism is the value from the DEGREE column in the row for the index in the USER_INDEXES view (that is, the value specified or defaulted for the PARALLEL keyword with the CREATE INDEX, ALTER INDEX, or ALTER INDEX REBUILD statement).
Improved query processing in multiprocessor system environments
In a multiprocessor system environment, if a spatial operator is invoked on a table with partitioned spatial index and if multiple partitions are involved in the query, multiple processors can be used to evaluate the query. The number of processors used is determined by the degree of parallelism and the number of partitions used in evaluating the query.
The following restrictions apply to spatial index partitioning:
The partition key for spatial tables must be a scalar value, and must not be a spatial column.
Only range partitioning is supported on the underlying table. All other kinds of partitioning are not currently supported for partitioned spatial indexes.
To create a partitioned spatial index, you must specify the LOCAL keyword. (If you do not specify the LOCAL keyword, a nonpartitioned spatial index is created on the data in all table partitions.) The following example creates a partitioned spatial index:
CREATE INDEX counties_idx ON counties(geometry) INDEXTYPE IS MDSYS.SPATIAL_INDEX LOCAL;
In this example, the default values are used for the number and placement of index partitions, namely:
Index partitioning is based on the underlying table partitioning. For each table partition, a corresponding index partition is created.
Each index partition is placed in the default tablespace.
If you do specify parameters for individual partitions, the following considerations apply:
The storage characteristics for each partition can be the same or different for each partition. If they are different, it may enable parallel I/O (if the tablespaces are on different disks) and may improve performance.
The sdo_indx_dims
value must be the same for all partitions.
The layer_gtype
parameter value (see Section 5.1.1) used for each partition may be different.
To override the default partitioning values, use a CREATE INDEX statement with the following general format:
CREATE INDEX <indexname> ON <table>(<column>) INDEXTYPE IS MDSYS.SPATIAL_INDEX [PARAMETERS ('<spatialparams>, <storageparams>')] LOCAL [( PARTITION <index_partition> PARAMETERS ('<spatialparams>, <storageparams>') [, PARTITION <index_partition> PARAMETERS ('<spatialparams>, <storageparams>')] )]
Queries can operate on partitioned tables to perform the query on only one partition. For example:
SELECT * FROM counties PARTITION(p1) WHERE ...<somespatialpredicate>;
Querying on a selected partition may speed up the query and also improve overall throughput when multiple queries operate on different partitions concurrently.
When queries use a partitioned spatial index, the semantics (meaning or behavior) of spatial operators and functions is the same with partitioned and nonpartitioned indexes, except in the case of SDO_NN (nearest neighbor). With SDO_NN, the requested number of geometries is returned for each partition that is affected by the query. (See the description of the SDO_NN operator in Chapter 19 for more information.)
For example, if you request the 5 closest restaurants to a point and the spatial index has 4 partitions, SDO_NN returns up to 20 (5*4) geometries. In this case, you must use the ROWNUM pseudocolumn (here, WHERE ROWNUM <=5
) to return the 5 closest restaurants, and the ORDER BY clause to sort the results by distance in miles. Example 51 returns the 5 nearest restaurants from a partitioned spatial index.
Example 51 SDO_NN Query with Partitioned Spatial Index
SELECT * FROM ( SELECT r.name, r.location, SDO_NN_DISTANCE(1) distance_in_miles FROM restaurants_part_table r WHERE SDO_NN(r.location, MDSYS.SDO_GEOMETRY(2001,8307,MDSYS.SDO_POINT_TYPE(110,35,Null),Null,Null), 'SDO_NUM_RES=5 distance=2 unit=MILE', 1) = 'TRUE' ORDER BY distance_in_miles ) WHERE ROWNUM<=5;
For a crossschema query when a table has a partitioned spatial index, the user must be granted SELECT privilege on both the spatial table and the index table (MDRT_xxx) for the spatial index that was created on the spatial table. For more information and an example, see "CrossSchema Invocation of SDO_JOIN" in the Usage Notes for the SDO_JOIN operator in Chapter 19.
If you want to create a local partitioned spatial index, Oracle recommends that you use the procedure in this section instead of using the PARALLEL keyword, to avoid having to start over if the creation of any partition's index fails for any reason (for example, because the tablespace is full). Follow these steps:
Create a local spatial index and specify the UNUSABLE keyword. For example:
CREATE INDEX sp_idx ON my_table (location)
INDEXTYPE IS mdsys.spatial_index
PARAMETERS ('tablespace=tb_name work_tablespace=work_tb_name')
LOCAL UNUSABLE;
This statement executes quickly and creates metadata associated with the index.
Create scripts with ALTER INDEX REBUILD statements, but without the PARALLEL keyword. For example, if you have 100 partitions and 10 processors, create 10 scripts with 10 ALTER INDEX statements such as the following:
ALTER INDEX sp_idx REBUILD PARTITION ip1; ALTER INDEX sp_idx REBUILD PARTITION ip2; . . . ALTER INDEX sp_idx REBUILD PARTITION ip10;
Run all the scripts at the same time, so that each processor works on the index for a single partition, but all the processors are busy working on their own set of ALTER INDEX statements.
If any of the ALTER INDEX statements fails, you do not need to rebuild any partitions for which the operation has successfully completed.
You can use the ALTER TABLE statement with the EXCHANGE PARTITION ... INCLUDING INDEXES clause to exchange a spatial table partition and its index partition with a corresponding table and its index. For information about exchanging partitions, see the description of the ALTER TABLE statement in Oracle Database SQL Language Reference.
This feature can help you to operate more efficiently in a number of situations, such as:
Bringing data into a partitioned table and avoiding the cost of index recreation.
Managing and creating partitioned indexes. For example, the data could be divided into multiple tables. The index for each table could be built one after the other to minimize the memory and tablespace resources needed during index creation. Alternately, the indexes could be created in parallel in multiple sessions. The tables (along with the indexes) could then be exchanged with the partitions of the original data table.
Managing offline insert operations. New data can be stored in a temporary table and periodically exchanged with a new partition (for example, in a database with historical data).
To exchange partitions including indexes with spatial data and indexes, the two spatial indexes (one on the partition, the other on the table) must have the same dimensionality (sdo_indx_dims
value). If the indexes do not have the same dimensionality, an error is raised. The table data is exchanged, but the indexes are not exchanged and the indexes are marked as failed. To use the indexes, you must rebuild them
If you use the Export utility to export tables with spatial data, the behavior of the operation depends on whether or not the spatial data has been spatially indexed:
If the spatial data has not been spatially indexed, the table data is exported. However, you must update the USER_SDO_GEOM_METADATA view with the appropriate information on the target system.
If the spatial data has been spatially indexed, the table data is exported, the appropriate information is inserted into the USER_SDO_GEOM_METADATA view on the target system, and the spatial index is built on the target system. However, if the insertion into the USER_SDO_GEOM_METADATA view fails (for example, if there is already a USER_SDO_GEOM_METADATA entry for the spatial layer), the spatial index is not built.
If you use the Import utility to import data that has been spatially indexed, the following considerations apply:
If the index on the exported data was created with a TABLESPACE
clause and if the specified tablespace does not exist in the database at import time, the index is not built. (This is different from the behavior with other Oracle indexes, where the index is created in the user's default tablespace if the tablespace specified for the original index does not exist at import time.)
If the import operation must be done by a privileged database user, and if the FROMUSER
and TOUSER
format is used, the TOUSER
user must be granted the CREATE TABLE and CREATE SEQUENCE privileges before the import operation, as shown in the following example (and enter the password for the SYSTEM account when prompted):
sqlplus system SQL> grant CREATE TABLE, CREATE SEQUENCE to CHRIS; SQL> exit; imp system file=spatl_data.dmp fromuser=SCOTT touser=CHRIS
For information about using the Export and Import utilities, see Oracle Database Utilities.
In a distributed transaction, different branches of the transaction can execute in different sessions. The branches can detach from their current session and migrate to another within the transaction scope. To maintain the consistency of Spatial indexes in distributed transactions, you must follow the usage guidelines in this section.
When the first insert, update, or delete operation on a spatial table (one with a spatial index) is performed in a distributed transaction, all subsequent insert, update, or delete operations on the table, as well as any prepare to commit operation (the first branch to prepare a commit), in the transaction should happen in the same session as the first operation. The branches performing these subsequent operations will first have to connect to the session in which the first operation was performed.
For more information about distributed transactions, see Oracle Database Administrator's Guide.
This section applies only if you (or the database administrator) are not using the automatic undo management feature or the PGA memory management feature, or both, of Oracle Database. Automatic memory management and PGA memory management are enabled by default, and their use is highly recommended. For explanations of these features, see:
The section about automatic undo management and undo segments in Oracle Database Concepts
The section about PGA memory management in Oracle Database Concepts
If you are not using automatic undo management and if the rollback segment is not large enough, an attempt to create a spatial index will fail. The rollback segment should be 100*n bytes, where n is the number of rows of data to be indexed. For example, if the table contains 1 million (1,000,000) rows, the rollback segment size should be 100,000,000 (100 million) bytes.
To ensure an adequate rollback segment, or if you have tried to create a spatial index and received an error that a rollback segment cannot be extended, review (or have a DBA review) the size and structure of the rollback segments. Create a public rollback segment of the appropriate size, and place that rollback segment online. In addition, ensure that any small inappropriate rollback segments are placed offline during large spatial index operations.
If you are not using the PGA memory management feature, the system parameter SORT_AREA_SIZE affects the amount of time required to create the index. The SORT_AREA_SIZE value is the maximum amount, in bytes, of memory to use for a sort operation. The optimal value depends on the database size, but a good guideline is to make it at least 1 million bytes when you create a spatial index. To change the SORT_AREA_SIZE value, use the ALTER SESSION statement. For example, to change the value to 20 million bytes:
ALTER SESSION SET SORT_AREA_SIZE = 20000000;
This section describes how the structures of a Spatial layer are used to resolve spatial queries and spatial joins.
Spatial uses a twotier query model with primary and secondary filter operations to resolve spatial queries and spatial joins, as explained in Section 1.6. The term twotier indicates that two distinct operations are performed to resolve queries. If both operations are performed, the exact result set is returned.
You cannot append a database link (dblink) name to the name of a spatial table in a query if a spatial index is defined on that table.
In a spatial Rtree index, each geometry is represented by its minimum bounding rectangle (MBR), as explained in Section 1.7.1. Consider the following layer containing several objects in Figure 51. Each object is labeled with its geometry name (geom_1 for the line string, geom_2 for the foursided polygon, geom_3 for the triangular polygon, and geom_4 for the ellipse), and the MBR around each object is represented by a dashed line.
A typical spatial query is to request all objects that lie within a query window, that is, a defined fence or window. A dynamic query window refers to a rectangular area that is not defined in the database, but that must be defined before it is used. Figure 52 shows the same geometries as in Figure 51, but adds a query window represented by the heavy dottedline box.
In Figure 52, the query window covers parts of geometries geom_1 and geom_2, as well as part of the MBR for geom_3 but none of the actual geom_3 geometry. The query window does not cover any part of the geom_4 geometry or its MBR.
The SDO_FILTER operator, described in Chapter 19, implements the primary filter portion of the twostep process involved in the Oracle Spatial query processing model. The primary filter uses the index data to determine only if a set of candidate object pairs may interact. Specifically, the primary filter checks to see if the MBRs of the candidate objects interact, not whether the objects themselves interact. The SDO_FILTER operator syntax is as follows:
SDO_FILTER(geometry1 SDO_GEOMETRY, geometry2 SDO_GEOMETRY, param VARCHAR2)
In the preceding syntax:
geometry1
is a column of type SDO_GEOMETRY in a table. This column must be spatially indexed.
geometry2
is an object of type SDO_GEOMETRY. This object may or may not come from a table. If it comes from a table, it may or may not be spatially indexed.
param
is an optional string of type VARCHAR2. It can specify either or both of the min_resolution
and max_resolution
keywords.
The following examples perform a primary filter operation only (with no secondary filter operation). They will return all the geometries shown in Figure 52 that have an MBR that interacts with the query window. The result of the following examples are geometries geom_1, geom_2, and geom_3.
Example 52 performs a primary filter operation without inserting the query window into a table. The window will be indexed in memory and performance will be very good.
Example 52 Primary Filter with a Temporary Query Window
SELECT A.Feature_ID FROM TARGET A WHERE sdo_filter(A.shape, SDO_geometry(2003,NULL,NULL, SDO_elem_info_array(1,1003,3), SDO_ordinate_array(x1,y1, x2,y2)) ) = 'TRUE';
In Example 52, (x1,y1)
and (x2,y2)
are the lowerleft and upperright corners of the query window.
In Example 53, a transient instance of type SDO_GEOMETRY was constructed for the query window instead of specifying the window parameters in the query itself.
Example 53 Primary Filter with a Transient Instance of the Query Window
SELECT A.Feature_ID FROM TARGET A WHERE sdo_filter(A.shape, :theWindow) = 'TRUE';
Example 54 assumes the query window was inserted into a table called WINDOWS, with an ID of WINS_1.
Example 54 Primary Filter with a Stored Query Window
SELECT A.Feature_ID FROM TARGET A, WINDOWS B WHERE B.ID = 'WINS_1' AND sdo_filter(A.shape, B.shape) = 'TRUE';
If the B.SHAPE column is not spatially indexed, the SDO_FILTER operator indexes the query window in memory and performance is very good.
The SDO_RELATE operator, described in Chapter 19, performs both the primary and secondary filter stages when processing a query. The secondary filter ensures that only candidate objects that actually interact are selected. This operator can be used only if a spatial index has been created on two dimensions of data. The syntax of the SDO_RELATE operator is as follows:
SDO_RELATE(geometry1 SDO_GEOMETRY, geometry2 SDO_GEOMETRY, param VARCHAR2)
In the preceding syntax:
geometry1
is a column of type SDO_GEOMETRY in a table. This column must be spatially indexed.
geometry2
is an object of type SDO_GEOMETRY. This object may or may not come from a table. If it comeAҾs from a table, it may or may not be spatially indexed.
param
is a quoted string with the mask
keyword and a valid mask value, and optionally either or both of the min_resolution
and max_resolution
keywords, as explained in the documentation for the SDO_RELATE operator in Chapter 19.
The following examples perform both primary and secondary filter operations. They return all the geometries in Figure 52 that lie within or overlap the query window. The result of these examples is objects geom_1 and geom_2.
Example 55 performs both primary and secondary filter operations without inserting the query window into a table. The window will be indexed in memory and performance will be very good.
Example 55 Secondary Filter Using a Temporary Query Window
SELECT A.Feature_ID FROM TARGET A WHERE sdo_relate(A.shape, SDO_geometry(2003,NULL,NULL, SDO_elem_info_array(1,1003,3), SDO_ordinate_array(x1,y1, x2,y2)), 'mask=anyinteract') = 'TRUE';
In Example 55, (x1,y1)
and (x2,y2)
are the lowerleft and upperright corners of the query window.
Example 56 assumes the query window was inserted into a table called WINDOWS, with an ID value of WINS_1.
Example 56 Secondary Filter Using a Stored Query Window
SELECT A.Feature_ID FROM TARGET A, WINDOWS B WHERE B.ID = 'WINS_1' AND sdo_relate(A.shape, B.shape, 'mask=anyinteract') = 'TRUE';
If the B.SHAPE column is not spatially indexed, the SDO_RELATE operator indexes the query window in memory and performance is very good.
The SDO_WITHIN_DISTANCE operator, described in Chapter 19, is used to determine the set of objects in a table that are within n distance units from a reference object. This operator can be used only if a spatial index has been created on two dimensions of data. The reference object may be a transient or persistent instance of SDO_GEOMETRY, such as a temporary query window or a permanent geometry stored in the database. The syntax of the operator is as follows:
SDO_WITHIN_DISTANCE(geometry1 SDO_GEOMETRY, aGeom SDO_GEOMETRY, params VARCHAR2);
In the preceding syntax:
geometry1
is a column of type SDO_GEOMETRY in a table. This column must be spatially indexed.
aGeom
is an instance of type SDO_GEOMETRY.
params
is a quoted string of keyword value pairs that determines the behavior of the operator. See the SDO_WITHIN_DISTANCE operator in Chapter 19 for a list of parameters.
The following example selects any objects within 1.35 distance units from the query window:
SELECT A.Feature_ID FROM TARGET A WHERE SDO_WITHIN_DISTANCE( A.shape, :theWindow, 'distance=1.35') = 'TRUE';
The distance units are based on the geometry coordinate system in use. If you are using a geodetic coordinate system, the units are meters. If no coordinate system is used, the units are the same as for the stored data.
The SDO_WITHIN_DISTANCE operator is not suitable for performing spatial joins. That is, a query such as Find all parks that are within 10 distance units from coastlines will not be processed as an indexbased spatial join of the COASTLINES and PARKS tables. Instead, it will be processed as a nested loop query in which each COASTLINES instance is in turn a reference object that is buffered, indexed, and evaluated against the PARKS table. Thus, the SDO_WITHIN_DISTANCE operation is performed n times if there are n rows in the COASTLINES table.
For nongeodetic data, there is an efficient way to accomplish a spatial join that involves buffering all geometries of a layer. This method does not use the SDO_WITHIN_DISTANCE operator. First, create a new table COSINE_BUFS as follows:
CREATE TABLE cosine_bufs UNRECOVERABLE AS SELECT SDO_BUFFER (A.SHAPE, B.DIMINFO, 1.35) FROM COSINE A, USER_SDO_GEOM_METADATA B WHERE TABLE_NAME='COSINES' AND COLUMN_NAME='SHAPE';
Next, create a spatial index on the SHAPE column of COSINE_BUFS. Then you can perform the following query:
SELECT /*+ ordered */ a.gid, b.gid FROM TABLE(SDO_JOIN('PARKS', 'SHAPE', 'COSINE_BUFS', 'SHAPE', 'mask=ANYINTERACT')) c, parks a, cosine_bufs b WHERE c.rowid1 = a.rowid AND c.rowid2 = b.rowid;
The SDO_NN operator, described in Chapter 19, is used to identify the nearest neighbors for a geometry. This operator can be used only if a spatial index has been created on two dimensions of data. The syntax of the operator is as follows:
SDO_NN(geometry1 SDO_GEOMETRY, geometry2 SDO_GEOMETRY, param VARCHAR2 [, number NUMBER]);
In the preceding syntax:
geometry1
is a column of type SDO_GEOMETRY in a table. This column must be spatially indexed.
geometry2
is an instance of type SDO_GEOMETRY.
param
is a quoted string of keywordvalue pairs that can determine the behavior of the operator, such as how many nearest neighbor geometries are returned. See the SDO_NN operator in Chapter 19 for information about this parameter.
number
is the same number used in the call to SDO_NN_DISTANCE. Use this only if the SDO_NN_DISTANCE ancillary operator is included in the call to SDO_NN. See the SDO_NN operator in Chapter 19 for information about this parameter.
The following example finds the two objects from the SHAPE column in the COLA_MARKETS table that are closest to a specified point (10,7). (Note the use of the optimizer hint in the SELECT statement, as explained in the Usage Notes for the SDO_NN operator in Chapter 19.)
SELECT /*+ INDEX(cola_markets cola_spatial_idx) */ c.mkt_id, c.name FROM cola_markets c WHERE SDO_NN(c.shape, SDO_geometry(2001, NULL, SDO_point_type(10,7,NULL), NULL, NULL), 'sdo_num_res=2') = 'TRUE';
Spatial also supplies functions for determining relationships between geometries, finding information about single geometries, changing geometries, and combining geometries. These functions all take into account two dimensions of source data. If the output value of these functions is a geometry, the resulting geometry will have the same dimensionality as the input geometry, but only the first two dimensions will accurately reflect the result of the operation.
A spatial join is the same as a regular join except that the predicate involves a spatial operator. In Spatial, a spatial join takes place when you compare all geometries of one layer to all geometries of another layer. This is unlike a query window, which compares a single geometry to all geometries of a layer.
Spatial joins can be used to answer questions such as Which highways cross national parks?
The following table structures illustrate how the join would be accomplished for this example:
PARKS( GID VARCHAR2(32), SHAPE SDO_GEOMETRY) HIGHWAYS( GID VARCHAR2(32), SHAPE SDO_GEOMETRY)
To perform a spatial join, use the SDO_JOIN operator, which is described in Chapter 19. The following spatial join query, to list the GID column values of highways and parks where a highway interacts with a park, performs a primary filter operation only ('mask=FILTER'
), and thus it returns only approximate results:
SELECT /*+ ordered */ a.gid, b.gid FROM TABLE(SDO_JOIN('PARKS', 'SHAPE', 'HIGHWAYS', 'SHAPE', 'mask=FILTER')) c, parks a, highways b WHERE c.rowid1 = a.rowid AND c.rowid2 = b.rowid;
The following spatial join query requests the same information as in the preceding example, but it performs both primary and secondary filter operations ('mask=ANYINTERACT'
), and thus it returns exact results:
SELECT /*+ ordered */ a.gid, b.gid FROM TABLE(SDO_JOIN('PARKS', 'SHAPE', 'HIGHWAYS', 'SHAPE', 'mask=ANYINTERACT')) c, parks a, highways b WHERE c.rowid1 = a.rowid AND c.rowid2 = b.rowid;
The elements of a spatial query can, in theory, have the following dimensionality:
The base table geometries (or geometry1
in Spatial operator formats) can have two, three, or more dimensions.
The spatial index created on the base table (or geometry1
) can be twodimensional or threedimensional.
The query window (or geometry2
in Spatial operator formats) can have two, three, or more dimensions.
Some combinations of dimensionality among the three elements are supported and some are not. Table 51 explains what happens with the possible combinations involving two and three dimensions.
Table 51 Data and Index Dimensionality, and Query Support
Base Table (geometry1) Dimensionality  Spatial Index Dimensionality  Query Window (geometry2) Dimensionality  Query Result 

2dimensional 
2dimensional 
2dimensional 
Performs a twodimensional query. 
2dimensional 
2dimensional 
3dimensional 
Supported if the query window has an appropriate SDO_GTYPE value less than 3008. 
2dimensional 
3dimensional 
2dimensional 
Not supported: 3D index not permitted on 2D data. 
2dimensional 
3dimensional 
3dimensional 
Not supported: 3D index not permitted on 2D data. 
3dimensional 
2dimensional 
2dimensional 
Ignores the third (Z) dimension in each base geometry and performs a twodimensional query. 
3dimensional 
2dimensional 
3dimensional 
Supported if the query window has an appropriate SDO_GTYPE value less than 3008. 
3dimensional 
3dimensional 
2dimensional 
Converts the 2D query window to a 3D window with zero Z values and performs a threedimensional query. 
3dimensional 
3dimensional 
3dimensional 
Performs a threedimensional query. 
The MDSYS.SDO_SAM package contains subprograms for spatial analysis and data mining.
To use the subprograms in this chapter, you must understand the conceptual information about spatial analysis and data mining in Chapter 8.
Note: SDO_SAM subprograms are supported for twodimensional geometries only. They are not supported for threedimensional geometries. 
Table 291 lists the spatial analysis and mining subprograms.
Table 291 Subprograms for Spatial Analysis and Mining
Function  Description 

SDO_SAM.AGGREGATES_FOR_GEOMETRY 
Computes the thematic aggregate for a geometry. 

Computes thematic aggregates for a layer of geometries. 

Computes the mostintersecting tile for a geometry. 

Assigns each location (and the corresponding row) in a data mining table to a spatial bin. 
SDO_SAM.COLOCATED_REFERENCE_FEATURES 
Performs a partial predicatebased join of tables, and materializes the join results into a table. 

Simplifies a geometry. 

Simplifies a geometry layer. 

Computes clusters using the existing Rtree index, and returns a set of SDO_REGION objects where the geometry column specifies the boundary of each cluster and the 

Tiles aggregates for a domain. For each tile, computes the intersecting geometries from the theme table; the values in the 

Tiles a twodimensional space and returns geometries corresponding to those tiles. 
The rest of this chapter provides reference information on the spatial analysis and mining subprograms, listed in alphabetical order.
Format
SDO_SAM.AGGREGATES_FOR_GEOMETRY(
theme_name IN VARCHAR2,
theme_colname IN VARCHAR2,
aggr_type_string IN VARCHAR2,
aggr_col_string IN VARCHAR2,
geom IN SDO_GEOMETRY,
dst_spec IN VARCHAR2 DEFAULT NULL
) RETURN NUMBER;
Parameters
Name of the theme table.
Name of the geometry column in theme_name
.
Any Oracle SQL aggregate function that accepts one or more numeric values and computes a numeric value, such as SUM
, MIN
, MAX
, or AVG
.
Name of a column in theme_name
on which to compute aggregate values, as explained in the Usage Notes. An example might be a POPULATION column.
Geometry object.
A quoted string specifying either a distance buffer or a number of nearest neighbor geometries to consider. See the Usage Notes for an explanation of the format and meaning.
Usage Notes
For a specific geometry, this function identifies the geometries in the theme_name
table, finds their intersection ratio, multiplies the specified aggregate using this intersection ratio, and aggregates it for the geometry. Specifically, for all rows of the theme_name
table that intersect with the specified geometry, it returns the value from the following function:
aggr_type_string(aggr_col_string * proportional_area_of_intersection(geometry, theme_name.theme_colname))
The theme_colname
column must have a spatial index defined on it. For best performance, insert simplified geometries into this column.
The dst_spec
parameter, if specified, is a quoted string that must contain either of the following:
The distance
keyword and optionally the unit
keyword (unit of measurement associated with the distance value), to specify a buffer around the geometry. For example, 'distance=2 unit=km'
specifies a 2kilometer buffer around the input geometry. If dst_spec
is not specified, no buffer is used.
If the unit
keyword is specified, the value must be an SDO_UNIT value from the MDSYS.SDO_DIST_UNITS table (for example, 'unit=km'
). If the unit
keyword is not specified, the unit of measurement associated with the geometry is used. See Section 2.10 for more information about unit of measurement specification.
The sdo_num_res
keyword, to specify the number of nearestneighbor geometries to consider, without considering proportional coverage. For example, 'sdo_num_res=5'
could be used in a query that asks for the populations of the five cities that are nearest to a specified point.
Examples
The following example computes the thematic aggregate for an area with a 3mile radius around a specified point geometry. In this case, the total population of the area is computed based on the proportion of the circle's area within different counties, assuming uniform distribution of population within the counties.
SELECT sdo_sam.aggregates_for_geometry( 'GEOD_COUNTIES', 'GEOM', 'sum', 'totpop', SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(73.943849, 40.6698,NULL), NULL, NULL), 'distance=3 unit=mile') FROM DUAL a ;
Format
SDO_SAM.AGGREGATES_FOR_LAYER(
theme_name IN VARCHAR2,
theme_colname IN VARCHAR2,
aggr_type_string IN VARCHAR2,
aggr_col_string IN VARCHAR2,
tablename IN VARCHAR2,
colname IN VARCHAR2,
dst_spec IN VARCHAR2 DEFAULT NULL
) RETURN SDO_REGAGGRSET;
Parameters
Name of the theme table.
Name of the geometry column in theme_name
.
Any Oracle SQL aggregate function that accepts one or more numeric values and computes a numeric value, such as SUM
, MIN
, MAX
, or AVG
.
Name of a column in theme_name
on which to compute aggregate values, as explained in the Usage Notes. An example might be a POPULATION column.
Name of the data mining table.
Name of the column in tablename
that holds the geometries.
A quoted string specifying either a distance buffer or a number of nearest neighbor geometries to consider. See the Usage Notes for the SDO_SAM.AGGREGATES_FOR_GEOMETRY function in this chapter for an explanation of the format and meaning.
Usage Notes
For each geometry in tablename
, this function identifies the geometries in the theme_name
table, finds their intersection ratio, multiplies the specified aggregate using this intersection ratio, and aggregates it for each geometry in tablename
. Specifically, for all rows of the theme_name
table, it returns the value from the following function:
aggr_type_string(aggr_col_string * proportional_area_of_intersection(geometry, theme_name.theme_colname))
This function returns an object of type SDO_REGAGGRSET. The SDO_REGAGGRSET object type is defined as:
TABLE OF SDO_REGAGGR
The SDO_REGAGGR object type is defined as:
Name Null? Type    REGION_ID VARCHAR2(24) GEOMETRY MDSYS.SDO_GEOMETRY AGGREGATE_VALUE NUMBER
The theme_colname
column must have a spatial index defined on it. For best performance, insert simplified geometries into this column.
Examples
The following example computes the thematic aggregates for all geometries in a table named TEST_TAB for an area with a 3mile radius around a specified point geometry. In this case, the total population of each area is computed based on the proportion of the circle's area within different counties, assuming uniform distribution of population within the counties.
SELECT a.aggregate_value FROM TABLE(sdo_sam.aggregates_for_layer( 'GEOD_COUNTIES', 'GEOM', 'SUM', TOTPOP', TEST_TAB', 'GEOM' 'distance=3 unit=mile')) a;
Format
SDO_SAM.BIN_GEOMETRY(
geom IN SDO_GEOMETRY,
tol IN SDO_DIM_ARRAY,
bin_tablename IN VARCHAR2,
bin_colname IN VARCHAR2
) RETURN NUMBER;
or
SDO_SAM.BIN_GEOMETRY(
geom IN SDO_GEOMETRY,
dim IN SDO_DIM_ARRAY,
bin_tablename IN VARCHAR2,
bin_colname IN VARCHAR2
) RETURN NUMBER;
Parameters
Geometry for which to compute the bin.
Tolerance value (see Section 1.5.5).
Dimensional array for the table that holds the geometries for the bins.
Name of the table that holds the geometries for the bins.
Column in bin_tablename
that holds the geometries for the bins.
Usage Notes
This function returns the bin that intersects most with the specified geometry. If multiple bins intersect to the same extent with the specified geometry, the bin with the smallest area is returned.
To perform this operation on all rows in the data mining table, using the specified bin_tablename
, you can use the SDO_SAM.BIN_LAYER procedure.
Examples
The following example computes the bin for a specified geometry.
SELECT sdo_sam.bin_geometry(a.geometry, 0.0000005, 'BINTBL', 'GEOMETRY') FROM poly_4pt a, user_sdo_geom_metadata b WHERE b.table_name='POLY_4PT' AND a.gid=1; SDO_SAM.BIN_GEOMETRY(A.GEOMETRY,0.0000005,'BINTBL','GEOMETRY')  43 1 row selected.
Format
SDO_SAM.BIN_LAYER(
tablename IN VARCHAR2,
colname IN VARCHAR2,
bin_tablename IN VARCHAR2,
bin_colname IN VARCHAR2,
bin_id_colname IN VARCHAR2,
commit_interval IN NUMBER DEFAULT 20);
Description
Assigns each location (and the corresponding row) in a data mining table to a spatial bin.
Parameters
Name of the data mining table.
Name of the column in table_name
that holds the location coordinates.
Name of the table that contains information (precomputed for the entire twodimensional space) about the spatial bins.
Column in bin_tablename
that holds the geometries for the bins.
Name of the column in the data mining table that holds the bin ID value of each geometry added to a bin. (Each affected row in the data mining table is updated with the ID value of the bin geometry in bin_tablename
.)
Number of bin insert operations to perform before Spatial performs an internal commit operation. If commit_interval
is not specified, a commit is performed after every 20 insert operations.
Usage Notes
This procedure computes the mostintersecting tile for each geometry in a specified layer using the bins in bin_tablename
. The bin ID value for each geometry is added in bin_id_colname
.
Using this procedure achieves the same result as using the SDO_SAM.BIN_GEOMETRY function on each row in the data mining table, using the specified bin_tablename
.
Examples
The following example assigns each GEOMETRY column location and corresponding row in the POLY_4PT_TEMP data mining table to a spatial bin, and performs an internal commit operation after each bin table insertion.
CALL SDO_SAM.BIN_LAYER('POLY_4PT_TEMP', 'GEOMETRY', 'BINTBL', 'GEOMETRY', 'BIN_ID', 1);
Format
SDO_SAM.COLOCATED_REFERENCE_FEATURES(
theme_tablename IN VARCHAR2,
theme_colname IN VARCHAR2,
theme_predicate IN VARCHAR2,
tablename IN VARCHAR2,
colname IN VARCHAR2,
ref_predicate IN VARCHAR2,
dst_spec IN VARCHAR2,
result_tablename IN VARCHAR2,
commit_interval IN NUMBER DEFAULT 100);
Description
Performs a partial predicatebased join of tables, and materializes the join results into a table.
Parameters
Name of the table with which to join tablename
.
Name of the geometry column in theme_tablename
.
Qualifying WHERE clause predicate to be applied to theme_tablename
.
Name of the data mining table.
Name of the column in tablename
that holds the location coordinates.
Qualifying WHERE clause predicate to be applied to tablename
. Must be a single table predicate, such as 'country_code=10'.
A quoted string containing a distance value and optionally a unit value for a buffer around the geometries. See the Usage Notes for an explanation of the format and meaning.
The table in which materialized join results are stored. This table must have the following definition: (tid NUMBER, rid1 VARCHAR2(24), rid2 VARCHAR2(24))
Number of internal join operations to perform before Spatial performs an internal commit operation. If commit_interval
is not specified, a commit is performed after every 100 internal join operations.
Usage Notes
This procedure materializes each pair of rowids returned from a predicatebased join operation, and stores them in the rid1, rid2
columns of result_tablename
. The tid
is a unique generated "interaction" number corresponding to each rid1
value.
The dst_spec
parameter, if specified, is a quoted string containing the distance
keyword and optionally the unit
keyword (unit of measurement associated with the distance value), to specify a buffer around the geometry. For example, 'distance=2 unit=km'
specifies a 2kilometer buffer around the input geometry. If dst_spec
is not specified, no buffer is used.
If the unit
keyword is specified, the value must be an SDO_UNIT value from the MDSYS.SDO_DIST_UNITS table (for example, 'unit=KM'
). If the unit
keyword is not specified, the unit of measurement associated with the geometry is used. See Section 2.10 for more information about unit of measurement specification.
Examples
The following example identifies cities with a 1990 population (POP90 column value) greater than 120,000 that are located within 20 kilometers of interstate highways (GEOM column in the GEOD_INTERSTATES table). It stores the results in a table named COLOCATION_TABLE, and performs an internal commit operation after each 20 internal operations.
EXECUTE SDO_SAM.COLOCATED_REFERENCE_FEATURES( 'geod_cities', 'location', 'pop90 > 120000', 'geod_interstates', 'geom', null, 'distance=20 unit=km', 'colocation_table', 20);
Format
SDO_SAM.SIMPLIFY_GEOMETRY(
geom IN SDO_GEOMETRY,
dim IN SDO_DIM_ARRAY,
pct_area_change_limit IN NUMBER DEFAULT 2
) RETURN SDO_GEOMETRY;
or
SDO_SAM.SIMPLIFY_GEOMETRY(
geom IN SDO_GEOMETRY,
tol IN NUMBER,
pct_area_change_limit IN NUMBER DEFAULT 2
) RETURN SDO_GEOMETRY;
Parameters
Geometry to be simplified.
Dimensional array for the geometry to be simplified.
Tolerance value (see Section 1.5.5).
The percentage of area changed to be used for each simplification iteration, as explained in the Usage Notes.
Usage Notes
This function reduces the number of vertices in a geometry by internally applying the SDO_UTIL.SIMPLIFY function (documented in Chapter 32) with an appropriate threshold value.
Reducing the number of vertices may result in a change in the area of the geometry. The pct_area_change_limit
parameter specifies how much area change can be tolerated while simplifying the geometry. It is usually a number from 1 to 100. The default value is 2; that is, the area of the geometry can either increase or decrease by at most two percent compared to the original geometry as a result of the geometry simplification.
Examples
The following example simplifies the geometries in the GEOMETRY column of the POLY_4PT_TEMP table.
SELECT sdo_sam.simplify_geometry(a.geometry, 0.00000005) FROM poly_4pt_temp a, user_sdo_geom_metadata b WHERE b.table_name='POLY_4PT_TEMP' ; SDO_SAM.SIMPLIFY_GEOMETRY(A.GEOMETRY,0.00000005)(ORIG_AREA, CUR_AREA, ORIG_LEN,  SDO_SMPL_GEOMETRY(28108.5905, 28108.5905, 758.440118, 758.440118, SDO_GEOMETRY(2 003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(122.4215, 37.7862, 122.422, 37.7869, 122.421, 37.789, 122.42, 37.7866, 122.4215, 37.78 62))) SDO_SMPL_GEOMETRY(4105.33806, 4105.33806, 394.723053, 394.723053, SDO_GEOMETRY(2 003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(122.4019, 37.8052, 122.4027, 37.8055, 122.4031, 37.806, 122.4012, 37.8052, 122.4019, 3 7.8052))) . . . 50 rows selected.
Format
SDO_SAM.SIMPLIFY_LAYER(
theme_tablename IN VARCHAR2,
theme_colname IN VARCHAR2,
smpl_geom_colname IN VARCHAR2,
commit_interval IN NUMBER DEFAULT 10,
pct_area_change_limit IN NUMBER DEFAULT 2);
Parameters
Name of the table containing the geometry layer to be simplified.
Column in theme_tablename
of type SDO_GEOMETRY containing the geometries to be simplified.
Column in theme_tablename
of type SDO_GEOMETRY into which the simplified geometries are to be placed by this procedure.
Number of geometries to simplify before Spatial performs an internal commit operation. If commit_interval
is not specified, a commit is performed after every 10 simplification operations.
The percentage of area changed to be used for each simplification iteration, as explained in the Usage Notes for the SDO_SAM.SIMPLIFY_GEOMETRY function.
Usage Notes
This procedure simplifies all geometries in a layer. It is equivalent to calling the SDO_SAM.SIMPLIFY_GEOMETRY function for each geometry in the layer, except that each simplified geometry is put in a separate column in the table instead of being returned to the caller. See also the Usage Notes for the SDO_SAM.SIMPLIFY_GEOMETRY function.
Examples
The following example adds a column named SMPL_GEOM to the POLY_4PT_TEMP table, then simplifies all geometries in the GEOMETRY :icolumn of the POLY_4PT_TEMP table, placing each simplified geometry in the SMPL_GEOM column in the same row with its associated original geometry.
ALTER TABLE poly_4pt_temp ADD (smpl_geom mdsys.sdo_geometry); Table altered. EXECUTE sdo_sam.simplify_layer('POLY_4PT_TEMP', 'GEOMETRY', 'SMPL_GEOM'); PL/SQL procedure successfully completed.
Format
SDO_SAM.SPATIAL_CLUSTERS(
tablename IN VARCHAR2,
colname IN VARCHAR2,
max_clusters IN NUMBER,
allow_outliers IN VARCHAR2 DEFAULT 'TRUE',
tablepartition IN VARCHAR2 DEFAULT NULL
) RETURN SDO_REGIONSET;
Description
Computes clusters using the existing Rtree index, and returns a set of SDO_REGION objects where the geometry column specifies the boundary of each cluster and the geometry_key
value is set to null.
Parameters
Name of the data mining table.
Name of the column in tablename
that holds the location coordinates.
Maximum number of clusters to obtain.
TRUE
(the default) causes outlying values (isolated instances) to be included in the spatial clusters; FALSE
causes outlying values not to be included in the spatial clusters. (TRUE
accommodates all data and may result in larger clusters; FALSE
may exclude some data and may result in smaller clusters.)
Name of the partition in tablename
.
Format
SDO_SAM.TILED_AGGREGATES(
theme_name IN VARCHAR2,
theme_colname IN VARCHAR2,
aggr_type_string IN VARCHAR2,
aggr_col_string IN VARCHAR2,
tiling_level IN NUMBER DEFAULT NULL,
tiling_domain IN SDO_DIM_ARRAY DEFAULT NULL,
zero_agg_tiles IN NUMBER DEFAULT 0,
xdivs IN NUMBER DEFAULT NULL,
ydivs IN NUMBER DEFAULT NULL
) RETURN SDO_REGAGGRSET;
Description
Tiles aggregates for a domain. For each tile, computes the intersecting geometries from the theme table; the values in the aggr_col_string
column are weighted proportionally to the area of the intersection, and aggregated according to aggr_col_string
.
Parameters
Table containing theme information (for example, demographic information).
Name of the column in the theme_name
table that contains geometry objects.
Any Oracle SQL aggregate function that accepts one or more numeric values and computes a numeric value, such as SUM
, MIN
, MAX
, or AVG
.
Name of a column in the theme_name
table on which to compute aggregate values. An example might be a POPULATION column.
Level to be used to create tiles. If you specify this parameter, the extent of each dimension is divided into 2^tiling_level
parts, resulting in at most 4*tiling_level
tiles. (Specify either this parameter or the combination of the xdivs
and ydivs
parameters.)
Domain for the tiling level. The parameter is not required, and if you do not specify it, the extent associated with the theme_name
table is used.
Specify 0 to exclude tiles that have a value of 0 for the computed aggregate, or specify 1 to return all tiles. The default value is 0, which ensures that only tiles with a nonzero aggregate value are returned.
The number of times that the extent in the first dimension is divided, such that the total number of parts is xdivs
+ 1. For example, if you specify 10 for xdivs
, the extent of the first dimension is divided into 11 parts.
The number of times that the extent in the second dimension is divided, such that the total number of parts is ydivs
+ 1. For example, if you specify 10 for ydivs
, the extent of the second dimension is divided into 11 parts.
Usage Notes
This function is similar to SDO_SAM.AGGREGATES_FOR_LAYER, but the results are dynamically generated using tiling information. Given a theme_name
table, the tiling domain is determined. Based on the tiling_level
value or the xdivs
and ydivs
values, the necessary tiles are generated. For each tile geometry, thematic aggregates are computed as described in the Usage Notes for SDO_SAM.AGGREGATES_FOR_LAYER.
You must specify either the tiling_level
parameter or both the xdivs
and ydivs
parameters. If you specify all three of these parameters, the tiling_level
parameter is ignored and the xdivs
and ydivs
parameters are used.
If you specify the xdivs
and ydivs
parameters, the total number of grids (tiles) returned is (xdivs+1)*(ydivs+1)
.
This function returns an object of type SDO_REGAGGRSET. The SDO_REGAGGRSET object type is defined as:
TABLE OF SDO_REGAGGR
The SDO_REGAGGR object type is defined as:
Name Null? Type    REGION_ID VARCHAR2(24) GEOMETRY MDSYS.SDO_GEOMETRY AGGREGATE_VALUE NUMBER
Examples
The following example computes the sum of the population rows of POLY_4PT_TEMP table intersecting with each tile. The extent of the POLY_4PT_TEMP table stored in the USER_SDO_GEOM_METADATA view is used as the domain, and a tiling level of 2 is used (that is, the domain is divided into 16 tiles).
SELECT a.geometry, a.aggregate_value from TABLE(sdo_sam.tiled_aggregates('POLY_4PT_TEMP', 'GEOMETRY', 'SUM', 'POPULATION', 2)) a; GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  AGGREGATE_VALUE  SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(180, 90, 90, 45)) .007150754 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(180, 45, 90, 0)) .034831005 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(180, 0, 90, 45)) 7.73307783 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(90, 90, 0, 45)) .019498368 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(90, 45, 0, 0)) .939061456 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(90, 0, 0, 45)) 1.26691592 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(0, 0, 90, 45)) 40 7 rows selected.
Format
SDO_SAM.TILED_BINS(
l1 IN NUMBER,
u1 IN NUMBER,
l2 IN NUMBER,
u2 IN NUMBER,
tiling_level IN NUMBER DEFAULT NULL,
srid IN NUMBER DEFAULT NULL,
xdivs IN NUMBER DEFAULT NULL,
ydivs IN NUMBER DEFAULT NULL
) RETURN SDO_REGIONSET;
Parameters
Lower bound of the extent in the first dimension.
Upper bound of the extent in the first dimension.
Lower bound of the extent in the second dimension.
Upper bound of the extent in the second dimension.
Level to be used to tile the specified extent. If you specify this parameter, the extent of each dimension is divided into 2^tiling_level
parts, resulting in at most 4*tiling_level
tiles. (Specify either this parameter or the combination of the xdivs
and ydivs
parameters.)
SRID value to be included for the coordinate system in the returned tile geometries.
The number of times that the extent in the first dimension is divided, such that the total number of parts is xdivs
+ 1. For example, if you specify 10 for xdivs
, the extent of the first dimension is divided into 11 parts.
The number of times that the extent in the second dimension is divided, such that the total number of parts is ydivs
+ 1. For example, if you specify 10 for ydivs
, the extent of the second dimension is divided into 11 parts.
Usage Notes
You must specify either the tiling_level
parameter or both the xdivs
and ydivs
parameters. If you specify all three of these parameters, the tiling_level
parameter is ignored and the xdivs
and ydivs
parameters are used.
If you specify the xdivs
and ydivs
parameters, the total number of grids (tiles) returned is (xdivs+1)*(ydivs+1)
.
This function returns an object of type SDO_REGIONSET. The SDO_REGIONSET object type is defined as:
TABLE OF SDO_REGION
The SDO_REGION object type is defined as:
Name Null? Type    ID NUMBER GEOMETRY MDSYS.SDO_GEOMETRY
Examples
The following example tiles the entire Earth's surface at the first tiling level, using the standard longitude and latitude coordinate system (SRID 8307). The resulting SDO_REGIONSET object contains four SDO_REGION objects, one for each tile.
SELECT * FROM TABLE(sdo_sam.tiled_bins(180, 180, 90, 90, 1, 8307)) ORDER BY id; ID  GEOMETRY(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  0 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(180, 90, 0, 0)) 1 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(180, 0, 0, 90)) 2 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(0, 90, 180, 0)) 3 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR AY(0, 0, 180, 90)) 4 rows selected.
This appendix provides examples, with explanations, of queries that are more complex than the examples in the reference chapters in Part III, "Reference Information". This appendix focuses on operators that are frequently used in Spatial applications, such as SDO_WITHIN_DISTANCE and SDO_NN.
This appendix is based on input from Oracle personnel who provide support and training to Spatial users. The Oracle Spatial training course covers many of these examples, and provides additional examples and explanations.
Before you use any of the examples in this appendix, be sure you understand the usage and reference information for the relevant operator or function in Part I, "Conceptual and Usage Information" and Part III, "Reference Information".
This appendix contains the following major sections:
The examples in this appendix refer to tables named GEOD_CITIES, GEOD_COUNTIES, and GEOD_INTERSTATES, which are defined as follows:
CREATE TABLE GEOD_CITIES( LOCATION SDO_GEOMETRY, CITY VARCHAR2(42), STATE_ABRV VARCHAR2(2), POP90 NUMBER, RANK90 NUMBER); CREATE TABLE GEOD_COUNTIES( COUNTY_NAME VARCHAR2(40), STATE_ABRV VARCHAR2(2), GEOM SDO_GEOMETRY); CREATE TABLE GEOD_INTERSTATES( HIGHWAY VARCHAR2(35), GEOM SDO_GEOMETRY);
The SDO_WITHIN_DISTANCE operator identifies the set of spatial objects that are within some specified distance of a given object. You can indicate that the distance is approximate or exact. If you specify querytype=FILTER
, the distance is approximate because only a primary filter operation is performed; otherwise, the distance is exact because both primary and secondary filtering operations are performed.
Example C1 finds all cities within 15 miles of the interstate highway I170.
Example C1 Finding All Cities Within a Distance of a Highway
SELECT /*+ ORDERED */ c.city FROM geod_interstates i, geod_cities c WHERE i.highway = 'I170' AND sdo_within_distance ( c.location, i.geom, 'distance=15 unit=mile') = 'TRUE';
Example C1 finds all cities within 15 miles ('distance=15 unit=mile'
) of the specified highway (i.highway = 'I170'
), and by default the result is exact (because the querytype
parameter was not used to limit the query to a primary filter operation). In the WHERE
clause of this example:
i.highway
refers to the HIGHWAY column of the INTERSTATES table, and I170
is a value from the HIGHWAY column.
c.location
specifies the search column (geometry1
). This is the LOCATION column of the GEOD_CITIES table.
i.geom
specifies the query window (aGeom
). This is the spatial geometry in the GEOM column of the GEOD_INTERSTATES table, in the row whose HIGHWAY column contains the value I170
.
Example C2 finds all interstate highways within 15 miles of the city of Tampa.
Example C2 Finding All Highways Within a Distance of a City
SELECT /*+ ORDERED */ i.highway FROM geod_cities c, geod_interstates i WHERE c.city = 'Tampa' AND sdo_within_distance ( i.geom, c.location, 'distance=15 unit=mile') = 'TRUE';
Example C2 finds all highways within 15 miles ('distance=15 unit=mile'
) of the specified city (c.city = 'Tampa'
), and by default the result is exact (because the querytype
parameter was not used to limit the query to a primary filter operation). In the WHERE
clause of this example:
c.city
refers to the CITY column of the GEOD_CITIES table, and Tampa
is a value from the CITY column.
i.geom
specifies the search column (geometry1
). This is the GEOM column of the GEOD_INTERSTATES table.
c.location
specifies the query window (aGeom
). This is the spatial geometry in the LOCATION column of the GEOD_CITIES table, in the row whose CITY column contains the value Tampa
.
The SDO_NN operator determines the nearest neighbor geometries to a geometry. No assumptions should be made about the order of the returned results, unless you specify the SDO_NN_DISTANCE ancillary operator in the ORDER BY clause to have the results returned in distance order. If you specify no optional parameters, one nearest neighbor geometry is returned.
If you specify the optional sdo_num_res
keyword, you can request how many nearest neighbors you want, but no other conditions in the WHERE clause are evaluated. For example, assume that you want the five closest banks from an intersection, but only where the bank name is CHASE
. If the five closest banks are not named CHASE
, SDO_NN with sdo_num_res=5
will return no rows because the sdo_num_res
keyword only takes proximity into account, and not any other conditions in the WHERE clause.
If you specify the optional sdo_batch_size
keyword, any sdo_num_res
specification is ignored, and SDO_NN keeps returning neighbor geometries in distance order to the WHERE clause. If the WHERE clause specifies bank_name = 'CHASE' AND rownum < 6
, you can return the five closest banks with bank_name = 'CHASE'
.
SDO_NN_DISTANCE is an ancillary operator to the SDO_NN operator. It returns the distance of an object returned by the SDO_NN operator and is valid only within a call to the SDO_NN operator.
Example C3 finds the five cities nearest to the interstate highway I170 and the distance in miles from the highway for each city, ordered by distance in miles.
Example C3 Finding the Cities Nearest to a Highway
SELECT /*+ ORDERED */ c.city, sdo_nn_distance (1) distance_in_miles FROM geod_interstates i, geod_cities c WHERE i.highway = 'I170' AND sdo_nn(c.location, i.geom, 'sdo_num_res=5 unit=mile', 1) = 'TRUE' ORDER BY distance_in_miles;
In Example C3, because the /*+ ORDERED*/
optimizer hint is used, it is important to have an index on the GEOD_INTERSTATES.HIGHWAY column. In this example, the hint forces the query to locate highway I170 before it tries to find nearest neighbor geometries. In the WHERE
clause of this example:
i.highway
refers to the HIGHWAY column of the GEOD_INTERSTATES table, and I170
is a value from the HIGHWAY column.
c.location
specifies the search column (geometry1
). This is the LOCATION column of the GEOD_CITIES table.
i.geom
specifies the query window (geometry2
). This is the spatial geometry in the GEOM column of the GEOD_INTERSTATES table, in the row whose HIGHWAY column contains the value I170
.
sdo_num_res=5
specifies how many nearest neighbor geometries to find.
unit=mile
specifies the unit of measurement to associate with distances returned by the SDO_NN_DISTANCE ancillary operator.
1
(in sdo_nn_distance (1)
and 'sdo_num_res=5 unit=mile', 1
) is the number
parameter value that associates the call to SDO_NN with the call to SDO_NN_DISTANCE.
In Example C3, ORDER BY distance_in_miles
orders the results from the WHERE clause by distance in miles.
The statement in Example C3 produces the following output (slightly reformatted for readability):
CITY DISTANCE_IN_MILES   St Louis 5.36297295 Springfield 78.7997464 Peoria 141.478022 Evansville 158.22422 Springfield 188.508631
Example C4 extends Example C3 by limiting the results to cities with a 1990 population over a certain number. It finds the five cities nearest to the interstate highway I170 that have a population greater than 300,000, the 1990 population for each city, and the distance in miles from the highway for each city, ordered by distance in miles.
Example C4 Finding the Cities Above a Specified Population Nearest to a Highway
SELECT /*+ ORDERED NO_INDEX(c pop90_idx) */ c.city, pop90, sdo_nn_distance (1) distance_in_miles FROM geod_interstates i, geod_cities c WHERE i.highway = 'I170' AND sdo_nn(c.location, i.geom, 'sdo_batch_size=10 unit=mile', 1) = 'TRUE' AND c.pop90 > 300000 AND rownum < 6 ORDER BY distance_in_miles;
In Example C4, because the ORDERED
optimizer hint is used, it is important to have an index on the GEOD_INTERSTATES.HIGHWAY column. In this example, the hint forces the query to locate highway I170 before it tries to find nearest neighbor geometries.
To ensure correct results, disable all nonspatial indexes on columns that come from the same table as the SDO_NN search column (geometry1
). In this example, the NO_INDEX(c pop90_idx)
optimizer hint disables the nonspatial index on the POP90 column.
In the WHERE
clause of this example:
sdo_batch_size=10
causes geometries to be returned continually (in distance order, in batches of 10 geometries), to be checked to see if they satisfy the other conditions in the WHERE clause.
c.pop90 > 300000
restricts the results to rows where the POP90 column value is greater than 300000.
rownum < 6
limits the number of results returned to five.
In Example C4, ORDER BY distance_in_miles
orders the results from the WHERE clause by distance in miles.
The statement in Example C4 produces the following output (slightly reformatted for readability):
CITY POP90 DISTANCE_IN_MILES    St Louis 396685 5.36297295 Kansas City 435146 227.404883 Indianapolis 741952 234.708666 Memphis 610337 244.202072 Chicago 2783726 253.547961
If many rows are being aggregated, a single SDO_AGGR_UNION aggregate function may take a long time to run. This is because SDO_AGGR_UNION aggregates the first two geometries passed in, then aggregates the result to the next geometry, then aggregates the result to the next one, and so on. The reason this will eventually run slowly is that the result will very quickly grow to a geometry with many vertices, and every subsequent aggregation will include this very complex geometry.
For better performance when aggregating many rows, break your aggregation into groupings so that each is always 50 geometries or fewer. Example C5 shows the following:
An initial SELECT statement to determine how many groupings of 50 (as a power of 2) are needed for the geometries you want to aggregate (in this case, ZIP code geometries in the US states of California, Oregon, and Washington). If there are 5000 such geometries, the POWER function result is 128, which you should use use for the innermost GROUP BY clause in the next SELECT statement.
A SELECT statement that uses nested aggregates and GROUP BY clauses. For best performance, "skip" power of 2 values in the GROUP BY clauses as you go down to 2. This example has clauses using 128, 32, 8, and 2; but it does not have clauses using 64, 16, or 4.
Example C5 Aggregate Union with Groupings for Many Rows
 Determine how many groupings of 50 are needed. Assume 5000 rows in  all. 5000/50 = 100; and 128 is the next higher power of 2. SELECT POWER(2, CEIL( LOG(2, COUNT(*)/50))) FROM ZIP_CODES z WHERE z.state_code IN ('CA', 'OR', 'WA');  Perform the aggregate union operation, using 128 in the  innermost GROUP BY clause. SELECT sdo_aggr_union(sdoaggrtype(aggr_geom,0.5)) aggr_geom FROM (SELECT sdo_aggr_union(sdoaggrtype(aggr_geom,0.5)) aggr_geom FROM (SELECT sdo_aggr_union(sdoaggrtype(aggr_geom,0.5)) aggr_geom FROM (SELECT sdo_aggr_union(sdoaggrtype(aggr_geom,0.5)) aggr_geom FROM (SELECT sdo_aggr_union(mdsys.sdoaggrtype(geom,0.5)) aggr_geom FROM ZIP_CODES z WHERE z.state_code IN ('CA', 'OR', 'WA') GROUP BY mod(rownum,128)) GROUP BY mod (rownum, 32)) GROUP BY mod (rownum, 8)) GROUP BY mod (rownum, 2) );
Oracle Spatial consists of a set of object data types, type methods, and operators, functions, and procedures that use these types. A geometry is stored as an object, in a single row, in a column of type SDO_GEOMETRY. Spatial index creation and maintenance is done using basic DDL (CREATE, ALTER, DROP) and DML (INSERT, UPDATE, DELETE) statements.
This chapter starts with a simple example that inserts, indexes, and queries spatial data. You may find it helpful to read this example quickly before you examine the detailed data type and metadata information later in the chapter.
This chapter contains the following major sections:
This section presents a simple example of creating a spatial table, inserting data, creating the spatial index, and performing spatial queries. It refers to concepts that were explained in Chapter 1 and that will be explained in other sections of this chapter.
The scenario is a soft drink manufacturer that has identified geographical areas of marketing interest for several products (colas). The colas could be those produced by the company or by its competitors, or some combination. Each area of interest could represent any userdefined criterion: for example, an area where that cola has the majority market share, or where the cola is under competitive pressure, or where the cola is believed to have significant growth potential. Each area could be a neighborhood in a city, or a part of a state, province, or country.
Figure 21 shows the areas of interest for four colas.
Example 21 performs the following operations:
Creates a table (COLA_MARKETS) to hold the spatial data
Inserts rows for four areas of interest (cola_a
, cola_b
, cola_c
, cola_d
)
Updates the USER_SDO_GEOM_METADATA view to reflect the dimensional information for the areas
Creates a spatial index (COLA_SPATIAL_IDX)
Performs some spatial queries
Many concepts and techniques in Example 21 are explained in detail in other sections of this chapter.
Example 21 Simple Example: Inserting, Indexing, and Querying Spatial Data
 Create a table for cola (soft drink) markets in a  given geography (such as city or state).  Each row will be an area of interest for a specific  cola (for example, where the cola is most preferred  by residents, where the manufacturer believes the  cola has growth potential, and so on).  (For restrictions on spatial table and column names, see  Section 2.8.1 and Section 2.8.2.) CREATE TABLE cola_markets ( mkt_id NUMBER PRIMARY KEY, name VARCHAR2(32), shape SDO_GEOMETRY);  The next INSERT statement creates an area of interest for  Cola A. This area happens to be a rectangle.  The area could represent any userdefined criterion: for  example, where Cola A is the preferred drink, where  Cola A is under competitive pressure, where Cola A  has strong growth potential, and so on. INSERT INTO cola_markets VALUES( 1, 'cola_a', SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,3),  one rectangle (1003 = exterior) SDO_ORDINATE_ARRAY(1,1, 5,7)  only 2 points needed to  define rectangle (lower left and upper right) with  Cartesiancoordinate data ) );  The next two INSERT statements create areas of interest for  Cola B and Cola C. These areas are simple polygons (but not  rectangles). INSERT INTO cola_markets VALUES( 2, 'cola_b', SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1),  one polygon (exterior polygon ring) SDO_ORDINATE_ARRAY(5,1, 8,1, 8,6, 5,7, 5,1) ) ); INSERT INTO cola_markets VALUES( 3, 'cola_c', SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1),  one polygon (exterior polygon ring) SDO_ORDINATE_ARRAY(3,3, 6,3, 6,5, 4,5, 3,3) ) );  Now insert an area of interest for Cola D. This is a  circle with a radius of 2. It is completely outside the  first three areas of interest. INSERT INTO cola_markets VALUES( 4, 'cola_d', SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,4),  one circle SDO_ORDINATE_ARRAY(8,7, 10,9, 8,11) ) );   UPDATE METADATA VIEW    Update the USER_SDO_GEOM_METADATA view. This is required  before the Spatial index can be created. Do this only once for each  layer (that is, tablecolumn combination; here: COLA_MARKETS and SHAPE). INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES ( 'cola_markets', 'shape', SDO_DIM_ARRAY(  20X20 grid SDO_DIM_ELEMENT('X', 0, 20, 0.005), SDO_DIM_ELEMENT('Y', 0, 20, 0.005) ), NULL  SRID );   CREATE THE SPATIAL INDEX   CREATE INDEX cola_spatial_idx ON cola_markets(shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX;  Preceding statement created an Rtree index.   PERFORM SOME SPATIAL QUERIES    Return the topological intersection of two geometries. SELECT SDO_GEOM.SDO_INTERSECTION(c_a.shape, c_c.shape, 0.005) FROM cola_markets c_a, cola_markets c_c WHERE c_a.name = 'cola_a' AND c_c.name = 'cola_c';  Do two geometries have any spatial relationship? SELECT SDO_GEOM.RELATE(c_b.shape, 'anyinteract', c_d.shape, 0.005) FROM cola_markets c_b, cola_markets c_d WHERE c_b.name = 'cola_b' AND c_d.name = 'cola_d';  Return the areas of all cola markets. SELECT name, SDO_GEOM.SDO_AREA(shape, 0.005) FROM cola_markets;  Return the area of just cola_a. SELECT c.name, SDO_GEOM.SDO_AREA(c.shape, 0.005) FROM cola_markets c WHERE c.name = 'cola_a';  Return the distance between two geometries. SELECT SDO_GEOM.SDO_DISTANCE(c_b.shape, c_d.shape, 0.005) FROM cola_markets c_b, cola_markets c_d WHERE c_b.name = 'cola_b' AND c_d.name = 'cola_d';  Is a geometry valid? SELECT c.name, SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(c.shape, 0.005) FROM cola_markets c WHERE c.name = 'cola_c';  Is a layer valid? (First, create the results table.) CREATE TABLE val_results (sdo_rowid ROWID, result VARCHAR2(2000)); CALL SDO_GEOM.VALIDATE_LAYER_WITH_CONTEXT('COLA_MARKETS', 'SHAPE', 'VAL_RESULTS', 2); SELECT * from val_results;
With Spatial, the geometric description of a spatial object is stored in a single row, in a single column of object type SDO_GEOMETRY in a userdefined table. Any table that has a column of type SDO_GEOMETRY must have another column, or set of columns, that defines a unique primary key for that table. Tables of this sort are sometimes referred to as spatial tables or spatial geometry tables.
Oracle Spatial defines the object type SDO_GEOMETRY as:
CREATE TYPE sdo_geometry AS OBJECT ( SDO_GTYPE NUMBER, SDO_SRID NUMBER, SDO_POINT SDO_POINT_TYPE, SDO_ELEM_INFO SDO_ELEM_INFO_ARRAY, SDO_ORDINATES SDO_ORDINATE_ARRAY);
Oracle Spatial also defines the SDO_POINT_TYPE, SDO_ELEM_INFO_ARRAY, and SDO_ORDINATE_ARRAY types, which are used in the SDO_GEOMETRY type definition, as follows:
CREATE TYPE sdo_point_type AS OBJECT ( X NUMBER, Y NUMBER, Z NUMBER); CREATE TYPE sdo_elem_info_array AS VARRAY (1048576) of NUMBER; CREATE TYPE sdo_ordinate_array AS VARRAY (1048576) of NUMBER;
Because the maximum SDO_ORDINATE_ARRAY size is 1,048,576 numbers, the maximum number of vertices in an SDO_GEOMETRY object depends on the number of dimensions per vertex: 524,288 for two dimensions, 349,525 for three dimensions, and 262,144 for four dimensions.
The sections that follow describe the semantics of each SDO_GEOMETRY attribute, and then describe some usage considerations (Section 2.2.6).
The SDO_GEOMETRY object type has methods that provide convenient access to some of the attributes. These methods are described in Section 2.3.
Some Spatial data types are described in locations other than this section:
Section 11.2 describes data types for geocoding.
Oracle Spatial GeoRaster Developer's Guide describes data types for Oracle Spatial GeoRaster.
Oracle Spatial Topology and Network Data Models Developer's Guide describes data types for the Oracle Spatial topology data model.
The SDO_GTYPE attribute indicates the type of the geometry. Valid geometry types correspond to those specified in the Geometry Object Model for the OGIS Simple Features for SQL specification (with the exception of Surfaces). The numeric values differ from those given in the OGIS specification, but there is a direct correspondence between the names and semantics where applicable.
The SDO_GTYPE value is 4 digits in the format DLTT, where:
D identifies the number of dimensions (2, 3, or 4)
L identifies the linear referencing measure dimension for a threedimensional linear referencing system (LRS) geometry, that is, which dimension (3 or 4) contains the measure value. For a nonLRS geometry, or to accept the Spatial default of the last dimension as the measure for an LRS geometry, specify 0. For information about the linear referencing system (LRS), see Chapter 7.
TT identifies the geometry type (00 through 09, with 10 through 99 reserved for future use).
Table 21 shows the valid SDO_GTYPE values. The Geometry Type and Description values reflect the OGIS specification.
Table 21 Valid SDO_GTYPE Values
Value  Geometry Type  Description 

DL00 
UNKNOWN_GEOMETRY 
Spatial ignores this geometry. 
DL01 
POINT 
Geometry contains one point. 
DL02 
LINE or CURVE 
Geometry contains one line string that can contain straight or circular arc segments, or both. (LINE and CURVE are synonymous in this context.) 
DL03 
POLYGON or SURFACE 
Geometry contains one polygon with or without holes,^{Foot 1 } or one surface consisting of one or more polygons. In a threedimensional polygon, all points must be on the same plane. 
DL04 
COLLECTION 
Geometry is a heterogeneous collection of elements. COLLECTION is a superset that includes all other types. 
DL05 
MULTIPOINT 
Geometry has one or more points. (MULTIPOINT is a superset of POINT.) 
DL06 
MULTILINE or MULTICURVE 
Geometry has one or more line strings. (MULTILINE and MULTICURVE are synonymous in this context, and each is a superset of both LINE and CURVE.) 
DL07 
MULTIPOLYGON or MULTISURFACE 
Geometry can have multiple, disjoint polygons (more than one exterior boundary). or surfaces (MULTIPOLYGON is a superset of POLYGON, and MULTISURFACE is a superset of SURFACE.) 
DL08 
SOLID 
Geometry consists of multiple surfaces and is completely enclosed in a threedimensional space. Can be a cuboid or a frustum. 
DL09 
MULTISOLID 
Geometry can have multiple, disjoint solids (more than one exterior boundary). (MULTISOLID is a superset of SOLID.) 
^{Footnote 1 }For a polygon with holes, enter the exterior boundary first, followed by any interior boundaries.
The D in the Value column of Table 21 is the number of dimensions: 2, 3, or 4. For example, an SDO_GTYPE value of 2003 indicates a twodimensional polygon. The number of dimensions reflects the number of ordinates used to represent each vertex (for example, X,Y for twodimensional objects).
In any given layer (column), all geometries must have the same number of dimensions. For example, you cannot mix twodimensional and threedimensional data in the same layer.
The following methods are available for returning the individual DLTT components of the SDO_GTYPE for a geometry object: Get_Dims, Get_LRS_Dim, and Get_Gtype. These methods are described in Section 2.3.
For more information about SDO_GTYPE values for threedimensional geometries, see Table 11 in Section 1.11.
The SDO_SRID attribute can be used to identify a coordinate system (spatial reference system) to be associated with the geometry. If SDO_SRID is null, no coordinate system is associated with the geometry. If SDO_SRID is not null, it must contain a value from the SRID column of the SDO_COORD_REF_SYS table (described in Section 6.7.9), and this value must be inserted into the SRID column of the USER_SDO_GEOM_METADATA view (described in Section 2.8).
All geometries in a geometry column must have the same SDO_SRID value if a spatial index will be built on that column.
For information about coordinate systems, see Chapter 6.
The SDO_POINT attribute is defined using the SDO_POINT_TYPE object type, which has the attributes X, Y, and Z, all of type NUMBER. (The SDO_POINT_TYPE definition is shown in Section 2.2.) If the SDO_ELEM_INFO and SDO_ORDINATES arrays are both null, and the SDO_POINT attribute is nonnull, then the X, Y, and Z values are considered to be the coordinates for a point geometry. Otherwise, the SDO_POINT attribute is ignored by Spatial. You should store point geometries in the SDO_POINT attribute for optimal storage; and if you have only point geometries in a layer, it is strongly recommended that you store the point geometries in the SDO_POINT attribute.
Section 2.7.5 illustrates a point geometry and provides examples of inserting and querying point geometries.
Note: Do not use the SDO_POINT attribute in defining a linear referencing system (LRS) point or an oriented point. For information about LRS, see Chapter 7. For information about oriented points, see Section 2.7.6. 
The SDO_ELEM_INFO attribute is defined using a varying length array of numbers. This attribute lets you know how to interpret the ordinates stored in the SDO_ORDINATES attribute (described in Section 2.2.5).
Each triplet set of numbers is interpreted as follows:
SDO_STARTING_OFFSET  Indicates the offset within the SDO_ORDINATES array where the first ordinate for this element is stored. Offset values start at 1 and not at 0. Thus, the first ordinate for the first element will be at SDO_GEOMETRY.SDO_ORDINATES(1). If there is a second element, its first ordinate will be at SDO_GEOMETRY.SDO_ORDINATES(n), where n reflects the position within the SDO_ORDINATE_ARRAY definition (for example, 19 for the 19th number, as in Figure 24 in Section 2.7.2).
SDO_ETYPE  Indicates the type of the element. Valid values are shown in Table 22.
SDO_ETYPE values 1, 2, 1003, and 2003 are considered simple elements. They are defined by a single triplet entry in the SDO_ELEM_INFO array. For SDO_ETYPE values 1003 and 2003, the first digit indicates exterior (1) or interior (2):
1003: exterior polygon ring (must be specified in counterclockwise order)
2003: interior polygon ring (must be specified in clockwise order)
Note: The use of 3 as an SDO_ETYPE value for polygon ring elements in a single geometry is discouraged. You should specify 3 only if you do not know if the simple polygon is exterior or interior, and you should then upgrade the table or layer to the current format using the SDO_MIGRATE.TO_CURRENT procedure, described in Chapter 26.You cannot mix 1digit and 4digit SDO_ETYPE values in a single geometry. 
SDO_ETYPE values 4, 1005, 2005, 1006, and 2006 are considered compound elements. They contain at least one header triplet with a series of triplet values that belong to the compound element. For 4digit SDO_ETYPE values, the first digit indicates exterior (1) or interior (2):
1005: exterior polygon ring (must be specified in counterclockwise order)
2005: interior polygon ring (must be specified in clockwise order)
1006: exterior surface consisting of one or more polygon rings
2006: interior surface in a solid element
The elements of a compound element are contiguous. The last point of a subelement in a compound element is the first point of the next subelement. The point is not repeated.
SDO_INTERPRETATION  Means one of two things, depending on whether or not SDO_ETYPE is a compound element.
If SDO_ETYPE is a compound element (4, 1005, or 2005), this field specifies how many subsequent triplet values are part of the element.
If the SDO_ETYPE is not a compound element (1, 2, 1003, or 2003), the interpretation attribute determines how the sequence of ordinates for this element is interpreted. For example, a line string or polygon boundary may be made up of a sequence of connected straight line segments or circular arcs.
Descriptions of valid SDO_ETYPE and SDO_INTERPRETATION value pairs are given in Table 22.
If a geometry consists of more than one element, then the last ordinate for an element is always one less than the starting offset for the next element. The last element in the geometry is described by the ordinates from its starting offset to the end of the SDO_ORDINATES varying length array.
For compound elements (SDO_ETYPE values 4, 1005, or 2005), a set of n triplets (one for each subelement) is used to describe the element. It is important to remember that subelements of a compound element are contiguous. The last point of a subelement is the first point of the next subelement. For subelements 1 through n1, the end point of one subelement is the same as the starting point of the next subelement. The starting point for subelements 2...n2 is the same as the end point of subelement 1...n1. The last ordinate of subelement n is either the starting offset minus 1 of the next element in the geometry, or the last ordinate in the SDO_ORDINATES varying length array.
The current size of a varying length array can be determined by using the function varray_variable.Count in PL/SQL or OCICollSize in the Oracle Call Interface (OCI).
The semantics of each SDO_ETYPE element and the relationship between the SDO_ELEM_INFO and SDO_ORDINATES varying length arrays for each of these SDO_ETYPE elements are given in Table 22.
Table 22 Values and Semantics in SDO_ELEM_INFO
SDO_ETYPE  SDO_INTERPRETATION  Meaning 

0 
(any numeric value) 
Type 0 (zero) element. Used to model geometry types not supported by Oracle Spatial. For more information, see Section 2.7.7. 
1 
1 
Point type. 
1 
0 
Orientation for an oriented point. For more information, see Section 2.7.6. 
1 
n > 1 
Point cluster with n points. 
2 
1 
Line string whose vertices are connected by straight line segments. 
2 
2 
Line string made up of a connected sequence of circular arcs. Each circular arc is described using three coordinates: the start point of the arc, any point on the arc, and the end point of the arc. The coordinates for a point designating the end of one arc and the start of the next arc are not repeated. For example, five coordinates are used to describe a line string made up of two connected circular arcs. Points 1, 2, and 3 define the first arc, and points 3, 4, and 5 define the second arc, where point 3 is only stored once. 
1003 or 2003 
1 
Simple polygon whose vertices are connected by straight line segments. You must specify a point for each vertex; and the last point specified must be exactly the same point as the first (within the tolerance value), to close the polygon. For example, for a 4sided polygon, specify 5 points, with point 5 the same as point 1. 
1003 or 2003 
2 
Polygon made up of a connected sequence of circular arcs that closes on itself. The end point of the last arc is the same as the start point of the first arc. Each circular arc is described using three coordinates: the start point of the arc, any point on the arc, and the end point of the arc. The coordinates for a point designating the end of one arc and the start of the next arc are not repeated. For example, five coordinates are used to describe a polygon made up of two connected circular arcs. Points 1, 2, and 3 define the first arc, and points 3, 4, and 5 define the second arc. The coordinates for points 1 and 5 must be the same (tolerance is not considered), and point 3 is not repeated. 
1003 or 2003 
3 
Rectangle type (sometimes called optimized rectangle). A bounding rectangle such that only two points, the lowerleft and the upperright, are required to describe it. The rectangle type can be used with geodetic or nongeodetic data. However, with geodetic data, use this type only to create a query window (not for storing objects in the database). For information about using this type with geodetic data, including examples, see Section 6.2.4. For information about creating threedimensional optimized rectangles, see Section 1.11.3. 
1003 or 2003 
4 
Circle type. Described by three distinct noncolinear points, all on the circumference of the circle. 
4 
n > 1 
Compound line string with some vertices connected by straight line segments and some by circular arcs. The value n in the Interpretation column specifies the number of contiguous subelements that make up the line string. The next n triplets in the SDO_ELEM_INFO array describe each of these subelements. The subelements can only be of SDO_ETYPE 2. The last point of a subelement is the first point of the next subelement, and must not be repeated. See Section 2.7.3 and Figure 25 for an example of a compound line string geometry. 
1005 or 2005 
n > 1 
Compound polygon with some vertices connected by straight line segments and some by circular arcs. The value n in the Interpretation column specifies the number of contiguous subelements that make up the polygon. The next n triplets in the SDO_ELEM_INFO array describe each of these subelements. The subelements can only be of SDO_ETYPE 2. The end point of a subelement is the start point of the next subelement, and it must not be repeated. The start and end points of the polygon must be exactly the same point (tolerance is ignored). See Section 2.7.4 and Figure 26 for an example of a compound polygon geometry. 
1006 or 2006 
n > 1 
Surface consisting of one or more polygons, with each edge shared by no more than two polygons. A surface contains an area but not a volume. The value n in the Interpretation column specifies the number of polygons that make up the surface. The next n triplets in the SDO_ELEM_INFO array describe each of these polygon subelements. A surface must be threedimensional. For an explanation of threedimensional support in Spatial, see Section 1.11. 
1007 
n = 1 or 3 
Solid consisting of multiple surfaces that are completely enclosed in a threedimensional space, so that the solid has an interior volume. A solid element can have one exterior surface defined by the 1006 elements and zero or more interior boundaries defined by the 2006 elements. The value n in the Interpretation column must be 1 or 3. Subsequent triplets in the SDO_ELEM_INFO array describe the exterior 1006 and optional interior 2006 surfaces that make up the solid element. If n is 3, the solid is an optimized box, such that only two threedimensional points are required to define it: one with minimum values for the box in the X, Y, and Z dimensions and another with maximum values for the box in the X, Y, and Z dimensions. For example: For an explanation of threedimensional support in Spatial, see Section 1.11. 
The SDO_ORDINATES attribute is defined using a varying length array (1048576) of NUMBER type that stores the coordinate values that make up the boundary of a spatial object. This array must always be used in conjunction with the SDO_ELEM_INFO varying length array. The values in the array are ordered by dimension. For example, a polygon whose boundary has four twodimensional points is stored as {X1, Y1, X2, Y2, X3, Y3, X4, Y4, X1, Y1}. If the points are threedimensional, then they are stored as {X1, Y1, Z1, X2, Y2, Z2, X3, Y3, Z3, X4, Y4, Z4, X1, Y1, Z1}. The number of dimensions associated with each point is stored as metadata in the xxx_SDO_GEOM_METADATA views, described in Section 2.8.
The values in the SDO_ORDINATES array must all be valid and nonnull. There are no special values used to delimit elements in a multielement geometry. The start and end points for the sequence describing a specific element are determined by the STARTING_OFFSET values for that element and the next element in the SDO_ELEM_INFO array, as explained in Section 2.2.4. The offset values start at 1. SDO_ORDINATES(1) is the first ordinate of the first point of the first element.
You should use the SDO_GTYPE values as shown in Table 21; however, Spatial does not check or enforce all geometry consistency constraints. Spatial does check the following:
For SDO_GTYPE values d001 and d005, any subelement not of SDO_ETYPE 1 is ignored.
For SDO_GTYPE values d002 and d006, any subelement not of SDO_ETYPE 2 or 4 is ignored.
For SDO_GTYPE values d003 and d007, any subelement not of SDO_ETYPE 3 or 5 is ignored. (This includes SDO_ETYPE variants 1003, 2003, 1005, and 2005, which are explained in Section 2.2.4).
The SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT function can be used to evaluate the consistency of a single geometry object or of all geometry objects in a specified feature table.
The SDO_GEOMETRY object type (described in Section 2.2) has methods (member functions) that retrieve information about a geometry object. Table 23 lists these methods.
Table 23 SDO_GEOMETRY Methods
Name  Returns  Description 

NUMBER 
Returns the number of dimensions of a geometry object, as specified in its SDO_GTYPE value. In Oracle Spatial, the Get_Dims and ST_CoordDim methods return the same result.  
NUMBER 
Returns the geometry type of a geometry object, as specified in its SDO_GTYPE value.  
NUMBER 
Returns the measure dimension of an LRS geometry object, as specified in its SDO_GTYPE value. A return value of 0 indicates that the geometry is a standard (nonLRS) geometry, or is an LRS geometry in the format before release 9.0.1 and with measure as the default (last) dimension; 3 indicates that the third dimension contains the measure information; 4 indicates that the fourth dimension contains the measure information.  
BLOB 
Returns the wellknown binary (WKB) format of a geometry object. (The returned object does not include any SRID information.)  
CLOB 
Returns the wellknown text (WKT) format (explained in Section 6.8.1.1) of a geometry object. (The returned object does not include any SRID information.)  
NUMBER 
Returns the coordinate dimension (as defined by the ISO/IEC SQL Multimedia standard) of a geometry object. In Oracle Spatial, the Get_Dims and ST_CoordDim methods return the same result.  
NUMBER 
Returns 0 if a geometry object is invalid or 1 if it is valid. (The ISO/IEC SQL Multimedia standard uses the term well formed for valid in this context.) This method uses 0.001 as the tolerance value. (Tolerance is explained in Section 1.5.5.) To specify a different tolerance value or to learn more about why a geometry is invalid, use the SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT function, which is documented in Chapter 24. 
Example 22 shows most of the SDO_GEOMETRY methods. (The Get_WKB method is not included because its output cannot be displayed by SQL*Plus.)
Example 22 SDO_GEOMETRY Methods
SELECT c.shape.Get_Dims() FROM cola_markets c WHERE c.name = 'cola_b'; C.SHAPE.GET_DIMS()  2 SELECT c.shape.Get_GType() FROM cola_markets c WHERE c.name = 'cola_b'; C.SHAPE.GET_GTYPE()  3 SELECT a.route_geometry.Get_LRS_Dim() FROM lrs_routes a WHERE a.route_id = 1; A.ROUTE_GEOMETRY.GET_LRS_DIM()  3 SELECT c.shape.Get_WKT() FROM cola_markets c WHERE c.name = 'cola_b'; C.SHAPE.GET_WKT()  POLYGON ((5.0 1.0, 8.0 1.0, 8.0 6.0, 5.0 7.0, 5.0 1.0)) SELECT c.shape.ST_CoordDim() FROM cola_markets c WHERE c.name = 'cola_b'; C.SHAPE.ST_COORDDIM()  2 SELECT c.shape.ST_IsValid() FROM cola_markets c WHERE c.name = 'cola_b'; C.SHAPE.ST_ISVALID()  1
The SDO_GEOMETRY object type (described in Section 2.2) has constructors that create a geometry object from a wellknown text (WKT) string in CLOB or VARCHAR2 format, or from a wellknown binary (WKB) object in BLOB format. The following constructor formats are available:
SDO_GEOMETRY(wkt CLOB, srid NUMBER DEFAULT NULL); SDO_GEOMETRY(wkt VARCHAR2, srid NUMBER DEFAULT NULL); SDO_GEOMETRY(wkb BLOB, srid NUMBER DEFAULT NULL);
If the created geometry is inserted into a table, the SRID value used with the constructor must match the SDO_SRID value of the geometries in the table.
The following simple example constructs a point geometry using a wellknown text string. (In a WKT, spaces separate ordinates of a vertex, and commas separate vertices.)
SELECT SDO_GEOMETRY('POINT(79 37)') FROM DUAL; SDO_GEOMETRY('POINT(7937)')(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_I  SDO_GEOMETRY(2001, NULL, SDO_POINT_TYPE(79, 37, NULL), NULL, NULL)
Example 23 shows SDO_GEOMETRY constructors that create geometry objects, insert the objects into a table, and display the objects that were added to the table.
Example 23 SDO_GEOMETRY Constructors to Create Geometries
DECLARE cola_b_wkb BLOB; cola_b_wkt_clob CLOB; cola_b_wkt_varchar VARCHAR2(255); cola_b_geom SDO_GEOMETRY; BEGIN  Get cola_b geometry into CLOB, VARCHAR2, and BLOB objects,  for use by the constructor. SELECT c.shape.Get_WKT() INTO cola_b_wkt_clob FROM cola_markets c WHERE c.name = 'cola_b'; cola_b_wkt_varchar := cola_b_wkt_clob; SELECT c.shape.Get_WKB() INTO cola_b_wkb FROM cola_markets c WHERE c.name = 'cola_b';  Use some SDO_GEOMETRY constructors;  insert 3 geometries into the table; display the geometries later. cola_b_geom := SDO_GEOMETRY(cola_b_wkt_clob); INSERT INTO cola_markets VALUES (101, 'cola_b_from_clob', cola_b_geom); cola_b_geom := SDO_GEOMETRY(cola_b_wkt_varchar); INSERT INTO cola_markets VALUES (102, 'cola_b_from_varchar', cola_b_geom); cola_b_geom := SDO_GEOMETRY(cola_b_wkb); INSERT INTO cola_markets VALUES (103, 'cola_b_from_wkb', cola_b_geom); END; / PL/SQL procedure successfully completed.  Display the geometries created using SDO_GEOMETRY constructors.  All three geometries are identical. SELECT name, shape FROM cola_markets WHERE mkt_id > 100; NAME  SHAPE(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  cola_b_from_clob SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1)) cola_b_from_varchar SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1)) cola_b_from_wkb SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1))
This section describes the following object types related to support for triangulated irregular networks (TINs):
SDO_TIN
SDO_TIN_BLK_TYPE
SDO_TIN_BLK
The description of a TIN is stored in a single row, in a single column of object type SDO_TIN in a userdefined table. The object type SDO_TIN is defined as:
CREATE TYPE sdo_tin AS OBJECT (base_table VARCHAR2(70), base_table_col VARCHAR2(1024), tin_id NUMBER. blk_table VARCHAR2(70), ptn_params VARCHAR2(1024), tin_extent SDO_GEOMETRY, tin_tol NUMBER, tin_tot_dimensions NUMBER, tin_domain SDO_ORGSCL_TYPE, tin_break_lines SDO_GEOMETRY, tin_stop_lines SDO_GEOMETRY, tin_void_rgns SDO_GEOMETRY, tin_val_attr_tables SDO_STRING_ARRAY, tin_other_attrs XMLTYPE);
The SDO_TIN type has the attributes shown in Table 24.
Table 24 SDO_TIN Type Attributes
Attribute  Explanation 

BASE_TABLE 
Name of the base table containing a column of type SDO_TIN 
BASE_TABLE_COL 
Name of the column of type SDO_TIN in the base table 
TIN_ID 
ID number for the TIN. (This unique ID number is generated by Spatial. It is unique within the schema for base tables containing a column of type SDO_TIN.) 
BLK_TABLE 
Name of the table that contains information about each block in the TIN. This table contains the columns shown in Table 25. 
PTN_PARAMS 
Parameters for partitioning the TIN 
TIN_EXTENT 
SDO_GEOMETRY object representing the spatial extent of the TIN (the minimum bounding object enclosing all objects in the TIN) 
TIN_TOL 
Tolerance value for objects in the TIN. (For information about spatial tolerance, see Section 1.5.5.) 
TIN_TOT_DIMENSIONS 
Total number of dimensions in the TIN. Includes spatial dimensions and any nonspatial dimensions, up to a maximum total of 9. 
TIN_DOMAIN 
(Not currently used.) 
TIN_BREAK_LINES 
(Not currently used.) 
TIN_STOP_LINES 
(Not currently used.) 
TIN_VOID_RGNS 
(Not currently used.). 
TIN_VAL_ATTR_TABLES 
SDO_STRING_ARRAY object specifying the names of any value attribute tables for the TIN. Type SDO_STRING_ARRAY is defined as 
TIN_OTHER_ATTRS 
XMLTYPE object specifying any other attributes of the TIN 
Figure 22 shows the storage model for TIN data, in which the TIN block table (specified in the BLK_TABLE attribute of the SDO_TIN type) stores the blocks associated with the SDO_TIN object.
The TIN block table contains the columns shown in Table 25.
Table 25 Columns in the TIN Block Table
Column Name  Data Type  Purpose 

BLK_ID 
NUMBER 
ID number of the block. 
BLK_EXTENT 
SDO_GEOMETRY 
Spatial extent of the block. 
BLK_DOMAIN 
SDO_ORGSCL_TYPE 
(Not currently used.) 
PCBLK_MIN_RES 
NUMBER 
For point cloud data, the minimum resolution level at which the block is visible in a query. The block is retrieved only if the query window intersects the spatial extent of the block and if the minimum  maximum resolution interval of the block intersects the minimum  maximum resolution interval of the query. Usually, lower values mean farther from the view point, and higher values mean closer to the view point. 
PCBLK_MAX_RES 
NUMBER 
For point cloud data, the maximum resolution level at which the block is visible in a query. The block is retrieved only if the query window intersects the spatial extent of the block and if the minimum  maximum resolution interval of the block intersects the minimum  maximum resolution interval of the query. Usually, lower values mean farther from the view point, and higher values mean closer to the view point. 
NUM_POINTS 
NUMBER 
For point cloud data, the total number of points in the POINTS BLOB 
NUM_UNSORTED_POINTS 
NUMBER 
For point cloud data, the number of unsorted points in the POINTS BLOB 
PT_SORT_DIM 
NUMBER 
For point cloud data, the number of spatial dimensions for the points (2 or 3) 
POINTS 
BLOB 
For point cloud data, BLOB containing the points. Consists of an array of points, with the following information for each point:

TR_LVL 
NUMBER 
(Not currently used.) 
TR_RES 
NUMBER 
(Not currently used.) 
NUM_TRIANGLES 
NUMBER 
Number of triangles in the TRIANGLES BLOB. 
TR_SORT_DIM 
NUMBER 
(Not currently used.) 
TRIANGLES 
BLOB 
BLOB containing the triangles. Consists of an array of triangles for the block:

For each BLOB in the POINTS column of the TIN block table:
The total size is (tdim+1)*8, where tdim is the total dimensionality of each block.
The total size should be less than 5 MB for Oracle Database Release 11.1.0.6 or earlier; it should be less than 12 MB for Oracle Database Release 11.1.0.7 or later.
You can use an attribute name in a query on an object of SDO_TIN. Example 24 shows part of a SELECT statement that queries the TIN_EXTENT attribute of the TERRAIN column of a hypothetical LANDSCAPES table.
When you perform a clip operation using the SDO_TIN_PKG.CLIP_TIN function, an object of SDO_TIN_BLK_TYPE is returned, which is defined as TABLE OF SDO_TIN_BLK
.
The attributes of the SDO_TIN_BLK object type are the same as the columns in the TIN block table, which is described in Table 25 in Section 2.5.2.
This section describes the following object types related to support for point clouds:
SDO_PC
SDO_PC_BLK
The description of a point cloud is stored in a single row, in a single column of object type SDO_PC in a userdefined table. The object type SDO_PC is defined as:
CREATE TYPE sdo_pc AS OBJECT (base_table VARCHAR2(70), base_table_col VARCHAR2(1024), pc_id NUMBER. blk_table VARCHAR2(70), ptn_params VARCHAR2(1024), pc_extent SDO_GEOMETRY, pc_tol NUMBER, pc_tot_dimensions NUMBER, pc_domain SDO_ORGSCL_TYPE, pc_val_attr_tables SDO_STRING_ARRAY, pc_other_attrs XMLTYPE);
The SDO_PC type has the attributes shown in Table 26.
Table 26 SDO_PC Type Attributes
Attribute  Explanation 

BASE_TABLE 
Name of the base table containing a column of type SDO_PC 
BASE_TABLE_COL 
Name of the column of type SDO_PC in the base table 
PC_ID 
ID number for the point cloud. (This unique ID number is generated by Spatial. It is unique within the schema for base tables containing a column of type SDO_PC.) 
BLK_TABLE 
Name of the table that contains information about each block in the point cloud. This table contains the columns shown in Table 27. 
PTN_PARAMS 
Parameters for partitioning the point cloud 
PC_EXTENT 
SDO_GEOMETRY object representing the spatial extent of the point cloud (the minimum bounding object enclosing all objects in the point cloud) 
PC_TOL 
Tolerance value for points in the point cloud. (For information about spatial tolerance, see Section 1.5.5.) 
PC_TOT_DIMENSIONS 
Total number of dimensions in the point cloud. Includes spatial dimensions and any nonspatial dimensions, up to a maximum total of 9. 
PC_DOMAINS 
(Not currently used.) 
PC_VAL_ATTR_TABLES 
SDO_STRING_ARRAY object specifying the names of any value attribute tables for the point cloud. Type SDO_STRING_ARRAY is defined as 
PC_OTHER_ATTRS 
XMLTYPE object specifying any other attributes of the point cloud 
The point cloud block table (specified in the BLK_TABLE attribute of the SDO_PC type) contains the columns shown in Table 27.
Table 27 Columns in the Point Cloud Block Table
Column Name  Data Type  Purpose 

OBJ_ID 
NUMBER 
ID number of the point cloud object. 
BLK_ID 
NUMBER 
ID number of the block. 
BLK_EXTENT 
SDO_GEOMETRY 
Spatial extent of the block. 
BLK_DOMAIN 
SDO_ORGSCL_TYPE 
(Not currently used.) 
PCBLK_MIN_RES 
NUMBER 
For point cloud data, the minimum resolution level at which the block is visible in a query. The block is retrieved only if the query window intersects the spatial extent of the block and if the minimum  maximum resolution interval of the block intersects the minimum  maximum resolution interval of the query. Usually, lower values mean farther from the view point, and higher values mean closer to the view point. 
PCBLK_MAX_RES 
NUMBER 
For point cloud data, the maximum resolution level at which the block is visible in a query. The block is retrieved only if the query window intersects the spatial extent of the block and if the minimum  maximum resolution interval of the block intersects the minimum  maximum resolution interval of the query. Usually, lower values mean farther from the view point, and higher values mean closer to the view point. 
NUM_POINTS 
NUMBER 
For point cloud data, the total number of points in the POINTS BLOB 
NUM_UNSORTED_POINTS 
NUMBER 
For point cloud data, the number of unsorted points in the POINTS BLOB 
PT_SORT_DIM 
NUMBER 
Number of the dimension (1 for the first dimension, 2 for the second dimension, and so on) on which the points are sorted. 
POINTS 
BLOB 
BLOB containing the points. Consists of an array of points, with the following information for each point:

You can use an attribute name in a query on an object of SDO_PC. Example 25 shows part of a SELECT statement that queries the PC_EXTENT attribute of the OCEAN_FLOOR column of a hypothetical OCEAN_FLOOR_MODEL table.
When you perform a clip operation using the SDO_PC_PKG.CLIP_PC function, an object of SDO_PC_BLK_TYPE is returned, which is defined as TABLE OF SDO_PC_BLK
.
The attributes of the SDO_PC_BLK object type are the same as the columns in the point cloud block table, which is described in Table 27 in Section 2.6.1.
This section contains examples of many geometry types:
Figure 23 illustrates the rectangle that represents cola_a
in the example in Section 2.1.
In the SDO_GEOMETRY definition of the geometry illustrated in Figure 23:
SDO_GTYPE = 2003. The 2 indicates twodimensional, and the 3 indicates a polygon.
SDO_SRID = NULL.
SDO_POINT = NULL.
SDO_ELEM_INFO = (1, 1003, 3). The final 3 in 1,1003,3 indicates that this is a rectangle. Because it is a rectangle, only two ordinates are specified in SDO_ORDINATES (lowerleft and upperright).
SDO_ORDINATES = (1,1, 5,7). These identify the lowerleft and upperright ordinates of the rectangle.
Example 26 shows a SQL statement that inserts the geometry illustrated in Figure 23 into the database.
Example 26 SQL Statement to Insert a Rectangle
INSERT INTO cola_markets VALUES( 1, 'cola_a', SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,3),  one rectangle (1003 = exterior) SDO_ORDINATE_ARRAY(1,1, 5,7)  only 2 points needed to  define rectangle (lower left and upper right) with  Cartesiancoordinate data ) );
Figure 24 illustrates a polygon consisting of two elements: an exterior polygon ring and an interior polygon ring. The inner element in this example is treated as a void (a hole).
In the SDO_GEOMETRY definition of the geometry illustrated in Figure 24:
SDO_GTYPE = 2003. The 2 indicates twodimensional, and the 3 indicates a polygon.
SDO_SRID = NULL.
SDO_POINT = NULL.
SDO_ELEM_INFO = (1,1003,1, 19,2003,1). There are two triplet elements: 1,1003,1 and 19,2003,1.
1003 indicates that the element is an exterior polygon ring; 2003 indicates that the element is an interior polygon ring.
19 indicates that the second element (the interior polygon ring) ordinate specification starts at the 19th number in the SDO_ORDINATES array (that is, 7, meaning that the first point is 7,5).
SDO_ORDINATES = (2,4, 4,3, 10,3, 13,5, 13,9, 11,13, 5,13, 2,11, 2,4, 7,5, 7,10, 10,10, 10,5, 7,5).
The area (SDO_GEOM.SDO_AREA function) of the polygon is the area of the exterior polygon minus the area of the interior polygon. In this example, the area is 84 (99  15).
The perimeter (SDO_GEOM.SDO_LENGTH function) of the polygon is the perimeter of the exterior polygon plus the perimeter of the interior polygon. In this example, the perimeter is 52.9193065 (36.9193065 + 16).
Example 27 shows a SQL statement that inserts the geometry illustrated in Figure 24 into the database.
Example 27 SQL Statement to Insert a Polygon with a Hole
INSERT INTO cola_markets VALUES( 10, 'polygon_with_hole', SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1, 19,2003,1),  polygon with hole SDO_ORDINATE_ARRAY(2,4, 4,3, 10,3, 13,5, 13,9, 11,13, 5,13, 2,11, 2,4, 7,5, 7,10, 10,10, 10,5, 7,5) ) );
An example of such a "polygon with a hole" might be a land mass (such as a country or an island) with a lake inside it. Of course, an actual land mass might have many such interior polygons: each one would require a triplet element in SDO_ELEM_INFO, plus the necessary ordinate specification.
Exterior and interior rings cannot be nested. For example, if a country has a lake and there is an island in the lake (and perhaps a lake on the island), a separate polygon must be defined for the island; the island cannot be defined as an interior polygon ring within the interior polygon ring of the lake.
In a multipolygon (polygon collection), rings must be grouped by polygon, and the first ring of each polygon must be the exterior ring. For example, consider a polygon collection that contains two polygons (A and B):
Polygon A (one interior "hole"): exterior ring A0, interior ring A1
Polygon B (two interior "holes"): exterior ring B0, interior ring B1, interior ring B2
The elements in SDO_ELEM_INFO and SDO_ORDINATES must be in one of the following orders (depending on whether you specify Polygon A or Polygon B first):
A0, A1; B0, B1, B2
B0, B1, B2; A0, A1
Figure 25 illustrates a crescentshaped object represented as a compound line string made up of one straight line segment and one circular arc. Four points are required to represent this shape: points (10,10) and (10,14) describe the straight line segment, and points (10,14), (6,10), and (14,10) describe the circular arc.
In the SDO_GEOMETRY definition of the geometry illustrated in Figure 25:
SDO_GTYPE = 2002. The first 2 indicates twodimensional, and the second 2 indicates one or more line segments.
SDO_SRID = NULL.
SDO_POINT = NULL.
SDO_ELEM_INFO = (1,4,2, 1,2,1, 3,2,2). There are three triplet elements: 1,4,2, 1,2,1, and 3,2,2.
The first triplet indicates that this element is a compound line string made up of two subelement line strings, which are described with the next two triplets.
The second triplet indicates that the line string is made up of straight line segments and that the ordinates for this line string start at offset 1. The end point of this line string is determined by the starting offset of the second line string, 3 in this instance.
The third triplet indicates that the second line string is made up of circular arcs with ordinates starting at offset 3. The end point of this line string is determined by the starting offset of the next element or the current length of the SDO_ORDINATES array, if this is the last element.
SDO_ORDINATES = (10,10, 10,14, 6,10, 14,10).
Example 28 shows a SQL statement that inserts the geometry illustrated in Figure 25 into the database.
Figure 26 illustrates an ice cream coneshaped object represented as a compound polygon made up of one straight line segment and one circular arc. Five points are required to represent this shape: points (6,10), (10,1), and (14,10) describe one acute angleshaped line string, and points (14,10), (10,14), and (6,10) describe the circular arc. The starting point of the line string and the ending point of the circular arc are the same point (6,10). The SDO_ELEM_INFO array contains three triplets for this compound line string. These triplets are {(1,1005,2), (1,2,1), (5,2,2)}.
In the SDO_GEOMETRY definition of the geometry illustrated in Figure 26:
SDO_GTYPE = 2003. The 2 indicates twodimensional, and the 3 indicates a polygon.
SDO_SRID = NULL.
SDO_POINT = NULL.
SDO_ELEM_INFO = (1,1005,2, 1,2,1, 5,2,2). There are three triplet elements: 1,1005,2, 1,2,1, and 5,2,2.
The first triplet indicates that this element is a compound polygon made up of two subelement line strings, which are described using the next two triplets.
The second triplet indicates that the first subelement line string is made up of straight line segments and that the ordinates for this line string start at offset 1. The end point of this line string is determined by the starting offset of the second line string, 5 in this instance. Because the vertices are twodimensional, the coordinates for the end point of the first line string are at ordinates 5 and 6.
The third triplet indicates that the second subelement line string is made up of a circular arc with ordinates starting at offset 5. The end point of this line string is determined by the starting offset of the next element or the current length of the SDO_ORDINATES array, if this is the last element.
SDO_ORDINATES = (6,10, 10,1, 14,10, 10,14, 6,10).
Example 29 shows a SQL statement that inserts the geometry illustrated in Figure 26 into the database.
Figure 27 illustrates a pointonly geometry at coordinates (12,14).
In the SDO_GEOMETRY definition of the geometry illustrated in Figure 27:
SDO_GTYPE = 2001. The 2 indicates twodimensional, and the 1 indicates a single point.
SDO_SRID = NULL.
SDO_POINT = SDO_POINT_TYPE(12, 14, NULL). The SDO_POINT attribute is defined using the SDO_POINT_TYPE object type, because this is a pointonly geometry.
For more information about the SDO_POINT attribute, see Section 2.2.3.
SDO_ELEM_INFO and SDO_ORDINATES are both NULL, as required if the SDO_POINT attribute is specified.
Example 210 shows a SQL statement that inserts the geometry illustrated in Figure 27 into the database.
Example 210 SQL Statement to Insert a PointOnly Geometry
INSERT INTO cola_markets VALUES( 90, 'point_only', SDO_GEOMETRY( 2001, NULL, SDO_POINT_TYPE(12, 14, NULL), NULL, NULL));
You can search for pointonly geometries based on the X, Y, and Z values in the SDO_POINT_TYPE specification. Example 211 is a query that asks for all points whose first coordinate (the X value) is 12, and it finds the point that was inserted in Example 210.
Example 211 Query for PointOnly Geometry Based on a Coordinate Value
SELECT * from cola_markets c WHERE c.shape.SDO_POINT.X = 12; MKT_ID NAME   SHAPE(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)  90 point_only SDO_GEOMETRY(2001, NULL, SDO_POINT_TYPE(12, 14, NULL), NULL, NULL)
An oriented point is a special type of point geometry that includes coordinates representing the locations of the point and a virtual end point, to indicate an orientation vector that can be used for rotating a symbol at the point or extending a label from the point. The main use for an oriented point is in map visualization and display applications that include symbols, such as a shield symbol to indicate a highway.
To specify an oriented point:
Use an SDO_GTYPE value (explained in Section 2.2.1) for a point or multipoint geometry.
Specify a null value for the SDO_POINT attribute.
In the SDO_ELEM_INFO array (explained in Section 2.2.4), specify an additional triplet, with the second and third values (SDO_ETYPE and SDO_INTERPRETATION) as 1 and 0. For example, a triplet of 3,1,0 indicates that the point is an oriented point, with the third number in the SDO_ORDINATES array being the first coordinate, or xaxis value, of the end point reflecting the orientation vector for any symbol or label.
In the SDO_ORDINATES array (explained in Section 2.2.5), specify the coordinates of the end point for the orientation vector from the point, with values between 1 and 1. The orientation start point is assumed to be (0,0), and it is translated to the location of the physical point to which it corresponds.
Figure 28 illustrates an oriented point geometry at coordinates (12,14), with an orientation vector of approximately 34 degrees (counterclockwise from the xaxis), reflecting the orientation coordinates 0.3,0.2. (To have an orientation that more precisely matches a specific angle, refer to the cotangent or tangent values in the tables in a trigonometry textbook.) The orientation vector in this example goes from (0,0) to (0.3,0.2) and extends onward. Assuming i=0.3 and j=0.2, the angle in radians can be calculated as follows: angle in radians = arctan (j/i). The angle is then applied to the physical point associated with the orientation vector.
In the SDO_GEOMETRY definition of the geometry illustrated in Figure 28:
SDO_GTYPE = 2001. The 2 indicates twodimensional, and the 1 indicates a single point.
SDO_SRID = NULL.
SDO_POINT = NULL.
SDO_ELEM_INFO = (1,1,1, 3,1,0). The final 1,0 in 3,1,0 indicates that this is an oriented point.
SDO_ORDINATES = (12,14, 0.3,0.2). The 12,14 identifies the physical coordinates of the point; and the 0.3,0.2 identifies the x and y coordinates (assuming 12,14 as the origin) of the end point of the orientation vector. The resulting orientation vector slopes upward at about a 34degree angle.
Example 212 shows a SQL statement that inserts the geometry illustrated in Figure 28 into the database.
Example 212 SQL Statement to Insert an Oriented Point Geometry
INSERT INTO cola_markets VALUES( 91, 'oriented_point', SDO_GEOMETRY( 2001, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1,1, 3,1,0), SDO_ORDINATE_ARRAY(12,14, 0.3,0.2)));
The following guidelines apply to the definition of an oriented point:
The numbers defining the orientation vector must be between 1 and 1. (In Example 212, these numbers are 0.3 and 0.2.)
Multipoint oriented points are allowed (see Example 213), but the orientation information must follow the point being oriented.
The following considerations apply to the dimensionality of the orientation vector for an oriented point:
A twodimensional point has a twodimensional orientation vector.
A twodimensional point with an LRS measure (SDO_GTYPE=3301) has a twodimensional orientation vector.
A threedimensional point (SDO_GTYPE=3001) has a threedimensional orientation vector.
A threedimensional point with an LRS measure (SDO_GTYPE=4401) has a threedimensional orientation vector.
A fourdimensional point (SDO_GTYPE=4001) has a threedimensional orientation vector.
Example 213 shows a SQL statement that inserts an oriented multipoint geometry into the database. The multipoint geometry contains two points, at coordinates (12,14) and (12, 10), with the two points having different orientation vectors. The statement is similar to the one in Example 212, but in Example 213 the second point has an orientation vector pointing down and to the left at 45 degrees (or, 135 degrees clockwise from the xaxis), reflecting the orientation coordinates 1,1.
Example 213 SQL Statement to Insert an Oriented Multipoint Geometry
 Oriented multipoint: 2 points, different orientations INSERT INTO cola_markets VALUES( 92, 'oriented_multipoint', SDO_GEOMETRY( 2005,  Multipoint NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1,1, 3,1,0, 5,1,1, 7,1,0), SDO_ORDINATE_ARRAY(12,14, 0.3,0.2, 12,10, 1,1)));
Type 0 (zero) elements are used to model geometry types that are not supported by Oracle Spatial, such as curves and splines. A type 0 element has an SDO_ETYPE value of 0. (See Section 2.2.4 for information about the SDO_ETYPE.) Type 0 elements are not indexed by Oracle Spatial, and they are ignored by Spatial functions and procedures.
Geometries with type 0 elements must contain at least one nonzero element, that is, an element with an SDO_ETYPE value that is not 0. The nonzero element should be an approximation of the unsupported geometry, and therefore it must have both:
An SDO_ETYPE value associated with a geometry type supported by Spatial
An SDO_INTERPRETATION value that is valid for the SDO_ETYPE value (see Table 22)
(The SDO_INTERPRETATION value for the type 0 element can be any numeric value, and applications are responsible for determining the validity and significance of the value.)
The nonzero element is indexed by Spatial, and it will be returned by the spatial index.
The SDO_GTYPE value for a geometry containing a type 0 element must be set to the value for the geometry type of the nonzero element.
Figure 29 shows a geometry with two elements: a curve (unsupported geometry) and a rectangle (the nonzero element) that approximates the curve. The curve looks like the letter S, and the rectangle is represented by the dashed line.
In the example shown in Figure 29:
The SDO_GTYPE value for the geometry is 2003 (for a twodimensional polygon).
The SDO_ELEM_INFO array contains two triplets for this compound line string. For example, the triplets might be {(1,0,57), (11,1003,3)}. That is:
Ordinate Starting Offset (SDO_STARTING_OFFSET)  Element Type (SDO_ETYPE)  Interpretation (SDO_INTERPRETATION) 

1  0  57 
11  1003  3 
In this example:
The type 0 element has an SDO_ETYPE value of 0.
The nonzero element (rectangle) has an SDO_ETYPE value of 1003, indicating an exterior polygon ring.
The nonzero element has an SDO_STARTING_OFFSET value of 11 because ordinate x6 is the eleventh ordinate in the geometry.
The type 0 element has an SDO_INTERPRETATION value whose significance is applicationspecific. In this example, the SDO_INTERPRETATION value is 57.
The nonzero element has an SDO_INTERPRETATION value that is valid for the SDO_ETYPE of 1003. In this example, the SDO_INTERPRETATION value is 3, indicating a rectangle defined by two points (lowerleft and upperright).
Example 214 shows a SQL statement that inserts the geometry with a type 0 element (similar to the geometry illustrated in Figure 29) into the database. In the SDO_ORDINATE_ARRAY structure, the curve is defined by points (6,6), (12,6), (9,8), (6,10), and (12,10), and the rectangle is defined by points (6,4) and (12,12).
Example 214 SQL Statement to Insert a Geometry with a Type 0 Element
INSERT INTO cola_markets VALUES( 13, 'type_zero_element_geom', SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,0,57, 11,1003,3),  1st is type 0 element SDO_ORDINATE_ARRAY(6,6, 12,6, 9,8, 6,10, 12,10, 6,4, 12,12) ) );
Example 215 creates a table and inserts various twodimensional geometries, including multipoints (point clusters), multipolygons, and collections. At the end, it calls the SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT function to validate the inserted geometries. Note that some geometries are deliberately invalid, and their descriptions include the string INVALID
.
Example 215 SQL Statements to Insert Various TwoDimensional Geometries
CREATE TABLE t1 ( i NUMBER, d VARCHAR2(50), g SDO_GEOMETRY ); INSERT INTO t1 (i, d, g) VALUES ( 1, 'Point', sdo_geometry (2001, null, null, sdo_elem_info_array (1,1,1), sdo_ordinate_array (10,5)) ); INSERT INTO t1 (i, d, g) VALUES ( 2, 'Line segment', sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,1), sdo_ordinate_array (10,10, 20,10)) ); INSERT INTO t1 (i, d, g) VALUES ( 3, 'Arc segment', sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,2), sdo_ordinate_array (10,15, 15,20, 20,15)) ); INSERT INTO t1 (i, d, g) VALUES ( 4, 'Line string', sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,1), sdo_ordinate_array (10,25, 20,30, 25,25, 30,30)) ); INSERT INTO t1 (i, d, g) VALUES ( 5, 'Arc string', sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,2), sdo_ordinate_array (10,35, 15,40, 20,35, 25,30, 30,35)) ); INSERT INTO t1 (i, d, g) VALUES ( 6, 'Compound line string', sdo_geometry (2002, null, null, sdo_elem_info_array (1,4,3, 1,2,1, 3,2,2, 7,2,1), sdo_ordinate_array (10,45, 20,45, 23,48, 20,51, 10,51)) ); INSERT INTO t1 (i, d, g) VALUES ( 7, 'Closed line string', sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,1), sdo_ordinate_array (10,55, 15,55, 20,60, 10,60, 10,55)) ); INSERT INTO t1 (i, d, g) VALUES ( 8, 'Closed arc string', sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,2), sdo_ordinate_array (15,65, 10,68, 15,70, 20,68, 15,65)) ); INSERT INTO t1 (i, d, g) VALUES ( 9, 'Closed mixed line', sdo_geometry (2002, null, null, sdo_elem_info_array (1,4,2, 1,2,1, 7,2,2), sdo_ordinate_array (10,78, 10,75, 20,75, 20,78, 15,80, 10,78)) ); INSERT INTO t1 (i, d, g) VALUES ( 10, 'Selfcrossing line', sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,1), sdo_ordinate_array (10,85, 20,90, 20,85, 10,90, 10,85)) ); INSERT INTO t1 (i, d, g) VALUES ( 11, 'Polygon', sdo_geometry (2003, null, null, sdo_elem_info_array (1,1003,1), sdo_ordinate_array (10,105, 15,105, 20,110, 10,110, 10,105)) ); INSERT INTO t1 (i, d, g) VALUES ( 12, 'Arc polygon', sdo_geometry (2003, null, null, sdo_elem_info_array (1,1003,2), sdo_ordinate_array (15,115, 20,118, 15,120, 10,118, 15,115)) ); INSERT INTO t1 (i, d, g) VALUES ( 13, 'Compound polygon', sdo_geometry (2003, null, null, sdo_elem_info_array (1,1005,2, 1,2,1, 7,2,2), sdo_ordinate_array (10,128, 10,125, 20,125, 20,128, 15,130, 10,128)) ); INSERT INTO t1 (i, d, g) VALUES ( 14, 'Rectangle', sdo_geometry (2003, null, null, sdo_elem_info_array (1,1003,3), sdo_ordinate_array (10,135, 20,140)) ); INSERT INTO t1 (i, d, g) VALUES ( 15, 'Circle', sdo_geometry (2003, null, null, sdo_elem_info_array (1,1003,4), sdo_ordinate_array (15,145, 10,150, 20,150)) ); INSERT INTO t1 (i, d, g) VALUES ( 16, 'Point cluster', sdo_geometry (2005, null, null, sdo_elem_info_array (1,1,3), sdo_ordinate_array (50,5, 55,7, 60,5)) ); INSERT INTO t1 (i, d, g) VALUES ( 17, 'Multipoint', sdo_geometry (2005, null, null, sdo_elem_info_array (1,1,1, 3,1,1, 5,1,1), sdo_ordinate_array (65,5, 70,7, 75,5)) ); INSERT INTO t1 (i, d, g) VALUES ( 18, 'Multiline', sdo_geometry (2006, null, null, sdo_elem_info_array (1,2,1, 5,2,1), sdo_ordinate_array (50,15, 55,15, 60,15, 65,15)) ); INSERT INTO t1 (i, d, g) VALUES ( 19, 'Multiline  crossing', sdo_geometry (2006, null, null, sdo_elem_info_array (1,2,1, 5,2,1), sdo_ordinate_array (50,22, 60,22, 55,20, 55,25)) ); INSERT INTO t1 (i, d, g) VALUES ( 20, 'Multiarc', sdo_geometry (2006, null, null, sdo_elem_info_array (1,2,2, 7,2,2), sdo_ordinate_array (50,35, 55,40, 60,35, 65,35, 70,30, 75,35)) ); INSERT INTO t1 (i, d, g) VALUES ( 21, 'Multiline  closed', sdo_geometry (2006, null, null, sdo_elem_info_array (1,2,1, 9,2,1), sdo_ordinate_array (50,55, 50,60, 55,58, 50,55, 56,58, 60,55, 60,60, 56,58)) ); INSERT INTO t1 (i, d, g) VALUES ( 22, 'Multiarc  touching', sdo_geometry (2006, null, null, sdo_elem_info_array (1,2,2, 7,2,2), sdo_ordinate_array (50,65, 50,70, 55,68, 55,68, 60,65, 60,70)) ); INSERT INTO t1 (i, d, g) VALUES ( 23, 'Multipolygon  disjoint', sdo_geometry (2007, null, null, sdo_elem_info_array (1,1003,1, 11,1003,3), sdo_ordinate_array (50,105, 55,105, 60,110, 50,110, 50,105, 62,108, 65,112)) ); INSERT INTO t1 (i, d, g) VALUES ( 24, 'Multipolygon  touching', sdo_geometry (2007, null, null, sdo_elem_info_array (1,1003,3, 5,1003,3), sdo_ordinate_array (50,115, 55,120, 55,120, 58,122)) ); INSERT INTO t1 (i, d, g) VALUES ( 25, 'Multipolygon  tangent * INVALID 13351', sdo_geometry (2007, null, null, sdo_elem_info_array (1,1003,3, 5,1003,3), sdo_ordinate_array (50,125, 55,130, 55,128, 60,132)) ); INSERT INTO t1 (i, d, g) VALUES ( 26, 'Multipolygon  multitouch', sdo_geometry (2007, null, null, sdo_elem_info_array (1,1003,1, 17,1003,1), sdo_ordinate_array (50,95, 55,95, 53,96, 55,97, 53,98, 55,99, 50,99, 50,95, 55,100, 55,95, 60,95, 60,100, 55,100)) ); INSERT INTO t1 (i, d, g) VALUES ( 27, 'Polygon with void', sdo_geometry (2003, null, null, sdo_elem_info_array (1,1003,3, 5,2003,3), sdo_ordinate_array (50,135, 60,140, 51,136, 59,139)) ); INSERT INTO t1 (i, d, g) VALUES ( 28, 'Polygon with void  reverse', sdo_geometry (2003, null, null, sdo_elem_info_array (1,2003,3, 5,1003,3), sdo_ordinate_array (51,146, 59,149, 50,145, 60,150)) ); INSERT INTO t1 (i, d, g) VALUES ( 29, 'Crescent (straight lines) * INVALID 13349', sdo_geometry (2003, null, null, sdo_elem_info_array (1,1003,1), sdo_ordinate_array (10,175, 10,165, 20,165, 15,170, 25,170, 20,165, 30,165, 30,175, 10,175)) ); INSERT INTO t1 (i, d, g) VALUES ( 30, 'Crescent (arcs) * INVALID 13349', sdo_geometry (2003, null, null, sdo_elem_info_array (1,1003,2), sdo_ordinate_array (14,180, 10,184, 14,188, 18,184, 14,180, 16,182, 14,184, 12,182, 14,180)) ); INSERT INTO t1 (i, d, g) VALUES ( 31, 'Heterogeneous collection', sdo_geometry (2004, null, null, sdo_elem_info_array (1,1,1, 3,2,1, 7,1003,1), sdo_ordinate_array (10,5, 10,10, 20,10, 10,105, 15,105, 20,110, 10,110, 10,105)) ); INSERT INTO t1 (i, d, g) VALUES ( 32, 'Polygon+void+island touch', sdo_geometry (2007, null, null, sdo_elem_info_array (1,1003,1, 11,2003,1, 31,1003,1), sdo_ordinate_array (50,168, 50,160, 55,160, 55,168, 50,168, 51,167, 54,167, 54,161, 51,161, 51,162, 52,163, 51,164, 51,165, 51,166, 51,167, 52,166, 52,162, 53,162, 53,166, 52,166)) ); COMMIT; SELECT i, d, SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT (g, 0.5) FROM t1;
Example 216 creates several tables (POINTS3D, LINES3D, and POLYGONS3D), and inserts threedimensional objects into each table as appropriate (points into POINTS3D; lines into LINES3D; and polygons, surfaces, and solids into POLYGONS3D). Example 217 then creates the metadata and spatial indexes for the tables.
For information about support for threedimensional geometries, see Section 1.11.
Example 216 SQL Statements to Insert ThreeDimensional Geometries
create table points3d(id number, geometry sdo_geometry); insert into points3d values(1, sdo_geometry(3001,null, sdo_point_type(0,0,0), null, null)); insert into points3d values(2, sdo_geometry(3001,null, sdo_point_type(1,1,1), null, null)); insert into points3d values(3, sdo_geometry(3001,null, sdo_point_type(0,1,1), null, null)); insert into points3d values(4, sdo_geometry(3001,null, sdo_point_type(0,0,1), null, null)); insert into points3d values(5, sdo_geometry(3001,null, sdo_point_type(1,1,0), null, null)); insert into points3d values(6, sdo_geometry(3001,null, sdo_point_type(1,0,1), null, null)); insert into points3d values(7, sdo_geometry(3001,null, sdo_point_type(1,0,0), null, null)); insert into points3d values(8, sdo_geometry(3001,null, sdo_point_type(0,1,0), null, null)); insert into points3d values(9, sdo_geometry(3005,null, null, sdo_elem_info_array(1,1,1, 4,1,1), sdo_ordinate_array(1,1,1, 0,0,0))); create table lines3d(id number, geometry sdo_geometry); insert into lines3d values(1, sdo_geometry(3002,null, null, sdo_elem_info_array(1,2,1), sdo_ordinate_array(1,1,1, 0,0,0))); insert into lines3d values(2, sdo_geometry(3002,null, null, sdo_elem_info_array(1,2,1), sdo_ordinate_array(1,0,1, 0,1,0))); insert into lines3d values(2, sdo_geometry(3002,null, null, sdo_elem_info_array(1,2,1), sdo_ordinate_array(0,1,1, 1,0,0))); insert into lines3d values(3, sdo_geometry(3002,null, null, sdo_elem_info_array(1,2,1), sdo_ordinate_array(0,1,1, 1,0,0))); insert into lines3d values(4, sdo_geometry(3002,null, null, sdo_elem_info_array(1,2,1), sdo_ordinate_array(0,1,0, 1,0,1))); create table polygons3d(id number, geometry sdo_geometry);  Simple Polygon  All points have to be on the same plane. insert into polygons3d values(1, SDO_Geometry (3003,NULL,NULL , SDO_Elem_Info_Array(1,1003,1), SDO_Ordinate_Array(0.5,0.0,0.0, 0.5,1.0,0.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 0.5,0.0,0.0 ))); insert into polygons3d values(2, SDO_Geometry (3003,NULL,NULL , SDO_Elem_Info_Array(1,1003,1), SDO_Ordinate_Array(6.0,6.0,6.0, 5.0,6.0,10.0, 3.0,4.0,8.0, 4.0,4.0,4.0, 6.0,6.0,6.0 ))); insert into polygons3d values(3, SDO_Geometry (3007,NULL,NULL , SDO_Elem_Info_Array(1,1003,1,16,1003,1), SDO_Ordinate_Array(6.0,6.0,6.0, 5.0,6.0,10.0, 3.0,4.0,8.0, 4.0,4.0,4.0, 6.0,6.0,6.0, 0.5,0.0,0.0, 0.5,1.0,0.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 0.5,0.0,0.0 )));  Polygon with a Hole (same rules as 2D) plus all points on the same plane insert into polygons3d values(4, SDO_Geometry (3003,NULL,NULL , SDO_Elem_Info_Array(1,1003,1,16,2003,1), SDO_Ordinate_Array(0.5,0.0,0.0, 0.5,1.0,0.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 0.5,0.0,0.0, 0.25,0.5,0.5, 0.15,0.5,0.7, 0.15,0.6,0.7, 0.25,0.6,0.5, 0.25,0.5,0.5 )));  Surface with 2 3D polygons (on same plane) insert into polygons3d values(5, SDO_Geometry (3003,NULL,NULL , SDO_Elem_Info_Array(1,1006,2,1,1003,1,16,1003,1), SDO_Ordinate_Array(0.5,0.0,0.0, 0.5,1.0,0.0, 0.0,1.0,0.0, 0.0,0.0,0.0, 0.5,0.0,0.0, 1.5,0.0,0.0, 2.5,1.0,0.0, 1.5,2.0,0.0, 0.5,2.0,0.0, 0.5,0.0,0.0, 1.5,0.0,0.0 )));  Surface with 2 3D polygons (on two planes) insert into polygons3d values(5, SDO_Geometry(3003,NULL,NULL , SDO_Elem_Info_Array(1,1006,2,1,1003,3,7,1003,3), SDO_Ordinate_Array(2,2,2, 4,4,2, 2,2,2, 4,2,4 )));  Surface with 2 3D polygons  First polygon has one ext and one int. insert into polygons3d values(6, SDO_Geometry (3003,NULL,NULL , SDO_Elem_Info_Array(1,1006,2,1,1003,1,16,2003,1,31,1003,1), SDO_Ordinate_Array(0.5,0.0,0.0, 0.5,1.0,0.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 0.5,0.0,0.0, 0.25,0.5,0.5, 0.15,0.5,0.7, 0.15,0.6,0.7, 0.25,0.6,0.5, 0.25,0.5,0.5, 1.5,0.0,0.0, 2.5,1.0,0.0, 1.5,2.0,0.0, 0.5,2.0,0.0, 0.5,0.0,0.0, 1.5,0.0,0.0 ))); 3D Surface with 3 3D polygons insert into polygons3d values(7, SDO_Geometry (3003,NULL,NULL , SDO_Elem_Info_Array(1,1006,3,1,1003,1,16,1003,1,34,1003,1), SDO_Ordinate_Array(0.5,0.0,0.0, 0.5,1.0,0.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 0.5,0.0,0.0, 1.5,0.0,0.0, 2.5,1.0,0.0, 1.5,2.0,0.0, 0.5,2.0,0.0, 0.5,0.0,0.0, 1.5,0.0,0.0, 1.5,0.0,0.0, 2.5,0.0,0.0, 2.5,1.0,0.0, 1.5,0.0,0.0 )));  3D surface with 3 3D polygons insert into polygons3d values(8, SDO_Geometry (3003,NULL,NULL , SDO_Elem_Info_Array(1,1006,3,1,1003,1,16,2003,1,31,1003,1,49,1003,1), SDO_Ordinate_Array(0.5,0.0,0.0, 0.5,1.0,0.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 0.5,0.0,0.0, 0.25,0.5,0.5, 0.15,0.5,0.7, 0.15,0.6,0.7, 0.25,0.6,0.5, 0.25,0.5,0.5, 1.5,0.0,0.0, 2.5,1.0,0.0, 1.5,2.0,0.0, 0.5,2.0,0.0, 0.5,0.0,0.0, 1.5,0.0,0.0, 0.5,1.0,0.0, 0.5,2.0,0.0, 0.0,2.0,0.0, 0.0,1.0,0.0, 0.5,1.0,0.0 )));  Simple 3D polygon insert into polygons3d values(9, SDO_Geometry (3003,NULL,NULL , SDO_Elem_Info_Array(1,1003,1), SDO_Ordinate_Array(0.0,4.0,1.0, 4.0,4.0,1.0, 5.0,3.0,1.0, 5.0,0.0,1.0, 3.0,1.0,1.0, 1.0,1.0,1.0, 3.0,0.5,1.0, 0.0,0.0,1.0, 6.0,2.0,1.0, 6.0,3.5,1.0, 2.0,3.5,1.0, 0.0,4.0,1.0 )));  SOLID with 6 polygons insert into polygons3d values(10, SDO_Geometry (3008,NULL,NULL , SDO_Elem_Info_Array(1,1007,1,1,1006,6,1,1003,1,16,1003,1,31,1003,1,46,1003,1,61,1003,1,76,1003,1), SDO_Ordinate_Array(1.0,0.0,1.0, 1.0,1.0,1.0, 1.0,1.0,1.0, 1.0,0.0,1.0, 1.0,0.0,1.0, 1.0,0.0,1.0, 0.0,0.0,1.0, 0.0,0.0,1.0, 1.0,0.0,1.0, 1.0,0.0,1.0, 0.0,1.0,1.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 0.0,0.0,1.0, 0.0,1.0,1.0, 1.0,1.0,1.0, 0.0,1.0,1.0, 0.0,1.0,1.0, 1.0,1.0,1.0, 1.0,1.0,1.0, 1.0,1.0,1.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 1.0,0.0,1.0, 1.0,1.0,1.0, 1.0,1.0,1.0, 1.0,0.0,1.0, 0.0,0.0,1.0, 0.0,1.0,1.0, 1.0,1.0,1.0 )));  Simple SOLID with 6 polygons  All polygons are described using the optimized rectangle representation. insert into polygons3d values(11, SDO_Geometry (3008,NULL,NULL , SDO_Elem_Info_Array(1,1007,1,1,1006,6,1,1003,3,7,1003,3,13,1003,3,19,1003,3,25,1003,3,31,1003,3), SDO_Ordinate_Array(1.0,0.0,1.0, 1.0,1.0,1.0, 1.0,0.0,1.0, 0.0,0.0,1.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 0.0,1.0,1.0, 1.0,1.0,1.0, 0.0,0.0,1.0, 1.0,1.0,1.0, 1.0,1.0,1.0, 0.0,0.0,1.0 )));  MultiSolid  Both solids use optimized representation. insert into polygons3d values(12, SDO_Geometry (3009,NULL,NULL , SDO_Elem_Info_Array(1,1007,3,7,1007,3), SDO_Ordinate_Array(2.0,1.0,3.0, 3.0,1.0,0.0, 0.0,0.0,0.0, 1.0,1.0,1.0 )));  MultiSolid  like multipolygon in 2D  disjoint solids insert into polygons3d values(13, SDO_Geometry (3009,NULL,NULL , SDO_Elem_Info_Array(1,1007,1,1,1006,6,1,1003,1,16,1003,1,31,1003,1,46,1003,1,61,1003,1,76,1003,1,91,1007,1,91,1006,7,91,1003,1,106,1003,1,121,1003,1,136,1003,1,151,1003,1,166,1003,1,184,1003,1), SDO_Ordinate_Array(1.0,0.0,4.0, 1.0,1.0,4.0, 1.0,1.0,6.0, 1.0,0.0,6.0, 1.0,0.0,4.0, 1.0,0.0,6.0, 0.0,0.0,6.0, 0.0,0.0,4.0, 1.0,0.0,4.0, 1.0,0.0,6.0, 0.0,1.0,6.0, 0.0,1.0,4.0, 0.0,0.0,4.0, 0.0,0.0,6.0, 0.0,1.0,6.0, 1.0,1.0,4.0, 0.0,1.0,4.0, 0.0,1.0,6.0, 1.0,1.0,6.0, 1.0,1.0,4.0, 1.0,1.0,6.0, 0.0,1.0,6.0, 0.0,0.0,6.0, 1.0,0.0,6.0, 1.0,1.0,6.0, 1.0,1.0,4.0, 1.0,0.0,4.0, 0.0,0.0,4.0, 0.0,1.0,4.0, 1.0,1.0,4.0, 2.0,0.0,3.0, 2.0,0.0,0.0, 4.0,2.0,0.0, 4.0,2.0,3.0, 2.0,0.0,3.0, 4.5,2.0,3.0, 4.5,2.0,0.0, 2.0,0.0,0.0, 2.0,0.0,3.0, 4.5,2.0,3.0, 4.5,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,0.0, 4.5,2.0,0.0, 4.5,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,0.0, 2.0,2.0,0.0, 2.0,2.0,3.0, 4.0,2.0,3.0, 4.0,2.0,0.0, 2.0,2.0,0.0, 2.0,2.0,3.0, 4.0,2.0,3.0, 2.0,0.0,3.0, 4.0,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,3.0, 4.5,2.0,3.0, 2.0,0.0,3.0, 2.0,0.0,0.0, 4.5,2.0,0.0, 2.0,2.0,0.0, 2.0,2.0,0.0, 4.0,2.0,0.0, 2.0,0.0,0.0 )));  SOLID with a hole  etype = 1007 exterior solid  etype = 2007 is interior solid  All polygons of etype=2007 are described as 2003's. insert into polygons3d values(14, SDO_Geometry (3008,NULL,NULL , SDO_Elem_Info_Array(1,1007,1,1,1006,7,1,1003,1,16,1003,1,31,1003,1,46,1003,1,61,1003,1,76,1003,1,94,1003,1,112,2006,6,112,2003,1,127,2003,1,142,2003,1,157,2003,1,172,2003,1,187,2003,1), SDO_Ordinate_Array(2.0,0.0,3.0, 2.0,0.0,0.0, 4.0,2.0,0.0, 4.0,2.0,3.0, 2.0,0.0,3.0, 4.5,2.0,3.0, 4.5,2.0,0.0, 2.0,0.0,0.0, 2.0,0.0,3.0, 4.5,2.0,3.0, 4.5,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,0.0, 4.5,2.0,0.0, 4.5,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,0.0, 2.0,2.0,0.0, 2.0,2.0,3.0, 4.0,2.0,3.0, 4.0,2.0,0.0, 2.0,2.0,0.0, 2.0,2.0,3.0, 4.0,2.0,3.0, 2.0,0.0,3.0, 4.0,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,3.0, 4.5,2.0,3.0, 2.0,0.0,3.0, 2.0,0.0,0.0, 4.5,2.0,0.0, 2.0,2.0,0.0, 2.0,2.0,0.0, 4.0,2.0,0.0, 2.0,0.0,0.0, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,0.5, 1.0,1.0,0.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,0.5, 1.0,1.0,0.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,0.5, 1.0,1.0,0.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,0.5, 1.0,1.0,0.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,2.5, 1.0,1.0,0.5, 1.0,1.0,0.5, 1.0,1.0,0.5, 1.0,1.0,0.5, 1.0,1.0,0.5 )));  Gtype = SOLID  The elements make up one composite solid (nondisjoint solids) like a cube  on a cube on a cube.  This is made up of two solid elements.  Each solid element here is a simple solid. insert into polygons3d values(15, SDO_Geometry (3008,NULL,NULL , SDO_Elem_Info_Array(1,1008,2,1,1007,1,1,1006,6,1,1003,1,16,1003,1,31,1003,1,46,1003,1,61,1003,1,76,1003,1,91,1007,1,91,1006,7,91,1003,1,106,1003,1,121,1003,1,136,1003,1,151,1003,1,166,1003,1,184,1003,1), SDO_Ordinate_Array(2.0,1.0,3.0, 2.0,1.0,0.0, 3.0,1.0,0.0, 3.0,1.0,3.0, 2.0,1.0,3.0, 3.0,1.0,3.0, 3.0,1.0,0.0, 3.0,1.0,0.0, 3.0,1.0,3.0, 3.0,1.0,3.0, 3.0,1.0,3.0, 3.0,1.0,0.0, 2.0,1.0,0.0, 2.0,1.0,3.0, 3.0,1.0,3.0, 2.0,1.0,3.0, 2.0,1.0,0.0, 2.0,1.0,0.0, 2.0,1.0,3.0, 2.0,1.0,3.0, 2.0,1.0,3.0, 2.0,1.0,3.0, 3.0,1.0,3.0, 3.0,1.0,3.0, 2.0,1.0,3.0, 2.0,1.0,0.0, 2.0,1.0,0.0, 3.0,1.0,0.0, 3.0,1.0,0.0, 2.0,1.0,0.0, 2.0,0.0,3.0, 2.0,0.0,0.0, 4.0,2.0,0.0, 4.0,2.0,3.0, 2.0,0.0,3.0, 4.5,2.0,3.0, 4.5,2.0,0.0, 2.0,0.0,0.0, 2.0,0.0,3.0, 4.5,2.0,3.0, 4.5,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,0.0, 4.5,2.0,0.0, 4.5,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,0.0, 2.0,2.0,0.0, 2.0,2.0,3.0, 4.0,2.0,3.0, 4.0,2.0,0.0, 2.0,2.0,0.0, 2.0,2.0,3.0, 4.0,2.0,3.0, 2.0,0.0,3.0, 4.0,2.0,3.0, 2.0,2.0,3.0, 2.0,2.0,3.0, 4.5,2.0,3.0, 2.0,0.0,3.0, 2.0,0.0,0.0, 4.5,2.0,0.0, 2.0,2.0,0.0, 2.0,2.0,0.0, 4.0,2.0,0.0, 2.0,0.0,0.0 )));
Example 217 updates the USER_SDO_GEOM_METADATA view with the necessary information about the tables created in Example 216 (POINTS3D, LINES3D, and POLYGONS3D), and it creates a spatial index on the geometry column (named GEOMETRY) in each table. The indexes are created with the PARAMETERS ('sdo_indx_dims=3')
clause, to ensure that all three dimensions are considered in operations that are supported on threedimensional geometries.
Example 217 Updating Metadata and Creating Indexes for 3Dimensional Geometries
INSERT INTO user_sdo_geom_metadata VALUES('POINTS3D', 'GEOMETRY', sdo_dim_array( sdo_dim_element('X', 100,100, 0.000005), sdo_dim_element('Y', 100,100, 0.000005), sdo_dim_element('Z', 100,100, 0.000005)), NULL); CREATE INDEX points3d_sidx on points3d(geometry) INDEXTYPE IS mdsys.spatial_index PARAMETERS ('sdo_indx_dims=3'); INSERT INTO user_sdo_geom_metadata VALUES('LINES3D', 'GEOMETRY', sdo_dim_array( sdo_dim_element('X', 100,100, 0.000005), sdo_dim_element('Y', 100,100, 0.000005), sdo_dim_element('Z', 100,100, 0.000005)), NULL); CREATE INDEX lines3d_sidx on lines3d(geometry) INDEXTYPE IS mdsys.spatial_index PARAMETERS ('sdo_indx_dims=3'); INSERT INTO user_sdo_geom_metadata VALUES('POLYGONS3D', 'GEOMETRY', sdo_dim_array( sdo_dim_element('X', 100,100, 0.000005), sdo_dim_element('Y', 100,100, 0.000005), sdo_dim_element('Z', 100,100, 0.000005)), NULL); CREATE INDEX polygons3d_sidx on polygons3d(geometry) INDEXTYPE IS mdsys.spatial_index PARAMETERS ('sdo_indx_dims=3');
The geometry metadata describing the dimensions, lower and upper bounds, and tolerance in each dimension is stored in a global table owned by MDSYS (which users should never directly update). Each Spatial user has the following views available in the schema associated with that user:
USER_SDO_GEOM_METADATA contains metadata information for all spatial tables owned by the user (schema). This is the only view that you can update, and it is the one in which Spatial users must insert metadata related to spatial tables.
ALL_SDO_GEOM_METADATA contains metadata information for all spatial tables on which the user has SELECT permission.
Spatial users are responsible for populating these views. For each spatial column, you must insert an appropriate row into the USER_SDO_GEOM_METADATA view. Oracle Spatial ensures that the ALL_SDO_GEOM_METADATA view is also updated to reflect the rows that you insert into USER_SDO_GEOM_METADATA.
Each metadata view has the following definition:
( TABLE_NAME VARCHAR2(32), COLUMN_NAME VARCHAR2(32), DIMINFO SDO_DIM_ARRAY, SRID NUMBER );
In addition, the ALL_SDO_GEOM_METADATA view has an OWNER column identifying the schema that owns the table specified in TABLE_NAME.
The following considerations apply to schema, table, and column names, and to any SDO_DIMNAME values, that are stored in any Oracle Spatial metadata views:
They must contain only letters, numbers, and underscores. For example, such a name cannot contain a space ( ), an apostrophe ('
), a quotation mark ("
), or a comma (,
).
All letters in the names are converted to uppercase before the names are stored in geometry metadata views or before the tables are accessed. This conversion also applies to any schema name specified with the table name.
The TABLE_NAME column contains the name of a feature table, such as COLA_MARKETS, that has a column of type SDO_GEOMETRY.
The table name is stored in the spatial metadata views in all uppercase characters.
The table name cannot contain spaces or mixedcase letters in a quoted string when inserted into the USER_SDO_GEOM_METADATA view, and it cannot be in a quoted string when used in a query (unless it is in all uppercase characters).
The spatial feature table cannot be an indexorganized table if you plan to create a spatial index on the spatial column.
The COLUMN_NAME column contains the name of the column of type SDO_GEOMETRY. For the COLA_MARKETS table, this column is called SHAPE.
The column name is stored in the spatial metadata views in all uppercase characters.
The column name cannot contain spaces or mixedcase letters in a quoted string when inserted into the USER_SDO_GEOM_METADATA view, and it cannot be in a quoted string when used in a query (unless it is in all uppercase characters).
The DIMINFO column is a varying length array of an object type, ordered by dimension, and has one entry for each dimension. The SDO_DIM_ARRAY type is defined as follows:
Create Type SDO_DIM_ARRAY as VARRAY(4) of SDO_DIM_ELEMENT;
The SDO_DIM_ELEMENT type is defined as:
Create Type SDO_DIM_ELEMENT as OBJECT ( SDO_DIMNAME VARCHAR2(64), SDO_LB NUMBER, SDO_UB NUMBER, SDO_TOLERANCE NUMBER);
The SDO_DIM_ARRAY instance is of size n if there are n dimensions. That is, DIMINFO contains 2 SDO_DIM_ELEMENT instances for twodimensional geometries, 3 instances for threedimensional geometries, and 4 instances for fourdimensional geometries. Each SDO_DIM_ELEMENT instance in the array must have valid (not null) values for the SDO_LB, SDO_UB, and SDO_TOLERANCE attributes.
Note: The number of dimensions reflected in the DIMINFO information must match the number of dimensions of each geometry object in the layer. 
For an explanation of tolerance and how to determine the appropriate SDO_TOLERANCE value, see Section 1.5.5, especially Section 1.5.5.1.
Spatial assumes that the varying length array is ordered by dimension. The DIMINFO varying length array must be ordered by dimension in the same way the ordinates for the points in SDO_ORDINATES varying length array are ordered. For example, if the SDO_ORDINATES varying length array contains {X1, Y1, ..., Xn, Yn}, then the first DIMINFO entry must define the X dimension and the second DIMINFO entry must define the Y dimension.
Example 21 in Section 2.1 shows the use of the SDO_GEOMETRY and SDO_DIM_ARRAY types. This example demonstrates how geometry objects (hypothetical market areas for colas) are represented, and how the COLA_MARKETS feature table and the USER_SDO_GEOM_METADATA view are populated with the data for those objects.
The SRID column should contain either of the following: the SRID value for the coordinate system for all geometries in the column, or NULL if no specific coordinate system should be associated with the geometries. (For information about coordinate systems, see Chapter 6.)
This section describes the structure of the tables containing the spatial index data and metadata. Concepts and usage notes for spatial indexing are explained in Section 1.7. The spatial index data and metadata are stored in tables that are created and maintained by the Spatial indexing routines. These tables are created in the schema of the owner of the feature (underlying) table that has a spatial index created on a column of type SDO_GEOMETRY.
There are two sets of spatial index metadata views for each schema (user): xxx_SDO_INDEX_INFO and xxx_SDO_INDEX_METADATA, where xxx can be USER or ALL. These views are readonly to users; they are created and maintained by the Spatial indexing routines.
The following views contain basic information about spatial indexes:
USER_SDO_INDEX_INFO contains index information for all spatial tables owned by the user.
ALL_SDO_INDEX_INFO contains index information for all spatial tables on which the user has SELECT permission.
The USER_SDO_INDEX_INFO and ALL_SDO_INDEX_INFO views contain the same columns, as shown Table 28, except that the USER_SDO_INDEX_INFO view does not contain the SDO_INDEX_OWNER column. (The columns are listed in their order in the view definition.)
Table 28 Columns in the xxx_SDO_INDEX_INFO Views
Column Name  Data Type  Purpose 

SDO_INDEX_OWNER 
VARCHAR2 
Owner of the index (ALL_SDO_INDEX_INFO view only). 
INDEX_NAME 
VARCHAR2 
Name of the index. 
TABLE_OWNER 
VARCHAR2 
Name of the owner of the table containing the column on which this index is built. 
TABLE_NAME 
VARCHAR2 
Name of the table containing the column on which this index is built. 
COLUMN_NAME 
VARCHAR2 
Name of the column on which this index is built. 
SDO_INDEX_TYPE 
VARCHAR2 
Contains RTREE (for an Rtree index). 
SDO_INDEX_TABLE 
VARCHAR2 
Name of the spatial index table (described in Section 2.9.2). 
SDO_INDEX_STATUS 
VARCHAR2 
(Reserved for Oracle use.) 
The following views contain detailed information about spatial index metadata:
USER_SDO_INDEX_METADATA contains index information for all spatial tables owned by the user.
ALL_SDO_INDEX_METADATA contains index information for all spatial tables on which the user has SELECT permission.
The USER_SDO_INDEX_METADATA and ALL_SDO_INDEX_METADATA views contain the same columns, as shown Table 29. (The columns are listed in their order in the view definition.)
Table 29 Columns in the xxx_SDO_INDEX_METADATA Views
Column Name  Data Type  Purpose 

SDO_INDEX_OWNER 
VARCHAR2 
Owner of the index. 
SDO_INDEX_TYPE 
VARCHAR2 
Contains RTREE (for an Rtree index). 
SDO_LEVEL 
NUMBER 
(No longer relevant; applies to a desupported feature.) 
SDO_NUMTILES 
NUMBER 
(No longer relevant; applies to a desupported feature.) 
SDO_MAXLEVEL 
NUMBER 
(No longer relevant; applies to a desupported feature.) 
SDO_COMMIT_INTERVAL 
NUMBER 
(No longer relevant; applies to a desupported feature.) 
SDO_INDEX_TABLE 
VARCHAR2 
Name of the spatial index table (described in Section 2.9.2). 
SDO_INDEX_NAME 
VARCHAR2 
Name of the index. 
SDO_INDEX_PRIMARY 
NUMBER 
Indicates if this is a primary or secondary index. 1 = primary, 2 = secondary. 
SDO_TSNAME 
VARCHAR2 
Schema name of the SDO_INDEX_TABLE. 
SDO_COLUMN_NAME 
VARCHAR2 
Name of the column on which this index is built. 
SDO_RTREE_HEIGHT 
NUMBER 
Height of the Rtree. 
SDO_RTREE_NUM_NODES 
NUMBER 
Number of nodes in the Rtree. 
SDO_RTREE_DIMENSIONALITY 
NUMBER 
Number of dimensions used internally by Spatial. This may be different from the number of dimensions indexed, which is controlled by the 
SDO_RTREE_FANOUT 
NUMBER 
Maximum number of children in each Rtree node. 
SDO_RTREE_ROOT 
VARCHAR2 
Rowid corresponding to the root node of the Rtree in the index table. 
SDO_RTREE_SEQ_NAME 
VARCHAR2 
Sequence name associated with the Rtree. 
SDO_FIXED_META 
RAW 
If applicable, this column contains the metadata portion of the SDO_GROUPCODE or SDO_CODE for a fixedlevel index. 
SDO_TABLESPACE 
VARCHAR2 
Same as in the SQL CREATE TABLE statement. Tablespace in which to create the SDOINDEX table. 
SDO_INITIAL_EXTENT 
VARCHAR2 
Same as in the SQL CREATE TABLE statement. 
SDO_NEXT_EXTENT 
VARCHAR2 
Same as in the SQL CREATE TABLE statement. 
SDO_PCTINCREASE 
NUMBER 
Same as in the SQL CREATE TABLE statement. 
SDO_MIN_EXTENTS 
NUMBER 
Same as in the SQL CREATE TABLE statement. 
SDO_MAX_EXTENTS 
NUMBER 
Same as in the SQL CREATE TABLE statement. 
SDO_INDEX_DIMS 
NUMBER 
Number of dimensions of the geometry objects in the column on which this index is built, as determined by the value of the 
SDO_LAYER_GTYPE 
VARCHAR2 
Contains DEFAULT if the layer can contain both point and polygon data, or a value from the Geometry Type column of Table 21 in Section 2.2.1. 
SDO_RTREE_PCTFREE 
NUMBER 
Minimum percentage of slots in each index tree node to be left empty when an Rtree index is created. 
SDO_INDEX_PARTITION 
VARCHAR2 
For a partitioned index, name of the index partition. 
SDO_PARTITIONED 
NUMBER 
Contains 0 if the index is not partitioned or 1 if the index is partitioned. 
SDO_RTREE_QUALITY 
NUMBER 
Quality score for an index. See the information about Rtree quality in Section 1.7.2. 
SDO_INDEX_VERSION 
NUMBER 
Internal version number of the index. 
SDO_INDEX_GEODETIC 
VARCHAR2 
Contains TRUE if the index is geodetic and FALSE if the index is not geodetic. 
SDO_INDEX_STATUS 
VARCHAR2 
(Reserved for Oracle use.) 
SDO_NL_INDEX_TABLE 
VARCHAR2 
Name of a separate index table (with a name in the form MDNT_...$) for nonleaf nodes of the index. For more information, see the description of the 
SDO_DML_BATCH_SIZE 
NUMBER 
Number of index updates to be processed in each batch of updates after a commit operation. For more information, see the description of the 
SDO_RTREE_EXT_XPND 
NUMBER 
(Reserved for future use.) 
SDO_ROOT_MBR 
SDO_GEOMETRY 
Minimum bounding rectangle of the maximum extent of the spatial layer. This is greater than or equal to the MBR of the current extent, and is reset to reflect the current extent when the index is rebuilt. 
For an Rtree index, a spatial index table (each SDO_INDEX_TABLE entry as described in Table 29 in Section 2.9.1.2) contains the columns shown in Table 210.
Table 210 Columns in an RTree Spatial Index Data Table
Column Name  Data Type  Purpose 

NODE_ID 
NUMBER 
Unique ID number for this node of the tree. 
NODE_LEVEL 
NUMBER 
Level of the node in the tree. Leaf nodes (nodes whose entries point to data items in the base table) are at level 1, their parent nodes are at level 2, and so on. 
INFO 
BLOB 
Other information in a node. Includes an array of 
Each Rtree spatial index table has an associated sequence object (SDO_RTREE_SEQ_NAME in the USER_SDO_INDEX_METADATA view, described in Table 29 in Section 2.9.1.2). The sequence is used to ensure that simultaneous updates can be performed to the index by multiple concurrent users.
The sequence name is the index table name with the letter S replacing the letter T before the underscore (for example, the sequence object MDRS_5C01$ is associated with the index table MDRT_5C01$).
Geometry functions that involve measurement allow an optional unit
parameter to specify the unit of measurement for a specified distance or area, if a georeferenced coordinate system (SDO_SRID value) is associated with the input geometry or geometries. The unit
parameter%p is not valid for geometries with a null SDO_SRID value (that is, an orthogonal Cartesian system). For information about support for coordinate systems, see Chapter 6.
The default unit of measure is the one associated with the georeferenced coordinate system. The unit of measure for most coordinate systems is the meter, and in these cases the default unit for distances is meter and the default unit for areas is square meter. By using the unit
parameter, however, you can have Spatial automatically convert and return results that are more meaningful to application users, for example, displaying the distance to a restaurant in miles.
The unit
parameter must be enclosed in single quotation marks and contain the string unit=
and a valid UNIT_OF_MEAS_NAME value from the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27). For example, 'unit=KM' in the following example (using data and definitions from Example 617 in Section 6.13) specifies kilometers as the unit of measurement:
SELECT c.name, SDO_GEOM.SDO_LENGTH(c.shape, m.diminfo, 'unit=KM') FROM cola_markets_cs c, user_sdo_geom_metadata m WHERE m.table_name = 'COLA_MARKETS_CS' AND m.column_name = 'SHAPE';
Spatial uses the information in the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27) to determine which unit names are valid and what ratios to use in comparing or converting between different units. For convenience, you can also use the following legacy views to see the angle, area, and distance units of measure:
MDSYS.SDO_ANGLE_UNITS (described in Section 6.8.2)
MDSYS.SSDO_AREA_UNITS (described in Section 6.8.3)
MDSYS.SSDO_DIST_UNITS (described in Section 6.8.5)
If the area and distance units of measurement supplied by Oracle are not sufficient for your needs, you can create userdefined area and distance units. (You cannot create a userdefined angle unit.) To do so, you must connect to the database as a user that has been granted the DBA role, and insert a row for each desired unit to the SDO_UNITS_OF_MEASURE table (described in Section 6.7.27)
Table 211 lists the columns in the SDO_UNITS_OF_MEASURE table and the requirements and recommendations for each if you are inserting a row for a userdefined unit of measurement.
Table 211 SDO_UNITS_OF_MEASURE Table Entries for UserDefined Unit
Column Name  Description 

UOM_ID 
Any unit of measure ID number not currently used for an Oraclesupplied unit or another userdefined unit. Example: 
UNIT_OF_MEAS_NAME 
Name of the userdefined unit of measurement. Example: 
SHORT_NAME 
Optional short name (if any) of the unit of measurement. 
UNIT_OF_MEAS_TYPE 
Type of measure for which the unit is used. Must be either 
TARGET_UOM_ID 
Optional, but for support purposes you should enter one of the following: 
FACTOR_B 
For a value that can be expressed as a floating point number, specify how many square meters (for an area unit) or meters (for a distance unit) are equal to one of the userdefined unit. For example, for a unit defined as onehalf of a standard meter, specify: For a value that cannot be expressed as a simple floating point number, specify the dividend for the expression FACTOR_B/FACTOR_C that determines how many square meters (for an area unit) or meters (for a distance unit) are equal to one of the userdefined unit. 
FACTOR_C 
For a value that can be expressed as a floating point number, specify 1. For a value that cannot be expressed as a simple floating point number, specify the divisor for the expression FACTOR_B/FACTOR_C that determines how many square meters (for an area unit) or meters (for a distance unit) are equal to one of the userdefined unit. 
INFORMATION_SOURCE 
Specify the following: 
DATA_SOURCE 
A phrase briefly describing the unit. Example: 
IS_LEGACY 
Specify the following: 
LEGACY_CODE 
(Do not use this for a userdefined unit.) 
Example 218 creates a userdefined distance unit named HALF_METER
, and uses it in a query to find all customers within 400,000 halfmeters (200 kilometers) of a specified store.
Example 218 Creating and Using a UserDefined Unit of Measurement
 Distance unit: HALF_METER  FACTOR_B specifies how many meters = one of this unit. INSERT INTO MDSYS.SDO_UNITS_OF_MEASURE (UOM_ID, UNIT_OF_MEAS_NAME, UNIT_OF_MEAS_TYPE, TARGET_UOM_ID, FACTOR_B, FACTOR_C, INFORMATION_SOURCE, DATA_SOURCE, IS_LEGACY) VALUES (100001, 'HALF_METER', 'length', 100001, .5, 1, 'Userdefined half meter', 'USER_DEFINED', 'FALSE'); . . .  Find all the customers within 400,000 halfmeters of store_id = 101 SELECT /*+ordered*/ c.customer_id, c.first_name, c.last_name FROM stores s, customers c WHERE s.store_id = 101 AND sdo_within_distance (c.cust_geo_location, s.store_geo_location, 'distance = 400000 unit = HALF_METER') = 'TRUE'; CUSTOMER_ID FIRST_NAME LAST_NAME    1005 Carla Rodriguez 1004 Thomas Williams 1003 Marian Chang 1001 Alexandra Nichols
This document has the following parts:
Part I provides conceptual and usage information about Oracle Spatial.
Part II provides conceptual and usage information about Oracle Spatial Web services.
Part III provides reference information about Oracle Spatial operators, functions, and procedures.
Part IV provides supplementary information (appendixes and a glossary).
Part IV contains the following:
Oracle Spatial Developer's Guide provides usage and reference information for indexing and storing spatial data and for developing spatial applications using Oracle Spatial and Oracle Locator.
Oracle Spatial requires the Enterprise Edition of Oracle Database 11g. It is a foundation for the deployment of enterprisewide spatial information systems, and Webbased and wireless locationbased applications requiring complex spatial data management. Oracle Locator is a feature of the Standard and Enterprise Editions of Oracle Database 11g. It offers a subset of Oracle Spatial capabilities (see Appendix B for a list of Locator features) typically required to support Internet and wireless service applications and partnerbased geographic information system (GIS) solutions.
The Standard and Enterprise Editions of Oracle Database 11g have the same basic features. However, several advanced features, such as extended data types, are available only with the Enterprise Edition, and some of these features are optional. For example, to use Oracle Database 11g table partitioning, you must have the Enterprise Edition and the Partitioning Option.
For information about the differences between Oracle Database 11g Standard Edition and Oracle Database 11g Enterprise Edition and the features and options that are available to you, see Oracle Database New Features Guide.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc
.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info
or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs
if you are hearing impaired.
For more information, see the following documents:
Oracle Spatial Topology and Network Data Models Developer's Guide
Oracle Database Error Messages  Spatial messages are in the range of 13000 to 13499.
The following text conventions are used in this document:
Convention  Meaning 

boldface  Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary. 
italic  Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values. 
monospace  Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter. 
This chapter contains descriptions of the spatial utility subprograms shown in Table 321.
Table 321 Spatial Utility Subprograms
Subprogram  Description 


Returns a geometry that reflects an affine transformation of the input geometry. 

Appends one geometry to another geometry to create a new geometry. 
SDO_UTIL.BEARING_TILT_FOR_POINTS 
Computes the bearing and tilt from a start point to an end point. 

Returns the polygon geometry that approximates and is covered by a specified circle. 

Concatenates two line or multiline twodimensional geometries to create a new geometry. 

Converts values from one angle, area, or distance unit of measure to another. 

Returns the polygon geometry that approximates and is covered by a specified ellipse. 

Returns the twodimensional geometry that represents a specified element (and optionally a ring) of the input twodimensional geometry. 

Returns all elements and subelements of the input twodimensional geometry, as an array of one or more geometries. 

Returns the threedimensional geometry that represents a specified subset of the input threedimensional geometry. 

Returns the threedimensional extrusion solid geometry from an input twodimensional polygon geometry. 

Converts a geography markup language (GML 3.1.1) fragment to a Spatial geometry object. 

Converts a geography markup language (GML 2.0) fragment to a Spatial geometry object. 

Converts a KML (Keyhole Markup Language) document to a Spatial geometry object. 

Converts a geometry in the wellknown binary (WKB) format to a Spatial geometry object. 

Converts a geometry in the wellknown text (WKT) format to a Spatial geometry object. 

Returns the number of elements in the input geometry. 

Returns the number of vertices in the input geometry. 

Returns the coordinates of the vertices of the input geometry. 
SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS 
Initializes all spatial indexes in a tablespace that was transported to another database. 

Returns a point that is guaranteed to be an interior point (not on the boundary or edge) on the surface of a polygon geometry object. 

Returns a point geometry that is at the specified distance and bearing from the start point. 

Converts all polygontype elements in a geometry to linetype elements, and sets the SDO_GTYPE value accordingly. 

Prepares a tablespace to be transported to another database, so that spatial indexes will be preserved during the transport operation. 

Fixes certain problems with the input geometry, and returns a valid geometry. 
SDO_UTIL.REMOVE_DUPLICATE_VERTICES 
Removes duplicate (redundant) vertices from a geometry. 

Returns a line string geometry with the vertices of the input geometry in reverse order. 

Simplifies the input geometry, based on a threshold value, using the DouglasPeucker algorithm. 

Converts a Spatial geometry object to a geography markup language (GML 3.1.1) fragment based on the geometry types defined in the Open GIS 

Converts a Spatial geometry object to a geography markup language (GML 2.0) fragment based on the geometry types defined in the Open GIS 

Converts a Spatial geometry object to a KML (Keyhole Markup Language) document. 

Converts a Spatial geometry object to the wellknown binary (WKB) format. 

Converts a Spatial geometry object to the wellknown text (WKT) format. 

Validates the input geometry, which is in the standard wellknown binary (WKB) format; returns the string 

Validates the input geometry, which is of type CLOB or VARCHAR2 and in the standard wellknown text (WKT) format; returns the string 
Format
SDO_UTIL.AFFINETRANSFORMS(
geometry IN SDO_GEOMETRY,
translation IN VARCHAR2,
tx IN NUMBER,
ty IN NUMBER,
tz IN NUMBER,
scaling IN VARCHAR2,
psc1 IN SDO_GEOMETRY
sx IN NUMBER,
sy IN NUMBER,
sz IN NUMBER,
rotation IN VARCHAR2,
p1 IN SDO_GEOMETRY,
line1 IN SDO_GEOMETRY,
angle IN NUMBER,
dir IN NUMBER,
shearing IN VARCHAR2
shxy IN NUMBER,
shyx IN NUMBER,
shxz IN NUMBER,
shzx IN NUMBER,
shyz IN NUMBER,
shzy IN NUMBER,
reflection IN VARCHAR2
pref IN SDO_GEOMETRY,
lineR IN SDO_GEOMETRY,
dirR IN NUMBER,
planeR IN VARCHAR2,
n IN SDO_NUMBER_ARRAY,
bigD IN SDO_NUMBER_ARRAY,
) RETURN SDO_GEOMETRY;
Parameters
Input geometry on which to perform the affine transformation.
A string value of TRUE causes translation to be performed; a string value of FALSE causes translation not to be performed. If this parameter is TRUE, translation is performed about the point at (tx,ty) or (tx,ty,tz).
Xaxis value for translation.
Yaxis value for translation.
Zaxis value for translation.
A string value of TRUE causes scaling to be performed; a string value of FALSE causes scaling not to be performed.
Point on the input geometry about which to perform the scaling. If scaling
is TRUE
, this geometry should be either a zero point (point geometry with 0,0 or 0,0,0 ordinates for scaling about the origin) or a nonzero point (point geometry with ordinates for scaling about a point other than the origin). If scaling
is FALSE
, psc1
can be a null value.
Xaxis value for scaling (about either the point specified in the psc1
parameter or the origin).
Yaxis value for scaling (about either the point specified in the psc1
parameter or the origin).
Zaxis value for scaling (about either the point specified in the psc1
parameter or the origin).
A string value of TRUE causes rotation to be performed; a string value of FALSE causes rotation not to be performed.
For twodimensional geometries, rotation uses the p1
and angle
values. For threedimensional geometries, rotation uses either the angle
and dir
values or the line1
and angle
values.
Point for twodimensional geometry rotation about a specified point.
Line for rotation about a specified axis.
Angle rotation parameter (in radians) for rotation about a specified axis or about the X, Y, or Z axis.
Rotation parameter for x(0), y(1), or z(2)axis roll. If the rotation
parameter value is TRUE
but the dir
parameter is not used, specify a value of 1.
A string value of TRUE causes shearing to be performed; a string value of FALSE causes shearing not to be performed.
For twodimensional geometries, shearing uses the shxy
and shyx
parameter values. For threedimensional geometries, shearing uses the shxy
, shyx
, shxz
, shzx
, shyz
, and shzy
parameter values.
Value for shearing due to X along the Y direction.
Value for shearing due to Y along the X direction.
Value for shearing due to X along the Z direction (threedimensional geometries only).
Value for shearing due to Z along the X direction (threedimensional geometries only).
Value for shearing due to Y along the Z direction (threedimensional geometries only).
Value for shearing due to Z along the Y direction (threedimensional geometries only).
A string value of TRUE causes reflection to be performed; a string value of FALSE causes reflection not to be performed.
For twodimensional geometries, reflection uses the lineR
value for reflection about an axis and the pref
value for the centroid for selfreflection. For threedimensional geometries, reflection uses the lineR
value for reflection about an axis; the dirR
value for reflection about the yz, xz, and xy planes; the planeR
, n
, and bigD
values for reflection about a specified plane; and the pref
value for the centroid for selfreflection.
Point through which to perform reflection.
Line along which to perform reflection.
Number indicating the plane about (through) which to perform reflection: 0 for the yz plane, 1 for the xz plane, or 2 for the xy plane. If the reflection
parameter value is TRUE
but the dirR
parameter is not used, specify a value of 1.
A string value of TRUE causes reflection about an arbitrary plane to be performed; a string value of FALSE causes reflection about an arbitrary plane not to be performed.
Normal vector of the plane.
Delta value for the plane equation in threedimensional geometries.
For threedimensional geometries, bigD = delta and n = (A,B,C) where n is the normal of the plane in threedimensional space. Thus, the plane equation is:
Ax+By+Cz+bigD = 3DDotProd(n,anypointonplane)+bigD = 0
Usage Notes
The order of affine transforms matter because these are matrix and vector multiplications.
You should validate the resulting geometry using the SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT function.
Examples
The following example performs an affine transformation on a twodimensional geometry.
 Polygon reflection in 2D about a specified line segment SELECT SDO_UTIL.AFFINETRANSFORMS( geometry => MDSYS.SDO_GEOMETRY(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1), MDSYS.SDO_ORDINATE_ARRAY( 1.5,0, 2.5,1, 1.5,2, 0.5,2, 0.5,0, 1.5,0)), translation => 'FALSE', tx => 0.0, ty => 0.0, tz => 0.0, scaling => 'FALSE', psc1 => NULL, sx => 0.0, sy => 0.0, sz => 0.0, rotation => 'FALSE', p1 => NULL, line1 => NULL, angle => 0.0, dir => 0, shearing => 'FALSE', shxy => 0.0, shyx => 0.0, shxz => 0.0, shzx => 0.0, shyz => 0.0, shzy => 0.0, reflection => 'TRUE', pref => NULL, lineR => MDSYS.SDO_GEOMETRY(2002,0,NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1), MDSYS.SDO_ORDINATE_ARRAY(2.5,0.0,2.5,2.0)), dirR => 1, planeR => 'FALSE', n => NULL, bigD => NULL ) FROM DUAL; SDO_UTIL.AFFINETRANSFORMS(GEOMETRY=>MDSYS.SDO_GEOMETRY(2003,NULL,NULL,MDSYS.SDO_  SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3.5, 0, 2.5, 1, 3.5, 2, 4.5, 2, 4.5, 0, 3.5, 0))
The following example performs an affine transformation on a threedimensional geometry.
 Polygon reflection in 3D about a specified plane (z=1 plane in this example) SELECT SDO_UTIL.AFFINETRANSFORMS( geometry => MDSYS.SDO_GEOMETRY(3003, 0, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1), MDSYS.SDO_ORDINATE_ARRAY( 1.5,0,0, 2.5,1,0, 1.5,2,0, 0.5,2,0, 0.5,0,0, 1.5,0,0)), translation => 'FALSE', tx => 0.0, ty => 0.0, tz => 0.0, scaling => 'FALSE', psc1 => NULL, sx => 0.0, sy => 0.0, sz => 0.0, rotation => 'FALSE', p1 => NULL, line1 => NULL, angle => 0.0, dir => 0, shearing => 'FALSE', shxy => 0.0, shyx => 0.0, shxz => 0.0, shzx => 0.0, shyz => 0.0, shzy => 0.0, reflection => 'TRUE', pref => NULL, lineR => NULL, dirR => 1, planeR => 'TRUE', n => SDO_NUMBER_ARRAY(0.0, 0.0, 1.0), bigD => SDO_NUMBER_ARRAY(1.0) ) FROM DUAL; SDO_UTIL.AFFINETRANSFORMS(GEOMETRY=>MDSYS.SDO_GEOMETRY(3003,0,NULL,MDSYS.SDO_ELE  SDO_GEOMETRY(3003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(1.5, 0, 2, 2.5, 1, 2, 1.5, 2, 2, .5, 2, 2, .5, 0, 2, 1.5, 0, 2))
Parameters
Geometry object to which geometry2
is to be appended.
Geometry object to append to geometry1
.
Usage Notes
This function should be used only on geometries that do not have any spatial interaction (that is, on disjoint objects). If the input geometries are not disjoint, the resulting geometry might be invalid.
This function does not perform a union operation or any other computational geometry operation. To perform a union operation, use the SDO_GEOM.SDO_UNION function, which is described in Chapter 24. The APPEND function executes faster than the SDO_GEOM.SDO_UNION function.
The geometry type (SDO_GTYPE value) of the resulting geometry reflects the types of the input geometries and the append operation. For example, if the input geometries are twodimensional polygons (SDO_GTYPE = 2003), the resulting geometry is a twodimensional multipolygon (SDO_GTYPE = 2007).
An exception is raised if geometry1
and geometry2
are based on different coordinate systems.
Examples
The following example appends the cola_a
and cola_c
geometries. (The example uses the definitions and data from Section 2.1.)
SELECT SDO_UTIL.APPEND(c_a.shape, c_c.shape) FROM cola_markets c_a, cola_markets c_c WHERE c_a.name = 'cola_a' AND c_c.name = 'cola_c'; SDO_UTIL.APPEND(C_A.SHAPE,C_C.SHAPE)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SD  SDO_GEOMETRY(2007, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3, 5, 1003, 1), SDO_ ORDINATE_ARRAY(1, 1, 5, 7, 3, 3, 6, 3, 6, 5, 4, 5, 3, 3))
Format
SDO_UTIL.BEARING_TILT_FOR_POINTS(
start_point IN SDO_GEOMETRY,
end_point IN SDO_GEOMETRY,
tol IN NUMBER,
bearing OUT NUMBER,
tilt OUT NUMBER
) RETURN SDO_GEOMETRY;
Parameters
Starting point geometry object from which to compute the bearing and tilt. The point geometry must be based on a geodetic coordinate system.
Ending point geometry object to use in computing the bearing and tilt. The point geometry must be based on the same geodetic coordinate system as start_point
.
Tolerance value (see Section 1.5.5).
Number of radians, measured clockwise from North.
Number of radians, measured from the normal.
Usage Notes
The input point geometries must be based on the same geodetic coordinate system. If they are based on a nongeodetic coordinate system, the output bearing is a null value.
The tilt is computed as the arctangent of the difference between the height values divided by the distance between the points (with height excluded from the distance calculation). That is: tilt = atan(height_difference/distance)
To convert radians to decimal degrees or decimal degrees to radians, you can use the SDO_UTIL.CONVERT_UNIT function. To return a point geometry that is at a specified distance and bearing from a start point, you can use the SDO_UTIL.POINT_AT_BEARING function.
Examples
The following example computes the bearing and tilt for two longitude/latitude points, where the elevation of the start point is 0 (zero) and the elevation of the end point is 5000 meters. This example displays the bearing and tilt values in radians.
DECLARE bearing NUMBER; tilt NUMBER; BEGIN SDO_UTIL.BEARING_TILT_FOR_POINTS( SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(71.5, 43, 0), NULL, NULL),  start_point SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(71, 43.5, 5000), NULL, NULL),  end_point 0.05, tolerance bearing, tilt); DBMS_OUTPUT.PUT_LINE('Bearing = '  bearing); DBMS_OUTPUT.PUT_LINE('Tilt = '  tilt); END; / Bearing = .628239101930666 Tilt = .0725397288678286910476298724869396973718
The following example is the same as the preceding one, except that it displays the bearing and tilt in decimal degrees instead of radians.
DECLARE bearing NUMBER; tilt NUMBER; BEGIN SDO_UTIL.BEARING_TILT_FOR_POINTS( SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(71.5, 43, 0), NULL, NULL),  start_point SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(71, 43.5, 5000), NULL, NULL),  end_point 0.05, tolerance bearing, tilt); DBMS_OUTPUT.PUT_LINE('Bearing in degrees = '  bearing * 180 / 3.1415926535897932384626433832795); DBMS_OUTPUT.PUT_LINE('Tilt in degrees = '  tilt * 180 / 3.1415926535897932384626433832795); END; / Bearing in degrees = 35.99544906571628894295547577999851892359 Tilt in degrees = 4.15622031114988533540349823511872120415
Format
SDO_UTIL.CIRCLE_POLYGON(
center_longitude IN NUMBER,
center_latitude IN NUMBER,
radius IN NUMBER,
arc_tolerance IN NUMBER
) RETURN SDO_GEOMETRY;
Parameters
Center longitude (in degrees) of the circle to be used to create the returned geometry.
Center latitude (in degrees) of the circle to be used to create the returned geometry.
Length (in meters) of the radius of the circle to be used to create the returned geometry.
A numeric value to be used to construct the polygon geometry. The arc_tolerance
parameter value has the same meaning and usage guidelines as the arc_tolerance
keyword value in the params
parameter string for the SDO_GEOM.SDO_ARC_DENSIFY function. The unit of measurement associated with the geometry is associated with the arc_tolerance
parameter value. (For more information, see the Usage Notes for the SDO_GEOM.SDO_ARC_DENSIFY function in Chapter 24.)
Usage Notes
This function is useful for creating a circlelike polygon around a specified center point when a true circle cannot be used (a circle is not valid for geodetic data with Oracle Spatial). The returned geometry has an SDO_SRID value of 8307 (for Longitude / Latitude (WGS 84)
).
Examples
The following example returns a circlelike polygon around a point near the center of Concord, Massachusetts. A radius
value of 100 meters and an arc_tolerance
value of 5 meters are used in computing the polygon vertices.
SELECT SDO_UTIL.CIRCLE_POLYGON(71.34937, 42.46101, 100, 5) FROM DUAL; SDO_UTIL.CIRCLE_POLYGON(71.34937,42.46101,100,5)(SDO_GTYPE, SDO_SRID, SDO_POINT  SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(71.34937, 42.4601107, 71.348653, 42.4602824, 71.348211, 42.4607321, 71.34 8211, 42.4612879, 71.348653, 42.4617376, 71.34937, 42.4619093, 71.350087, 42. 4617376, 71.350529, 42.4612879, 71.350529, 42.4607321, 71.350087, 42.4602824, 71.34937, 42.4601107))
Format
SDO_UTIL.CONCAT_LINES(
geometry1 IN SDO_GEOMETRY,
geometry2 IN SDO_GEOMETRY
) RETURN SDO_GEOMETRY;
Parameters
First geometry object for the concatenation operation.
Second geometry object for the concatenation operation.
Usage Notes
Each input geometry must be a twodimensional line or multiline geometry (that is, the SDO_GTYPE value must be 2002 or 2006). This function is not supported for LRS geometries. To concatenate LRS geometric segments, use the SDO_LRS.CONCATENATE_GEOM_SEGMENTS function (described in Chapter 25).
The input geometries must be line strings whose vertices are connected by straight line segments. Circular arcs and compound line strings are not supported.
If an input geometry is a multiline geometry, the elements of the geometry must be disjoint. If they are not disjoint, this function may return incorrect results.
The topological relationship between geometry1
and geometry2
must be DISJOINT or TOUCH; and if the relationship is TOUCH, the geometries must intersect only at two end points.
You can use the SDO_AGGR_CONCAT_LINES spatial aggregate function (described in Chapter 20) to concatenate multiple twodimensional line or multiline geometries.
An exception is raised if geometry1
and geometry2
are based on different coordinate systems.
Examples
The following example concatenates two simple line string geometries.
 Concatenate two touching lines: one from (1,1) to (5,1) and the  other from (5,1) to (8,1). SELECT SDO_UTIL.CONCAT_LINES( SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(1,1, 5,1)), SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(5,1, 8,1)) ) FROM DUAL; SDO_UTIL.CONCAT_LINES(SDO_GEOMETRY(2002,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO  SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 1, 1, 5, 1, 8, 1))
Format
SDO_UTIL.CONVERT_UNIT(
ivalue IN NUMBER,
in_unit IN VARCHAR2,
out_unit IN VARCHAR2
) RETURN NUMBER;
Parameters
Number of units to be converted. For example, to convert 10 decimal degrees to radians, specify 10
.
The unit of measure from which to convert the input value. Must be a value from the SDO_UNIT column of the MDSYS.SDO_ANGLE_UNITS table (described in Section 6.8.2), the MDSYS.SDO_AREA_UNITS table (described in Section 2.10), or the MDSYS.SDO_DIST_UNITS table (described in Section 2.10). For example, to convert decimal degrees to radians, specify Degree
.
The unit of measure into which to convert the input value. Must be a value from the SDO_UNIT column of the same table used for in_unit
. For example, to convert decimal degrees to radians, specify Radian
.
Usage Notes
The value returned by this function might not be correct at an extremely high degree of precision because of the way internal mathematical operations are performed, especially if they involve small numbers or irrational numbers (such as pi). For example, converting 1 decimal degree into decimal minutes results in the value 60.0000017.
Description
Drops any transient ("scratch") tables and views in the current schema that were created during the creation of a point cloud or TIN.
Parameters
Object ID string representing a hexadecimal number. Use the string given in the error message that indicated that scratch tables need to be dropped.
Usage Notes
If scratch tables still exist from a previous SDO_PC_PKG.CREATE_PC or SDO_TIN_PKG.CREATE_TIN operation when you try to create a point cloud or TIN, an error message is displayed indicating that you must first drop the scratch tables. Use the SDO_UTIL.DROP_WORK_TABLES procedure to drop these scratch tables.
This procedure drops all tables and views that match 'M%_<oidstr>$$%'
.
Examples
The following example drops the scratch tables from a previous SDO_PC_PKG.CREATE_PC or SDO_TIN_PKG.CREATE_TIN operation, using an OID string specified in a previous error message.
EXECXUTE SDO_UTIL.DROP_WORK_TABLES('A1B2C3');
Format
SDO_UTIL.ELLIPSE_POLYGON(
center_longitude IN NUMBER,
center_latitude IN NUMBER,
semi_major_axis IN NUMBER,
semi_minor_axis IN NUMBER,
azimuth IN NUMBER,
arc_tolerance IN NUMBER
) RETURN SDO_GEOMETRY;
Parameters
Center longitude (in degrees) of the ellipse to be used to create the returned geometry.
Center latitude (in degrees) of the ellipse to be used to create the returned geometry.
Length (in meters) of the semimajor axis of the ellipse to be used to create the returned geometry.
Length (in meters) of the semiminor axis of the ellipse to be used to create the returned geometry.
Number of degrees of the azimuth (clockwise rotation of the major axis from north) of the ellipse to be used to create the returned geometry. Must be from 0 to 180. The returned geometry is rotated by the specified number of degrees.
A numeric value to be used to construct the polygon geometry. The arc_tolerance
parameter value has the same meaning and usage guidelines as the arc_tolerance
keyword value in the params
parameter string for the SDO_GEOM.SDO_ARC_DENSIFY function. The unit of measurement associated with the geometry is associated with the arc_tolerance
parameter value. (For more information, see the Usage Notes for the SDO_GEOM.SDO_ARC_DENSIFY function in Chapter 24.)
Usage Notes
This function is useful for creating an ellipselike polygon around a specified center point when a true ellipse cannot be used (an ellipse is not valid for geodetic data with Oracle Spatial). The returned geometry has an SDO_SRID value of 8307 (for Longitude / Latitude (WGS 84)
).
Examples
The following example returns an ellipselike polygon, oriented eastwest (azimuth
= 90), around a point near the center of Concord, Massachusetts. An arc_tolerance
value of 5 meters is used in computing the polygon vertices.
SELECT SDO_UTIL.ELLIPSE_POLYGON(71.34937, 42.46101, 100, 50, 90, 5) FROM DUAL; SDO_UTIL.ELLIPSE_POLYGON(71.34937,42.46101,100,50,90,5)(SDO_GTYPE, SDO_SRID, SD  SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(71.350589, 42.46101, 71.350168, 42.4606701, 71.349708, 42.460578, 71.3493 7, 42.4605603, 71.349032, 42.460578, 71.348572, 42.4606701, 71.348151, 42.461 01, 71.348572, 42.4613499, 71.349032, 42.461442, 71.34937, 42.4614597, 71.34 9708, 42.461442, 71.350168, 42.4613499, 71.350589, 42.46101))
Format
SDO_UTIL.EXTRACT(
geometry IN SDO_GEOMETRY,
element IN NUMBER,
ring IN NUMBER DEFAULT 0
) RETURN SDO_GEOMETRY;
Description
Returns the twodimensional geometry that represents a specified element (and optionally a ring) of the input twodimensional geometry.
Parameters
Geometry from which to extract the geometry to be returned. Must be a twodimensional geometry.
Number of the element in the geometry: 1 for the first element, 2 for the second element, and so on. Geometries with SDO_GTYPE values (explained in Section 2.2.1) ending in 1, 2, or 3 have one element; geometries with SDO_GTYPE values ending in 4, 5, 6, or 7 can have more than one element. For example, a multipolygon with an SDO_GTYPE of 2007 might contain three elements (polygons).
Number of the subelement (ring) within element
: 1 for the first subelement, 2 for the second subelement, and so on. This parameter is valid only for specifying a subelement of a polygon with one or more holes or of a point cluster:
For a polygon with holes, its first subelement is its exterior ring, its second subelement is its first interior ring, its third subelement is its second interior ring, and so on. For example, in the polygon with a hole shown in Figure 24 in Section 2.7.2, the exterior ring is subelement 1 and the interior ring (the hole) is subelement 2.
For a point cluster, its first subelement is the first point in the point cluster, its second subelement is the second point in the point cluster, and so on.
The default is 0, which causes the entire element to be extracted.
Usage Notes
This function applies to twodimensional geometries only. For threedimensional geometries, use the SDO_UTIL.EXTRACT3D function.
This function is useful for extracting a specific element or subelement from a complex geometry. For example, if you have identified a geometry as invalid by using the SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT function or the SDO_GEOM.VALIDATE_LAYER_WITH_CONTEXT procedure (both of which are documented in Chapter 24), you can use the EXTRACT function to extract the invalid geometry in order to examine it.
For a polygon with one or more holes, the returned geometry representing an extracted interior ring is reoriented so that its vertices are presented in counterclockwise order (as opposed to the clockwise order within an interior ring).
If geometry
is null or has an SDO_GTYPE value ending in 0, this function returns a null geometry.
geometry
cannot contain a type 0 (zero) element. Type 0 elements are described in Section 2.7.7.
This function is not intended for use with geometries that have any null ordinate values. Any null ordinate values in the returned geometry are replaced by 0 (zero).
An exception is raised if element
or ring
is an invalid number for geometry
.
Examples
The following example extracts the first (and only) element in the cola_c
geometry. (The example uses the definitions and data from Section 2.1.)
SELECT c.name, SDO_UTIL.EXTRACT(c.shape, 1) FROM cola_markets c WHERE c.name = 'cola_c'; NAME  SDO_UTIL.EXTRACT(C.SHAPE,1)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_IN  cola_c SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(3, 3, 6, 3, 6, 5, 4, 5, 3, 3))
The following example inserts a polygon with a hole (using the same INSERT statement as in Example 27 in Section 2.7.2), and extracts the geometry representing the hole (the second subelement). Notice that in the geometry returned by the EXTRACT function, the vertices are in counterclockwise order, as opposed to the clockwise order in the hole (second subelement) in the input geometry.
 Insert polygon with hole. INSERT INTO cola_markets VALUES( 10, 'polygon_with_hole', SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1, 19,2003,1),  polygon with hole SDO_ORDINATE_ARRAY(2,4, 4,3, 10,3, 13,5, 13,9, 11,13, 5,13, 2,11, 2,4, 7,5, 7,10, 10,10, 10,5, 7,5) ) ); 1 row created.  Extract the hole geometry (second subelement). SELECT SDO_UTIL.EXTRACT(c.shape, 1, 2) FROM cola_markets c WHERE c.name = 'polygon_with_hole'; SDO_UTIL.EXTRACT(C.SHAPE,1,2)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_  SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(7, 5, 10, 5, 10, 10, 7, 10, 7, 5))
Format
SDO_UTIL.EXTRACT_ALL(
geometry IN SDO_GEOMETRY,
flatten IN NUMBER DEFAULT 1
) RETURN SDO_GEOMETRY_ARRAY;
Description
Returns all elements and subelements of the input twodimensional geometry, as an array of one or more geometries. Returns an object of type SDO_GEOMETRY_ARRAY, which is defined as VARRAY OF SDO_GEOMETRY
.
Parameters
Geometry from which to extract all elements and subelements. Must be a twodimensional geometry.
A flag indicating whether to "flatten" rings into individual geometries for geometries that contain an exterior ring and one or more interior rings:
0
(zero) returns one geometry for each element, but does not flatten rings into individual geometries. (A geometry will still be returned for each element of the input geometry.)
1
(the default) or any other nonzero value flattens rings into individual geometries.
For example, if a polygon contains an outer ring and an inner ring, a value of 0
returns a single geometry containing both rings, and a value of 1
returns two geometries, each containing a ring as a geometry.
This parameter is ignored for geometries that do not contain an exterior ring and one or more interior rings.
Usage Notes
This function applies to twodimensional geometries only. For threedimensional geometries, use the SDO_UTIL.EXTRACT3D function.
This function enables you to extract all elements and subelements from a geometry, regardless of how many elements and subelements the geometry has. Geometries with SDO_GTYPE values (explained in Section 2.2.1) ending in 1, 2, or 3 have one element; geometries with SDO_GTYPE values ending in 4, 5, 6, or 7 can have more than one element. For example, a multipolygon with an SDO_GTYPE of 2007 might contain three elements (polygons). To extract individual elements, use the SDO_UTIL.EXTRACT function instead.
For a polygon with one or more holes, with the default value for the flatten
parameter, the returned geometry representing an extracted interior ring is reoriented so that its vertices are presented in counterclockwise order (as opposed to the clockwise order within an interior ring). However, if the flatten
parameter value is 0, no reorientation is performed.
If geometry
is null or has an SDO_GTYPE value ending in 0, this function returns a null geometry.
geometry
cannot contain a type 0 (zero) element. Type 0 elements are described in Section 2.7.7.
This function is not intended for use with geometries that have any null ordinate values. Any null ordinate values in the returned geometry are replaced by 0 (zero).
Examples
The following example extracts all elements from the cola_b
geometry. (The example uses the definitions and data from Section 2.1.)
SELECT * FROM TABLE( SELECT SDO_UTIL.EXTRACT_ALL(c.shape) FROM cola_markets c WHERE c.name = 'cola_b'); SDO_GTYPE SDO_SRID   SDO_POINT(X, Y, Z)  SDO_ELEM_INFO  SDO_ORDINATES  2003 SDO_ELEM_INFO_ARRAY(1, 1003, 1) SDO_ORDINATE_ARRAY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1)
The following example inserts a polygon with a hole (using the same INSERT statement as in Example 27 in Section 2.7.2), and extracts all elements and subelements from the polygon_with_hole
geometry. Notice that because the flatten
parameter is not specified, in the second geometry returned by the EXTRACT_ALL function the vertices are in counterclockwise order, as opposed to the clockwise order in the hole (second subelement) in the input geometry.
 Insert polygon with hole. INSERT INTO cola_markets VALUES( 10, 'polygon_with_hole', SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1, 19,2003,1),  polygon with hole SDO_ORDINATE_ARRAY(2,4, 4,3, 10,3, 13,5, 13,9, 11,13, 5,13, 2,11, 2,4, 7,5, 7,10, 10,10, 10,5, 7,5) ) ); 1 row created.  Extract all, with default for flatten. SELECT * FROM TABLE( SELECT SDO_UTIL.EXTRACT_ALL(c.shape) FROM cola_markets c WHERE c.name = 'polygon_with_hole'); SDO_GTYPE SDO_SRID   SDO_POINT(X, Y, Z)  SDO_ELEM_INFO  SDO_ORDINATES  2003 SDO_ELEM_INFO_ARRAY(1, 1003, 1) SDO_ORDINATE_ARRAY(2, 4, 4, 3, 10, 3, 13, 5, 13, 9, 11, 13, 5, 13, 2, 11, 2, 4) SDO_GTYPE SDO_SRID   SDO_POINT(X, Y, Z)  SDO_ELEM_INFO  SDO_ORDINATES  2003 SDO_ELEM_INFO_ARRAY(1, 1003, 1) SDO_ORDINATE_ARRAY(7, 5, 10, 5, 10, 10, 7, 10, 7, 5)
The following example extracts all elements and subelements from the polygon_with_hole
geometry (inserted in the preceding example), and it specifies the flatten
parameter value as 0 (zero). This causes the returned array to contain a single geometry that is the same as the input geometry; thus, in the geometry returned by the EXTRACT_ALL function, the vertices are in same clockwise order in the hole (second subelement) as in the input geometry.
 Extract all, with flatten = 0. SELECT * FROM TABLE( SELECT SDO_UTIL.EXTRACT_ALL(c.shape, 0) FROM cola_markets c WHERE c.name = 'polygon_with_hole'); SDO_GTYPE SDO_SRID   SDO_POINT(X, Y, Z)  SDO_ELEM_INFO  SDO_ORDINATES  2003 SDO_ELEM_INFO_ARRAY(1, 1003, 1, 19, 2003, 1) SDO_ORDINATE_ARRAY(2, 4, 4, 3, 10, 3, 13, 5, 13, 9, 11, 13, 5, 13, 2, 11, 2, 4, 7, 5, 7, 10, 10, 10, 10, 5, 7, 5) SDO_GTYPE SDO_SRID   SDO_POINT(X, Y, Z)  SDO_ELEM_INFO  SDO_ORDINATES 
Description
Returns the threedimensional geometry that represents a specified subset of the input threedimensional geometry.
Parameters
Geometry from which to extract the geometry to be returned. Must be a threedimensional geometry
A commadelimited string of numbers that identify the subset geometry to be returned. Each number identifies the relative position of a geometry item within the input geometry. The items and their positions within the label
string are:
pointID
: Point number
edgeID
: Edge number
ringID
: Ring number
polygonID
: Polygon number
csurfID
: Composite surface number
solidID
: Solid number
multiID
: Multisolid number
A value of 0 (zero) means that the item does not apply, and you can omit trailing items that do not apply. For example, '0,2,1,4,1'
means that point number does not apply, and it specifies the second edge of the first ring of the fourth polygon of the first composite surface.
Usage Notes
This function applies to threedimensional geometries only. For twodimensional geometries, use the SDO_UTIL.EXTRACT function.
This function uses the getElementByLabel
method of the oracle.spatial.geometry.ElementExtractor
Java class, which is described in Oracle Spatial Java API Reference.
Examples
The following example extracts, from a specified threedimensional geometry, the subset geometry consisting of the following: edge 2 of ring 1 of polygon 4 of composite surface 1 of the input geometry.
SELECT SDO_UTIL.EXTRACT3D( SDO_GEOMETRY (3008,NULL,NULL , SDO_ELEM_INFO_ARRAY( 1,1007,1, 1,1006,6, 1,1003,1, 16,1003,1, 31,1003,1, 46,1003,1, 61,1003,1, 76,1003,1), SDO_ORDINATE_ARRAY( 1.0,0.0,1.0, 1.0,1.0,1.0, 1.0,1.0,1.0, 1.0,0.0,1.0, 1.0,0.0,1.0, 1.0,0.0,1.0, 0.0,0.0,1.0, 0.0,0.0,1.0, 1.0,0.0,1.0, 1.0,0.0,1.0, 0.0,1.0,1.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 0.0,0.0,1.0, 0.0,1.0,1.0, 1.0,1.0,1.0, 0.0,1.0,1.0, 0.0,1.0,1.0, 1.0,1.0,1.0, 1.0,1.0,1.0, 1.0,1.0,1.0, 0.0,1.0,1.0, 0.0,0.0,1.0, 1.0,0.0,1.0, 1.0,1.0,1.0, 1.0,1.0,1.0, 1.0,0.0,1.0, 0.0,0.0,1.0, 0.0,1.0,1.0, 1.0,1.0,1.0 ) ), '0,2,1,4,1') FROM DUAL; SDO_UTIL.EXTRACT3D(SDO_GEOMETRY(3008,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1007,1,1,10  SDO_GEOMETRY(3002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 0, 1, 1, 0, 1, 1))
Format
SDO_UTIL.EXTRUDE(
geometry IN SDO_GEOMETRY,
grdheight IN SDO_NUMBER_ARRAY,
height IN SDO_NUMBER_ARRAY,
tol IN NUMBER,
optional3dSrid IN NUMBER DEFAULT NULL
) RETURN SDO_GEOMETRY;
Description
Returns the threedimensional extrusion solid geometry from an input twodimensional polygon geometry.
Parameters
Twodimensional polygon geometry from which to return the extrusion geometry. This geometry forms the "base" of the returned geometry.
Ground heights as a set of Z (height) values at the base of the solid. The numbers in this array should be the Z (height) values at the base of each vertex in the input geometry.
Height values for the extrusion geometry. The numbers in this array should be the Z (height) values at the "top" of each corresponding point in the grdheight array. For example, if the ground height at the base of the first vertex is 0 and the height at that vertex is 10, the solid at that point along the base extends 10 units high.
Tolerance value (see Section 1.5.5).
Threedimensional coordinate system (SRID) to be assigned to the returned geometry. If you do not specify this parameter, Spatial automatically assigns a threedimensional SRID value based on the SRID value of the input geometry.
Usage Notes
The input geometry must be a twodimensional polygon geometry.
If the input geometry is a polygon with multiple inner rings, this function internally combines these inner rings to make them one inner ring, producing a new geometry that approximately represents the original appearance; the function then performs the extrusion process on this new geometry, and returns the result.
Examples
The following example returns the threedimensional solid geometry representing an extrusion from a twodimensional polygon geometry.
SELECT SDO_UTIL.EXTRUDE( SDO_GEOMETRY( 2003, null, null, SDO_ELEM_INFO_ARRAY(1,1003,1), SDO_ORDINATE_ARRAY(5, 1,8,1,8,6,5,7,5,1)), SDO_NUMBER_ARRAY(0,0,0,0,0), SDO_NUMBER_ARRAY(5,10,10,5,5), 0.005) from dual; SDO_UTIL.EXTRUDE(SDO_GEOMETRY(2003,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1003,1),SDO_O  SDO_GEOMETRY(3008, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1007, 1, 1, 1006, 6, 1, 10 03, 1, 16, 1003, 1, 31, 1003, 1, 46, 1003, 1, 61, 1003, 1, 76, 1003, 1), SDO_ORD INATE_ARRAY(5, 1, 0, 5, 7, 0, 8, 6, 0, 8, 1, 0, 5, 1, 0, 5, 1, 5, 8, 1, 10, 8, 6 , 10, 5, 7, 5, 5, 1, 5, 5, 1, 0, 8, 1, 0, 8, 1, 10, 5, 1, 5, 5, 1, 0, 8, 1, 0, 8 , 6, 0, 8, 6, 10, 8, 1, 10, 8, 1, 0, 8, 6, 0, 5, 7, 0, 5, 7, 5, 8, 6, 10, 8, 6, 0, 5, 7, 0, 5, 1, 0, 5, 1, 5, 5, 7, 5, 5, 7, 0))
The following example returns the threedimensional composite solid geometry representing an extrusion from a twodimensional polygon geometry with inner rings.
SELECT SDO_UTIL.EXTRUDE( SDO_GEOMETRY( 2003, null, null, SDO_ELEM_INFO_ARRAY(1, 1003, 1, 11, 2003, 1, 21, 2003,1, 31,2003,1, 41, 2003, 1), SDO_ORDINATE_ARRAY(0,0, 8,0, 8,8, 0,8, 0,0, 1,3, 1,4, 2,4, 2,3, 1,3, 1,1, 1,2, 2,2, 2,1, 1,1, 1,6, 1,7, 2,7, 2,6, 1,6, 3,2, 3,4, 4,4, 4,2, 3,2)), SDO_NUMBER_ARRAY(1.0), SDO_NUMBER_ARRAY(1.0), 0.0001) from dual; SDO_UTIL.EXTRUDE(SDO_GEOMETRY(2003,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1003,1,11,200  SDO_GEOMETRY(3008, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1008, 4, 1, 1007, 1, 1, 10 06, 16, 1, 1003, 1, 46, 1003, 1, 91, 1003, 1, 106, 1003, 1, 121, 1003, 1, 136, 1 003, 1, 151, 1003, 1, 166, 1003, 1, 181, 1003, 1, 196, 1003, 1, 211, 1003, 1, 22 6, 1003, 1, 241, 1003, 1, 256, 1003, 1, 271, 1003, 1, 286, 1003, 1, 301, 1007, 1 , 301, 1006, 10, 301, 1003, 1, 328, 1003, 1, 355, 1003, 1, 370, 1003, 1, 385, 10 03, 1, 400, 1003, 1, 415, 1003, 1, 430, 1003, 1, 445, 1003, 1, 460, 1003, 1, 475 , 1007, 1, 475, 1006, 6, 475, 1003, 1, 490, 1003, 1, 505, 1003, 1, 520, 1003, 1, 535, 1003, 1, 550, 1003, 1, 565, 1007, 1, 565, 1006, 10, 565, 1003, 1, 592, 100 3, 1, 619, 1003, 1, 634, 1003, 1, 649, 1003, 1, 664, 1003, 1, 679, 1003, 1, 694, 1003, 1, 709, 1003, 1, 724, 1003, 1), SDO_ORDINATE_ARRAY(4, 0, 1, 4, 2, 1, 4, 4, 1, 3, 4, 1, 2, 4, 1, 2, 7, 1, 1, 7, 1, 1, 6, 1, 1, 4, 1, 1, 3, 1, 0, 3, 1, 0, 8, 1, 8, 8, 1, 8, 0, 1, 4, 0, 1, 4, 0, 1, 8, 0, 1, 8, 8, 1, 0, 8, 1, 0, 3, 1, 1, 3, 1, 1, 4, 1, 1, 6, 1, 1, 7, 1, 2, 7, 1, 2, 4, 1, 3, 4, 1, 4, 4 , 1, 4, 2, 1, 4, 0, 1, 4, 0, 1, 8, 0, 1, 8, 0, 1, 4, 0, 1, 4, 0, 1, 8, 0, 1, 8, 8, 1, 8, 8, 1, 8, 0, 1, 8, 0, 1, 8, 8, 1, 0, 8, 1, 0, 8, 1, 8, 8, 1, 8, 8, 1, 0, 8, 1, 0, 3, 1, 0, 3, 1, 0, 8, 1, 0, 8, 1, 0, 3, 1, 1, 3, 1, 1, 3, 1, 0, 3, 1, 0, 3, 1, 1, 3, 1, 1, 4, 1, 1, 4, 1, 1, 3, 1, 1, 3, 1, 1, 4, 1, 1, 6, 1, 1, 6, 1, 1, 4, 1, 1, 4, 1, 1, 6, 1, 1, 7, 1, 1, 7, 1, 1, 6, 1, 1, 6, 1, 1, 7, 1, 2, 7, 1, 2, 7, 1, 1, 7, 1, 1, 7, 1, 2, 7, 1, 2, 4, 1, 2, 4, 1, 2, 7, 1, 2, 7, 1, 2, 4, 1, 3, 4, 1, 3, 4, 1, 2, 4, 1, 2, 4, 1, 3, 4, 1, 4, 4, 1, 4, 4, 1, 3, 4, 1, 3, 4, 1, 4, 4, 1, 4, 2, 1, 4, 2, 1, 4, 4, 1, 4, 4, 1, 4, 2, 1, 4, 0, 1, 4, 0, 1, 4, 2, 1, 4, 2, 1, 0, 3, 1, 1, 3, 1, 1, 1, 1, 2, 1, 1, 3, 2, 1, 4, 2, 1, 4, 0, 1, 0, 0, 1, 0, 3, 1, 0, 3, 1, 0, 0, 1, 4, 0, 1, 4, 2, 1, 3, 2, 1, 2, 1, 1, 1, 1, 1, 1, 3, 1, 0, 3, 1, 0, 3, 1, 0, 0 , 1, 0, 0, 1, 0, 3, 1, 0, 3, 1, 0, 0, 1, 4, 0, 1, 4, 0, 1, 0, 0, 1, 0, 0, 1 , 4, 0, 1, 4, 2, 1, 4, 2, 1, 4, 0, 1, 4, 0, 1, 4, 2, 1, 3, 2, 1, 3, 2, 1, 4 , 2, 1, 4, 2, 1, 3, 2, 1, 2, 1, 1, 2, 1, 1, 3, 2, 1, 3, 2, 1, 2, 1, 1, 1, 1 , 1, 1, 1, 1, 2, 1, 1, 2, 1, 1, 1, 1, 1, 1, 3, 1, 1, 3, 1, 1, 1, 1, 1, 1, 1 , 1, 3, 1, 0, 3, 1, 0, 3, 1, 1, 3, 1, 1, 3, 1, 1, 6, 1, 2, 6, 1, 2, 4, 1, 1, 4, 1, 1, 6, 1, 1, 6, 1, 1, 4, 1, 2, 4, 1, 2, 6, 1, 1, 6, 1, 1, 6, 1, 1, 4, 1, 1, 4, 1, 1, 6, 1, 1, 6, 1, 1, 4, 1, 2, 4, 1, 2, 4, 1, 1, 4, 1, 1, 4, 1, 2, 4, 1, 2, 6, 1, 2, 6, 1, 2, 4, 1, 2, 4, 1, 2, 6, 1, 1, 6, 1, 1, 6, 1, 2, 6, 1, 2, 6, 1, 1, 3, 1, 2, 3, 1, 2, 4, 1, 3, 4, 1, 3, 2, 1, 2, 1, 1, 2, 2, 1, 1, 2, 1, 1, 3, 1, 1, 3, 1, 1, 2, 1, 2, 2, 1, 2, 1, 1, 3, 2, 1, 3, 4, 1, 2, 4, 1, 2, 3, 1, 1, 3, 1, 1, 3, 1, 1, 2, 1, 1, 2, 1, 1, 3, 1, 1, 3, 1, 1, 2 , 1, 2, 2, 1, 2, 2, 1, 1, 2, 1, 1, 2, 1, 2, 2, 1, 2, 1, 1, 2, 1, 1, 2, 2, 1 , 2, 2, 1, 2, 1, 1, 3, 2, 1, 3, 2, 1, 2, 1, 1, 2, 1, 1, 3, 2, 1, 3, 4, 1, 3, 4, 1, 3, 2, 1, 3, 2, 1, 3, 4, 1, 2, 4, 1, 2, 4, 1, 3, 4, 1, 3, 4, 1, 2, 4 , 1, 2, 3, 1, 2, 3, 1, 2, 4, 1, 2, 4, 1, 2, 3, 1, 1, 3, 1, 1, 3, 1, 2, 3, 1 , 2, 3, 1))
Format
SDO_UTIL.FROM_GML311GEOMETRY(
geometry IN CLOB,
srsNamespace IN VARCHAR2 DEFAULT NULL
) RETURN SDO_GEOMETRY;
or
SDO_UTIL.FROM_GML311GEOMETRY(
geometry IN VARCHAR2,
srsNamespace IN VARCHAR2 DEFAULT NULL
) RETURN SDO_GEOMETRY;
Parameters
Geometry in GML version 3.1.1 format to be converted to SDO_GEOMETRY format.
(Reserved for Oracle use.)
Usage Notes
The input geometry must be a valid GML fragment describing a GML version 3.1.1 geometry type defined in the Open GIS Implementation Specification.
Examples
The following example shows conversion to and from GML version 3.1.1 format. (The example uses the definitions and data from Section 2.1, specifically the cola_b
geometry from the COLA_MARKETS table.)
DECLARE gmlgeom CLOB; geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_b';  To GML 3.1.1 geometry gmlgeom := SDO_UTIL.TO_GML311GEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To GML 3.1.1 geometry result = '  TO_CHAR(gmlgeom));  From GML 3.1.3 geometry geom_result := SDO_UTIL.FROM_GML311GEOMETRY(gmlgeom); END; / To GML 3.1.1 geometry result = <gml:Polygon srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"><gml:exterior><gml:LinearRing><gml:posLis t srsDimension="2">5.0 1.0 8.0 1.0 8.0 6.0 5.0 7.0 5.0 1.0 </gml:posList></gml:LinearRing></gml:exterior></gml:Polygon> PL/SQL procedure successfully completed.
Format
SDO_UTIL.FROM_GMLGEOMETRY(
geometry IN CLOB,
srsNamespace IN VARCHAR2 DEFAULT NULL
) RETURN SDO_GEOMETRY;
or
SDO_UTIL.FROM_GMLGEOMETRY(
geometry IN VARCHAR2,
srsNamespace IN VARCHAR2 DEFAULT NULL
) RETURN SDO_GEOMETRY;
Parameters
Geometry in GML version 2.0 format to be converted to SDO_GEOMETRY format.
(Reserved for Oracle use.)
Usage Notes
The input geometry must be a valid GML fragment describing a GML version 2.0 geometry type defined in the Open GIS Implementation Specification.
Examples
The following example shows conversion to and from GML version 2.0 format. (The example uses the definitions and data from Section 2.1, specifically the cola_b
geometry from the COLA_MARKETS table.)
DECLARE gmlgeom CLOB; geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_b';  To GML geometry gmlgeom := SDO_UTIL.TO_GMLGEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To GML geometry result = '  TO_CHAR(gmlgeom));  From GML geometry geom_result := SDO_UTIL.FROM_GMLGEOMETRY(gmlgeom); END; / To GML geometry result = <gml:Polygon srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"><gml:outerBoundaryIs><gml:LinearRing><gml :coordinates decimal="." cs="," ts=" ">5.0,1.0 8.0,1.0 8.0,6.0 5.0,7.0 5.0,1.0 </gml:coordinates></gml:LinearRing></gml:outerBoundaryIs></gml:Polygon> PL/SQL procedure successfully completed.
Format
SDO_UTIL.FROM_KMLGEOMETRY(
geometry IN CLOB
) RETURN SDO_GEOMETRY;
or
SDO_UTIL.FROM_KMLGEOMETRY(
geometry IN VARCHAR2
) RETURN SDO_GEOMETRY;
Parameters
Geometry in KML format of type CLOB or VARCHAR2 to be converted to SDO_GEOMETRY format.
Usage Notes
The input geometry must be a valid document conforming to the KML 2.1 specification.
This function does not process the whole KML document; it only processes the KML geometry tags.
Examples
The following example shows conversion to and from KML format. (The example uses the definitions and data from Section 2.1, specifically the cola_c
geometry from the COLA_MARKETS table.)
 Convert cola_c geometry to a KML document; convert that result to  a spatial geometry. DECLARE kmlgeom CLOB; val_result VARCHAR2(5); geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_c';  To KML geometry kmlgeom := SDO_UTIL.TO_KMLGEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To KML geometry result = '  TO_CHAR(kmlgeom));  From KML geometry geom_result := SDO_UTIL.FROM_KMLGEOMETRY(kmlgeom);  Validate the returned geometry val_result := SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(geom_result, 0.005); DBMS_OUTPUT.PUT_LINE('Validation result = '  val_result); END; / To KML geometry result = <Polygon><extrude>0</extrude><tessellate>0</tessellate><altitudeMode>relativeToG round</altitudeMode><outerBoundaryIs><LinearRing><coordinates>3.0,3.0 6.0,3.0 6.0,5.0 4.0,5.0 3.0,3.0 </coordinates></LinearRing></outerBoundaryIs></Polygon> Validation result = TRUE
Usage Notes
The input geometry must be in the wellknown binary (WKB) format, as defined by the Open Geospatial Consortium and the International Organization for Standardization (ISO).
This function is patterned after the SQL Multimedia recommendations in ISO 132493, Information technology  Database languages  SQL Multimedia and Application Packages  Part 3: Spatial.
To convert an SDO_GEOMETRY object to WKB format, use the SDO_UTIL.TO_WKBGEOMETRY function.
Examples
The following example shows conversion to and from WKB and WKT format, and validation of WKB and WKT geometries. (The example uses the definitions and data from Section 2.1, specifically the cola_b
geometry from the COLA_MARKETS table.)
DECLARE wkbgeom BLOB; wktgeom CLOB; val_result VARCHAR2(5); geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_b';  To WBT/WKT geometry wkbgeom := SDO_UTIL.TO_WKBGEOMETRY(geom); wktgeom := SDO_UTIL.TO_WKTGEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To WKT geometry result = '  TO_CHAR(wktgeom));  From WBT/WKT geometry geom_result := SDO_UTIL.FROM_WKBGEOMETRY(wkbgeom); geom_result := SDO_UTIL.FROM_WKTGEOMETRY(wktgeom);  Validate WBT/WKT geometry val_result := SDO_UTIL.VALIDATE_WKBGEOMETRY(wkbgeom); DBMS_OUTPUT.PUT_LINE('WKB validation result = '  val_result); val_result := SDO_UTIL.VALIDATE_WKTGEOMETRY(wktgeom); DBMS_OUTPUT.PUT_LINE('WKT validation result = '  val_result); END;/ To WKT geometry result = POLYGON ((5.0 1.0, 8.0 1.0, 8.0 6.0, 5.0 7.0, 5.0 1.0)) WKB validation result = TRUE WKT validation result = TRUE
Format
SDO_UTIL.FROM_WKTGEOMETRY(
geometry IN CLOB
) RETURN SDO_GEOMETRY;
or
SDO_UTIL.FROM_WKTGEOMETRY(
geometry IN VARCHAR2
) RETURN SDO_GEOMETRY;
Usage Notes
The input geometry must be in the wellknown text (WKT) format, as defined by the Open Geospatial Consortium and the International Organization for Standardization (ISO).
This function is patterned after the SQL Multimedia recommendations in ISO 132493, Information technology  Database languages  SQL Multimedia and Application Packages  Part 3: Spatial.
To convert an SDO_GEOMETRY object to a CLOB in WKT format, use the SDO_UTIL.TO_WKTGEOMETRY function. (You can use the SQL function TO_CHAR to convert the resulting CLOB to VARCHAR2 type.)
Examples
The following example shows conversion to and from WKB and WKT format, and validation of WKB and WKT geometries. (The example uses the definitions and data from Section 2.1, specifically the cola_b
geometry from the COLA_MARKETS table.)
DECLARE wkbgeom BLOB; wktgeom CLOB; val_result VARCHAR2(5); geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_b';  To WBT/WKT geometry wkbgeom := SDO_UTIL.TO_WKBGEOMETRY(geom); wktgeom := SDO_UTIL.TO_WKTGEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To WKT geometry result = '  TO_CHAR(wktgeom));  From WBT/WKT geometry geom_result := SDO_UTIL.FROM_WKBGEOMETRY(wkbgeom); geom_result := SDO_UTIL.FROM_WKTGEOMETRY(wktgeom);  Validate WBT/WKT geometry val_result := SDO_UTIL.VALIDATE_WKBGEOMETRY(wkbgeom); DBMS_OUTPUT.PUT_LINE('WKB validation result = '  val_result); val_result := SDO_UTIL.VALIDATE_WKTGEOMETRY(wktgeom); DBMS_OUTPUT.PUT_LINE('WKT validation result = '  val_result); END;/ To WKT geometry result = POLYGON ((5.0 1.0, 8.0 1.0, 8.0 6.0, 5.0 7.0, 5.0 1.0)) WKB validation result = TRUE WKT validation result = TRUE
Examples
The following example returns the number of elements for each geometry in the SHAPE column of the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
SELECT c.name, SDO_UTIL.GETNUMELEM(c.shape) FROM cola_markets c; NAME SDO_UTIL.GETNUMELEM(C.SHAPE)   cola_a 1 cola_b 1 cola_c 1 cola_d 1
Examples
The following example returns the number of vertices for each geometry in the SHAPE column of the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
SELECT c.name, SDO_UTIL.GETNUMVERTICES(c.shape) FROM cola_markets c; NAME SDO_UTIL.GETNUMVERTICES(C.SHAPE)   cola_a 2 cola_b 5 cola_c 5 cola_d 3
Usage Notes
This function returns an object of MDSYS.VERTEX_SET_TYPE, which consists of a table of objects of MDSYS.VERTEX_TYPE. Oracle Spatial defines the type VERTEX_SET_TYPE as:
CREATE TYPE vertex_set_type as TABLE OF vertex_type;
Oracle Spatial defines the object type VERTEX_TYPE as:
CREATE TYPE vertex_type AS OBJECT (x NUMBER, y NUMBER, z NUMBER, w NUMBER, v5 NUMBER, v6 NUMBER, v7 NUMBER, v8 NUMBER, v9 NUMBER, v10 NUMBER, v11 NUMBER, id NUMBER);
Note: The VERTEX_SET_TYPE and VERTEX_TYPE types are intended for use by Oracle only. Do not use these types in column definitions or functions that you create. 
This function can be useful in finding a vertex that is causing a geometry to be invalid. For example, if you have identified a geometry as invalid by using the SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT function or the SDO_GEOM.VALIDATE_LAYER_WITH_CONTEXT procedure (both of which are documented in Chapter 24), you can use the GETVERTICES function to view the vertices in tabular format.
Examples
The following example returns the X and Y coordinates and ID
values of the vertices of the geometries in the SHAPE column of the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
SELECT c.mkt_id, c.name, t.X, t.Y, t.id FROM cola_markets c, TABLE(SDO_UTIL.GETVERTICES(c.shape)) t ORDER BY c.mkt_id, t.id; MKT_ID NAME X Y ID      1 cola_a 1 1 1 1 cola_a 5 7 2 2 cola_b 5 1 1 2 cola_b 8 1 2 2 cola_b 8 6 3 2 cola_b 5 7 4 2 cola_b 5 1 5 3 cola_c 3 3 1 3 cola_c 6 3 2 3 cola_c 6 5 3 3 cola_c 4 5 4 3 cola_c 3 3 5 4 cola_d 8 7 1 4 cola_d 10 9 2 4 cola_d 8 11 3 15 rows selected.
Description
Initializes all spatial indexes in a tablespace that was transported to another database.
Usage Notes
This procedure is part of the support for using the Oracle transportable tablespace feature with tablespaces that contain any spatial indexes. Use this procedure only either (A) the import operation of preRelease 11.2 dump files is completed, or (B) after the import operation from different endian platform in Release 11.2 or later is completed. Each user that has a spatial index in the tablespace must call the procedure.
For preRelease 11.2 dump files, after calling the SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS procedure, you must execute a statement in the following format for each index that is in the imported transportable tablespace:
ALTER INDEX spatialindexfromimportedtts PARAMETERS ('CLEAR_TTS=TRUE');
For detailed information about transportable tablespaces and transporting tablespaces to other databases, see Oracle Database Administrator's Guide.
Examples
The following example for an import of preRelease 11.2 dump files initializes all spatial indexes in a tablespace that was transported to another database. It also includes the required ALTER INDEX statement for two hypothetical spatial indexes.
CALL SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS; ALTER INDEX xyz1_spatial_idx PARAMETERS ('CLEAR_TTS=TRUE'); ALTER INDEX xyz2_spatial_idx PARAMETERS ('CLEAR_TTS=TRUE');
In the following example, the owner of the spatial index must call the SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS procedure only if the SELECT statement returns the string Y
, to reflect the fact that the spatial indexes are imported from different endian platforms in Release 11.2.
SELECT DECODE(BITAND(sdo_index_version, 1024), 1024, 'Y', 'N') ENDIAN_FLAG FROM user_sdo_index_metadata WHERE sdo_index_name = :index_name;  If the result is 'Y', perform the next statement. CALL SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS;  No ALTER INDEX statements are needed.
In this example, if you call the SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS procedure when the SELECT statement returns the string N
, the procedure does nothing because there is no need to perform endian conversion.
Format
SDO_UTIL.INTERIOR_POINT(
geom IN SDO_GEOMETRY,
tol IN NUMBER DEFAULT 0.00000000005
) RETURN SDO_GEOMETRY;
Description
Returns a point that is guaranteed to be an interior point (not on the boundary or edge) on the surface of a polygon geometry object.
Parameters
Polygon geometry object. The SDO_GTYPE value of the geometry must be 2003 or 2007. (SDO_GTYPE values are explained in Section 2.2.1.)
Tolerance value (see Section 1.5.5).
Usage Notes
This function returns a point geometry object representing a point that is guaranteed to be an interior point on the surface, but not on the boundary or edge, of geom
. The returned point can be any interior point on the surface; however, if you call the function multiple times with the same geom
and tol
parameter values, the returned point will be the same.
The relationship between the returned point and the original geometry is INSIDE, which you can check using the SDO_RELATE operator with'mask=inside'
.
In most cases this function is more useful than the SDO_GEOM.SDO_POINTONSURFACE function, which returns a point that is not guaranteed to be an interior point.
Examples
The following example returns a geometry object that is an interior point on the surface of cola_a
. (The example uses the definitions and data from Section 2.1.)
 Return an interior point on the surface of a geometry. SELECT SDO_UTIL.INTERIOR_POINT(c.shape, 0.005) FROM cola_markets c WHERE c.name = 'cola_a'; SDO_UTIL.INTERIOR_POINT(C.SHAPE,0.005)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z),  SDO_GEOMETRY(2001, NULL, SDO_POINT_TYPE(2.75, 2.875, NULL), NULL, NULL)
Format
SDO_UTIL.POINT_AT_BEARING(
start_point IN SDO_GEOMETRY,
bearing IN NUMBER,
distance IN NUMBER
) RETURN SDO_GEOMETRY;
Description
Returns a point geometry that is at the specified distance and bearing from the start point.
Parameters
Point geometry object from which to compute the distance at the specified bearing, to locate the desired point. The point geometry must be based on a geodetic coordinate system.
Number of radians, measured clockwise from North. Must be in the range of either pi to pi or 0 to 2*pi. (Either convention on ranges will work).
Number of meters from start_point
and along the initial bearing direction to the computed destination point. Must be less than onehalf the circumference of the Earth.
Usage Notes
The input point geometry must be based on a geodetic coordinate system. If it is based on a nongeodetic coordinate system, this function returns a null value.
To convert decimal degrees to radians or nonmetric distances to meters, you can use the SDO_UTIL.CONVERT_UNIT function. To compute the bearing and tilt from a start point to an end point, you can use the SDO_UTIL.BEARING_TILT_FOR_POINTS procedure.
Examples
The following example returns the point 100 kilometers at a bearing of 1 radian from the point with the longitude and latitude coordinates (72, 43).
SELECT SDO_UTIL.POINT_AT_BEARING( SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(72, 43, NULL), NULL, NULL), 1,  1 radian (57.296 degrees clockwise from North) 100000  100 kilometers ) FROM DUAL; SDO_UTIL.POINT_AT_BEARING(SDO_GEOMETRY(2001,8307,SDO_POINT_TYPE(72,43,NULL),NUL  SDO_GEOMETRY(2001, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY( 70.957053, 43.4811935))
Description
Converts all polygontype elements in a geometry to linetype elements, and sets the SDO_GTYPE value accordingly.
Usage Notes
The order of the vertices of each resulting linetype element is the same as in the associated polygontype element, and the start and end points of each linetype segment are the same point.
If the input geometry is a line, it is returned.
Examples
The following example converts the input polygon geometry, which is the same geometry as cola_b (see Figure 21 and Example 21 in Section 2.1), to a line string geometry. In the returned geometry, the SDO_GTYPE value (2002) indicates a twodimensional LINE geometry, and the SDO_ETYPE value (2) and SDO_INTERPRETATION value (1) in the SDO_ELEM_INFO array indicate a line string whose vertices are connected by straight line segments.
SELECT SDO_UTIL.POLYGONTOLINE( SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1),  one polygon (exterior polygon ring) SDO_ORDINATE_ARRAY(5,1, 8,1, 8,6, 5,7, 5,1) ) ) FROM DUAL; SDO_UTIL.POLYGONTOLINE(SDO_GEOMETRY(2003,TWODIMENSIONALPOLYGONNULL,NULL,SDO_E  SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 5, 1, 8, 1, 8, 6, 5, 7, 5, 1))
Description
(Deprecated feature. Previous usage was: "Prepares a tablespace to be transported to another database, so that spatial indexes will be preserved during the transport operation.")
Parameters
Tablespace to be transported. Must be the tablespace containing the spatial table or tables. For a partitioned table, must be the tablespace of one of the partitions.
Usage Notes
Effective with Oracle Database Release 11.2, this procedure is deprecated. You do not need to call the PREPARE_FOR_TTS procedure before performing a transportable tablespace export operation.
For detailed information about transportable tablespaces and transporting tablespaces to other databases, see Oracle Database Administrator's Guide.
Format
SDO_UTIL.RECTIFY_GEOMETRY(
geometry IN SDO_GEOMETRY,
tolerance IN NUMBER
) RETURN SDO_GEOMETRY;
Parameters
Geometry to be checked for problems that can be fixed.
Tolerance value (see Section 1.5.5).
Usage Notes
This function checks for the following problems that can make a geometry invalid, and fixes the problems in the returned geometry:
Duplicate vertices
Polygon boundary intersecting itself
Incorrect orientation of exterior or interior rings (or both) of a polygon
If the input geometry has any other problem that makes it invalid, the function raises an exception.
If the input geometry is valid, the function returns a geometry that is identical to the input geometry.
For information about using this function as part of the recommended procedure for loading and validating spatial data, see Section 4.3.
This function is used internally by the SDO_UTIL.SIMPLIFY function as part of the geometry simplification process.
Examples
The following example checks the cola_b
geometry to see if it has problems that can be fixed. (In this case, the geometry is valid, so the input geometry is returned. The example uses the definitions and data from Section 2.1.)
SELECT SDO_UTIL.RECTIFY_GEOMETRY(shape, 0.005) FROM COLA_MARKETS c WHERE c.name = 'cola_b'; SDO_UTIL.RECTIFY_GEOMETRY(SHAPE,0.005)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z),  SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1))
Format
SDO_UTIL.REMOVE_DUPLICATE_VERTICES
geometry IN SDO_GEOMETRY,
tolerance IN NUMBER
) RETURN SDO_GEOMETRY;
Parameters
Geometry from which to remove duplicate vertices.
Tolerance value (see Section 1.5.5).
Usage Notes
When two consecutive vertices in a geometry are the same or within the tolerance value associated with the geometry, Spatial considers the geometry to be invalid. The Spatial geometry validation functions return the error ORA13356 in these cases. You can use the REMOVE_DUPLICATE_VERTICES function to change such invalid geometries into valid geometries.
This function also closes polygons so that the first vertex of the ring is the same as the last vertex of the ring.
This function is not supported for any point geometries (including oriented points).
If the input geometry does not contain any duplicate vertices, it is returned.
Examples
The following example removes a duplicate vertex from the input geometry, which is the same geometry as cola_b (see Figure 21 and Example 21 in Section 2.1) except that it has been deliberately made invalid by adding a third vertex that is the same point as the second vertex (8,1).
SELECT SDO_UTIL.REMOVE_DUPLICATE_VERTICES( SDO_GEOMETRY( 2003,  twodimensional polygon NULL, NULL, SDO_ELEM_INFO_ARRAY(1,1003,1),  one polygon (exterior polygon ring) SDO_ORDINATE_ARRAY(5,1, 8,1, 8,1, 8,6, 5,7, 5,1)  2nd and 3rd points  are duplicates. ), 0.005  tolerance value ) FROM DUAL; SDO_UTIL.REMOVE_DUPLICATE_VERTICES(SDO_GEOMETRY(2003,TWODIMENSIONALPOLYGONNUL  SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARR AY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1))
Description
Returns a line string geometry with the vertices of the input geometry in reverse order.
Parameters
Line string geometry whose vertices are to be reversed in the output geometry. The SDO_GTYPE value of the input geometry must be 2002. (Section 2.2.1 explains SDO_GTYPE values.)
Usage Notes
Because the SDO_GTYPE value of the input geometry must be 2002, this function cannot be used to reverse LRS geometries. To reverse an LRS geometry, use the SDO_LRS.REVERSE_GEOMETRY function, which is described in Chapter 25.
Examples
The following example returns a line string geometry that reverses the vertices of the input geometry.
SELECT SDO_UTIL.REVERSE_LINESTRING( SDO_GEOMETRY(2002, 8307, NULL, SDO_ELEM_INFO_ARRAY(1,2,1), SDO_ORDINATE_ARRAY(72,43, 71.5,43.5, 71,42, 70,40)) ) FROM DUAL; SDO_UTIL.REVERSE_LINESTRING(SDO_GEOMETRY(2002,8307,NULL,SDO_ELEM_INFO_ARRAY(1,2,  SDO_GEOMETRY(2002, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 70, 40, 71, 42, 71.5, 43.5, 72, 43))
Format
SDO_UTIL.SIMPLIFY(
geometry IN SDO_GEOMETRY,
threshold IN NUMBER
tolerance IN NUMBER DEFAULT 0.0000005
) RETURN SDO_GEOMETRY;
Description
Simplifies the input geometry, based on a threshold value, using the DouglasPeucker algorithm.
Parameters
Geometry to be simplified.
Threshold value to be used for the geometry simplification. Should be a positive number. (Zero causes the input geometry to be returned.) If the input geometry is geodetic, the value is the number of meters; if the input geometry is nongeodetic, the value is the number of units associated with the data.
As the threshold value is decreased, the returned geometry is likely to be closer to the input geometry; as the threshold value is increased, fewer points are likely to be in the returned geometry. See the Usage Notes for more information.
Tolerance value (see Section 1.5.5). Must not be greater than threshold
; and for better performance, should not be the same as threshold
. If you do not specify a value, the default value is 0.0000005.
Usage Notes
This function also converts arcs to line stings, eliminates duplicate vertices, and corrects many overlapping edge polygon problems. The reason this function sometimes fixes problems is that it internally calls the SDO_UTIL.RECTIFY_GEOMETRY function at the end of the simplification process to ensure that a valid geometry is returned.
This function is useful when you want a geometry with less fine resolution than the original geometry. For example, if the display resolution cannot show the hundreds or thousands of turns in the course of a river or in a political boundary, better performance might result if the geometry were simplified to show only the major turns.
If you use this function with geometries that have more than two dimensions, only the first two dimensions are used in processing the query, and only the first two dimensions in the returned geometry are to be considered valid and meaningful. For example, the measure values in a returned LRS geometry will probably not reflect actual measures in that geometry. In this case, depending on your application needs, you might have several options after the simplification operation, such as ignoring the new measure values or redefining the new LRS geometry to reset the measure values.
This function uses the DouglasPeucker algorithm, which is explained in several cartography textbooks and reference documents. (In some explanations, the term tolerance is used instead of threshold; however, this is different from the Oracle Spatial meaning of tolerance.)
The returned geometry can be a polygon, line, or point, depending on the geometry definition and the threshold value. The following considerations apply:
A polygon can simplify to a line or a point and a line can simplify to a point, if the threshold value associated with the geometry is sufficiently large. For example, a thin rectangle will simplify to a line if the distance between the two parallel long sides is less than the threshold value, and a line will simplify to a point if the distance between the start and end points is less than the threshold value.
In a polygon with a hole, if the exterior ring or the interior ring (the hole) simplifies to a line or a point, the interior ring disappears from (is not included in) the resulting geometry.
Topological characteristics of the input geometry might not be maintained after simplification. For a collection geometry, the number of elements might increase, to prevent overlapping of individual elements. In all cases, this function will not return an invalid geometry.
Examples
The following example simplifies the road shown in Figure 720 in Section 7.7. Because the threshold value (6) is fairly large given the input geometry, the resulting LRS line string has only three points: the start and end points, and (12, 4,12). The measure values in the returned geometry are not meaningful, because this function considers only two dimensions.
SELECT SDO_UTIL.SIMPLIFY( SDO_GEOMETRY( 3302,  line string, 3 dimensions (X,Y,M), 3rd is linear ref. dimension NULL, NULL, SDO_ELEM_INFO_ARRAY(1,2,1),  one line string, straight segments SDO_ORDINATE_ARRAY( 2,2,0,  Starting point  Exit1; 0 is measure from start. 2,4,2,  Exit2; 2 is measure from start. 8,4,8,  Exit3; 8 is measure from start. 12,4,12,  Exit4; 12 is measure from start. 12,10,NULL,  Not an exit; measure automatically calculated and filled. 8,10,22,  Exit5; 22 is measure from start. 5,14,27)  Ending point (Exit6); 27 is measure from start. ), 6,  threshold value for geometry simplification 0.5  tolerance ) FROM DUAL; SDO_UTIL.SIMPLIFY(SDO_GEOMETRY(3302,LINESTRING,3DIMENSIONS(X,Y,M),3RDISLINEARR  SDO_GEOMETRY(3302, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY( 2, 2, 0, 12, 4, 12, 5, 14, 27))
Figure 321 shows the result of this example. In Figure 321, the thick solid black line is the resulting geometry, the thin solid light line between the start and end points is the input geometry, and the thin dashed line with the arrowhead at the end shows the direction of the segment.
Description
Converts a Spatial geometry object to a geography markup language (GML version 3.1.1) fragment based on the geometry types defined in the Open GIS geometry.xsd
schema document.
Usage Notes
This function does not convert circles, geometries containing any circular arcs, LRS geometries, or geometries with an SDO_ETYPE value of 0 (type 0 elements); it returns an empty CLOB in these cases.
This function converts the input geometry to a GML version 3.1.1 fragment based on some GML geometry types defined in the Open GIS Implementation Specification.
Polygons must be defined using the conventions for Oracle9i and later releases of Spatial. That is, the outer boundary is stored first (with ETYPE=1003) followed by zero or more inner boundary elements (ETYPE=2003). For a polygon with holes, the outer boundary must be stored first in the SDO_ORDINATES definition, followed by coordinates of the inner boundaries.
LRS geometries must be converted to standard geometries (using the SDO_LRS.CONVERT_TO_STD_GEOM or SDO_LRS.CONVERT_TO_STD_LAYER function) before being passed to the TO_GMLGEOMETRY function. (See the Examples section for an example that uses CONVERT_TO_STD_GEOM with the TO_GMLGEOMETRY function.)
Any circular arcs or circles must be densified (using the SDO_GEOM.SDO_ARC_DENSIFY function) or represented as polygons (using the SDO_GEOM.SDO_BUFFER function) before being passed to the TO_GMLGEOMETRY function. (See the Examples section for an example that uses SDO_ARC_DENSIFY with the TO_GMLGEOMETRY function.)
Label points are discarded. That is, if a geometry has a value for the SDO_POINT field and values in SDO_ELEM_INFO and SDO_ORDINATES, the SDO_POINT is not output in the GML fragment.
The SDO_SRID value is output in the form srsName="SDO:<srid>"
. For example, "SDO:8307"
indicates SDO_SRID 8307, and "SDO:"
indicates a null SDO_SRID value. No checks are made for the validity or consistency of the SDO_SRID value. For example, the value is not checked to see if it exists in the MDSYS.CS_SRS table or if it conflicts with the SRID value for the layer in the USER_SDO_GEOM_METADATA view.
Coordinates are always output using the <coordinates>
tag and decimal='.'
, cs=','
(that is, with the comma as the coordinate separator), and ts=' '
(that is, with a space as the tuple separator), even if the NLS_NUMERIC_CHARACTERS setting has ','
(comma) as the decimal character.
The GML output is not formatted; there are no line breaks or indentation of tags. To see the contents of the returned CLOB in SQL*Plus, use the TO_CHAR() function or set the SQL*Plus parameter LONG to a suitable value (for example, SET LONG 40000
). To get formatted GML output or to use the return value of TO_GMLGEOMETRY in SQLX or Oracle XML DB functions such as XMLELEMENT, use the XMLTYPE(clobval CLOB) constructor.
Examples
The following example returns the GML version 3.1.1 fragment for the cola_b
geometry in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
 Convert cola_b geometry to GML 3.1.1 fragment. SELECT TO_CHAR(SDO_UTIL.TO_GML311GEOMETRY(shape)) AS Gml311Geometry FROM COLA_MARKETS c WHERE c.name = 'cola_b'; GML311GEOMETRY  <gml:Polygon srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"><gml:exterior ><gml:LinearRing><gml:posList srsDimension="2">5.0 1.0 8.0 1.0 8.0 6.0 5.0 7.0 5 .0 1.0 </gml:posList></gml:LinearRing></gml:exterior></gml:Polygon>
The following example returns the GML version 3.1.1 fragment for the arc densification of the cola_d
geometry in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
SET LONG 40000 SELECT XMLTYPE(SDO_UTIL.TO_GML311GEOMETRY( SDO_GEOM.SDO_ARC_DENSIFY(c.shape, m.diminfo, 'arc_tolerance=0.05'))) AS Gml311Geometry FROM cola_markets c, user_sdo_geom_metadata m WHERE m.table_name = 'COLA_MARKETS' AND m.column_name = 'SHAPE' AND c.name = 'cola_d'; GML311GEOMETRY  <gml:Polygon srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"> <gml:exterior> <gml:LinearRing> <gml:posList srsDimension="2">8.0 7.0 8.76536686473018 7.15224093497743 9. 4142135623731 7.58578643762691 9.84775906502257 8.23463313526982 10.0 9.0 9.8477 5906502257 9.76536686473018 9.4142135623731 10.4142135623731 8.76536686473018 10 .8477590650226 8.0 11.0 7.23463313526982 10.8477590650226 6.58578643762691 10.41 42135623731 6.15224093497743 9.76536686473018 6.0 9.0 6.15224093497743 8.2346331 3526982 6.58578643762691 7.5857864376269 7.23463313526982 7.15224093497743 8.0 7 .0 </gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon>
The following example converts an LRS geometry to a standard geometry and returns the GML version 3.1.1 fragment for the geometry. (The example uses the definitions and data from Section 7.7.)
SET LONG 40000  Convert LRS grometry to standard geometry before using TO_GML311GEOMETRY. SELECT XMLTYPE(SDO_UTIL.TO_GML311GEOMETRY( SDO_LRS.CONVERT_TO_STD_GEOM(route_geometry))) AS Gml311Geometry FROM lrs_routes a WHERE a.route_id = 1; GML311GEOMETRY  <gml:Curve srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"> <gml:segments> <gml:LineStringSegment> <gml:posList srsDimension="2">2.0 2.0 2.0 4.0 8.0 4.0 12.0 4.0 12.0 10.0 8 .0 10.0 5.0 14.0 </gml:posList> </gml:LineStringSegment> </gml:segments> </gml:Curve>
The following examples return GML version 3.1.1 fragments for a variety of geometry types.
 Point geometry with coordinates in SDO_ORDINATES. Note the  coordinates in the GML are (10.0 10.0) and the values in the  SDO_POINT field are discarded. SELECT TO_CHAR( SDO_UTIL.TO_GML311GEOMETRY(sdo_geometry(2001, 8307, sdo_point_type(80, 70, null), sdo_elem_info_array(1,1,1), sdo_ordinate_array(10, 10))) ) AS Gml311Geometry FROM DUAL; GML311GEOMETRY  <gml:Point srsName="SDO:8307" xmlns:gml="http://www.opengis.net/gml"><gml:posLis t srsDimension="2">10.0 10.0 </gml:posList></gml:Point>  Multipolygon SET LONG 40000 SELECT SDO_UTIL.TO_GML311GEOMETRY( sdo_geometry(2007, 8307, null, sdo_elem_info_array(1,1003,1, 13,1003,1, 23,1003,3), sdo_ordinate_array(10.10,10.20, 20.50,20.10, 30.30,30.30, 40.10,40.10, 30.50, 30.20, 10.10, 10.20, 5,5, 5,6, 6,6, 6,5, 5,5, 7,7, 8,8 )) ) AS Gml311Geometry FROM DUAL; GML311GEOMETRY  <gml:MultiSurface srsName="SDO:8307" xmlns:gml="http://www.opengis.net/gml"><gml :surfaceMember><gml:Polygon><gml:exterior><gml:LinearRing><gml:posList srsDimens ion="2">10.1 10.2 20.5 20.1 30.3 30.3 40.1 40.1 30.5 30.2 10.1 10.2 </gml:posLis t></gml:LinearRing></gml:exterior></gml:Polygon></gml:surfaceMember><gml:surface Member><gml:Polygon><gml:exterior><gml:LinearRing><gml:posList srsDimension="2"> 5.0 5.0 5.0 6.0 6.0 6.0 6.0 5.0 5.0 5.0 </gml:posList></gml:LinearRing></gml:ext erior></gml:Polygon></gml:surfaceMember><gml:surfaceMember><gml:Polygon><gml:ext erior><gml:LinearRing><gml:posList srsDimension="2">7.0 7.0 8.0 7.0 8.0 8.0 7.0 8.0 7.0 7.0 </gml:posList></gml:LinearRing></gml:exterior></gml:Polygon></gml:su rfaceMember></gml:MultiSurface> SET LONG 80  Rectangle (geodetic) SELECT TO_CHAR( SDO_UTIL.TO_GML311GEOMETRY(sdo_geometry(2003, 8307, null, sdo_elem_info_array(1,1003,3), sdo_ordinate_array(10.10,10.10, 20.10,20.10 ))) ) AS Gml311Geometry FROM DUAL; GML311GEOMETRY  <gml:Polygon srsName="SDO:8307" xmlns:gml="http://www.opengis.net/gml"><gml:exte rior><gml:LinearRing><gml:posList srsDimension="2">10.1 10.1 20.1 10.1 20.1 20.1 10.1 20.1 10.1 10.1 </gml:posList></gml:LinearRing></gml:exterior></gml:Polygon >  Polygon with holes SELECT TO_CHAR( SDO_UTIL.TO_GML311GEOMETRY(sdo_geometry(2003, 262152, null, sdo_elem_info_array(1,1003,3, 5, 2003, 1, 13, 2003, 1), sdo_ordinate_array(10.10,10.20, 40.50, 41.10, 30.30, 30.30, 30.30, 40.10, 40.10, 40.10, 30.30, 30.30, 5, 5, 5, 6, 6, 6, 6, 5, 5, 5 ))) ) AS Gml311Geometry FROM DUAL; GML311GEOMETRY  <gml:Polygon srsName="SDO:262152" xmlns:gml="http://www.opengis.net/gml"><gml:ex terior><gml:LinearRing><gml:posList srsDimension="2">10.1 10.2 40.5 10.2 40.5 41 .1 10.1 41.1 10.1 10.2 </gml:posList></gml:LinearRing></gml:exterior><gml:interi or><gml:LinearRing><gml:posList srsDimension="2">30.3 30.3 30.3 40.1 40.1 40.1 3 0.3 30.3 </gml:posList></gml:LinearRing></gml:interior><gml:interior><gml:Linear Ring><gml:posList srsDimension="2">5.0 5.0 5.0 6.0 6.0 6.0 6.0 5.0 5.0 5.0 </gml :posList></gml:LinearRing></gml:interior></gml:Polygon>  Creating an XMLTYPE from the GML fragment. Also useful for "pretty  printing" the GML output. SET LONG 40000 SELECT XMLTYPE( SDO_UTIL.TO_GML311GEOMETRY(sdo_geometry(2003, 262152, null, sdo_elem_info_array(1,1003,1, 11, 2003, 1, 21, 2003, 1), sdo_ordinate_array(10.10,10.20, 40.50,10.2, 40.5,41.10, 10.1,41.1, 10.10, 10.20, 30.30,30.30, 30.30, 40.10, 40.10, 40.10, 40.10, 30.30, 30.30, 30.30, 5, 5, 5, 6, 6, 6, 6, 5, 5, 5 ))) ) AS Gml311Geometry FROM DUAL; GML311GEOMETRY  <gml:Polygon srsName="SDO:262152" xmlns:gml="http://www.opengis.net/gml"> <gml:exterior> <gml:LinearRing> <gml:posList srsDimension="2">10.1 10.2 40.5 10.2 40.5 41.1 10.1 41.1 10.1 10.2 </gml:posList> </gml:LinearRing> </gml:exterior> <gml:interior> <gml:LinearRing> <gml:posList srsDimension="2">30.3 30.3 30.3 40.1 40.1 40.1 40.1 30.3 30.3 30.3 </gml:posList> GML311GEOMETRY  </gml:LinearRing> </gml:interior> <gml:interior> <gml:LinearRing> <gml:posList srsDimension="2">5.0 5.0 5.0 6.0 6.0 6.0 6.0 5.0 5.0 5.0 </gm l:posList> </gml:LinearRing> </gml:interior> </gml:Polygon>
Description
Converts a Spatial geometry object to a geography markup language (GML 2.0) fragment based on the geometry types defined in the Open GIS geometry.xsd
schema document.
Usage Notes
This function does not convert circles, geometries containing any circular arcs, LRS geometries, or geometries with an SDO_ETYPE value of 0 (type 0 elements); it returns an empty CLOB in these cases.
This function converts the input geometry to a GML fragment based on some GML geometry types defined in the Open GIS Implementation Specification.
Polygons must be defined using the conventions for Oracle9i and later releases of Spatial. That is, the outer boundary is stored first (with ETYPE=1003) followed by zero or more inner boundary elements (ETYPE=2003). For a polygon with holes, the outer boundary must be stored first in the SDO_ORDINATES definition, followed by coordinates of the inner boundaries.
LRS geometries must be converted to standard geometries (using the SDO_LRS.CONVERT_TO_STD_GEOM or SDO_LRS.CONVERT_TO_STD_LAYER function) before being passed to the TO_GMLGEOMETRY function. (See the Examples section for an example that uses CONVERT_TO_STD_GEOM with the TO_GMLGEOMETRY function.)
Any circular arcs or circles must be densified (using the SDO_GEOM.SDO_ARC_DENSIFY function) or represented as polygons (using the SDO_GEOM.SDO_BUFFER function) before being passed to the TO_GMLGEOMETRY function. (See the Examples section for an example that uses SDO_ARC_DENSIFY with the TO_GMLGEOMETRY function.)
Label points are discarded. That is, if a geometry has a value for the SDO_POINT field and values in SDO_ELEM_INFO and SDO_ORDINATES, the SDO_POINT is not output in the GML fragment.
The SDO_SRID value is output in the form srsName="SDO:<srid>"
. For example, "SDO:8307"
indicates SDO_SRID 8307, and "SDO:"
indicates a null SDO_SRID value. No checks are made for the validity or consistency of the SDO_SRID value. For example, the value is not checked to see if it exists in the MDSYS.CS_SRS table or if it conflicts with the SRID value for the layer in the USER_SDO_GEOM_METADATA view.
Coordinates are always output using the <coordinates>
tag and decimal='.'
, cs=','
(that is, with the comma as the coordinate separator), and ts=' '
(that is, with a space as the tuple separator), even if the NLS_NUMERIC_CHARACTERS setting has ','
(comma) as the decimal character.
The GML output is not formatted; there are no line breaks or indentation of tags. To see the contents of the returned CLOB in SQL*Plus, use the TO_CHAR() function or set the SQL*Plus parameter LONG to a suitable value (for example, SET LONG 40000
). To get formatted GML output or to use the return value of TO_GMLGEOMETRY in SQLX or Oracle XML DB functions such as XMLELEMENT, use the XMLTYPE(clobval CLOB) constructor.
Examples
The following example returns the GML fragment for the cola_b
geometry in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
 Convert cola_b geometry to GML fragment. SELECT TO_CHAR(SDO_UTIL.TO_GMLGEOMETRY(shape)) AS GmlGeometry FROM COLA_MARKETS c WHERE c.name = 'cola_b'; GMLGEOMETRY  <gml:Polygon srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"><gml:outerBou ndaryIs><gml:LinearRing><gml:coordinates decimal="." cs="," ts=" ">5,1 8,1 8,6 5 ,7 5,1 </gml:coordinates></gml:LinearRing></gml:outerBoundaryIs></gml:Polygon>
The following example returns the GML fragment for the arc densification of the cola_d
geometry in the COLA_MARKETS table. (The example uses the definitions and data from Section 2.1.)
SET LONG 40000 SELECT XMLTYPE(SDO_UTIL.TO_GMLGEOMETRY( SDO_GEOM.SDO_ARC_DENSIFY(c.shape, m.diminfo, 'arc_tolerance=0.05'))) AS GmlGeometry FROM cola_markets c, user_sdo_geom_metadata m WHERE m.table_name = 'COLA_MARKETS' AND m.column_name = 'SHAPE' AND c.name = 'cola_d'; GMLGEOMETRY  <gml:Polygon srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"><gml:outerBou ndaryIs><gml:LinearRing><gml:coordinates decimal="." cs="," ts=" ">8,7 8.7653668 6473018,7.15224093497743 9.4142135623731,7.58578643762691 9.84775906502257,8.234 63313526982 10,9 9.84775906502257,9.76536686473018 9.4142135623731,10.4142135623 731 8.76536686473018,10.8477590650226 8,11 7.23463313526982,10.8477590650226 6.5 8578643762691,10.4142135623731 6.15224093497743,9.76536686473018 6,9 6.152240934 97743,8.23463313526982 6.58578643762691,7.5857864376269 7.23463313526982,7.15224 093497743 8,7 </gml:coordinates></gml:LinearRing></gml:outerBoundaryIs></gml:Pol ygon>
The following example converts an LRS geometry to a standard geometry and returns the GML fragment for the geometry. (The example uses the definitions and data from Section 7.7.)
SET LONG 40000  Convert LRS geometry to standard geometry before using TO_GMLGEOMETRY. SELECT XMLTYPE(SDO_UTIL.TO_GMLGEOMETRY( SDO_LRS.CONVERT_TO_STD_GEOM(route_geometry))) AS GmlGeometry FROM lrs_routes a WHERE a.route_id = 1; GMLGEOMETRY  <gml:LineString srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"> <gml:coordinates decimal="." cs="," ts=" ">2,2 2,4 8,4 12,4 12,10 8,10 5,14 </ gml:coordinates> </gml:LineString>
The following examples return GML fragments for a variety of geometry types.
 Point geometry with coordinates in SDO_ORDINATES. Note the  coordinates in the GML are (10,10) and the values in the  SDO_POINT field are discarded. SELECT TO_CHAR( SDO_UTIL.TO_GMLGEOMETRY(sdo_geometry(2001, 8307, sdo_point_type(80, 70, null), sdo_elem_info_array(1,1,1), sdo_ordinate_array(10, 10))) ) AS GmlGeometry FROM DUAL; GMLGEOMETRY  <gml:Point srsName="SDO:8307" xmlns:gml="http://www.opengis.net/gml"><gml:coordi nates decimal="." cs="," ts=" ">10,10 </gml:coordinates></gml:Point>  Multipolygon SET LONG 40000 SELECT SDO_UTIL.TO_GMLGEOMETRY( sdo_geometry(2007, 8307, null, sdo_elem_info_array(1,1003,1, 13,1003,1, 23,1003,3), sdo_ordinate_array(10.10,10.20, 20.50,20.10, 30.30,30.30, 40.10,40.10, 30.50, 30.20, 10.10, 10.20, 5,5, 5,6, 6,6, 6,5, 5,5, 7,7, 8,8 )) ) AS GmlGeometry FROM DUAL; GMLGEOMEtTRY  <gml:MultiPolygon srsName="SDO:8307" xmlns:gml="http://www.opengis.net/gml"><gml :polygonMember><gml:Polygon><gml:outerBoundaryIs><gml:LinearRing><gml:coordinate s decimal="." cs="," ts=" ">10.1,10.2 20.5,20.1 30.3,30.3 40.1,40.1 30.5,30.2 10 .1,10.2 </gml:coordinates></gml:LinearRing></gml:outerBoundaryIs></gml:Polygon>< /gml:polygonMember><gml:polygonMember><gml:Polygon><gml:outerBoundaryIs><gml:Lin earRing><gml:coordinates decimal="." cs="," ts=" ">5.0,5.0 5.0,6.0 6.0,6.0 6.0,5 .0 5.0,5.0 </gml:coordinates></gml:LinearRing></gml:outerBoundaryIs></gml:Polygo n></gml:polygonMember><gml:polygonMember><gml:Polygon><gml:outerBoundaryIs><gml: LinearRing><gml:coordinates decimal="." cs="," ts=" ">7.0,7.0 8.0,7.0 8.0,8.0 7. 0,8.0 7.0,7.0 </gml:coordinates></gml:LinearRing></gml:outerBoundaryIs></gml:Pol ygon></gml:polygonMember></gml:MultiPolygon> SQL> SET LONG 80  Rectangle (geodetic) SELECT TO_CHAR( SDO_UTIL.TO_GMLGEOMETRY(sdo_geometry(2003, 8307, null, sdo_elem_info_array(1,1003,3), sdo_ordinate_array(10.10,10.10, 20.10,20.10 ))) ) AS GmlGeometry FROM DUAL; GMLGEOMETRY  <gml:Box srsName="SDO:8307" xmlns:gml="http://www.opengis.net/gml"><gml:coordina tes decimal="." cs="," ts=" ">10.1,10.1 20.1,20.1 </gml:coordinates></gml:Box>  Polygon with holes SELECT TO_CHAR( SDO_UTIL.TO_GMLGEOMETRY(sdo_geometry(2003, 262152, null, sdo_elem_info_array(1,1003,3, 5, 2003, 1, 13, 2003, 1), sdo_ordinate_array(10.10,10.20, 40.50, 41.10, 30.30, 30.30, 30.30, 40.10, 40.10, 40.10, 30.30, 30.30, 5, 5, 5, 6, 6, 6, 6, 5, 5, 5 ))) ) AS GmlGeometry FROM DUAL; GMLGEOMETRY  <gml:Polygon srsName="SDO:262152" xmlns:gml="http://www.opengis.net/gml"><gml:ou terBoundaryIs><gml:LinearRing><gml:coordinates decimal="." cs="," ts=" ">10.1,10 .2, 40.5,10.2, 40.5,41.1, 10.1,41.1, 10.1,10.2 </gml:coordinates></gml:LinearRin g></gml:outerBoundaryIs><gml:innerBoundaryIs><gml:LinearRing><gml:coordinates de cimal="." cs="," ts=" ">30.3,30.3 30.3,40.1 40.1,40.1 30.3,30.3 </gml:coordinate s></gml:LinearRing></gml:innerBoundaryIs><gml:innerBoundaryIs><gml:LinearRing><g ml:coordinates decimal="." cs="," ts=" ">5,5 5,6 6,6 6,5 5,5 </gml:coordinates>< /gml:LinearRing></gml:innerBoundaryIs></gml:Polygon>  Creating an XMLTYPE from the GML fragment. Also useful for "pretty  printing" the GML output. SET LONG 40000 SELECT XMLTYPE( SDO_UTIL.TO_GMLGEOMETRY(sdo_geometry(2003, 262152, null, sdo_elem_info_array(1,1003,1, 11, 2003, 1, 21, 2003, 1), sdo_ordinate_array(10.10,10.20, 40.50,10.2, 40.5,41.10, 10.1,41.1, 10.10, 10.20, 30.30,30.30, 30.30, 40.10, 40.10, 40.10, 40.10, 30.30, 30.30, 30.30, 5, 5, 5, 6, 6, 6, 6, 5, 5, 5 ))) ) AS GmlGeometry FROM DUAL; GMLGEOMETRY  <gml:Polygon srsName="SDO:262152" xmlns:gml="http://www.opengis.net/gml"><gml:ou terBoundaryIs><gml:LinearRing><gml:coordinates decimal="." cs="," ts=" ">10.1,10 .2 40.5,10.2 40.5,41.1 10.1,41.1 10.1,10.2 </gml:coordinates></gml:LinearRing></ gml:outerBoundaryIs><gml:innerBoundaryIs><gml:LinearRing><gml:coordinates decima l="." cs="," ts=" ">30.3,30.3 30.3,40.1 40.1,40.1 40.1,30.3 30.3,30.3 </gml:coor dinates></gml:LinearRing></gml:innerBoundaryIs><gml:innerBoundaryIs><gml:LinearR ing><gml:coordinates decimal="." cs="," ts=" ">5,5 5,6 6,6 6,5 5,5 </gml:coordin ates></gml:LinearRing></gml:innerBoundaryIs></gml:Polygon>
The following example uses the TO_GMLGEOMETRY function with the Oracle XML DB XMLTYPE data type and the XMLELEMENT and XMLFOREST functions.
SELECT xmlelement("State", xmlattributes( 'http://www.opengis.net/gml' as "xmlns:gml"), xmlforest(state as "Name", totpop as "Population", xmltype(sdo_util.to_gmlgeometry(geom)) as "gml:geometryProperty")) AS theXMLElements FROM states WHERE state_abrv in ('DE', 'UT'); THEXMLELEMENTS  <State xmlns:gml="http://www.opengis.net/gml"> <Name>Delaware</Name> <Population>666168</Population> <gml:geometryProperty> <gml:Polygon srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"> <gml:outerBoundaryIs> <gml:LinearRing> <gml:coordinates decimal="." cs="," ts=" ">75.788704,39.721699 75.78 8704,39.6479 75.767014,39.377106 75.76033,39.296497 75.756294,39.24585 75.74 8016,39.143196 75.722961,38.829895 75.707695,38.635166 75.701912,38.560619 7 5.693871,38.460011 75.500336,38.454002 75.341614,38.451855 75.049339,38.45165 3 75.053841,38.538429 75.06015,38.605465 75.063263,38.611275 75.065308,38.62 949 75.065887,38.660919 75.078697,38.732403 75.082527,38.772045 75.091667,38 .801208 75.094185,38.803699 75.097572,38.802986 75.094116,38.793579 75.09926 6,38.78756 75.123619,38.781784 75.137962,38.782703 75.18692,38.803772 75.215 019,38.831547 75.23735,38.849014 75.260498,38.875 75.305908,38.914673 75.316 399,38.930309 75.317284,38.93676 75.312851,38.945576 75.312859,38.945618 75. 31205,38.967804 75.31778,38.986012 75.341431,39.021233 75.369606,39.041359 7 5.389229,39.051422 75.40181,39.06702 75.401306,39.097713 75.411369,39.148029 75.407845,39.175201 75.396271,39.187778 75.39225,39.203377 75.40181,39.23104 9 75.402817,39.253189 75.409355,39.264759 75.434006,39.290424 75.439041,39.3 13065 75.453125,39.317093 75.457657,39.326653 75.469231,39.330677 75.486336, 39.341743 75.494888,39.354324 75.504448,39.357346 75.51284,39.366291 75.5129 24,39.366482 75.523773,39.392052 75.538651,39.415707 75.56749,39.436436 75.5 9137,39.463696 75.592941,39.471806 75.590019,39.488026 75.587311,39.496136 7 5.5774,39.508076 75.554192,39.506947 75.528442,39.498005 75.530373,39.510303 75.527145,39.531326 75.52803,39.535168 75.53437,39.540592 75.519386,39.55528 6 75.512291,39.567505 75.515587,39.580639 75.528046,39.584 75.538269,39.5935 67 75.554016,39.601727 75.560143,39.622578 75.556602,39.6348 75.549599,39.63 7699 75.542397,39.645901 75.535507,39.647099 75.514999,39.668499 75.507523,3 9.69685 75.496597,39.701302 75.488914,39.714722 75.477997,39.714901 75.47550 2,39.733501 75.467972,39.746975 75.463707,39.761101 75.448494,39.773857 75.4 38301,39.783298 75.405701,39.796101 75.415405,39.801678 75.454102,39.820202  75.499199,39.833199 75.539703,39.8381 75.5802,39.838417 75.594017,39.837345  75.596107,39.837044 75.639488,39.82893 75.680145,39.813839 75.71096,39.796352 75.739716,39.772881 75.760689,39.74712 75.774101,39.721699 75.788704,39.721 699 </gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> </gml:geometryProperty> </State> <State xmlns:gml="http://www.opengis.net/gml"> <Name>Utah</Name> <Population>1722850</Population> <gml:geometryProperty> <gml:Polygon srsName="SDO:" xmlns:gml="http://www.opengis.net/gml"> <gml:outerBoundaryIs> <gml:LinearRing> <gml:coordinates decimal="." cs="," ts=" ">114.040871,41.993805 114. 038803,41.884899 114.041306,41 114.04586,40.116997 114.046295,39.906101 114. 046898,39.542801 114.049026,38.67741 114.049339,38.572968 114.049095,38.14864 114.0476,37.80946 114.05098,37.746284 114.051666,37.604805 114.052025,37.10 3989 114.049797,37.000423 113.484375,37 112.898598,37.000401 112.539604,37.0 00683 112,37.000977 111.412048,37.001514 111.133018,37.00079 110.75,37.00320 1 110.5,37.004265 110.469505,36.998001 110,36.997967 109.044571,36.999088 1 09.045143,37.375 109.042824,37.484692 109.040848,37.881176 109.041405,38.1530 27 109.041107,38.1647 109.059402,38.275501 109.059296,38.5 109.058868,38.719 906 109.051765,39 109.050095,39.366699 109.050697,39.4977 109.050499,39.6605 109.050156,40.222694 109.047577,40.653641 109.0494,41.000702 109.2313,41.00 2102 109.534233,40.998184 110,40.997398 110.047768,40.997696 110.5,40.994801 111.045982,40.998013 111.045815,41.251774 111.045097,41.579899 111.045944,4 2.001633 111.506493,41.999588 112.108742,41.997677 112.16317,41.996784 112.1 72562,41.996643 112.192184,42.001244 113,41.998314 113.875,41.988091 114.040 871,41.993805 </gml:coordinates> </gml:LinearRing> </gml:outerBoundaryIs> </gml:Polygon> </gml:geometryProperty> </State>
Usage Notes
This function does not convert circles, geometries containing any circular arcs, LRS geometries, or geometries with an SDO_ETYPE value of 0 (type 0 elements); it returns an empty CLOB in these cases.
Polygons must be defined using the conventions for Oracle9i and later releases of Spatial. That is, the outer boundary is stored first (with ETYPE=1003) followed by zero or more inner boundary elements (ETYPE=2003). For a polygon with holes, the outer boundary must be stored first in the SDO_ORDINATES definition, followed by coordinates of the inner boundaries.
LRS geometries must be converted to standard geometries (using the SDO_LRS.CONVERT_TO_STD_GEOM or SDO_LRS.CONVERT_TO_STD_LAYER function) before being passed to the TO_KMLGEOMETRY function.
Any circular arcs or circles must be densified (using the SDO_GEOM.SDO_ARC_DENSIFY function) or represented as polygons (using the SDO_GEOM.SDO_BUFFER function) before being passed to the TO_KMLGEOMETRY function.
Label points are discarded. That is, if a geometry has a value for the SDO_POINT field and values in SDO_ELEM_INFO and SDO_ORDINATES, the SDO_POINT is not output in the KML document.
Solid geometries are converted to KML MultiGeometry objects, because KML 2.1 does not support solids. If you then use the SDO_UTIL.FROM_KMLGEOMETRY function on the MultiGeometry, the result is not an Oracle Spatial solid geometry (that is, its SDO_GTYPE value does not reflect a geometry type of SOLID or MULTISOLID).
The KML output is not formatted; there are no line breaks or indentation of tags. To see the contents of the returned CLOB in SQL*Plus, use the TO_CHAR() function or set the SQL*Plus parameter LONG to a suitable value (for example, SET LONG 2000
). To get formatted GML output or to use the return value of TO_KMLGEOMETRY in SQLX or Oracle XML DB functions such as XMLELEMENT, use the XMLTYPE(clobval CLOB) constructor.
Examples
The following example shows conversion to and from KML format. (The example uses the definitions and data from Section 2.1, specifically the cola_c
geometry from the COLA_MARKETS table.)
 Convert cola_c geometry to a KML document; convert that result to  a spatial geometry. set long 2000; DECLARE kmlgeom CLOB; val_result VARCHAR2(5); geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_c';  To KML geometry kmlgeom := SDO_UTIL.TO_KMLGEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To KML geometry result = '  TO_CHAR(kmlgeom));  From KML geometry geom_result := SDO_UTIL.FROM_KMLGEOMETRY(kmlgeom);  Validate the returned geometry. val_result := SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(geom_result, 0.005); DBMS_OUTPUT.PUT_LINE('Validation result = '  val_result); END; / To KML geometry result = <Polygon><extrude>0</extrude><tessellate>0</tessellate><altitudeMode>relativeToG round</altitudeMode><outerBoundaryIs><LinearRing><coordinates>3.0,3.0 6.0,3.0 6.0,5.0 4.0,5.0 3.0,3.0 </coordinates></LinearRing></outerBoundaryIs></Polygon> Validation result = TRUE
Usage Notes
The input geometry is converted to the wellknown binary (WKB) format, as defined by the Open Geospatial Consortium and the International Organization for Standardization (ISO).
This function is patterned after the SQL Multimedia recommendations in ISO 132493, Information technology  Database languages  SQL Multimedia and Application Packages  Part 3: Spatial.
To convert a geometry in WKB format to an SDO_GEOMETRY object, use the SDO_UTIL.FROM_WKBGEOMETRY function.
Examples
The following example shows conversion to and from WKB and WKT format, and validation of WKB and WKT geometries. (The example uses the definitions and data from Section 2.1, specifically the cola_b
geometry from the COLA_MARKETS table.)
DECLARE wkbgeom BLOB; wktgeom CLOB; val_result VARCHAR2(5); geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_b';  To WBT/WKT geometry wkbgeom := SDO_UTIL.TO_WKBGEOMETRY(geom); wktgeom := SDO_UTIL.TO_WKTGEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To WKT geometry result = '  TO_CHAR(wktgeom));  From WBT/WKT geometry geom_result := SDO_UTIL.FROM_WKBGEOMETRY(wkbgeom); geom_result := SDO_UTIL.FROM_WKTGEOMETRY(wktgeom);  Validate WBT/WKT geometry val_result := SDO_UTIL.VALIDATE_WKBGEOMETRY(wkbgeom); DBMS_OUTPUT.PUT_LINE('WKB validation result = '  val_result); val_result := SDO_UTIL.VALIDATE_WKTGEOMETRY(wktgeom); DBMS_OUTPUT.PUT_LINE('WKT validation result = '  val_result); END;/ To WKT geometry result = POLYGON ((5.0 1.0, 8.0 1.0, 8.0 6.0, 5.0 7.0, 5.0 1.0)) WKB validation result = TRUE WKT validation result = TRUE
Usage Notes
The input geometry is converted to the wellknown text (WKT) format, as defined by the Open Geospatial Consortium and the International Organization for Standardization (ISO).
This function is patterned after the SQL Multimedia recommendations in ISO 132493, Information technology  Database languages  SQL Multimedia and Application Packages  Part 3: Spatial.
To convert a geometry in WKT format to an SDO_GEOMETRY object, use the SDO_UTIL.FROM_WKTGEOMETRY function.
Examples
The following example shows conversion to and from WKB and WKT format, and validation of WKB and WKT geometries. (The example uses the definitions and data from Section 2.1, specifically the cola_b
geometry from the COLA_MARKETS table.)
DECLARE wkbgeom BLOB; wktgeom CLOB; val_result VARCHAR2(5); geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_b';  To WBT/WKT geometry wkbgeom := SDO_UTIL.TO_WKBGEOMETRY(geom); wktgeom := SDO_UTIL.TO_WKTGEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To WKT geometry result = '  TO_CHAR(wktgeom));  From WBT/WKT geometry geom_result := SDO_UTIL.FROM_WKBGEOMETRY(wkbgeom); geom_result := SDO_UTIL.FROM_WKTGEOMETRY(wktgeom);  Validate WBT/WKT geometry val_result := SDO_UTIL.VALIDATE_WKBGEOMETRY(wkbgeom); DBMS_OUTPUT.PUT_LINE('WKB validation result = '  val_result); val_result := SDO_UTIL.VALIDATE_WKTGEOMETRY(wktgeom); DBMS_OUTPUT.PUT_LINE('WKT validation result = '  val_result); END;/ To WKT geometry result = POLYGON ((5.0 1.0, 8.0 1.0, 8.0 6.0, 5.0 7.0, 5.0 1.0)) WKB validation result = TRUE WKT validation result = TRUE
Description
Validates the input geometry, which is in the standard wellknown binary (WKB) format; returns the string TRUE
if the geometry is valid or FALSE
if the geometry is not valid.
Usage Notes
To be valid, the input geometry must be in the wellknown binary (WKB) format, as defined by the Open Geospatial Consortium and the International Organization for Standardization (ISO).
This function is patterned after the SQL Multimedia recommendations in ISO 132493, Information technology  Database languages  SQL Multimedia and Application Packages  Part 3: Spatial.
To validate a geometry in the wellknown text (WKT) format, use the SDO_UTIL.VALIDATE_WKTGEOMETRY function.
Examples
The following example shows conversion to and from WKB and WKT format, and validation of WKB and WKT geometries. (The example uses the definitions and data from Section 2.1, specifically the cola_b
geometry from the COLA_MARKETS table.)
DECLARE wkbgeom BLOB; wktgeom CLOB; val_result VARCHAR2(5); geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_b';  To WBT/WKT geometry wkbgeom := SDO_UTIL.TO_WKBGEOMETRY(geom); wktgeom := SDO_UTIL.TO_WKTGEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To WKT geometry result = '  TO_CHAR(wktgeom));  From WBT/WKT geometry geom_result := SDO_UTIL.FROM_WKBGEOMETRY(wkbgeom); geom_result := SDO_UTIL.FROM_WKTGEOMETRY(wktgeom);  Validate WBT/WKT geometry val_result := SDO_UTIL.VALIDATE_WKBGEOMETRY(wkbgeom); DBMS_OUTPUT.PUT_LINE('WKB validation result = '  val_result); val_result := SDO_UTIL.VALIDATE_WKTGEOMETRY(wktgeom); DBMS_OUTPUT.PUT_LINE('WKT validation result = '  val_result); END;/ To WKT geometry result = POLYGON ((5.0 1.0, 8.0 1.0, 8.0 6.0, 5.0 7.0, 5.0 1.0)) WKB validation result = TRUE WKT validation result = TRUE
Format
SDO_UTIL.VALIDATE_WKTGEOMETRY(
geometry IN CLOB
) RETURN VARCHAR2;
or
SDO_UTIL.VALIDATE_WKTGEOMETRY(
geometry IN VARCHAR2
) RETURN VARCHAR2;
Description
Validates the input geometry, which is of type CLOB or VARCHAR2 and in the standard wellknown text (WKT) format; returns the string TRUE
if the geometry is valid or FALSE
if the geometry is not valid.
Usage Notes
To be valid, the input geometry must be in the wellknown text (WKT) format, as defined by the Open Geospatial Consortium and the International Organization for Standardization (ISO).
This function is patterned after the SQL Multimedia recommendations in ISO 132493, Information technology  Database languages  SQL Multimedia and Application Packages  Part 3: Spatial.
To validate a geometry in the wellknown binary (WKB) format, use the SDO_UTIL.VALIDATE_WKBGEOMETRY function.
Examples
The following example shows conversion to and from WKB and WKT format, and validation of WKB and WKT geometries. (The example uses the definitions and data from Section 2.1, specifically the cola_b
geometry from the COLA_MARKETS table.)
DECLARE wkbgeom BLOB; wktgeom CLOB; val_result VARCHAR2(5); geom_result SDO_GEOMETRY; geom SDO_GEOMETRY; BEGIN SELECT c.shape INTO geom FROM cola_markets c WHERE c.name = 'cola_b';  To WBT/WKT geometry wkbgeom := SDO_UTIL.TO_WKBGEOMETRY(geom); wktgeom := SDO_UTIL.TO_WKTGEOMETRY(geom); DBMS_OUTPUT.PUT_LINE('To WKT geometry result = '  TO_CHAR(wktgeom));  From WBT/WKT geometry geom_result := SDO_UTIL.FROM_WKBGEOMETRY(wkbgeom); geom_result := SDO_UTIL.FROM_WKTGEOMETRY(wktgeom);  Validate WBT/WKT geometry val_result := SDO_UTIL.VALIDATE_WKBGEOMETRY(wkbgeom); DBMS_OUTPUT.PUT_LINE('WKB validation result = '  val_result); val_result := SDO_UTIL.VALIDATE_WKTGEOMETRY(wktgeom); DBMS_OUTPUT.PUT_LINE('WKT validation result = '  val_result); END;/ To WKT geometry result = POLYGON ((5.0 1.0, 8.0 1.0, 8.0 6.0, 5.0 7.0, 5.0 1.0)) WKB validation result = TRUE WKT validation result = TRUE
ym/nԃT]J'9ЩNQʳleZSSWP)AԤB*2>~YA {vd/
7]ss
ꖲx3I8!IeK*F#1űYKkgN<%eivQZXͮzYmEYc<{pUg2rSGT9*IbbҊY:(gX%MQP*t)p!.Pu1QtqP;^/5'N4C4Ico/x<>ukƥ%߽ܲJݥ(B8/\~fk%9ٹ?:*<`Gs:u==
>%^#$9%lxMǺYUqTrR(P>
k/V~(į?4φo[U{[WƿW;ָ+/Yk:4vqx3U^3<QF&]*K>=Wetjca
s3U3Yay<>=:ձyaaGqE0ZtESγ%>x]3+mS4JNω͝oEZ_E$qoѪhW6zN:BiJ4\JE^iS^*?FI*Odr!SĬU_t2UWk(ʊPTJ1NԦ}s~:쳩~ҒTC]vBEx>}75[ަ&mQU״SW7pEgiZmESxSne:qrtpp^kS1xҭS3:؊WĺbU/_.K5Q'9ѕj,YTCQ**O/x7OM[_71ϡx3E.{G뜿"'yGiEg?L_
]\kUKa;:G<(4YfۻsxΝT/\1JjЧRD9}j:4qjV/Aӹթ5<$+SV,ExVKMNS¬`9TT9J7_,'">j ut[AL)&RM'\G.CBQ4}*XXi)W_IcQܥ &:7VT8\F5f3C둯_PQqlMyƍ>Z MART > R.I{^վ"\kGjLwEgJNL'SepocF_injM_O8Sޞl1oo
,&YYRyʝ7N&˟?e~1xվ'K\xsş/M7,%c{o
iZ5?Ūhvk1\..bE?<Y%%u1u)c}iU7<x;᾿MG7^vM_G#ӯ5{ۙW*{s4hT=)\t3oA_0UՌ{*Ri^zzE:':pc?*\aBQS ^u(ExuWBjގ.(w^ʔ^ȾQcσ>xA(<5&K{{exZ{?)uawZ:AeI$W+bk9Yf9n&/[+(ӕu=JiNPp%NJO20i`t!˂̩bhbiORukǙ89U~2(ΔeJPpTG<'Gujzm}Ox{!o[qb<'7þ>iďM>!3wuYC χpeDQQ*xbj8Jzxjt)՝JTp:y7YsSRr^ySS)I8
I1X