Index problem in a spatial query

I try to run following query in SQL Plus:
SELECT A.objectid FROM TABBDG A, TABREG B
WHERE A.objectid = 68 AND B.regionname = 'Hong2'
AND SDO_RELATE(A.geoloc, B.geoloc, 'mask=INSIDE querytype = WINDOW') = 'TRUE';
To find out weather or not objectid = 68 is inside of region (='Hong2"). I got following error messages:
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 57
ORA-06512: at line 1
But when I try to add an index to table TABREG, I got following error:
ERROR at line 1:
ORA-29879: cannot create multiple domain indexes on a column list using same indextype
Seem to me that the index was already there. Can any one help me? Thanks.

I found out the reason of problem. I used an old version of EasyLoader (4.5?). When I get the latest EasyLoader V6.5, there is no problem any more to run spatial query. You can get lates EasyLoader V6.5 from MapInfo or from me at: [email protected]
Thanks for all help.

Similar Messages

Not using Index when SDO_RELATE in Spatial Query is used in LEFT OUTER JOIN

I want to know for every City (Point geometry) in which Municipality (Polygon geometry) it is.
Some cities will not be covered by any municipality (as there is no data for it), so its municipality name should be blank in the result
We have 4942 cities (point geometries)
and 500 municipalities (polygon geometry)
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1
LEFT OUTER JOIN MUNICIPALITY T2 ON SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'The explain plan for this query is:
SELECT STATEMENT
FILTER
    Filter Predicates
      MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'
    MERGE JOIN
      TABLE ACCESS              CITY               FULL                            11
      BUFFER                                       SORT                        100605
          TABLE ACCESS          MUNICIPALITY       FULL                            20So the cost is in the BUFFER (whatever that is), it takes +2000 seconds to run this, it is not using the spatial index.
And we are not getting all rows, but only the ones interacting with a municipality, e.g. 2436 rows.
But I want all rows, including the ones not interacting with any Municipality.
When we want only those cities that actually are in a municipality, I use a different query and it will use the index.
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1, MUNICIPALITY T2
WHERE SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'I get (only) 2436 rows (as expected) in 5 seconds (it is fast) and the explain plan shows it is using the spatial index.
But in this case, I am not getting any cities not inside any municipality (of course)
SELECT STATEMENT
   NESTED LOOPS
      TABLE ACCESS                   MUNICIPALITY       FULL                22
      TABLE ACCESS                   CITY               BY INDEX ROWID      22
         DOMAIN INDEX                CITY_SDX                                0
            Access Predicates
               MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'I always thought a LEFT OUTER JOIN would return all rows from the Table, whatever happens in the next,
but it seems the query has been rewritten so that it is now using a Filter Predicate in the end, which filters those geometries having no interaction.
As an example I also do thing alphanumerically, I do get 4942 rows, including the ones which have no Municipality name.
In this case the names must match, so its only for testing if the LEFT OUTER JOIN returns stuff correctly, which it does in this case.
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1
LEFT OUTER JOIN MUNICIPALITY T2 ON T1.NAME = T2.NAMEIs this an Oracle Spatial bug, e.g. not return 4942 rows, but only 2436 rows on the first query?
Note all tests performed on Oracle 11g R2 (11.2.0.1.0)

Patrick,
Even so, your geoms in the relate were the wrong way around.
Also, I don't recall you saying (or showing) that you wanted the municipality geometry returned. Still,
no matter, easy to do.
Here are some additional suggestions. I don't have your data so I have had to use some of my own.
set serveroutput on timing on autotrace on
SELECT T1.SPECIES as City,
       (SELECT T2.ADMIN_NAME FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as Municipality,
       (SELECT T2.GEOM       FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as geom
FROM GUTDATA T1;
762 rows selected
Elapsed: 00:00:21.656
Plan hash value: 2160035213
| Id | Operation                   | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |                            |   762 | 49530 |     5   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES          |     1 |   115 |     0   (0)| 00:00:01 |
|* 2 |   DOMAIN INDEX              | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
|   3 | TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES          |     1 |   115 |     0   (0)| 00:00:01 |
|* 4 |   DOMAIN INDEX              | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
|   5 | TABLE ACCESS FULL          | GUTDATA                    |   762 | 49530 |     5   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
   4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
           24576 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksThe above can look messy as you add more (SELECT ...) attributes, but is is fast (though can't use in Materialized Views).
/* The set of all cities not in municipalities */
SELECT T1.SPECIES                 as City,
       cast(null as varchar2(42)) as municipality,
       cast(null as sdo_geometry) as geom
FROM GUTDATA T1
WHERE NOT EXISTS (SELECT 1
                     FROM AUSTRALIAN_STATES T2
                    WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
UNION ALL
/* The set of all cities in municipalities */
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality,
       T2.GEOM       as geom
FROM GUTDATA T1
       INNER JOIN
       AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
762 rows selected
Elapsed: 00:00:59.953
Plan hash value: 2854682795
| Id | Operation           | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT    |                            |    99 | 13450 |    38 (87)| 00:00:01 |
|   1 | UNION-ALL          |                            |       |       |            |          |
|* 2 |   FILTER            |                            |       |       |            |          |
|   3 |    TABLE ACCESS FULL| GUTDATA                    |   762 | 49530 |     5   (0)| 00:00:01 |
|* 4 |    DOMAIN INDEX     | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
|   5 |   NESTED LOOPS      |                            |    61 | 10980 |    33   (0)| 00:00:01 |
|   6 |    TABLE ACCESS FULL| AUSTRALIAN_STATES          |     8 |   920 |     3   (0)| 00:00:01 |
|* 7 |    TABLE ACCESS FULL| GUTDATA                    |     8 |   520 |     4   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter( NOT EXISTS (SELECT 0 FROM "AUSTRALIAN_STATES" "T2" WHERE "MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE'))
   4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
   7 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
          131072 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksMuch slower but Materialized View friendly.
This one is a bit more "natural" but still slower than the first.
set serveroutput on timing on autotrace on
/* The set of all cities in municipalities */
WITH municipal_cities As (
SELECT T1.ID         as City,
         T2.ADMIN_NAME as Municipality,
         T2.GEOM       as geom
    FROM GUTDATA T1
         INNER JOIN
         AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
SELECT T1.ID           as City,
       T2.Municipality as Municipality,
       T2.GEOM         as geom
FROM GUTDATA          T1
       LEFT OUTER JOIN
       municipal_cities T2
       ON (T2.CITY = T1.ID);
762 rows selected
Elapsed: 00:00:50.228
Plan hash value: 745978991
| Id | Operation             | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |                   |   762 | 44196 |    36   (3)| 00:00:01 |
|* 1 | HASH JOIN RIGHT OUTER|                   |   762 | 44196 |    36   (3)| 00:00:01 |
|   2 |   VIEW                |                   |    61 | 3294 |    33   (0)| 00:00:01 |
|   3 |    NESTED LOOPS       |                   |    61 | 10980 |    33   (0)| 00:00:01 |
|   4 |     TABLE ACCESS FULL | AUSTRALIAN_STATES |     8 |   920 |     3   (0)| 00:00:01 |
|* 5 |     TABLE ACCESS FULL | GUTDATA           |     8 |   520 |     4   (0)| 00:00:01 |
|   6 |   INDEX FAST FULL SCAN| GUTDATA_ID_PK     |   762 | 3048 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("T2"."CITY"(+)="T1"."ID")
   5 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
           49152 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksFinally, the Pièce de résistance: trick the LEFT OUTER JOIN operator...
set serveroutput on timing on autotrace on
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality,
       T2.GEOM       as geom
FROM GUTDATA           T1
       LEFT OUTER JOIN
       AUSTRALIAN_STATES T2
       ON (t2.admin_name = to_char(t1.ID) OR
           SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
762 rows selected
Elapsed: 00:00:50.273
Plan hash value: 158854308
| Id | Operation           | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT    |                   |   762 | 92964 | 2294   (1)| 00:00:28 |
|   1 | NESTED LOOPS OUTER |                   |   762 | 92964 | 2294   (1)| 00:00:28 |
|   2 |   TABLE ACCESS FULL | GUTDATA           |   762 | 49530 |     5   (0)| 00:00:01 |
|   3 |   VIEW              |                   |     1 |    57 |     3   (0)| 00:00:01 |
|* 4 |    TABLE ACCESS FULL| AUSTRALIAN_STATES |     1 |   115 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("T2"."ADMIN_NAME"=TO_CHAR("T1"."ID") OR
              "MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
               0 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksTry these combinations to see what works for you.
Interestingly, for me, the following returns absolutely nothing.
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality
FROM GUTDATA           T1
       LEFT OUTER JOIN
       AUSTRALIAN_STATES T2
       ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
MINUS
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality
FROM GUTDATA           T1
       LEFT OUTER JOIN
       AUSTRALIAN_STATES T2
       ON (t2.admin_name = to_char(t1.ID) OR
           SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');(I leave it to you to see if you can see why as the LEFT OUTER JOIN seems to be working correctly for me but I am not going to dedicate time to detailed checking of results.)
Note all tests performed on Oracle 11g R2 (11.2.0.1.0)
If you get the answer you want: mark the post as answered to assign points.
regards
Simon

Problems with basic spatial query

I'm trying to learn Oracle Spatial working with 11g R2 and with 3D georeferenced data (specifically data describing buildings in a city).
But I'm having trouble getting a basic query to work on my dataset (it works for the book example), and I'm trying to do it exactly the way it's done in the Spatial Developer's Guide for 11g.
To learn how spatial queries work, I set up the cola_markets tables used in the documentation, made the appropriate manual entry in the user_sdo_geom_metadata view and created the index. Having done that, I can run the following simple query (as well as the others in the manual) on the book tables:
SELECT SDO_GEOM.SDO_DISTANCE(c_b.shape, c_d.shape, 0.005)
FROM cola_markets c_b, cola_markets c_d
WHERE c_b.name = 'cola_b' AND c_d.name = 'cola_d';
but when I try to do the same thing on my own tables (created from citygml data), I get an error. There is the difference that the data is 3D, and the index was created without any PARAMETERS ( ... ), hence is just 2D. But still I don't get why the following query doesn't work:
SELECT SDO_GEOM.SDO_DISTANCE(c_w.envelope, c_b.envelope, 0.0005)
FROM cityobject c_w,
cityobject c_b
WHERE c_w.id = 50025
AND c_b.id = 50018;
The id's for the buildings are valid, and I used the same tolerance used by the software that set up the database.
Here's the error I get in SQL developer:
ORA-29532: Java call terminated by uncaught Java exception: java.lang.Exception: 54535
ORA-06512: at "MDSYS.SDO_3GL", line 637
ORA-06512: at "MDSYS.SDO_GEOM", line 1973
ORA-06512: at "MDSYS.SDO_GEOM", line 1990
29532. 00000 - "Java call terminated by uncaught Java exception: %s"
*Cause: A Java exception or error was signaled and could not be
resolved by the Java code.
*Action: Modify Java code, if this behavior is not intended.
So, thinking it might have something to do with the fact that it's a Java interface, I also tried running it from SQL/PL command line and get essentially the same thing:
ERROR at line 1:
ORA-29532: Java call terminated by uncaught Java exception:
java.lang.Exception: 54535
ORA-06512: at "MDSYS.SDO_3GL", line 637
ORA-06512: at "MDSYS.SDO_GEOM", line 1973
ORA-06512: at "MDSYS.SDO_GEOM", line 1990
Any ideas why this isn't working?

Hi,-
There are many ways to model a building with our open 3D data model:
Please note that each polygon can be any planar surface as long as you dont use
shortcut definitions like axis-aligned box as Siva mentioned. We dont allow curved surfaces in 3D.
Gtype 3003 can be composite surface which means each polygon should be connected to another polygon with an edge. Etype must be then 1006. You can have as many polygons as possible as long as they are connected.
Gtype 3003 can also be a single polygon. But, this will not be able to model a building.
As you pointed out, maybe it is the footprint of the building.
You can also model building with gtype 3008 which is simple or composite solid.
Etype 1007 means it is simple solid and etype 1008 means it is composite solid.
Composite solid has one or more solids which has at least one full or partial common surface in between.
In your case with single polygon, you can use sdo_util.extrude as follows to make
3D buildings. The surfaces created will be on the out-side surface of the building.
You will not have walls inside the building when you use this following function:
SELECT SDO_UTIL.EXTRUDE(
SDO_GEOMETRY(
    2003,
    null,
    null,
    SDO_ELEM_INFO_ARRAY(1,1003,1),
    SDO_ORDINATE_ARRAY(5, 1,8,1,8,6,5,7,5,1)),
SDO_NUMBER_ARRAY(0,0,0,0,0),
SDO_NUMBER_ARRAY(5,10,10,5,5),
0.005) from dual;
SDO_UTIL.EXTRUDE(SDO_GEOMETRY(2003,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1003,1),SDO_O
SDO_GEOMETRY(3008, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1007, 1, 1, 1006, 6, 1, 10
03, 1, 16, 1003, 1, 31, 1003, 1, 46, 1003, 1, 61, 1003, 1, 76, 1003, 1), SDO_ORD
INATE_ARRAY(5, 1, 0, 5, 7, 0, 8, 6, 0, 8, 1, 0, 5, 1, 0, 5, 1, 5, 8, 1, 10, 8, 6
, 10, 5, 7, 5, 5, 1, 5, 5, 1, 0, 8, 1, 0, 8, 1, 10, 5, 1, 5, 5, 1, 0, 8, 1, 0, 8
, 6, 0, 8, 6, 10, 8, 1, 10, 8, 1, 0, 8, 6, 0, 5, 7, 0, 5, 7, 5, 8, 6, 10, 8, 6,
0, 5, 7, 0, 5, 1, 0, 5, 1, 5, 5, 7, 5, 5, 7, 0))
The following example returns the three-dimensional composite solid geometry representing an extrusion from a two-dimensional polygon geometry with inner rings.
SELECT SDO_UTIL.EXTRUDE(
SDO_GEOMETRY(
    2003,
    null,
    null,
    SDO_ELEM_INFO_ARRAY(1, 1003, 1, 11, 2003, 1,
      21, 2003,1, 31,2003,1, 41, 2003, 1),
    SDO_ORDINATE_ARRAY(0,0, 8,0, 8,8, 0,8, 0,0,
      1,3, 1,4, 2,4, 2,3, 1,3, 1,1, 1,2, 2,2, 2,1, 1,1,
      1,6, 1,7, 2,7, 2,6, 1,6, 3,2, 3,4, 4,4, 4,2, 3,2)),
SDO_NUMBER_ARRAY(-1.0),
SDO_NUMBER_ARRAY(1.0),
0.0001) from dual;
SDO_UTIL.EXTRUDE(SDO_GEOMETRY(2003,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1003,1,11,200
SDO_GEOMETRY(3008, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1008, 4, 1, 1007, 1, 1, 10
06, 16, 1, 1003, 1, 46, 1003, 1, 91, 1003, 1, 106, 1003, 1, 121, 1003, 1, 136, 1
003, 1, 151, 1003, 1, 166, 1003, 1, 181, 1003, 1, 196, 1003, 1, 211, 1003, 1, 22
6, 1003, 1, 241, 1003, 1, 256, 1003, 1, 271, 1003, 1, 286, 1003, 1, 301, 1007, 1
, 301, 1006, 10, 301, 1003, 1, 328, 1003, 1, 355, 1003, 1, 370, 1003, 1, 385, 10
03, 1, 400, 1003, 1, 415, 1003, 1, 430, 1003, 1, 445, 1003, 1, 460, 1003, 1, 475
, 1007, 1, 475, 1006, 6, 475, 1003, 1, 490, 1003, 1, 505, 1003, 1, 520, 1003, 1,
535, 1003, 1, 550, 1003, 1, 565, 1007, 1, 565, 1006, 10, 565, 1003, 1, 592, 100
3, 1, 619, 1003, 1, 634, 1003, 1, 649, 1003, 1, 664, 1003, 1, 679, 1003, 1, 694,
1003, 1, 709, 1003, 1, 724, 1003, 1), SDO_ORDINATE_ARRAY(4, 0, -1, 4, 2, -1, 4,
4, -1, 3, 4, -1, 2, 4, -1, 2, 7, -1, 1, 7, -1, 1, 6, -1, 1, 4, -1, 1, 3, -1, 0,
3, -1, 0, 8, -1, 8, 8, -1, 8, 0, -1, 4, 0, -1, 4, 0, 1, 8, 0, 1, 8, 8, 1, 0, 8,
1, 0, 3, 1, 1, 3, 1, 1, 4, 1, 1, 6, 1, 1, 7, 1, 2, 7, 1, 2, 4, 1, 3, 4, 1, 4, 4
, 1, 4, 2, 1, 4, 0, 1, 4, 0, -1, 8, 0, -1, 8, 0, 1, 4, 0, 1, 4, 0, -1, 8, 0, -1,
8, 8, -1, 8, 8, 1, 8, 0, 1, 8, 0, -1, 8, 8, -1, 0, 8, -1, 0, 8, 1, 8, 8, 1, 8,
8, -1, 0, 8, -1, 0, 3, -1, 0, 3, 1, 0, 8, 1, 0, 8, -1, 0, 3, -1, 1, 3, -1, 1, 3,
1, 0, 3, 1, 0, 3, -1, 1, 3, -1, 1, 4, -1, 1, 4, 1, 1, 3, 1, 1, 3, -1, 1, 4, -1,
1, 6, -1, 1, 6, 1, 1, 4, 1, 1, 4, -1, 1, 6, -1, 1, 7, -1, 1, 7, 1, 1, 6, 1, 1,
6, -1, 1, 7, -1, 2, 7, -1, 2, 7, 1, 1, 7, 1, 1, 7, -1, 2, 7, -1, 2, 4, -1, 2, 4,
1, 2, 7, 1, 2, 7, -1, 2, 4, -1, 3, 4, -1, 3, 4, 1, 2, 4, 1, 2, 4, -1, 3, 4, -1,
4, 4, -1, 4, 4, 1, 3, 4, 1, 3, 4, -1, 4, 4, -1, 4, 2, -1, 4, 2, 1, 4, 4, 1, 4,
4, -1, 4, 2, -1, 4, 0, -1, 4, 0, 1, 4, 2, 1, 4, 2, -1, 0, 3, -1, 1, 3, -1, 1, 1,
-1, 2, 1, -1, 3, 2, -1, 4, 2, -1, 4, 0, -1, 0, 0, -1, 0, 3, -1, 0, 3, 1, 0, 0,
1, 4, 0, 1, 4, 2, 1, 3, 2, 1, 2, 1, 1, 1, 1, 1, 1, 3, 1, 0, 3, 1, 0, 3, -1, 0, 0
, -1, 0, 0, 1, 0, 3, 1, 0, 3, -1, 0, 0, -1, 4, 0, -1, 4, 0, 1, 0, 0, 1, 0, 0, -1
, 4, 0, -1, 4, 2, -1, 4, 2, 1, 4, 0, 1, 4, 0, -1, 4, 2, -1, 3, 2, -1, 3, 2, 1, 4
, 2, 1, 4, 2, -1, 3, 2, -1, 2, 1, -1, 2, 1, 1, 3, 2, 1, 3, 2, -1, 2, 1, -1, 1, 1
, -1, 1, 1, 1, 2, 1, 1, 2, 1, -1, 1, 1, -1, 1, 3, -1, 1, 3, 1, 1, 1, 1, 1, 1, -1
, 1, 3, -1, 0, 3, -1, 0, 3, 1, 1, 3, 1, 1, 3, -1, 1, 6, -1, 2, 6, -1, 2, 4, -1,
1, 4, -1, 1, 6, -1, 1, 6, 1, 1, 4, 1, 2, 4, 1, 2, 6, 1, 1, 6, 1, 1, 6, -1, 1, 4,
-1, 1, 4, 1, 1, 6, 1, 1, 6, -1, 1, 4, -1, 2, 4, -1, 2, 4, 1, 1, 4, 1, 1, 4, -1,
2, 4, -1, 2, 6, -1, 2, 6, 1, 2, 4, 1, 2, 4, -1, 2, 6, -1, 1, 6, -1, 1, 6, 1, 2,
6, 1, 2, 6, -1, 1, 3, -1, 2, 3, -1, 2, 4, -1, 3, 4, -1, 3, 2, -1, 2, 1, -1, 2,
2, -1, 1, 2, -1, 1, 3, -1, 1, 3, 1, 1, 2, 1, 2, 2, 1, 2, 1, 1, 3, 2, 1, 3, 4, 1,
2, 4, 1, 2, 3, 1, 1, 3, 1, 1, 3, -1, 1, 2, -1, 1, 2, 1, 1, 3, 1, 1, 3, -1, 1, 2
, -1, 2, 2, -1, 2, 2, 1, 1, 2, 1, 1, 2, -1, 2, 2, -1, 2, 1, -1, 2, 1, 1, 2, 2, 1
, 2, 2, -1, 2, 1, -1, 3, 2, -1, 3, 2, 1, 2, 1, 1, 2, 1, -1, 3, 2, -1, 3, 4, -1,
3, 4, 1, 3, 2, 1, 3, 2, -1, 3, 4, -1, 2, 4, -1, 2, 4, 1, 3, 4, 1, 3, 4, -1, 2, 4
, -1, 2, 3, -1, 2, 3, 1, 2, 4, 1, 2, 4, -1, 2, 3, -1, 1, 3, -1, 1, 3, 1, 2, 3, 1
, 2, 3, -1))These are examples from Spatial User's Guide.
ORA-54668 means that you need to update your srid to a 3D srid.
Please check out Spatial User's Guide, Pro Oracle Spatial for 11g book and
the following paper (which we can send you a copy offline)
B. M. Kazar, R. Kothuri, P. v. Oosterom and S. Ravada, "On Valid and Invalid Three-
Dimensional Geometries", 2nd International Workshop on 3D Geo-Information: Requirements, Acquisition,
Modelling, Analysis, Visualisation, 12-14 December 2007, Delft, the Netherlands (Published as Chapter 2,
pp. 19-46 in Advances in 3D Geoinformation Systems Series: Lecture Notes in Geoinformation and
Cartography Oosterom, P.v.; Zlatanova, S.; Penninga, F.; Fendel, E. (Eds.) 2008, XX, 441 p. 235 illus.,
Hardcover ISBN: 978-3-540-72134-5
Maybe if you can post here an example geometry from your data,
we can help you more.
Hope these help.
Thanks

Spatial Query by users other than data owner

I am having a problem with a spatial query that works perfectly for the user that owns the table containing the SDO_GEOMETRY column. But I am unable to make this query work for other users.
I am aware that the problem is related the using the indexes, as the error I am getting is "... Failed to tessellate window - ORA-13209 internal error while reading SDO_INDEX_METADATA ..."
I cannot seem to find any reference in the release documentation to making this possible. And several attempts to create indexes for other users have failed, probably because I am missing some important step.
Any advice or pointers to doco would be appreciated.
Greg.

I don't know of any way to control what elements of the model are made visable to a particular user. To control which data values (dimension members and associated fact data), you could implement the OLAP DML PERMIT command using OLAP DML programs that you create.

Problem on creating spatial index

Hi,
I am newbie in Oracle Spatial and looking for help on creating spatial index
I am working on OpenStreetMap data. I intended to import the OSM data from PostGis to Oracle Spatial. This code is executed to import the data
ogr2ogr -f OCI OCI:osm/password@pdborcl PG:"host=localhost user=postgres password=password dbname=gis port=5432" -lco OVERWRITE=yes -lco SRID=8307 -nln planet_osm_polygon planet_osm_polygon
However, I got this error when importing the data.
ERROR 1: ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial index: index build failed
ORA-13249: Error in spatial index: [mdrcrtxfergm]
ORA-13249: Error in spatial index: [mdpridxtxfergm]
ORA-13200: internal error [ROWID:AAAW/iAAQAAAIfsAAP] in spatial indexing.
ORA-13206: internal error [] while creating the spatial index
ORA-13033: Invalid data in the SDO_ELEM_INFO_ARRAY in SDO_GEOMETRY object
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
in CREATE INDEX "OSI_12283" ON PLANET_OSM_POLYGON("ORA_GEOMETRY") INDEXTYPE IS
MDSYS.SPATIAL_INDEX
This creating index failure only happen when I tried to import planet_osm_polygon table. I did not get this error when I imported the planet_osm_point, planet_osm_roads and planet_osm_line and indexing worked fine. The geometry type of column which was failed to index is ST MultiPolygon ( I am not sure if this is the cause).
Apparently, the data is imported to database. I tried to create index on that table, and it returns the same error.
CREATE INDEX PLANET_OSM_POLYGONI ON PLANET_OSM_POLYGON(ORA_GEOMETRY)
INDEXTYPE IS MDSYS.SPATIAL_INDEX;
Please help!

Hi Ivan Bush
Thank you for the reply.
Sorry for the lengthy reply. To be honest, I dont understand how to read query result. This is the query that I executed:
select * from (select sdo_geom.validate_geometry_with_context(p.ora_geometry, 0.05) from planet_osm_polygon p) where rownum <100;
And the snippet of the query result:
Could you help me to explain the meaning of the query result? I chose 0.05 as tolerance value based on this reference (http://docs.oracle.com/cd/B19306_01/appdev.102/b14255/sdo_intro.htm#i884589) .
Anyway, this information might be useful in solving the problem. When I imported the OSM data to PostGis, the SRID of geometry data was 900913. Since I want the data in WGS84 coordinate system, I change the SRID of the geometry data to 4326. I could perform this below-mentioned PostgreSQL query to change its SRID for geometry column in table planet_osm_point, planet_osm_roads and planet_osm_line. However, this query did not work on planet_osm_polygon one since this query does not recognize multipolygon datatype.
ALTER TABLE planet_osm_point
ALTER COLUMN way TYPE geometry(point,4326) USING ST_Transform(way,4326);
So for planet_osm_polygon case, I check this post (QGIS, Postgis: Geometry type does not match column type - Geographic Information Systems Stack Exchange) and follow @dbaston's answer to change the geometry data type to generic'geometry'. Then change the SRID, and return the geometry data type to MultiPolygon.
ALTER TABLE planet_osm_polygon ALTER COLUMN way SET data type geometry(MultiPolygon) USING ST_Multi(way);
Let me know if this might be the cause of the indexing problem.

Spatial Query not using Spatial Index

Hi All,
I have a query which uses the SDO_WITHIN_DISTANCE operator, but is taking far too long to complete.
SELECT
               RT.*,RD.RPD_NODE_ID, RD.RPD_XCOORD,RD.RPD_YCOORD
          FROM
               railplan_data RD
               LEFT JOIN Walk_data_sets WDS ON RD.RPD_RPS_ID = WDS.WDS_RPS_ID
               LEFT JOIN RWNet_Temp RT ON WDS.WDS_ID = RT.RW_WDS_ID
          WHERE
               WDS.wds_id = 441
          AND
               MDSYS.SDO_WITHIN_DISTANCE(RT.RW_GEOM,RD.RPD_GEOLOC,'DISTANCE=' || TO_CHAR(RT.RW_BUFFER) || ' UNIT=METER') = 'TRUE';
Upon generation of the explain plan I have realised that the spatial index is not being used in the query, but I can't for the life of me get the thing working
3     | Id | Operation | Name | Rows | Bytes |TempSpc| Cost |
4     ------------------------------------------------------------------------------------------
5     | 0 | SELECT STATEMENT | | 25841 | 99M| | 201 |
6     |* 1 | FILTER | | | | | |
7     | 2 | MERGE JOIN OUTER | | | | | |
8     |* 3 | HASH JOIN | | 12652 | 420K| 2968K| 185 |
9     | 4 | TABLE ACCESS FULL | RAILPLAN_DATA | 75910 | 2075K| | 60 |
10     | 5 | TABLE ACCESS BY INDEX ROWID| WALK_DATA_SETS | 1 | 6 | | 1 |
11     |* 6 | INDEX UNIQUE SCAN | WDS_PK | 1 | | | |
12     |* 7 | SORT JOIN | | 16 | 63760 | | 16 |
13     |* 8 | TABLE ACCESS FULL | RWNET_TEMP | 16 | 63760 | | 4 |
If anyone could help me out in figuring out why the spatial index is not being used, I would be most appreciative.
TIA
Dan

Hi all again,
Well I finally got an upgrade to Oracle 10 (yay!), so I am now trying to implement the SDO_JOIN method as per my earlier posts. In fact it is actually working, but I have a question. When I run an explain plan it does not show the use of any domain indexes which I would expect to see, but performs fine (1.07s) with just a few records (10 in 1 table, 15000 in the other), please see code and explain plan below:
SELECT
Distinct
    RT.RW_ID, RD.RPD_NODE_ID,
    RD.RPD_XCOORD,RD.RPD_YCOORD
FROM
    RPD_TEMP_762 RD,
    WALK_DATA_SETS WDS,
    RWNET_TEMP RT,
    TABLE
    (SDO_JOIN
        ( 'RWNET_TEMP',
            'RW_GEOM',
            'RPD_TEMP_762',
            'RPD_GEOLOC',
            'distance= ' || TO_CHAR(RT.RW_BUFFER) || ' unit=meter')) SPATIAL_JOIN_RESULT
WHERE WDS.WDS_ID = RT.RW_WDS_ID
AND WDS.WDS_ID = 762
AND SPATIAL_JOIN_RESULT.ROWID1 = RT.ROWID
AND SPATIAL_JOIN_RESULT.ROWID2 = RD.ROWID
PLAN_TABLE_OUTPUT
| Id | Operation                            | Name         | Rows | Bytes | Cost (%CPU)|
|   0 | SELECT STATEMENT                     |              |    74 | 5994 | 21753   (1)|
|   1 | SORT UNIQUE                         |              |    74 | 5994 | 21691   (1)|
|* 2 |   HASH JOIN                          |              | 1046K|    80M| 1859   (1)|
|   3 |    NESTED LOOPS                      |              | 6076 |   213K| 1824   (1)|
|   4 |     NESTED LOOPS                     |              |    74 | 2516 |   194   (1)|
|* 5 |      INDEX UNIQUE SCAN               | WDS_PK       |     1 |     4 |     0   (0)|
|* 6 |      TABLE ACCESS FULL               | RWNET_TEMP   |    74 | 2220 |   194   (1)|
|* 7 |     COLLECTION ITERATOR PICKLER FETCH| SDO_JOIN     |       |       |            |
|   8 |    TABLE ACCESS FULL                 | RPD_TEMP_762 | 17221 |   756K|    28   (0)|
------------------------------------------------------------------------------------------ When i try to add hints to force the use of spatial indexes the performance of this query drops through the floor (it takes minutes / hours), index hint shown below:
/*+ ORDERED INDEX(RW rw_geom) INDEX(RD rpd_geoloc) */My question is is the first query using domain indexes, and if not, how do I get it to?
TIA
Dan

Oracle 9i 10g slow spatial query

I have been using the following spatial query in oracle 9i to assign jurisdictions to spatial points.
SELECT /*+ordered*/ L.TCH_X_COORD, L.TCH_Y_COORD, T.NAME
FROM tis.tis_coordinates_hold_on L,
geospatial.mdt_admin_districts T
WHERE SDO_RELATE(T.GEOMETRY,
MDSYS.SDO_GEOMETRY(2001,41079,MDSYS.SDO_POINT_TYPE(tch_x_coord,tch_y_coord,NULL),
NULL,NULL),'mask=ANYINTERACT querytype=WINDOW') = 'TRUE'
AND tch_assigned_base_rte='M00001N'
By using the ordered hint I was able to double the retrieval rate. My problem is this: We are now migrating to oracle 10g, and the use of the ordered returns no rows (different incorrect results). If I remove the + ordered the results are correct, but I no longer get the increased speed of retrieval. Has anyone run into this problem, and can you suggest a way that I could speed up this query. As it stands now it takes more than 1/2 sec for each record retrieved, and I have millions of records !! Thanks.

We're using 10.2.4.0 I believe I have found the reason the queries were different. When I dropped the spatial index and re-created it, the query returned the same rows as 9i. However, I still have an issue with the speed. 10g appears to be about 1/3 as fast as 9i was. It doesn't seem to make any difference whether I put in the +ordered or not. Our dba says just based on cpu and processing speed the server that has 10g should be significantly faster. Any comments? Thanks.

Why Oracle Spatial Query So Slow???

I have 90,000 lines in my database. When I did a query about
finding all the lines within a certain distance of a point, it
took me nearly 30 seconds. And when I query the intersection
between the lines, it took me about 5 minutes!! God, I can't
believe it!
Do you guys met the problem before? Please share something with
me, thank you so much!
Xiong

Hi,
Are you using a spatial index for your within distance query? If
so, what kind, and have you tuned it at all?
As far as the intersection question goes, how many geometries are
you testing? Are they big? Are you only comparing the ones
returned by within distance?
If they are big geometries, there are some very large performance
gains in 9i when dealing with larger geometries.
Dan

Spatial query optimizing

hi, there.
I am working Oracle Spatial 9.0.1 and I have a problem about the
performance of spaital query, can someone help me resolve it?
/*query 1*/
select t1.line_seg
from spatial_list_Traj
where sdo_within_distance(convert_trajseg_to_lineseg
(t1.line_seg), MDSYS.SDO_GEOMETRY(2003, NULL, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY
(212.117, 352.613, 221.617, 362.708)), 'querytype=filter
distance=0.5') = 'TRUE';
/* query 2*/
select t1.line_seg
from spatial_list_traj
where object_id = 1 and sdo_within_distance
(convert_trajseg_to_lineseg(t1.line_seg), MDSYS.SDO_GEOMETRY
(2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3),
MDSYS.SDO_ORDINATE_ARRAY(212.117, 352.613, 221.617,
362.708)), 'querytype=filter distance=0.5') = 'TRUE';
there are about 120,000 rows in the spatial_list_Traj table and
query 1 takes only 1 second to finish, which is a good result
but if I add another condition, like query 2, the time cost is
still 1 second. I thought it can be much faster since there is
only 48 rows whose object_id is 1. what I expected it to do was
for the optimizer to filter out the rows that match
the 'object_id = 1' criteria and then do a spatial query on the
filtered data.
PS: there are two indices--a b-tree index on column 'object_id'
and of course, a functional spatial index on column 'line_seg',
which is a R-tree.
thanks in advance
Hu Cao

Hi Hu,
The second query is probably not using the spatial index. The
spatial index indexes the whole table based on spatial
relationships, so even though you may have filtered out all but
48 rows, the spatial index has to be applied to all of the rows.
In this case, it is probable that all of the rows returned with
object_id=1 are being geometrically compared with your query
window, which may account for the extra time.
You may want to try a hint to tell the optimizer not to use the
index on object_id, i.e.
SELECT /*+NO_INDEX(spatial_list_traj object_id_index_name)*/
Hope this helps,
dan

Running Spatial Query as different user

Has anyone else run into a problem with running a spatial query that works fine in the scheme that created the tables but when I run it after giving permissions to another user it returns no rows. Here is my example and sorry it is little complicated. I am running 9.2.0.7 are there specfic object or system privlidges i need to give the user that doesn't own those tables to run spaital functions?
SELECT /*+ ORDERED ALL_ROWS */ COUNT(incident_n)
FROM mpd_data.incidentsshp i
WHERE sdo_relate(i.geom,(SELECT /*+ ORDERED ALL_ROWS */ sdo_geom.sdo_buffer(geom, m.diminfo, 2)
FROM (SELECT /*+ ORDERED ALL_ROWS */ mdsys.sdo_aggr_union(mdsys.sdoaggrtype(union_geom, 0.5)) geom FROM (select mdsys.sdo_aggr_union(mdsys.SDOAGGRTYPE(d.geom,0.5)) union_geom
from spatial.dime d WHERE d.rcd_nbr IN (select rcd_nbr
from dime
where ((lo_add_r >= 1500 and hi_add_r <= 1600) or
(lo_add_l >= 1500 and hi_add_l <= 1600) or
(1500 between lo_add_r and hi_add_r and
1600 between lo_add_l and hi_add_l))
and street = 'WARREN' and dir = 'N' and sttype = 'AV')))
,mdsys.user_sdo_geom_metadata m
WHERE m.TABLE_NAME = 'DIME'), 'MASK = ANYINTERACT' ) = 'TRUE'
and cdate between 20060101 and 20061231

I have a separate schema for querying with and it works fine. I granted select on the needed tables and created synonyms (for convenience). Didn't have to do anything special for spatial indexes at all.
I believe there is an issue doing spatial queries across a DB Link, so that should be avoided.
--Peter

Combined flat (regular) and Spatial query

DB: Oracle 8.1.7.2.1 (8i Release 3, patch 81721)
I performed a spatial query on the results of a regular query, in the form of:
Select count(*) from
(select * from myTable where key=...)
WHERE (MDSYS.SDO_RELATE("GEOLOC",
MDSYS.SDO_GEOMETRY(2003,NULL,null,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),
MDSYS.SDO_ORDINATE_ARRAY(-118.83939716391866,
29.951783100000025, -100.20650379608135,
40.52319191999998)),
'mask=ANYINTERACT layer_gtype=POINT
querytype = WINDOW')='TRUE');
The first flat query results in a small number of records and takes minimum time if run separately.
Select count(*) from
(select * from myTable where key=...)
However, when appended the spatial join condition, it takes a long time, same as querying from the whole dataset without the first flat query. I tried to optimize the spatial index and it did not help much.
Why isn't the spatial query taking advantage of the flat query? Can I somehow force it to do so to improve the performance? (This is a dynamic query in an application.)
Thanks.

Hi
I have a similar problem and i'd like to know if anyone have got a solution.
We are developing a vehicle localization system.
The amount of data it's about 6 million positions per year.
The queries to the data could be the actual location of the vehicle (100 vehicles) or historical locations.
For historical location we have partitioned the table an index by date (each week), and for actual location we have created a bitmap index based on field L_ULTIMA.
Allwais the queries are filtered by alfanumeric conditions more restrictive then spatial (range of dates or last_location).
When runnin alfanumeric queries over a subset of une million rows, it takes only few seconds (even less) but when including spatial conditions (SDO_RELATE to a rectangle) it takes more than one minute.
We have tried different hints to force the use of bitmap index but in all cases the execution plan uses de spatial index.
It's there any way to combine spatial and flat indexes?
SELECT
COUNT(*)
FROM SLFP_LOCALIZACIONES A
WHERE sdo_relate(A.geom, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(159657,3978069, 546051,4116358)),
'mask=anyinteract querytype=window') = 'TRUE';
COUNT(*)
899073
Transcurrido: 00:02:126.34
SELECT /*+ INDEX_COMBINE(A SLFP_LOCALI_ULTIMA_I) */
COUNT(*)
FROM SLFP_LOCALIZACIONES A
WHERE sdo_relate(A.geom, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(159657,3978069, 546051,4116358)),
'mask=anyinteract querytype=window') = 'TRUE' AND
A.L_ULTIMA = 1;
COUNT(*)
102
Transcurrido: 00:02:121.00
SELECT COUNT(*) FROM SLFP_LOCALIZACIONES WHERE L_ULTIMA = 1
COUNT(*)
104
Transcurrido: 00:00:00.72
SQL> SELECT /*+ INDEX_COMBINE(A SLFP_LOCALI_ULTIMA_I) */
2 COUNT(*)
3 FROM SLFP_LOCALIZACIONES A
4 WHERE N_X >= 159657 AND
5 N_X <= 546051 AND
6 N_Y >= 3978069 AND
7 N_Y <= 4116358 AND
8 A.L_ULTIMA = 1;
COUNT(*)
102
Transcurrido: 00:00:00.59

Bugy nearest neighbour spatial query?

Hi,
I have the following problem. The last query below returns the bad number of rows and I suspect some RDBMS bug behinde this, but am not really shure. Could some one please have a look?
-- Preparation steps:
-- Create 'Varos' Table
CREATE TABLE VAROS (
GMIPRIMARYKEY NUMBER (10) NOT NULL,
TNEV VARCHAR2 (50),
NEV VARCHAR2 (50),
GEOMETRY MDSYS.SDO_GEOMETRY,
PRIMARY KEY ( GMIPRIMARYKEY ));
-- Insert 5 records
--           2 have no name (nev attribute contains 'nincs neve')
--          3 have meaningful name
insert into varos values (615484,'Kisszentmarton','58131',MDSYS.SDO_GEOMETRY(2002,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(18.04725,45.788384,18.04698,45.786578)));
insert into varos values (617351,'Czn','nincs neve',MDSYS.SDO_GEOMETRY(2002,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(18.060483,45.785141,18.060615,45.784949,18.06079,45.783938,18.061508,45.782226,18.061641,45.781539,18.061686,45.780696,18.061677,45.780531)));
insert into varos values (617352,'Czn','nincs neve',MDSYS.SDO_GEOMETRY(2002,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(18.061677,45.780531,18.061638,45.779749,18.061463,45.778458,18.061103,45.777196,18.060708,45.776133,18.060355,45.775182)));
insert into varos values (622732,'Vejti','Tancsics Mihaly utca',MDSYS.SDO_GEOMETRY(2002,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(17.964469,45.809845,17.964149,45.809448,17.9641,45.809356,17.964009,45.809186,17.964004,45.808933,17.964007,45.808886,17.964169,45.808335,17.964781,45.807061,17.965233,45.806119,17.965492,45.805637,17.965682,45.805283,17.965802,45.805063,17.965932,45.804825,17.966221,45.804298)));
insert into varos values (629498,'Pisks','5821',MDSYS.SDO_GEOMETRY(2002,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(17.912804,45.80585,17.913105,45.805645,17.922503,45.803835,17.935384,45.803584)));
-- Insert metadata record
insert into USER_SDO_GEOM_METADATA values('VAROS','GEOMETRY',MDSYS.SDO_DIM_ARRAY( MDSYS.SDO_DIM_ELEMENT('Lon',16,23,0.00000001),MDSYS.SDO_DIM_ELEMENT('Lat',45.5,48.8,0.00000001)),NULL);
-- Commit
commit;
-- Create spatial index
CREATE INDEX VAROS_INDEX ON VAROS(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS('SDO_LEVEL=10 SDO_NUMTILES=8');
-- Test steps:
-- Select records with not 'nincs neve'
select gmiprimarykey,tnev,nev
     from varos
     where nev <> 'nincs neve';
-- It fetches 3 records
-- 615484,Kisszentmarton,58131
-- 622732,Vejti,Tancsics Mihaly utca
-- 629498,Pisks,5821
-- Right.
-- Embed the above select statement as a subselect to a nearest-neighbour spatial query.
-- It is requested to return the 3 nearest records ('sdo_num_res=3').
select gmiprimarykey,tnev,nev
     from ( select gmiprimarykey,tnev,nev,geometry
               from varos
               where nev <> 'nincs neve'
          ) y
     where mdsys.SDO_NN(y.geometry,mdsys.sdo_geometry(2001,NULL,mdsys.sdo_point_type(18,45.5,0),NULL,NULL),'sdo_num_res=3')='TRUE';
-- It is expected to return 3 records (the same ones as above), but it returns only 1 single record
-- 615484,Kisszentmarton,58131
-- Wrong.
It seems that Oracle executes the neaest neighbour spatial query BEFORE evaluating the inline view.
Regards,
Tamas Szecsy
[email protected]

Hi,
The nearest neighbor query has to use the spatial index, and there is no way to filter the results and
use the spatial index.
So, in Oracle9i the SDO_NN tuning parameter SDO_BATCH_SIZE was introduced - what this does is
keep streaming results from the SDO_NN query until some other condition is met.
Rewriting your query to use SDO_BATCH_SIZE:
select gmiprimarykey,tnev,nev
from varos y
where mdsys.SDO_NN(y.geometry,
mdsys.sdo_geometry(2001,NULL,mdsys.sdo_point_type(18,45.5,0),NULL,NULL),
'sdo_batch_size=5')='TRUE'
and nev <> 'nincs neve'
and rownum < 4;
Two things about SDO_BATCH_SIZE:
Cannot be used with SDO_NUM_RES
Requires an R-tree index
Also, you are using hybrid quadtree indexes. At this point in time, there are almost no situations where
Oracle recommends using hybrid quadtree indexes (this is true in all versions of Oracle Spatial).
As of Oracle9i, the recommendation is to use R-tree indexes (which work as well or better than
quadtree indexes most of the time). Certainly if you require the incremental nearest neighbor functionality
described above then you need to use an R-tree index.
If you must use a quadtree index, then you will still have to use sdo_num_res, but you should try to set the
number large enough so that any filtering leaves enough in the result set.

Spatial query w/ logical operators in a subquery on Linux using Oracle 1

Hello...
I'm being given XML that I need to parse and create SQL from it. Below my signature is the SQL that I generate (its a simple example) and can be more elaborate due to the logical operators (AND and OR) given in the XML.
The problem that we're seeing is performance-based: when one of the logical operator queries is Spatial-based, like below. Running it in JDBC, the query never returns.
The spatial query just by itself returns ~300 rows (takes approximately 0.2 seconds). The "PERCENTAGE" query by itself returns about ~40000 rows (takes approximately ~.8 seconds).
If we run the query below with 2 non-spatial subqueries, the result returns and performance is very acceptable (~ 0.9 seconds)-- the result set is about 80000 rows.
Thanks,
Jim
=========================
SELECT
COLUMN_WE_WANT , RESULTS
FROM
TABLE_A
WHERE
COLUMN_WE_WANT IN
SELECT
COLUMN_WE_WANT
FROM
TABLE_A
WHERE
SDO_OVERLAPBDYINTERSECT(TABLE_A.MY_SPATIAL_COLUMN,
SDO_GEOMETRY(2003,
4326,
null,
SDO_elem_info_array( 1 , 3 , 1 ),
SDO_ORDINATE_ARRAY( lng_1,lat_1 , lng_2,lat_2 , lng_3,lat_3 , lng_4,lat_4 , lng_1,lat_1 )
) = 'TRUE'
OR
COLUMN_WE_WANT IN
SELECT
COLUMN_WE_WANT
FROM
TABLE_B
WHERE
SOME_PERCENTAGE_RATE_COLUMN < 90
)

Its difficult to comment without seeing the execution plan. You should trace this query to get a better idea of exactly what's happening.
Depending on the complexity of the logical operators, I would look at doing this using set operations. So for an OR you might have...
SELECT COLUMN_WE_WANT, RESULTS
FROM TABLE_A
WHERE COLUMN_WE_WANT IN (
     SELECT COLUMN_WE_WANT
     FROM TABLE_A
     WHERE SDO_OVERLAPBDYINTERSECT(TABLE_A.MY_SPATIAL_COLUMN,SDO_GEOMETRY(2003,4326,
     NULL, SDO_elem_info_array( 1 , 3 , 1 ),
     SDO_ORDINATE_ARRAY( lng_1,lat_1 , lng_2,lat_2 , lng_3,lat_3 , lng_4,lat_4 , lng_1,lat_1 ) )) = 'TRUE'
UNION
     SELECT COLUMN_WE_WANT
     FROM TABLE_B
     WHERE SOME_PERCENTAGE_RATE_COLUMN < 90)For an AND, you would use INTERSECT.
Edited by: Reggie to remove the extra INTERSECT

Spatial query w/ logical operators in a subquery on Linux using Oracle 10g

Hello...
I'm being given XML that I need to parse and create SQL from it. Below my signature is the SQL that I generate (its a simple example) and can be more elaborate due to the logical operators (AND and OR) given in the XML.
The problem that we're seeing is performance-based: when one of the logical operator queries is Spatial-based, like below. Running it in JDBC, the query never returns.
The spatial query just by itself returns ~300 rows (takes approximately 0.2 seconds). The "PERCENTAGE" query by itself returns about ~40000 rows (takes approximately ~.8 seconds).
If we run the query below with 2 non-spatial subqueries, the result returns and performance is very acceptable (~ 0.9 seconds)-- the result set is about 80000 rows.
Thanks,
Jim
=========================
SELECT
COLUMN_WE_WANT , RESULTS
FROM
TABLE_A
WHERE
COLUMN_WE_WANT IN
SELECT
COLUMN_WE_WANT
FROM
TABLE_A
WHERE
SDO_OVERLAPBDYINTERSECT(TABLE_A.MY_SPATIAL_COLUMN,
SDO_GEOMETRY(2003,
4326,
null,
SDO_elem_info_array( 1 , 3 , 1 ),
SDO_ORDINATE_ARRAY( lng_1,lat_1 , lng_2,lat_2 , lng_3,lat_3 , lng_4,lat_4 , lng_1,lat_1 ) )
) = 'TRUE'
OR
COLUMN_WE_WANT IN
SELECT
COLUMN_WE_WANT
FROM
TABLE_B
WHERE
SOME_PERCENTAGE_RATE_COLUMN < 90
)

There is a spatial forum. You will likely have a far better experience there.

SSRS - SQL Server Spatial Query

Hi, I was hoping someone could help me.
I'm creating an SSRS report with Map and importing points via SQL Server Spatial query. I have a db table with 8,000 points bu the import only ever brings in the first 2,000 queried (no matter what the filter is). Is there a limitation in SSRS that can be
changed via a configuration setting?
Many thanks in advance for any help on this,
Steve.

Really appreciate you coming back so quick Olaf.
No its a straightforward query (select AccountNum, Name, Address, Longitude, Lattitude, UrbanArea, County, MI_STYLE, MI_PRINX, SP_GEOMETRY from <table>)
Just to give the whole picture. I had 8,000 points in MapInfo version 10. I imported them to SQL Server 2012 via MapInfo Easy Loader.
The SQL Server spatial points import to SSRS and the Bing overlay map works great (so they import to correct space) but its only a subset of the points that import. I can pick any subset using the WHERE clause but I cannot get all 8,000 points.
I was hoping there was a configuration setting somewhere in SSRS that was causing the problem.

Index problem in a spatial query

Similar Messages

Maybe you are looking for