Search Results sdo_poly_union




Overview
Explore in AI Chat

Overview

MDSYS.SDO_GEOM is the core Oracle Spatial geometry package, shipped as part of the Oracle Locator/Spatial option that is installed by default in the database tier supporting Oracle E-Business Suite 12.1.1 and 12.2.2. Within the EBS technical stack, this package is owned by the MDSYS schema and holds a VALID status, indicating that it is a standard, supported database component rather than a custom or patched object. Its principal business function is to provide the geometric engine that allows spatial data — points, lines, and polygons — to be stored, validated, measured, compared, and transformed. In EBS environments that implement spatial capabilities, such as field service dispatch, territory management, asset tracking, or utility network modeling, SDO_GEOM supplies the low-level operations consumed by higher-level Oracle Spatial APIs and by any customer extensions that manipulate geometry columns. Because it is a database-level utility, it is not owned by the APPS schema; EBS code interacts with it through schema-qualified references or public synonyms, with execution privilege typically granted to APPS and related schemas.

Key Procedures and Functions

The documented API exposes 95 procedures and functions, reflecting the breadth of geometric processing supported. Representative entries include:

  • INIT_ELEMENT — initializes the internal element state used when constructing or parsing an SDO_GEOMETRY value.
  • ADD_NODES — inserts additional nodes into a geometry, commonly used to densify linework or prepare shapes for spatial operations.
  • VALIDATE_GEOMETRY — checks that a geometry is well-formed and consistent with its dimensional model.
  • VALIDATE_LAYER — validates the metadata and contents of a spatial layer rather than a single geometry.
  • CHECK_BOUNDS — verifies that a geometry falls within the declared coordinate bounds of its spatial reference system.
  • GET_ORDS — returns the ordinate values (coordinate components) of a geometry.
  • INTERACT — determines whether two geometries interact spatially.
  • RELATE — computes the nine-intersection relationship between two geometries, the basis for topological predicates.
  • WITHIN_DISTANCE — tests whether two geometries lie within a specified distance of one another.
  • SDO_BUFFER, SDO_UNION, SDO_SELF_UNION, SDO_DIFFERENCE, SDO_XOR, SDO_INTERSECTION — the principal set-based geometry constructors and operators.
  • SDO_POLY_UNION, SDO_POLY_DIFFERENCE, SDO_POLY_XOR, SDO_POLY_INTERSECTION — polygon-specific variants of the corresponding set operations.
  • SDO_LENGTH — returns the length of a linear geometry or the perimeter of a polygon.

These routines are consumed by other MDSYS packages such as SDO_UTIL, SDO_LRS, SDO_TOPO, and SDO_GEOR, and are therefore foundational rather than end-user-facing.

Tables Accessed

The package references several data dictionary and internal tables through APPS synonyms. ALL_TAB_COLS and USER_TAB_COLUMNS are used to inspect column metadata, typically to identify geometry columns or confirm column definitions during validation and metadata refresh activities. PLITBLM is an internal MDSYS support table used during geometry processing. Because SDO_GEOM is a database utility, its direct table access is limited to these metadata and internal structures; feature data itself resides in application-defined tables containing SDO_GEOMETRY columns.

Usage Notes

SDO_GEOM is rarely invoked directly from Oracle EBS forms or concurrent programs. Instead, it is called indirectly: Forms or OAF pages may submit spatial queries that the database resolves through Spatial operators, and concurrent programs may call higher-level packages such as SDO_UTIL or SDO_LRS, which in turn invoke SDO_GEOM. Custom PL/SQL that performs geometric validation, buffering, or set operations should call the documented entry points rather than manipulate SDO_GEOMETRY structures manually. Because the package is referenced by 24 other packages, any modification or invalidation can cascade across the spatial stack, so DBAs should treat it as a protected Oracle-supplied object and rely on supported patching rather than direct edits.