Spatial Engine OracleSpatial

A spatial engine provides access to a service that can perform spatial operations, one of the available spatial engines is for Oracle Spatial.

Namespace

urn:com.cohga.server.spatial.geotools#1.0

Tags

spatialengine

Properties

Sub-tags

None

Content

None

Notes

No connection pool configuration is provided with this driver, the driver manages the connection pooling itself.
If database starts with '(' then the format of the connection url will be
jdbc:oracle:thin:@database
If database starts with '/' then the format of the connection url will be
jdbc:oracle:thin:@//host:portdatabase
else the format of the connection url will be
jdbc:oracle:thin:@host:port:database

Examples

<spatial:spatialengine id="oracle">
	<dbtype>oracle</dbtype>
	<host>oradev</host>
	<port>1521</port>
	<user>gis</user>
	<passwd>hak0rz</passwd>
	<schema>GIS</schema>
</spatial:spatialengine>

<spatial:spatialengine id="sdbeos">
	<dbtype>oracle</dbtype>
	<host>sdbeos</host>
	<port>1521</port>
	<database>staging</database>
	<user>data_viewer</user>
	<passwd>ENCSSJKXUMJBMTPGEJFGCXCQFXJJZUTMJZJ</passwd>
	<schema>ASSETS</schema>
</spatial:spatialengine>

Primary Key Metadata

If the primary key for a table can not be determined by Weave directly from the database then the information can be provided by creating a table or directly embedding the information in the spatial engine configuration.

CREATE TABLE gt_pk_metadata (
  table_schema VARCHAR(32),
  table_name VARCHAR(32) NOT NULL,
  pk_column VARCHAR(32) NOT NULL,
  pk_column_idx INTEGER,
  pk_policy VARCHAR(32),
  pk_sequence VARCHAR(64),
  unique (table_schema, table_name, pk_column),
  check (pk_policy in ('sequence', 'assigned', 'autogenerated'))
)

pk_policy can be 'assigned', 'sequence' or 'autogenerated' depending upon how the key column value is generated. The pk_sequence value only need to be set if the policy is 'sequence'.
'sequence' means that the value for the column is generated using a database sequence, and the 'pk_sequence' value must be set.
'autogenerated' means that the value for the column is generated by the database using another method.
'assigned' means that the value for the column is determined by the current maximum value +1, if the column is an integral type, or as a random string if the column is textual.

Using primary key metadata configuration

You can also specify the above information directly in the spatial engin configuration.

The table name

The optional table schema

<spatial:spatialengine id="sdbeos">
  <dbtype>oracle</dbtype>
  <host>sdbeos</host>
  <port>1521</port>
  <database>staging</database>
  <user>data_viewer</user>
  <passwd>ENCSSJKXUMJBMTPGEJFGCXCQFXJJZUTMJZJ</passwd>
  <schema>ASSETS</schema>
  <primarykeymetadata>
    <table schema="ASSETS" name="PARK" column="GID" policy="autogenerated"/>
    <table schema="ASSETS" name="PROPERTY" column="PARK_ID" type="autogenerated"/>
    <table schema="ASSETS" name="ROAD" column="OBJECTID" type="autogenerated"/>
  </primarykeymetadata>
</spatial:spatialengine>

Geometry metadata

The Oracle data store will, by default, look into the MDSYS.USER_SDO* and MDSYS.ALL_SDO* views to determine the geometry type and native SRID of each geometry column. Those views are automatically populated with information about the geometry columns stored in tables that the current user owns (for the MDSYS.USER_SDO* views) or can otherwise access (for the MDSYS.ALL_SDO* views).

There are a few hiccups in this process:

• if the connection pool user cannot access the tables (because impersonation is being used) the MDSYS views will be empty, making it impossible to determine either the geometry type and the native SRID
• the geometry type can be specified only while building the spatial indexes, as a index constraint, however such information is often not included when creating the indexes
• the views are populated dynamically based on the current user, if the database has thousands of tables and users the views can become very slow

The database administrator can address the above issues by manually creating a geometry metadata table describing each geometry column, and then indicate its presence among the Oracle data store connection parameter named geometrymetadatatable (either as a simple table name, or a schema qualified one). The table has the following structure (the table name is free, just indicate the one chosen in the data store connection parameter):

CREATE TABLE GEOMETRY_COLUMNS(
   F_TABLE_SCHEMA VARCHAR(30) NOT NULL,
   F_TABLE_NAME VARCHAR(30) NOT NULL,
   F_GEOMETRY_COLUMN VARCHAR(30) NOT NULL,
   COORD_DIMENSION INTEGER,
   SRID INTEGER NOT NULL,
   TYPE VARCHAR(30) NOT NULL,
   UNIQUE(F_TABLE_SCHEMA, F_TABLE_NAME, F_GEOMETRY_COLUMN),
   CHECK(TYPE IN ('POINT','LINESTRING', 'POLYGON', 'COLLECTION', 'MULTIPOINT', 'MULTILINESTRING', 'MULTIPOLYGON', 'GEOMETRY') )
);

When the table is present the store will first search it for information about each geometry column to be classified, and fall back on the MDSYS views only if such table does not contain any information.

Using geometry metadata configuration 

As of Weave 2.5.16 it's possible to specify the information contained in the geometry metadata table directly in the spatial engine configuration.

name

The table name

schema

The optional table schema

The geometry type (point, linestring, curve, polygon, multipoint, multilinestring, multicurve, multipolygon)

The geometry srid

The geometry dimension

<spatial:spatialengine id="sdbeos">
  <dbtype>oracle</dbtype>
  <host>sdbeos</host>
  <port>1521</port>
  <database>staging</database>
  <user>data_viewer</user>
  <passwd>ENCSSJKXUMJBMTPGEJFGCXCQFXJJZUTMJZJ</passwd>
  <schema>ASSETS</schema>
  <geometrymetadata>
    <table name="PARK" type="multipolygon" srid="28355" dimension="2"/>
    <table name="PROPERTY" type="polygon" srid="28355" dimension="2"/>
    <table name="ROAD" type="linestring" srid="28355" dimension="2"/>
  </geometrymetadata>
</spatial:spatialengine>