Search Results sdo_addr_array

Overview

MDSYS.SDO_GCDR is the Oracle Spatial and Graph geocoding engine, delivered as part of the MDSYS schema that underlies the Oracle Locator / Spatial option. In the Oracle E-Business Suite 12.1.1 and 12.2.2 environments, the package provides the server-side address-matching and coordinate-assignment services that convert a structured postal address into a geographic location, and conversely resolve a coordinate back into a descriptive address. The status of the package is VALID and its owner is MDSYS. In the ETRM inventory the package is classified with an API type of OTHER, meaning it is not an EBS-owned application interface but a database-tier engine surfaced to EBS through public synonyms and direct schema references.

The specific dependency entry that prompted this research, MDSYS.SDO_ADDR_ARRAY, is the collection type used by SDO_GCDR to pass arrays of normalized address records into and out of the geocoding routines. It is one of several MDSYS-defined types the package depends on, alongside SDO_GEOMETRY, SDO_GEO_ADDR, SDO_KEYWORDARRAY and SDO_STRING_ARRAY. These objects share the same owner and are all resolved at compile time, which is why the dependency tree for SDO_GCDR remains compact and self-contained within MDSYS.

Key Procedures and Functions

The ETRM metadata documents twenty-seven entry points in this package. They fall into three functional groups.

• Geocoding: GEOCODE, GEOCODE_AS_GEOMETRY, GEOCODE_ADDR, GEOCODE_ALL and GEOCODE_ADDR_ALL perform forward geocoding. GEOCODE_AS_GEOMETRY returns an SDO_GEOMETRY point directly, while GEOCODE_ADDR and GEOCODE_ADDR_ALL operate against the SDO_ADDR_ARRAY collection so that batches of addresses can be processed in a single call. BATCH_GEOCODE provides the set-oriented variant used for bulk loads.
• Reverse geocoding: REVERSE_GEOCODE accepts a spatial location and returns the corresponding street address components, typically as an SDO_GEO_ADDR record.
• Reference-data validation: VALIDATECOUNTRYROW, VALIDATEREGIONROW, VALIDATECITYROW, VALIDATELOCALITYDICTROW, VALIDATESTREETDICTROW, VALIDATESTREETTYPEROW, VALIDATEINLINESTREETTYPEROW, VALIDATESTREETPREFIXROW, VALIDATESTREETSUFFIXROW, VALIDATESECONDUNITROW, VALIDATEPOBOXROW and VALIDATEPLACENAMEROW check individual rows of the geocoding lookup tables for conformance with the expected address model. CREATE_PROFILE_TABLES builds the profile and index tables that the geocoder reads at run time.

No parameter lists are reproduced here; the documented inventory exposes only the callable names and their validation or geocoding purpose.

Tables Accessed

The ETRM extract records two table references resolved through APPS synonyms: DBMS_ASSERT and PLITBLM. DBMS_ASSERT is the Oracle-supplied assertion package used to validate schema and object names passed into dynamic SQL, which confirms that SDO_GCDR constructs and executes dynamic statements internally. PLITBLM is the PL/SQL integer table type used to carry numeric collections between the caller and the package. The geocoding engine itself reads the profile tables created by CREATE_PROFILE_TABLES and the MDSYS geocoding metadata (country, region, city, street and PO box dictionaries) that the VALIDATE* routines inspect; these are MDSYS-owned and are consulted rather than owned by EBS.

Usage Notes

SDO_GCDR is not invoked from standard EBS forms or concurrent programs. It is reached by custom PL/SQL that references the PUBLIC synonym SDO_GCDR, and by the MDSYS package SDO_OLS_LOCUTL, which the ETRM dependency listing shows as referencing SDO_GCDR. Any EBS extension that needs address-to-coordinate conversion, store-locator distance calculations, or reverse address lookup should call this package directly after ensuring the Oracle Spatial option and the geocoding profile tables are installed. Because the package is MDSYS-owned and VALID, it should be treated as a vendor object: no modification, and recompilation only through supported Oracle patching.