Geodetic spatial queries - sdo_relate

Hello,
The following script populates a spatial table with points on a query boundary and then queries that table using the query boundary. When using a srid of 8307 not all of the points are returned using sdo_relate. If the srid is NULL then all points 'on' the query boundary are returned.
In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
Thanks in advance,
Rick
========= Script follows ============
geomdetic relate test case
This script demonstrates cases where sdo_relate, in a geodetic coordate system where
"A two point line on a given meridian, doesn't necessarily follow that meridian,
so any feature touching that meridian between those two points is not necessarily
touching that line""
The script generates an input query boundary using max and min values. It inserts
point features on the query boundary at input interval into a test table. '
A spatial query is executed against the test table using the query boundary.
DECLARE
TYPE ord_type IS TABLE OF NUMBER
INDEX BY BINARY_INTEGER;
x_tab ord_type;
y_tab ord_type;
maxlon NUMBER DEFAULT 65;
minlon NUMBER DEFAULT 64;
maxlat NUMBER DEFAULT 45 ;
minlat NUMBER DEFAULT 44;
INCREMENT NUMBER DEFAULT 0.001;
offset number default 0;
srid number default 8307;
curval NUMBER;
objectnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (objectnotexists, -942);
indexnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (indexnotexists, -1418);
PROCEDURE populate_array (
p_minval IN NUMBER,
p_maxval IN NUMBER,
p_increment IN NUMBER,
p_array IN OUT ord_type
IS
i BINARY_INTEGER DEFAULT 0;
BEGIN
curval := p_minval;
LOOP
p_array (i) := curval;
curval := curval + INCREMENT;
i := i + 1;
EXIT WHEN curval > p_maxval;
END LOOP;
END populate_array;
PROCEDURE insert_points_on_tangent (
p_tangent IN NUMBER,
p_ords IN ord_type,
orientation IN VARCHAR
IS
v_geom MDSYS.SDO_GEOMETRY;
i BINARY_INTEGER;
BEGIN
i := p_ords.FIRST; -- get subscript of first element
WHILE i IS NOT NULL
LOOP
IF orientation = 'Y'
THEN
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_tangent,
p_ords (i)
ELSE
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_ords (i),
p_tangent
END IF;
EXECUTE IMMEDIATE 'insert into sdo_relate_geom_test (geom, geom_type) values (:boundary, :geom_tag)'
USING v_geom, orientation || ' ' || i;
i := p_ords.NEXT (i); -- get subscript of next element
END LOOP;
END insert_points_on_tangent;
-- Create a table to hold the geometries.
PROCEDURE TEST
IS
v_geom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_viewportgeom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
0,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_expected NUMBER;
v_relate_results NUMBER;
v_filter_results NUMBER;
v_relate_results_arc NUMBER;
v_dimino MDSYS.SDO_DIM_ARRAY;
v_count_sql VARCHAR2 (1000)
DEFAULT 'select count(*) from sdo_relate_geom_test';
v_filter_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_filter '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
v_relate_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_relate '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
BEGIN
EXECUTE IMMEDIATE v_count_sql
INTO v_expected;
EXECUTE IMMEDIATE v_filter_sql
INTO v_filter_results
USING v_geom;
EXECUTE IMMEDIATE v_relate_sql
INTO v_relate_results
USING v_geom;
DBMS_OUTPUT.put_line ( ' boundary minLat '
|| minlat
|| ' minLon '
|| minlon
|| ' maxLat '
|| maxlat
|| ' maxLon '
|| maxlon
||' increment '
|| INCREMENT
DBMS_OUTPUT.put_line ( 'expected '
|| v_expected
|| ' relate returned '
|| v_relate_results
|| ', '
|| 'filter returned '
|| v_filter_results
|| '. '
DBMS_OUTPUT.put_line('');
END TEST;
BEGIN
BEGIN
EXECUTE IMMEDIATE 'drop table sdo_relate_geom_test';
EXCEPTION
WHEN objectnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create table sdo_relate_geom_test(geom mdsys.sdo_geometry, geom_type VARCHAR2(100))';
-- generate the points we want to test
populate_array (minlon, maxlon, INCREMENT, x_tab);
populate_array (minlat, maxlat, INCREMENT, y_tab);
-- insert the points on the query boundary
insert_points_on_tangent (minlon + offset, y_tab, 'Y');
insert_points_on_tangent (maxlon - offset, y_tab, 'Y');
insert_points_on_tangent (minlat + offset, x_tab, 'X');
insert_points_on_tangent (maxlat - offset, x_tab, 'X');
DELETE user_sdo_geom_metadata
WHERE table_name = 'SDO_RELATE_GEOM_TEST';
INSERT INTO user_sdo_geom_metadata
(table_name, column_name,
diminfo,
srid
VALUES ('SDO_RELATE_GEOM_TEST', 'GEOM',
MDSYS.sdo_dim_array (MDSYS.sdo_dim_element ('x',
-180,
180,
.00000005
MDSYS.sdo_dim_element ('y',
-90,
90,
.00000005
srid
BEGIN
EXECUTE IMMEDIATE 'drop index SDO_RELATE_GEOM_TEST_spa_idx';
EXCEPTION
WHEN indexnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create index SDO_RELATE_GEOM_TEST_spa_idx on SDO_RELATE_GEOM_TEST(geom) indextype is mdsys.spatial_index';
TEST;
END;
/

In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
In Oracle Spatial's support for geodetic coordinates, the line segments connecting consecutive vertices of a polygon or line string are geodesics - the shortest paths between the vertices on the earth spheroid. The shortest path between {30, 50} and {35, 50) does not coincide with the 50 latitude parallel, but goes to higher latitude. Only at the equator does the geodesic connecting points of constant latitude coincide with the latitude parallel.

Similar Messages

  • Spatial Queries Not Always Producing Accurate Results

    Hi,
    Spatial queries are not always producing accurate results. Here are the issues. We would appreciate any clarification you could provide to resolve these issues.
    1. When querying for points inside a polygon that is not an MBR (minimum bounded rectangle), some of the coordinates returned are not inside the polygon. It is as though the primary filter is working, but not the secondary filter when using sdo_relate. How can we validate that the spatial query using sdo_relate is using the secondary filter?
    2. SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT returns true when validating geometries even though we find results that are invalid.
    3. Illegal geodetic coordinates can be inserted into a table: latitude > 90.0, latitude < -90.0, longitude > 180.0 or longitude < -180.0.
    4. Querying for coordinates outside the MBR for the world where illegal coordinates existed did NOT return any rows, yet there were coordinates of long, lat: 181,91.
    The following are examples and information relating to the above-referenced points.
    select * from USER_SDO_GEOM_METADATA
    TABLE_NAME      COLUMN_NAME      DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE)      SRID
    LASTKNOWNPOSITIONS      THE_GEOM SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05), SDO_DIM_ELEMENT('Y', -90, 90, .05))      8307
    POSITIONS     THE_GEOM SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05), SDO_DIM_ELEMENT('Y', -90, 90, .05))      8307
    Example 1: Query for coordinates inside NON-rectangular polygon includes points outside of polygon.
    SELECT l.vesselid, l.latitude, l.longitude, TO_CHAR(l.observationtime,
    'YYYY-MM-DD HH24:MI:SS') as obstime FROM lastknownpositions l where
    SDO_RELATE(l.the_geom,SDO_GEOMETRY(2003, 8307, NULL,
    SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    SDO_ORDINATE_ARRAY(-98.20268,18.05079,-57.30101,18.00705,-57.08229,
    54.66061,-98.59638,32.87842,-98.20268,18.05079)),'mask=inside')='TRUE'
    This query returns the following coordinates that are outside of the polygon:
    vesselid : 1152 obstime : 2005-08-24 06:00:00 long : -82.1 lat : 45.3
    vesselid : 3140 obstime : 2005-08-28 12:00:00 long : -80.6 lat : 44.6
    vesselid : 1253 obstime : 2005-08-22 09:00:00 long : -80.0 lat : 45.3
    Example 2a: Using SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
    Select areaid, the_geom,
    SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(the_geom, 0.005) from area where
    areaid=24
    ResultSet:
    AREAID THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO,
    SDO_ORDINATES) SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(THE_GEOM,0.005)
    24 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(-98.20268, 18.05079, -57.30101, 18.00705, -57.08229, 54.66061, -98.59638, 32.87842, -98.20268, 18.05079)) TRUE
    Example 2b: Using SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
    Select positionid, vesselid, the_geom,
    SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(the_geom, 0.005) from positions where vesselid=1152
    ResultSet:
    POSITIONID VESSELID THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z),
    SDO_ELEM_INFO, SDO_ORDINATES) DO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(THE_GEOM,0.005)
    743811 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-82.1, 45.3, NULL), NULL, NULL) TRUE
    743812 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-82.1, 45.3, NULL), NULL, NULL) TRUE
    743813 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-80.2, 42.5, NULL), NULL, NULL) TRUE
    743814 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-80.2, 42.5, NULL), NULL, NULL) TRUE
    Example 3: Invalid Coordinate values found in POSITIONS table.
    SELECT p.positionid, p.latitude, p.longitude, p.the_geom FROM positions p
    WHERE p.latitude < -180.0
    2 lines from ResultSet:
    POSITIONID LATITUDE LONGITUDE THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    714915 -210.85408 -79.74449 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-79.74449, -210.85408, NULL), NULL, NULL)
    714938 -211.13632 -79.951256 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-79.951256, -211.13632, NULL), NULL, NULL)
    SELECT p.positionid, p.latitude, p.longitude, p.the_geom FROM positions p
    WHERE p.longitude > 180.0
    3 lines from ResultSet:
    POSITIONID LATITUDE LONGITUDE THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
    588434 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
    589493 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
    589494 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
    Example 4: Failure to locate illegal coordinates by querying for disjoint coordinates outside of MBR for the world:
    SELECT p.vesselid, p.latitude, p.longitude, p.the_geom,
    TO_CHAR(p.observationtime, 'YYYY-MM-DD HH24:MI:SS') as obstime,
    SDO_GEOM.RELATE(p.the_geom, 'determine',
    SDO_GEOMETRY(2003, 8307, NULL,SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    SDO_ORDINATE_ARRAY(-180.0,-90.0,180.0,-90.0,180.0,90.0,
    -180.0,90.0,-180.0,-90.0)), .005) relationship FROM positions p where
    SDO_GEOM.RELATE(p.the_geom, 'disjoint', SDO_GEOMETRY(2003, 8307,
    NULL,SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    SDO_ORDINATE_ARRAY(-180.0,-90.0,180.0,-90.0,180.0,90.0,-80.0,90.0,
    -180.0,-90.0)),.005)='TRUE'
    no rows selected
    Carol Saah

    Hi Carol,
    1) I think the results are correct. Note in a geodetic coordinate system adjacent points in a linestring or polygon are connected via geodesics. You are probably applying planar thinking to an ellipsoidal problem! I don't have time to do the full analysis right now, but a first guess is that is what is happening.
    2) The query window seems to be valid. I don't think this is a problem.
    3) Oracle will let you insert most anything into a table. In the index, it probably wraps. If you validate, I think the validation routines will tell you is is illegal if you use the signature with diminfo, where the coordinate system bounds are included in the validation.
    4) Your query window is not valid. Your data is not valid. As the previous reply stated, you need to have valid data. If you think in terms of a geodetic coordinate system, you will realize that -180.0,-90.0 and 180.0,-90.0 are really the same point. Also, Oracle has a rule that polygon geometries cannot be greater than half the surface of the Earth.
    Hope this helps.

  • Spatial Queries are CPU bound and show very heavy use of query buffers

    Hi,
    Spatial Queries:
    When using tkprof to analyse spatial queries it is clear that
    there are implicit queries being done by Oracle spatial which
    use vast amounts of buffers, and seem unable to cache basic
    information from query to query - thus resulting in our machine
    being CPU bound when stress testing Oracle Spatial, for example
    the example below shows how information which is fixed for a
    table and not likely to change very often is being retrieved
    inefficiently (note the 26729 query buffers being used to do 6
    executions of what should be immediately available!!!):
    TKPROF: Release 8.1.7.0.0 - Production on Tue Oct 16 09:43:38
    2001
    (c) Copyright 2000 Oracle Corporation. All rights reserved.
    SELECT ATTR_NO, ATTR_NAME, ATTR_TYPE_NAME, ATTR_TYPE_OWNER
    FROM
    ALL_TYPE_ATTRS WHERE OWNER = :1 AND TYPE_NAME = :2 ORDER BY
    ATTR_NO
    call count cpu elapsed disk query rows
    Parse 6 0.00 0.01 0 0 0
    Execute 6 0.00 0.01 0 0 0
    Fetch 6 0.23 0.41 0 26729 5
    total 18 0.23 0.43 0 26729 5
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 37 (NAGYE)
    Rows Row Source Operation
    0 SORT ORDER BY
    0 FILTER
    1 NESTED LOOPS
    1 NESTED LOOPS
    290 NESTED LOOPS
    290 NESTED LOOPS
    290 NESTED LOOPS
    290 NESTED LOOPS
    290 TABLE ACCESS FULL ATTRIBUTE$
    578 TABLE ACCESS CLUSTER TYPE$
    578 TABLE ACCESS CLUSTER TYPE$
    578 INDEX UNIQUE SCAN (object id 255)
    578 TABLE ACCESS BY INDEX ROWID OBJ$
    578 INDEX RANGE SCAN (object id 35)
    578 TABLE ACCESS CLUSTER USER$
    578 INDEX UNIQUE SCAN (object id 11)
    289 TABLE ACCESS BY INDEX ROWID OBJ$
    578 INDEX RANGE SCAN (object id 35)
    0 TABLE ACCESS CLUSTER USER$
    0 INDEX UNIQUE SCAN (object id 11)
    0 FIXED TABLE FULL X$KZSPR
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN (object id 101)
    error during parse of EXPLAIN PLAN statement
    ORA-01039: insufficient privileges on underlying objects of the
    view
    and again:
    SELECT diminfo, nvl(srid,0)
    FROM
    ALL_SDO_GEOM_METADATA WHERE OWNER = 'NAGYE' AND TABLE_NAME =
    NLS_UPPER('TILE_MED_LINES_MBR') AND '"'||COLUMN_NAME||'"'
    = '"GEOM"'
    call count cpu elapsed disk query
    current rows
    Parse 20 0.00 0.04 0
    0 0 0
    Execute 20 0.00 0.00 0
    0 0 0
    Fetch 20 0.50 0.50 0 5960
    100 20
    total 60 0.50 0.54 0 5960
    100 20
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 37 (NAGYE) (recursive depth: 1)
    Rows Row Source Operation
    1 FILTER
    2 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE
    2 INDEX RANGE SCAN (object id 24672)
    1 UNION-ALL
    1 FILTER
    1 NESTED LOOPS
    1 NESTED LOOPS
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS OUTER
    1 NESTED LOOPS
    1 TABLE ACCESS FULL OBJ$
    1 TABLE ACCESS CLUSTER TAB$
    1 INDEX UNIQUE SCAN (object id 3)
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    1 INDEX UNIQUE SCAN (object id 33)
    0 INDEX UNIQUE SCAN (object id 33)
    0 TABLE ACCESS CLUSTER USER$
    1 INDEX UNIQUE SCAN (object id 11)
    1 TABLE ACCESS CLUSTER SEG$
    1 INDEX UNIQUE SCAN (object id 9)
    1 TABLE ACCESS CLUSTER TS$
    1 INDEX UNIQUE SCAN (object id 7)
    1 TABLE ACCESS CLUSTER USER$
    1 INDEX UNIQUE SCAN (object id 11)
    0 FILTER
    0 NESTED LOOPS
    0 NESTED LOOPS OUTER
    0 NESTED LOOPS
    0 TABLE ACCESS FULL USER$
    0 TABLE ACCESS BY INDEX ROWID OBJ$
    0 INDEX RANGE SCAN (object id 34)
    0 INDEX UNIQUE SCAN (object id 97)
    0 INDEX UNIQUE SCAN (object id 96)
    0 FIXED TABLE FULL X$KZSPR
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN (object id 101)
    0 FIXED TABLE FULL X$KZSPR
    0 NESTED LOOPS
    0 FIXED TABLE FULL X$KZSRO
    0 INDEX RANGE SCAN (object id 101)
    error during parse of EXPLAIN PLAN statement
    ORA-01039: insufficient privileges on underlying objects of the
    view
    Note: The actual query being performed is:
    select a.id, a.geom
    from
    tile_med_lines_mbr a where sdo_relate(a.geom,mdsys.sdo_geometry
    (2003,NULL,
    NULL,mdsys.sdo_elem_info_array
    (1,1003,3),mdsys.sdo_ordinate_array(151.21121,
    -33.86325,151.21132,-33.863136)), 'mask=anyinteract
    querytype=WINDOW') =
    'TRUE'
    call count cpu elapsed disk query
    current rows
    Parse 1 0.00 0.00 0 0 0 0
    Execute 1 0.08 0.08 0 4 0 0
    Fetch 5 1.62 21.70 0 56 0 827
    total 7 1.70 21.78 0 60 0 827
    Misses in library cache during parse: 0
    Optimizer goal: CHOOSE
    Parsing user id: 37 (NAGYE)
    Rows Row Source Operation
    827 TABLE ACCESS BY INDEX ROWID TILE_MED_LINES_MBR
    828 DOMAIN INDEX
    Rows Execution Plan
    0 SELECT STATEMENT GOAL: CHOOSE
    827 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
    'TILE_MED_LINES_MBR'
    828 DOMAIN INDEX OF 'TILE_MLINES_SPIND'
    CPU: none, I/O: none
    call count cpu elapsed disk query
    current rows
    Parse 1 0.00 0.00 0 92
    Execute 1 0.00 0.00 0 22
    Fetch 1 0.00 0.00 38 236
    total 3 0.00 0.00 38 350
    Misses in library cache during parse: 1
    Optimizer goal: CHOOSE
    Parsing user id: 37 (NAGYE)
    Rows Row Source Operation
    12 TABLE ACCESS BY INDEX ROWID ROADELEMENT_MBR
    178 DOMAIN INDEX
    Rows Execution Plan
    0 SELECT STATEMENT GOAL: CHOOSE
    12 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
    'ROADELEMENT_MBR'
    178 DOMAIN INDEX OF 'RE_MBR_SPIND'
    CPU: none, I/O: none
    Can Oracle improve the performance of Oracle spatial by
    improving the implementation so as to perform alternative
    implicit queries so as not to use these vast amounts of memory?
    Cheers
    Alex Eadie

    Hi Ravi,
    Thankyou for your reply.
    Here are some more details for you:
    Yes the queries are cached in that it gets its data from RAM and
    not from disk however the number of buffers used internally by
    Oracle RDBMS/Spatial is rather large and results in significant
    CPU usage (namely > 5000 per query or >40MByte). Which I'm sure
    you'd agree? Those numerous internal queries taking >10ms CPU
    time each, which is culmulative.
    A single real of ours query of will take between 180ms and 580ms
    depending on the number of results returned.
    An example query is:
    select a.id, a.geom
    from tile_med_lines_mbr a where sdo_relate
    (a.geom,mdsys.sdo_geometry
    (2003,NULL, NULL,mdsys.sdo_elem_info_array
    (1,1003,3),mdsys.sdo_ordinate_array(151.21121,
    -33.86325,151.21132,-33.863136)), 'mask=anyinteract
    querytype=WINDOW') = 'TRUE'
    Our 500Mhz PC Server database can only execute 3 processes
    running these queries simultaneously to go to 100% CPU loaded.
    The disk is hardly utilized.
    The data is the main roads in Sydney, Australia.
    The tables, data and indexes were created as shown below:
    1.     Create the Oracle tables:
    create table tile_med_nodes_mbr (
         id     number not null,
         geom     mdsys.sdo_geometry not null,
         xl     number not null,
         yl     number not null,
         xh     number not null,
         yh     number not null);
    create table tile_med_lines_mbr (
         id     number not null,
         fromid     number not null,
         toid     number not null,
         geom     mdsys.sdo_geometry not null,
         xl     number not null,
         yl     number not null,
         xh     number not null,
         yh     number not null);
    2.     Use the sqlldr Oracle loader utility to load the data
    into Oracle.
    % sqlldr userid=csiro_scats/demo control=nodes.ctl
    % sqlldr userid=csiro_scats/demo control=lines.ctl
    3.     Determine the covering spatial extent for the tile
    mosaic and use this to create the geometry metadata.
    % sqlplus
    SQLPLUS>     set numw 12
    SQLPLUS>     select min(xl), min(yl), max(xh), max(yh)
         from (select xl, yl, xh, yh
              from tile_med_nodes_mbr union
              select xl, yl, xh, yh
              from tile_med_lines_mbr);
    insert into USER_SDO_GEOM_METADATA
         (TABLE_NAME, COLUMN_NAME, DIMINFO)
         VALUES ('TILE_MED_NODES_MBR', 'GEOM',
         MDSYS.SDO_DIM_ARRAY
         (MDSYS.SDO_DIM_ELEMENT('X', 151.21093421,
                   151.21205421, 0.000000050),
         MDSYS.SDO_DIM_ELEMENT('Y', -33.86347146,
                   -33.86234146, 0.000000050)));
    insert into USER_SDO_GEOM_METADATA
         (TABLE_NAME, COLUMN_NAME, DIMINFO)
         VALUES ('TILE_MED_LINES_MBR', 'GEOM',
         MDSYS.SDO_DIM_ARRAY
         (MDSYS.SDO_DIM_ELEMENT('X', 151.21093421,
                   151.21205421, 0.000000050),
         MDSYS.SDO_DIM_ELEMENT('Y', -33.86347146,
                   -33.86234146, 0.000000050)));
    4.     Validate the data loaded:
    create table result
    (UNIQ_ID number, result varchar2(10));
    execute sdo_geom.validate_layer
    ('TILE_MED_NODES_MBR','GEOM','ID','RESULT');
    select result, count(result)
    from RESULT
    group by result;
    truncate table result;
    execute sdo_geom.validate_layer
    ('TILE_MED_LINES_MBR','GEOM','ID','RESULT');
    select result, count(result)
    from RESULT
    group by result;
    drop table result;
    5.     Fix any problems reported in the result table.
    6.     Create a spatial index, use the spatial index advisor to
    determine the sdo_level.
    create index tile_mlines_spind on
    tile_med_lines_mbr (geom) indextype is
    mdsys.spatial_index parameters
    ( 'sdo_level=7,initial=1M,next=1M,pctincrease=0');
    7.     Analyse table:
    analyze table TILE_MED_LINES_MBR compute statistics;
    8.     Find the spatial index table name:
    select sdo_index_table, sdo_column_name
    from user_sdo_index_metadata
    where sdo_index_name in
    (select index_name
    from user_indexes
    where ityp_name = 'SPATIAL_INDEX'
    and table_name = 'TILE_MED_LINES_MBR');
    9.     Analyse spatial index table:
    analyze table TILE_MLINES_SPIND_FL7$
    compute statistics;
    I hope this helps.
    Cheers
    Alex Eadie

  • How to create spatial query (sdo_relate) on 2 views

    Hi, I want to create a spatial query in the form of:
    select /*+ORDERED*/ column1,column2
    from view1,view2
    where sdo_relate(view2.geometry,view1.geometry,'mask= ... ')Both views are very fast and return a smal number of rows out of a large dataset. I would expect that running the spatial query on this selection should be fast but when performing the above query it takes quite some time.
    It seems that the spatial query is performed on the underlying tables before the views make their selection.
    What is a good way to handle this kind of problem? How to make the spatial query to be executed on the resultset of the views?
    thanks Rene

    Hi Udo,
    Let me tell you a bit more about the requirements of the application.
    We have a table with geometries. Some geometries are buildings, others are roads, trees, parking areas, etc.
    We let users specify what geometries they are interested in. This can be the type (tree, building) or a list of types, plus some other selection such as type of tree, name of road etc. Based on the specifications the application creates a view that returns exactly the geometries the user is interested in.
    Users may not only be interested in just a tree but may be looking for a tree located inside a building, or a building within a certain distance from a road. This then would be the query I am talking about in this post. Two views and a spatial relationship between them.
    Depending on the definition of the views and the data currently loaded the number of rows returned by the views will vary. I can't be there all the time making sure that the correct table is queried first and the correct hints are given. This is why we have the CBO. But it seems to do a poor job when it comes to spatial queries.
    Rene

  • Continual library cache misses in trace file for spatial queries

    Hi all,
    Could somebody explain to me how the SQL parse engine works for spatial queries.
    My understanding is that Oracle creates a hash value for SQL that is parsed with no errors. This hash value is then stored in the library cache ready to be matched against other incoming SQL statements. This provides one of the main reasons for using parametising SQL in languages such as PL/SQL, .Net etc and improves performance on query intensive applications.
    However i have noticed that for spatial, any queries except for refreshes of identical ones already sent, the SQL engines re parses the query. This can take upto 0.2 seconds which is causing a performance bottle neck.
    When looking at the full trace file of a single spatial query using SDO_FILTER with a query window the amount of additional internal queries that are performed is quiet a lot. Are these additional queries included in the total parse time?
    I am wondering why for spatial queries the only way to get a hit in the library cache was to refresh an exact same SQL that had been previously sent?
    Thanks
    Daniel

    Those additional internal queries are not included in the parse time,
    if they are used in the execution time.
    Edited by: yhu on Mar 4, 2011 10:52 AM

  • Spatial queries using Discoverer 3i

    We are looking for a web reporting tool for an Oracle 8i Spatial database. Spatial queries are very important to us. Would it make sense and would it be possible to use Oracle Discoverer 3i? This product does not seem to talk the language of a 'spatial user'.

    Thanks Dan,
    Presumably, it would currently be possible to use Discoverer on database views with fixed spatial where-clauses. Is that right? If so, would it currently also be possible to have a parameterised spatial where-clause, allowing a user for instance to define the spatial view for his particular region. Does Discoverer somehow allow for this?
    null

  • Combining 2 spatial queries into 1

    Hi there. I want to merge two different spatial queries both of which return a single aspect of what I need. The first query returns the distinct group feature ids of all those geometries falling within a specified tolerance of a particular point, i.e. each geometry belongs to one feature id type:
    select distinct a2.cfcc from GEOMETRY_MAP.GEOM_POINT$_TABLE a1,
    attribute_map.landmark_table a2 where SDO_WITHIN_DISTANCE
    (location, (MDSYS.SDO_GEOMETRY(2001, 8265, MDSYS.SDO_POINT_TYPE(-104.9,39.9,null),NULL, NULL)), 'DISTANCE = 10000')='TRUE'
    and a1.land = a2.land order by cfcc;
    The following results are returned (one for each feature id) e.g. D43 is the id for schools but many schools may have fallen within the specified distance:
    CFCC
    D43
    D44
    D61
    D65
    The second query returns the feature ids of geometries AND their distances from the specified point and looks as follows:
    select distinct a2.cfcc, sdo_geom.sdo_distance(location, b.pgeom, 0.005) distance from GEOMETRY_MAP.GEOM_POINT$_TABLE a1, attribute_map.landmark_table a2, (select MDSYS.SDO_GEOMETRY(2001,8265,MDSYS.SDO_POINT_TYPE(-104.9,39.9,null), NULL, NULL) pgeom from dual)b where a1.land = a2.land and SDO_WITHIN_DISTANCE (location, b.pgeom, 'DISTANCE = 10000')='TRUE' order by cfcc, distance;
    The results of this query are:
    CFCC DISTANCE
    D43 4025.459
    D43 5585.05361
    D43 5589.70435
    D61 7770.4209
    D65 6223.59763
    D65 7929.03858
    As you can see the second query returns not just the feature id but the associated distance of each individual feature of that type. What I would like to do is to merge the two result sets so that only the closest individual feature of a particular type and its distance from the input point is returned, i.e. I only need the closest school as oppose to all the closest schools. Any ideas? Thanks a lot, Joe

    Hi Richard. Thnaks for your reply. I should have mentioned that more than one feature type is returned, i.e. not just schools, and so ROWNUM = 1 would not work in this scenario. Any other ideas. Cheers, Joe

  • Sample SQL code ( Oracle Spatial queries)

    Hi All,
    Can anyone tell me where can I get sample spatial queries.
    Please tell me the urls for spatial queries.
    Thank you
    Anju

    Hi All,
    Can anyone tell me where can I get sample spatial queries.
    Please tell me the urls for spatial queries.
    Thank you
    AnjuHow about the spatial users guide which is available on
    http://technet.oracle.com/doc/inter.815/a67295/toc.htm
    It also contains example statements.
    There is also a
    spatial_users_guide_817.pdf available
    Gerjan

  • Error while running spatial queries on a table with more than one geometry.

    Hello,
    I'm using GeoServer with Oracle Spatial database, and this is a second time I run into some problems because we use tables with more than one geometry.
    When GeoServer renders objects with more than one geometry on the map, it creates a query where it asks for objects which one of the two geometries interacts with the query window. This type of query always fails with "End of TNS data channel" error.
    We are running Oracle Standard 11.1.0.7.0.
    Here is a small script to demonstrate the error. Could anyone confirm that they also have this type of error? Or suggest a fix?
    What this script does:
    1. Create table object1 with two geometry columns, geom1, geom2.
    2. Create metadata (projected coordinate system).
    3. Insert a row.
    4. Create spacial indices on both columns.
    5. Run a SDO_RELATE query on one column. Everything is fine.
    6. Run a SDO_RELATE query on both columns. ERROR: "End of TNS data channel"
    7. Clean.
    CREATE TABLE object1
    id NUMBER PRIMARY KEY,
    geom1 SDO_GEOMETRY,
    geom2 SDO_GEOMETRY
    INSERT INTO user_sdo_geom_metadata (table_name, column_name, srid, diminfo)
    VALUES
    'OBJECT1',
    'GEOM1',
    2180,
    SDO_DIM_ARRAY
    SDO_DIM_ELEMENT('X', 400000, 700000, 0.05),
    SDO_DIM_ELEMENT('Y', 300000, 600000, 0.05)
    INSERT INTO user_sdo_geom_metadata (table_name, column_name, srid, diminfo)
    VALUES
    'OBJECT1',
    'GEOM2',
    2180,
    SDO_DIM_ARRAY
    SDO_DIM_ELEMENT('X', 400000, 700000, 0.05),
    SDO_DIM_ELEMENT('Y', 300000, 600000, 0.05)
    INSERT INTO object1 VALUES(1, SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(550000, 450000, NULL), NULL, NULL));
    CREATE INDEX object1_geom1_sidx ON object1(geom1) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
    CREATE INDEX object1_geom2_sidx ON object1(geom2) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
    SELECT *
    FROM object1
    WHERE
    SDO_RELATE("GEOM1", SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), 'MASK=ANYINTERACT') = 'TRUE';
    SELECT *
    FROM object1
    WHERE
    SDO_RELATE("GEOM1", SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), 'MASK=ANYINTERACT') = 'TRUE' OR
    SDO_RELATE("GEOM2", SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), 'MASK=ANYINTERACT') = 'TRUE';
    DELETE FROM user_sdo_geom_metadata WHERE table_name = 'OBJECT1';
    DROP INDEX object1_geom1_sidx;
    DROP INDEX object1_geom2_sidx;
    DROP TABLE object1;
    Thanks for help.

    This error appears in GeoServer and SQLPLUS.
    I have set up a completly new database installation to test this error and everything works fine. I tried it again on the previous database but I still get the same error. I also tried to restart the database, but with no luck, the error is still there. I geuss something is wrong with the database installation.
    Anyone knows what could cause an error like this "End of TNS data channel"?

  • Memory Leak With Spatial queries

    We are using 8.1.6 on NT (4.0) for spatial data queries. We are facing memory leak problems. At the starting our job will run very fast and after some time it will start slipping. I'm monitoring PGA size from v$sessionstat/v$sysstat and it is regularly increasing. Same is the case for memory on NT machine when I'm monitoring thru performance monitor. I have already applied the spatial patch available for 8.1.6 but no improvement.
    Please let me know If there is any workaround. When I'm submitting my job in parts and shutdown the database in between then It is releasing all the memory and It is working fine. Without shutting the database it is not relasing the memory even though I stop my spatial data batch job.
    null

    Hi,
    Thanks for your responses.
    This is the query:
    SELECT a.geo_id, mdsys.sdo_geom.sdo_length(
    mdsys.sdo_cs.transform(
    mdsys.sdo_geometry(2002, 8307, null,
    mdsys.sdo_elem_info_array(1,2,1),
    mdsys.sdo_ordinate_array(' &#0124; &#0124;
    longi &#0124; &#0124;
    ', ' &#0124; &#0124;
    lati &#0124; &#0124;
    a.geo_geometry.sdo_point.x,
    a.geo_geometry.sdo_point.y )),
    mdsys.sdo_dim_array(mdsys.sdo_dim_element(' &#0124; &#0124;
    '''' &#0124; &#0124;
    'X' &#0124; &#0124;
    '''' &#0124; &#0124;
    ',-180,180, .00000005),
    mdsys.sdo_dim_element(' &#0124; &#0124;
    '''' &#0124; &#0124;
    'Y' &#0124; &#0124;
    '''' &#0124; &#0124;
    ',-90,90, .00000005)), 41004),
    .00000005) * 6.213712e-04 distance_in_miles
    FROM ' &#0124; &#0124;
    t_name &#0124; &#0124;
    ' a
    WHERE mdsys.sdo_nn(a.geo_geometry,
    mdsys.sdo_geometry(1, 8307,
    mdsys.sdo_point_type(' &#0124; &#0124;
    longi &#0124; &#0124;
    ', ' &#0124; &#0124;
    lati &#0124; &#0124;
    ', null),
    null, null),' &#0124; &#0124;
    '''' &#0124; &#0124;
    'SDO_NUM_RES=5' &#0124; &#0124;
    '''' &#0124; &#0124;
    ') = ' &#0124; &#0124;
    '''' &#0124; &#0124;
    'TRUE' &#0124; &#0124;
    '''' &#0124; &#0124;
    AND a.geo_id ' &#0124; &#0124;
    filter &#0124; &#0124;
    ORDER BY 2;
    Here we are passing the tname and filter dynamically based on certain conditions and the memory leak is almost 100K to 200K per query.
    First I tried to closing the session only but that didn't work. Database shutdown is only able to release the memory. I'm monitoring v$sysstat/v$sesstat and size of oracle.exe in NT performance monitor. Please let me know If something else need to be monitor.
    Thanks.
    Sandeep
    null

  • Speeding up of spatial Queries - SDO_Intersection

    HI, I'm running a basic query - calculating the area of spatial intersection sbetween two polygonal datasets:
    select  s.Designation, SUM (
    sdo_geom.sdo_area(
    sdo_geom.sdo_intersection (s.geoloc, m.geoloc, 0.0005),
    *0.0005, 'unit = HECTARE')) total_overlap_area*
    **from SPA_v s, os_bdyline_mlw m*
    where sdo_relate (s.geoloc, m.geoloc, 'mask=overlapbdyintersect') = 'TRUE'
    The problem is that the query is taking a long, long time to run > 8 hours
    First of all the datasets are quite complex, they've been captured at a scale of 1:2500 and 1:10,000 on the Ordnance Survey British National Grid, (the formerbeing of 1mm accuracy, therefore the tolerances involved).
    Spatial Indexes have been created on the Geoloc - (geometry) - column.
    Is there anything I can do to speed this query up (I'm going to have to create this for further datasets) - I've tried reducing the tolerances to 0.5, but hten have problems where I get this error messages:
    ERROR at line 4:
    ORA-13050: unable to construct spatial object
    ORA-06512: at "MDSYS.SDO_3GL", line 715
    ORA-06512: at "MDSYS.SDO_GEOM", line 3016
    ORA-06512: at "MDSYS.SDO_GEOM", line 3065
    Any help gretfully received :-)
    Thanks,
    Bruce

    Hi Ivan, thanks for the response.
    Yep, I've validated all of the geometries.
    There are 21 SPA's in Wales, and am only using the Boundaryline data for Wales - principally because there are far fewer nodes in this dataset than there would be if I had used the Mean Low Water Mark, derived from OS Mastermap (at 1:2500.
    Obviously this is going cause some small errors creeping in where the two datsets do not precisely meet, but this would probably be within the acceptable range. The other thing I could do would be to thin the SPA dataset so that it would be at 0.05 tolerance (OS 1:10,000 has a node separation of 10 cm)
    Thanks,
    Bruce

  • Cannot do spatial queries across a view.

    I have two tables: MAGPGS, which holds current data, and MAGPGS_HISTORY, which holds historical data. I want to be able to create a view and query BOTH tables at once.
    I have another table MPPCCA which contains some geometries, and I want to see how these tables interract.
    I can run
    select p.gdo_gid,m.gdo_gid
    from magpgs p, mppcca m
    where mdsys.sdo_relate(p.geom,m.geometry1,
    'mask=anyinteract')='TRUE';
    and
    select p.gdo_gid,m.gdo_gid
    from magpgs_history p, mppcca m
    where mdsys.sdo_relate(p.geom,m.geometry1,
    'mask=anyinteract')='TRUE';
    successfully, but when I try and run the same query on a view I get this
    SQL> select p.gdo_gid,m.gdo_gid
    2 from magpgs_all p, mppcca m
    3 where mdsys.sdo_relate(p.geom,m.geometry1,
    4 'mask=anyinteract')='TRUE';
    select p.gdo_gid,m.gdo_gid
    ERROR at line 1:
    ORA-13226: interface not supported without a spatial index
    ORA-06512: at "MDSYS.MD", line 1723
    ORA-06512: at "MDSYS.MDERR", line 8
    ORA-06512: at "MDSYS.SDO_3GL", line 58
    The MAGPGS_ALL view has been created via EM as
    SELECT * FROM MAGPGS
    UNION ALL
    SELECT * FROM MAGPGS_HISTORY.
    Obviously EM has then updated my query with the real column names, and I have subsequently recompiled the view.
    Having read previous posts, I have tried my query with an entry for the view in the USER_SDO_GEOM_METADATA table, and without an entry, with the same result.
    I have also tried rewriting the SQL as per another previous post which identified a workaround if the query was re-written thus
    select p.gdo_gid
    from magpgs_all p
    where exists (select 1 from mppcca m
    where mdsys.sdo_relate(p.geom,m.geometry1,
    'mask=anyinteract')='TRUE');
    but again, with no success. Does anybody have any idea what else I can try?
    MTIA
    Rob

    Hi Rob,
    This is similar to bug 4268528 which I opened a few months ago. I believe it should work, but it is possible that it shouldn't based on the original response. I've updated it with a case that is closer to yours.

  • Example Oracle Spatial Queries for NAVTEQ Data

    Hi,
    I recently installed NAVTEQ RDF data into an Oracle database. I am new to Oracle Spatial and am looking for some example queries using the NAVTEQ data in the Oracle database.
    For example, suppose I have a point (latitude,longitude). What are the queries for each of these:
    1) find roads or faces within 5 miles of that point;
    2) find roads or faces that cover that point
    Thanks!
    Bowden

    Hi,
    There are a lot of of ways to license the data (county, state, country), there are different flavors (mapping, geocoding, and routing), and there are different licensing options for the Oracle platform (user based and cpu/core based). I cannot think of a use case that would approach the cost below.
    Feel free to drop me an email (daniel dot abugov at navteq dot com) and we can discuss.
    Dan Abugov
    NAVTEQ Enterprise Business Development and Consulting

  • Spatial queries slow

    Hi,
    I'm working with a point table with approximately 6100 tuples (each has a point geometry)
    When I run the query:
    SELECT ID, shape FROM POINT_TAB WHERE SDO_FILTER(shape, MDSYS.SDO_GEOMETRY(2003, 1000001, null, MDSYS.SDO_ELEM_INFO_ARRAY( 1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY( 568220.418621453, 8628249.80447949, 575257.418621453, 8632873.80447949) ), 'querytype=window') = 'TRUE';
    it takes about 12 seconds.
    However when I run an equivalent query using the Spatial Index Advisor it takes about 1 second to draw the points on screen.
    I've created an R-Tree index on this table.
    Please any cues?
    Thanks a lot,
    Claudio.

    Hi Daniel,
    Here it is the info you´ve requested:
    USER_SDO_GEOM_METADATA
    table_name: POINT_TAB
    column_name: SHAPE
    SDO_DIMINFO: SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -47302, 630691,6, ,5), SDO_DIM_ELEMENT('Y', 8013976, 9044443, ,5))
    SRID: 1000001
    Oracle Version: 9.2.0.1.0
    INDEX creation:
    CREATE INDEX Point_RTREE_IDX ON POINT_TAB(shape)
         INDEXTYPE IS MDSYS.SPATIAL_INDEX
    The query returns 134 rows (out of 6151)
    We are using a customized SRID:
    WKTEXT: PROJCS["UTM Zone 24, Southern Hemisphere (Aratu)", GEOGCS [ "Aratu", DATUM ["Aratu", SPHEROID ["International 1924", 6378388.000000, 297.000000]], PRIMEM [ "Longitude of Origin", -39.000000 ], UNIT ["Decimal Degree", 0.00048481368110953599]], PROJECTION ["Transverse Mercator"], PARAMETER ["Scale_Factor", 0.999600], PARAMETER ["Central_Meridian", -39.000000], PARAMETER ["False_Easting", 500000.000000], PARAMETER ["False_Northing", 10000000.000000], UNIT ["Meter", 1.000000000000]]
    TRACE:
    Execution Plan
    0 SELECT STATEMENT Optimizer=CHOOSE (Cost=70 Card=405 Bytes=15 96915)
    1 0 TABLE ACCESS (BY INDEX ROWID) OF 'POCOS_TAB' (Cost=70 Card=405 Bytes=1596915)
    2 1 DOMAIN INDEX OF 'POCOS_RTREE_IDX'
    Many thanks,
    Claudio.

  • Executing spatial queries on someone else's tables

    I am trying to execute a spatial
    query using a table owned by
    someone else.
    The SQL is...
    select a.plancoupe, a.coupecrop, a.ha
    from dba1.coupes a, dba1.coupes b
    where b.plancoupe = 'CM004H' and
    mdsys.sdo_within_distance(a.geom,b.geom,
    'distance=1000 querytype=WINDOW')
    = 'TRUE'
    The query works fine when I am connected
    as dba1, but when I connect as someone
    else I get...
    ERROR at line 1:
    ORA-29902: error in executing ODCIIndexStart() routine
    ORA-13211: failed to tessellate the window object
    ORA-13209: internal error while reading SDO_INDEX_METADATA table
    ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 73
    ORA-06512: at line 1
    I have granted SELECT permissions on the
    table in question to PUBLIC and also to
    dba1.sdo_geom_metadata and the spatial
    index table generated by the spatial
    indexing creation routines...
    Any ideas?
    regards
    SImon

    Hi Simon,
    From your e-mail below, I assume you are
    running Oracle 8.1.5.
    Here is what you need to do for 8.1.5.
    Hope this helps.
    Please let me know if you have any questions. Thanks.
    Dan
    ======
    In Oracle 8.1.6, your query will work
    if you do the following:
    1) Grant select on dba1.coupes
    2) Grant select on the spatial index
    table created on dba1.coupes
    In Oracle 8.1.5 ONLY, do steps 3 and 4:
    3) In addition to step 1 and 2 above,
    grant select on sdo_geom_metadata
    4) As the Oracle MDSYS user, you must run
    the following:
    connect mdsys/mdsys
    drop view sdo_index_metadata;
    create view sdo_index_metadata as
    select SDO_INDEX_OWNER, SDO_INDEX_NAME, SDO_INDEX_TABLE, SDO_INDEX_PRIMARY,
    SDO_TSNAME, SDO_COLUMN_NAME,
    SDO_LEVEL, SDO_NUMTILES,
    SDO_MAXLEVEL, SDO_COMMIT_INTERVAL,
    SDO_FIXED_META,
    SDO_TABLESPACE,
    SDO_INITIAL_EXTENT,
    SDO_NEXT_EXTENT,
    SDO_PCTINCREASE,
    SDO_MIN_EXTENTS,
    SDO_MAX_EXTENTS
    from SDO_INDEX_METADATA_TABLE
    where
    (exists
    (select table_name from all_tables
    where table_name=sdo_index_table and owner=sdo_index_owner)
    or
    exists
    (select view_name from all_views
    where view_name=sdo_index_table and owner=sdo_index_owner)
    or
    exists
    (select table_name from all_object_tables
    where table_name=sdo_index_table and owner=sdo_index_owner)
    grant select on sdo_index_metadata to public;
    null

Maybe you are looking for