|Oracle® Spatial User's Guide and Reference
10g Release 2 (10.2)
|PDF · Mobi · ePub|
This section describes major new and changed Oracle Spatial features for the current release.
Coordinate system support in Spatial is now based on, but is not identical to, the data model and data provided by the European Petroleum Survey Group (EPSG), as explained in Section 6.4. Applications that depend on the data model from previous releases (the "legacy" model) continue to be fully supported; however, the EPSG model bases Spatial on a widely accepted standard and enables greater flexibility for users who want to perform customized datum transformations.
The SDO_CS package (described in Chapter 13) contains the following new subprograms to support the EPSG model:
|SDO_CS.ADD_PREFERENCE_FOR_OP||Adds a preference for an operation between a source coordinate system and a target coordinate system.|
|SDO_CS.CONVERT_NADCON_TO_XML||Converts a NADCON (North American Datum Conversion) grid in ASCII format to an Oracle Spatial XML representation.|
|SDO_CS.CONVERT_NTV2_TO_XML||Converts an NTv2 (National Transformation Version 2) grid in ASCII format to an Oracle Spatial XML representation.|
|SDO_CS.CONVERT_XML_TO_NADCON||Converts an Oracle Spatial XML representation of a NADCON (North American Datum Conversion) grid to NADCON ASCII format.|
|SDO_CS.CONVERT_XML_TO_NTV2||Converts an Oracle Spatial XML representation of an NTv2 (National Transformation Version 2) grid to NTv2 ASCII format.|
|SDO_CS.CREATE_CONCATENATED_OP||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.|
|SDO_CS.DELETE_ALL_EPSG_RULES||Deletes the basic set of EPSG rules to be applied in certain transformations.|
|SDO_CS.DELETE_OP||Deletes a concatenated operation.|
|SDO_CS.DETERMINE_CHAIN||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.|
|SDO_CS.FIND_GEOG_CRS||Returns the SRID values of geodetic (geographic) coordinate reference systems that have the same well-known text (WKT) numeric values as the coordinate reference system with the specified reference SRID value.|
|SDO_CS.FIND_PROJ_CRS||Returns the SRID values of geodetic (geographic) coordinate reference systems that have the same well-known text (WKT) numeric values as the coordinate reference system with the specified reference SRID value.|
|SDO_CS.FROM_OGC_SIMPLEFEATURE_SRS||Returns the SRID values of projected coordinate reference systems that have the same well-known text (WKT) numeric values as the coordinate reference system with the specified reference SRID value.|
|SDO_CS.MAP_EPSG_SRID_TO_ORACLE||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 well-known text string from the Open Geospatial Consortium simple feature format that includes the
The SDO_GEOMETRY object type has the following new methods (member functions): Get_WKB, Get_WKT, ST_CoordDim, and ST_IsValid. The SDO_GEOMETRY methods are described in Section 2.3. (The methods were described in a separate chapter in the previous release of this guide.)
The SDO_GEOMETRY object type has new constructors for creating a geometry object from a well-known text (WKT) string in CLOB or VARCHAR2 format, or from a well-known binary (WKT) object in BLOB format. These constructors are described in Section 2.4.
min_resolution includes only geometries for which at least one side of the geometry's MBR is equal to or greater than the specified value. For example,
min_resolution=10 includes only geometries for which the width or the height (or both) of the geometry's MBR is at least 10. (This keyword can be used to exclude geometries that are too small to be of interest.)
max_resolution includes only geometries for which at least one side of the geometry's MBR is less than or equal to the specified value. For example,
max_resolution=10 includes only geometries for which the width or the height (or both) of the geometry's MBR is less than or equal to 10. (This keyword can be used to exclude geometries that are too large to be of interest.)
The Spatial operators are described in Chapter 11.
sdo_dml_batch_size parameter for the CREATE INDEX statement can affect the performance of applications that insert or update spatial data. This parameter specifies the number of index updates to be processed in each batch of updates after a commit operation. The default value is 1000. See the CREATE INDEX statement reference information and Usage Note in Chapter 10 for details.
This parameter is part of a change for this release in how Spatial updates the spatial index when rows are inserted, updated, or deleted in the spatial table. In previous releases, Spatial updated the index after each DML (insert, update, or delete) operation on the table. In the current release, Spatial does not update the index until after the commit operation completes the transaction, and it updates the index in batches of operations determined by the
sdo_dml_batch_size value. The result is faster processing of each DML operation and some extra time required after the commit operation, but a substantial overall performance improvement.
As a result of this change in spatial index update behavior, as well as other internal improvements, you are no longer encouraged to perform commit operations after each spatial table insert or update operation. Instead, for better performance (especially with large numbers of operations), perform the commit operation after a number of insert or update operations that is greater than the
sdo_dml_batch_size value. There is no longer a risk of deadlocks or other locking problems if you delay performing the commit operation, even if multiple users in the same session are updating the spatial table.
The SDO_GCDR package (described in Chapter 14) contains the following new subprograms:
|SDO_GCDR.GEOCODE_ADDR||Geocodes an input address using attributes in an SDO_GEO_ADDR object, and returns the first matched address as an SDO_GEO_ADDR object.|
|SDO_GCDR.GEOCODE_ADDR_ALL||Geocodes an input address using attributes in an SDO_GEO_ADDR object, and returns matching addresses as an SDO_ADDR_ARRAY object.|
|SDO_GCDR.REVERSE_GEOCODE||Reverse geocodes a location, specified by its spatial geometry object and country, and returns an SDO_GEO_ADDR object.|
The SDO_UTIL package (described in Chapter 20) contains the following new subprograms:
|SDO_UTIL.FROM_WKBGEOMETRY||Converts a geometry in the well-known binary (WKB) format to a Spatial geometry object.|
|SDO_UTIL.FROM_WKTGEOMETRY||Converts a geometry in the well-known text (WKT) format to a Spatial geometry object.|
|SDO_UTIL.RECTIFY_GEOMETRY||Fixes certain problems with the input geometry, and returns a valid geometry.|
|SDO_UTIL.TO_WKBGEOMETRY||Converts a Spatial geometry object to the well-known binary (WKB) format.|
|SDO_UTIL.TO_WKTGEOMETRY||Converts a Spatial geometry object to the well-known text (WKT) format.|
|SDO_UTIL.VALIDATE_WKBGEOMETRY||Validates the input geometry, which is in the standard well-known binary (WKB) format; returns the string
|SDO_UTIL.VALIDATE_WKTGEOMETRY||Validates the input geometry, which is of type CLOB or VARCHAR2 and in the standard well-known text (WKT) format; returns the string
Spatial now supports the conversion of point locations between the U.S. National Grid format and the SDO_GEOMETRY point format. Support for the U.S. National Grid point representation format is described in Section 6.10.
unknown CRS (SRID 999999) and
NaC (SRID 999998) coordinate reference systems have been added for Oracle internal use and other possible special uses. These coordinate reference systems are described in Section 6.9.4.
Spatial now includes a routing engine, which enables you to host an XML-based Web service that provides information about a single driving route or multiple routes. The Spatial routing engine is described in Appendix C.
Effective with release 10.2.0.3, the new SDO_LRS.LRS_INTERSECTION function (described in Chapter 16) enables you to return an LRS geometry object that is the topological intersection (AND operation) of an LRS geometric segment and another geometry object.