Page Comparison

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@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@host:port:database

Examples

...

...

Basic Oracle connection

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

Basic Oracle connection with the password using the osgi encrypt command and a database specified

<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.

SQL create statement for gt_pk_metadata table

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.

<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 MDSYSthe MDSYS.USER_SDO* and MDSYS 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 MDSYSthe MDSYS.USER_SDO* views) or can otherwise access (for the MDSYSthe 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):

Code Block
language sql
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','LINELINESTRING', 'POLYGON', 'COLLECTION', 'MULTIPOINT', 'MULTILINEMULTILINESTRING', '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.

<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>