Mdsys.sdo_relate Problem

Hi!
I'va got two Tables, one of them ("kante") has a Geometry - Column in it and a Quad - Tree Index is
Created, the other one ("kabelabschnitt") is linked to "kante" via a foreign key.
This Query is very fast:
SELECT k.* FROM kante k
where sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL, mdsys.sdo_elem_info_array(1,1003,3), mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)), 'mask=ANYINTERACT querytype=window') = 'TRUE';
But this takes about 20 s:
SELECT k.*, ka.* FROM kante k, kabelabschnitt ka
where ka.id_ka = k.id_kante
and sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL, mdsys.sdo_elem_info_array(1,1003,3), mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)), 'mask=ANYINTERACT querytype=window') = 'TRUE';
Can anynone tell me why??
Thanx in advance,
J

Hi,
It could be slower because the optimizer is choosing to use an index associated
with the join key between the tables instead of the spatial index.
Try adding the /*+ no_index (, index_name) */ hint, i.e.
SELECT /*+ no_index (K name_of_id_kante_index) k.*, ka.*
FROM kante k, kabelabschnitt ka
where ka.id_ka = k.id_kante
and sdo_relate(geom, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(34520, 253535, 34621, 253606)),
'mask=ANYINTERACT querytype=window') = 'TRUE';
Hope this helps,
Dan

Similar Messages

  • Error using mdsys.sdo_relate()

    Hi, I am using Oracle 8.1.5 and i am trying to execute the following sql statement
    SQL> select p.name
    2 from parks p
    3 where mdsys.sdo_relate(p.shape,
    mdsys.sdo_geometry(
    3,null,null,
    mdsys.sdo_elem_info_array(1,3,3),
    4 mdsys.sdo_ordinate_array(10,10,20,20)),
    5 'mask=anyinteract querytype=window')
    = 'true';
    But i recieved the following error message
    ERROR at line 1:
    ORA-29902: error in executing ODCIIndexStart() routine
    ORA-13207: incorrect use of the [SDO_RELATE] operator
    ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 73
    ORA-06512: at line 1
    Do anyone know how to recify this?
    Thanks!
    null

    Ops, sorry it's TRUE not true
    I managed to solved it. Thanks:>
    brian
    null

  • Can mdsys.sdo_relate return FALSE?

    I have the following query:
    SELECT MIN (dtczas) dtczas
    FROM sd_car_location
    WHERE dyza_id = 2
    AND dtczas > '24-JUN-2002 11:06:48'
    AND mdsys.sdo_relate(
    geom,
    MDSYS.SDO_GEOMETRY( 2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3),
    MDSYS.SDO_ORDINATE_ARRAY( 3734329.56686484, 5567865.09443332,
    3735261.90177227, 5568277.30732063 )
    'mask=ANYINTERACT querytype=WINDOW') = 'FALSE'
    while executing this query I receive:
    ORA-29902: error in executing ODCIIndexStart() routine
    ORA-13207: incorrect use of the [SDO_RELATE] operator
    ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 84
    ORA-06512: at line 1
    so, is it possible to use sdo_relate in such way? When I try "<> 'TRUE'" or "AND NOT .... = 'TRUE'" index is not used.
    Thanks in advance for help.
    regards
    Krzysztof

    It is not possible. You must use ='TRUE'.
    The reason for this is related to how the operators work.
    First they do an index lookup to return the data that is
    likely to interact, then they do further filtering to find the
    data that actually interacts. All operators use the index
    in this way.
    If ='FALSE' was allowed, you'd get an answer that includes
    only the geometries that were likely to interact (returned from
    the index query), but that didn't interact, i.e. wrong answer.
    You might be able to do something like this:
    select min (dtczas) from
    SELECT dtczas
    FROM sd_car_location
    WHERE dyza_id = 2
    AND dtczas > '24-JUN-2002 11:06:48
    MINUS
    SELECT dtczas
    FROM sd_car_location
    WHERE dyza_id = 2
    AND dtczas > '24-JUN-2002 11:06:48'
    AND mdsys.sdo_relate(
    geom,
    MDSYS.SDO_GEOMETRY( 2003, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 3),
    MDSYS.SDO_ORDINATE_ARRAY( 3734329.56686484, 5567865.09443332,
    3735261.90177227, 5568277.30732063 ) ),
    'mask=ANYINTERACT querytype=WINDOW') = 'TRUE');
    Hope this helps,
    Dan

  • Mdsys.sdo_relate slow, waiting on ALL_SDO_GEOM_METADATA

    Database Oracle 8.1.7 Server Windows NT
    Hello,
    I have a query that uses sdo_relate which I have tested on two different oracle instances. On both instances I am testing the query on the same data. On one instance the query takes less that 10 seconds while on the second instance the query takes longer than then minutes.
    Tracing the query on the second, slow instance shows many wait events while the server is executing the following query
    PARSING IN CURSOR #3 len=126 dep=1 uid=346 oct=3 lid=346 tim=69164025 hv=1087985607 ad='48217d4'
    SELECT DIMINFO FROM ALL_SDO_GEOM_METADATA WHERE OWNER = 'TESTUSER' AND TABLE_NAME = 'SPATIALTABLE' AND COLUMN_NAME = 'GEOM'
    END OF STMT
    PARSE #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=69164025
    BINDS #3:
    EXEC #3:c=0,e=0,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,tim=69164029
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=319 p3=4
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=325 p3=2
    WAIT #3: nam='db file scattered read' ela= 4 p1=1 p2=1515 p3=2
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=1518 p3=2
    WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=1528 p3=1
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=7295 p3=2
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=7298 p3=6
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12051 p3=2
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12055 p3=8
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12063 p3=3
    WAIT #3: nam='db file scattered read' ela= 4 p1=1 p2=12651 p3=2
    WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=12654 p3=1
    WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=12656 p3=1
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=12663 p3=4
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13307 p3=2
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13311 p3=8
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13319 p3=4
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13766 p3=8
    WAIT #3: nam='db file sequential read' ela= 4 p1=1 p2=13774 p3=1
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=13776 p3=3
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=14163 p3=7
    WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=14171 p3=1
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=14173 p3=4
    WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=14178 p3=1
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=14643 p3=8
    WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=14651 p3=1
    WAIT #3: nam='db file scattered read' ela= 4 p1=1 p2=14653 p3=2
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=15065 p3=2
    WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=16323 p3=1
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=16326 p3=3
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=16334 p3=3
    WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=16338 p3=1
    WAIT #3: nam='db file sequential read' ela= 3 p1=1 p2=18275 p3=1
    WAIT #3: nam='db file scattered read' ela= 3 p1=1 p2=18277 p3=3
    Is there some configuration change and tuning that I can do that will optimize this internal mdsys query?
    It may be significant to note that the instance that the query is fast on is a 8.1.7.4 database, while the other is a 8.1.7.0. As well on the slow instance there are many more spatial indexes and many more entries in the table ALL_SDO_GEOM_METADATA.
    Any suggestions?
    Thanks in advance,
    Rick

    Hi Rick,
    I looked to see if there were any bug fixes between 8.1.7 and 8.1.7.4 regarding metadata fetching, and I didn't see anything that jumped out at me. That's not to say there weren't, however - I know there have been several metadata improvements that have been done over time.
    Can you upgrade your 8.1.7 version to 8.1.7.4?
    Thanks,
    Dan

  • SDO_Relate problem

    is there anything that i can do to speed up the results of a
    query such as this one. the civic table contains point data and
    the parcels2 is polygons. Presently this query takes 23 secs
    but the amount of pids can be much larger.
    SELECT /*+ RULE */
         CIVIC_ID,
         PA.GEOMID
    FROM MGIS.CIVIC C,
    MGIS.PARCELS2 PA
    WHERE PA.PID IN
    ('15710940','15706633','15706658','15706732','15706666','15706823
    ','15102726','15084833','15102734','15084783','15102742','1508446
    0','15084411','15084841','15675713','15084429','15706781','150848
    58','15102692','15084924','15084437','15084866','15084445','15102
    684','15084916','15084874','15084452','15706740','15084908','1510
    2676','15084882','15084890','15102668','15084932','15084940','157
    10940','15710270','15710296','15102627','15101702','15706633','15
    706807','15706815','15084726','15706658','15084734','15084601','1
    5084593','15706773','15084585','15084742','15084544','15706799','
    15084759','15084825','15084551','15084767','15084569','15084775',
    '15084494','15696446','15706732','15706666','15084577','15084817'
    ,'15084486','15706823','15102700','15084809','15102726','15084791
    ','15084833','15084478','15102734','15084783','15102742','1508446
    0','15084411','15084841','15675713','15084429','15706781')
    AND SDO_RELATE(C.GEOM, PA.GEOM,'mask=ANYINTERACT
    querytype=WINDOW') = 'TRUE'

    An excellent point about indexing PA.PID.
    You might want to try the top part as:
    select /*+ ordered */
    CIVIC_ID,
    PA.GEOMID
    FROM MGIS.PARCELS2 PA,
    MGIS.CIVIC C
    Note the ordered hint, and reversing the table names in the from
    clause.

  • Problem with sdo_relate returning unexpected results

    I am having a problem with an oracle spatial query not returning what I feel is an appropriate result.
    I have a bounding box that has 6 points from a table that should be inside it. There are several hundred points total in this table. I perform the following query and oracle returns only 4 points, well 5 but we will get to that later, within the area of the search.
    SQL> Select feature_id
    From city_points A
    where (MDSYS.SDO_RELATE(A.GEOM, mdsys.sdo_geometry(2003, 8307, NULL, mdsys.sdo_elem_info_array(1,1003,1), mdsys.sdo_ordinate_array(-101.8417,-52.8083,-23.8417,-52.8083,-23.8417,-13.8083,-101.8417,-13.8083,101.8417,-52.8083)), 'mask=ANYINTERACT querytype=join') = 'TRUE');
    I used a different application to perform the same type of query. The difference is that the application does the spatial query, not oracle. Further the application gets all of the points and performs this query on the client. What the application returns is correct both visually and spatially.
    Two of the points not returned in the oracle spatial query are 300km inside the bounding box. This far exceeds the .5 m tolerance used in our decimal degrees data set (SRID 8307).
    I have experienced this problem on 9.2.0.1. I then patched that instance to 9.2.0.7 and duplicated the problem. I then exported the data and imported into a 10g release 1 database and again duplicated the problem. I have tried to re-index the data to no avail.
    I have also tried different querytypes also yielding less than expected results.
    The data looks like this:
    243
    SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-58.45, -34.6, NULL),NULL, NULL)
    254
    SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-56.18333, -34.883334, NULL), NULL, NULL)
    377
    SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-70.666671, -33.449999, NULL), NULL, NULL)
    385
    SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-68.149999, -16.5, NULL), NULL, NULL)
    388
    SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-47.916667, -15.783333, NULL), NULL, NULL)
    427
    SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-57.640066, -25.270295, NULL), NULL, NULL)
    The number is the id field, the rest is the geometry.
    The oracle spatial query above only returns id #s 359, 377,243,254,427
    There are five returned records. The extra value is outside the bounding area. So it should not have been returned at all. It is all too strange.
    I have seen this with different geometry types (points lines and area) as well.
    If anyone has suggestions, I would appreciate your comments.
    Thanks,
    John

    John,,
    What you are seeing is the behavior you should expect in the geodetic space.
    When you have a very long line connecting from longitude -101 to -23, that line
    does not follow the same latitude value.
    Since these points are in southern hemisphere, the line connecting them
    will curve downward (this is the great circle line).
    If you really want a line connecting with constant latitude, you should
    use the MBR type for the window geometry which densifies the
    lines along constant latitude before passing it into relate.
    SDO_GEOMETRY(2003, 8307, NULL,
    sdo_elem_info_array(1,1003,3),
    sdo_ordinate_array(-101.8417,-52.8083, 23.8417,-13.8083))
    siva

  • ORA-21779: duration not active error line 25 of MDSYS.AGGRUNION

    I execute the following pl/sql (line 56/57 in
    a procedure called RebuildSMZLabels)....
    v_query := 'SELECT /*+ INDEX ( A BASE_SMZ_A_SHAPE ) NO_INDEX ( A BASE_SMZ_A_RETIREDATE ) */ MDSYS.SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE(a.s
    hape,:1)) FROM &owner.base_smz_a A WHERE MDSYS.SDO_RELATE(a.shape,:2,''mask=ANYINTERACT querytype=window'') = ''TRUE'' and retiredate is
    null';
    EXECUTE IMMEDIATE v_query INTO v_union_shape USING v_diminfo(1).sdo_tolerance, v_trans_shape ;
    And I get...
    Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production
    With the Partitioning, OLAP and Oracle Data Mining options
    JServer Release 9.2.0.4.0 - Production
    DECLARE
    ERROR at line 1:
    ORA-21779: duration not active
    ORA-06512: at "MDSYS.AGGRUNION", line 25
    ORA-06512: at "MDSYS.AGGRUNION", line 25
    ORA-06512: at line 1
    ORA-06512: at "MDCADM.REBUILDSMZLABELS", line 57
    ORA-06512: at line 5
    Got me beat... anyone got any ideas?
    Simon Greener
    GIS Manager
    Forestry Tasmania

    Dan
    I reverted to the old 8i code (with individual
    UNIONS) and it still fails:
    DECLARE
    ERROR at line 1:
    ORA-21779: duration not active
    ORA-06512: at "MDSYS.SDO_3GL", line 439
    ORA-06512: at "MDSYS.SDO_GEOM", line 3096
    ORA-06512: at "MDCADM.REBUILDSMZLABELS", line 74
    ORA-06512: at line 5
    Line 74 is:
    v_union_shape := MDSYS.SDO_GEOM.SDO_UNION(v_union_shape,v_diminfo,v_shape,v_diminfo);
    Any ideas as I need this to work in 9i ASAP (as it
    doesn't work in 8i)?
    PS Dan, it is the same database/code problem I sent
    to you earlier this year. It is getting to the point
    that I am going to have to rebuild all this database
    centric code (which is where it needs to be in the
    business process) within our GIS (ArcInfo) which is going
    to be far more complex and not sustainable in the medium
    term.
    regards
    Simon

  • Sdo_relate in alternate user with views.

    Hello,
    I am using Oracle 8.1.7.2 and creating a view as follows.
    CREATE OR REPLACE VIEW REPORT_STREETINFO AS
    SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
    NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
    MIN_FROMNRLE,
    MAX(ST.TONRLE) MAX_TONRLE,
    NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
    MIN_FROMNRRI,
    MAX(ST.TONRRI) MAX_TONRRI,
    MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET MKT_STREET,
    MKT.CITY MKT_CITY,
    MKT.ZIP MKT_ZIP,
    MKT.PO_BOX MKT_POBOX
    FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
    DTWA,WALKERAREA WA
    WHERE PRIM_NAME IS NOT NULL AND
    (ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
    ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
    DTWA.DISTAREA_ID = DT.ID AND
    WA.WASID = DTWA.WASID AND
    MKT.SRNO = DT.MARKET_ID AND
    MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
    (inside+coveredby+on)
    querytype=window') = 'TRUE'
    GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
    MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP, MKT.PO_BOX
    ORDER BY PRIM_NAME
    I grant the rights to this above view to an alternate user. When
    I fire a query like
    SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 22;
    from the owner of the view I have no problems but when I fire
    this query from alternate user I get error
    ORA-03113 end-of-file on communication channel.
    I checked out the documentation which states from physical
    failure but this is definately not the case.
    Any help on this problem will be appretiated.
    Amol.

    Hello Ravi,
    I am posting a spool file which shows the steps I have followed
    and error that I get. I have taken care with the grants from
    mdsys for the SDO_RELATE and all the other operators.
    DEV>SHO USER
    USER ist "GEODIS"
    DEV>CREATE OR REPLACE VIEW REPORT_STREETINFO AS
    2 SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
    3 NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
    MIN_FROMNRLE,
    4 MAX(ST.TONRLE) MAX_TONRLE,
    5 NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
    MIN_FROMNRRI,
    6 MAX(ST.TONRRI) MAX_TONRRI,
    7 MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET
    MKT_STREET, MKT.CITY MKT_CITY,
    8 MKT.ZIP MKT_ZIP,
    9 MKT.PO_BOX MKT_POBOX
    10 FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
    DTWA,WALKERAREA WA
    11 WHERE PRIM_NAME IS NOT NULL AND
    12 (ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
    13 ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
    14 DTWA.DISTAREA_ID = DT.ID AND
    15 WA.WASID = DTWA.WASID AND
    16 MKT.SRNO = DT.MARKET_ID AND
    17 MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
    (inside+coveredby+on)
    18 querytype=window') = 'TRUE'
    19 GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
    20 MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP,
    MKT.PO_BOX
    21 ORDER BY PRIM_NAME
    22 /
    View wurde angelegt.
    DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
    PRIM_NAME
    Altenhagener
    Weg
    Alter
    Zollweg
    Am
    Knill
    Am
    Kroog
    Am
    Lehmberg
    Babenstieg
    Bargteheider
    Strasse
    Bekassinenau
    Blomeweg
    Boltenhagener
    Strasse
    Bublitzer
    Strasse
    Carlssonweg
    Farmsener
    Zoll
    Finkenfurth
    Grvmitzer
    Weg
    Grundherrenstrasse
    Herwardistrasse
    Hohenkamp
    Hoher
    Berg
    Im
    Wiesengrund
    Jacobshagener
    Weg
    Kohvvedstrasse
    Kvsliner
    Strasse
    Krohnsheide
    K|hlungsborner
    Strasse
    Nienhagener
    Strasse
    Pfefferstrasse
    Rahlstedter
    Stieg
    Rahlstedter
    Weg
    Raschweg
    R|genwalder
    Strasse
    Rummelsburger
    Strasse
    Sandkule
    Scharbeutzer
    Strasse
    Sierksdorfer
    Strasse
    Stargarder
    Strasse
    Thiessenweg
    Timmendorfer
    Stieg
    Timmendorfer
    Strasse
    Treptower
    Strasse
    Wolliner
    Strasse
    41 Zeilen ausgewdhlt.
    DEV>GRANT SELECT ON REPORT_STREETINFO TO PWEIH;
    Benutzerzugriff (Grant) wurde erteilt.
    DEV>CREATE SYNONYM PWEIH.REPORT_STREETINFO FOR
    GEODIS.REPORT_STREETINFO;
    Synonym wurde angelegt.
    DEV>CONN PWEIH/PWEIH@DEVELOP
    Connect durchgef|hrt.
    DEV>DESC REPORT_STREETINFO;
    Name Null? Typ
    ID NOT NULL NUMBER(10)
    MKT_CODE VARCHAR2(10)
    PRIM_NAME VARCHAR2(40)
    MIN_FROMNRLE VARCHAR2(40)
    MAX_TONRLE NUMBER
    MIN_FROMNRRI VARCHAR2(40)
    MAX_TONRRI NUMBER
    MKT_NAME VARCHAR2(40)
    MKT_NAME2 VARCHAR2(40)
    MKT_STREET VARCHAR2(40)
    MKT_CITY VARCHAR2(40)
    MKT_ZIP VARCHAR2(9)
    MKT_POBOX VARCHAR2(40)
    DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
    SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108
    FEHLER in Zeile 1:
    ORA-03113: Unerwartetes \bertragungsende in Kommunikation
    DEV>SPOOL OFF;
    Regards,
    Amol.

  • SDO_RELATE and ORA-03113 error

    Hello,
    I am trying to use the SDO_RELATE function and I receive the following error:
    ERROR at line 1:
    ORA-03113: end-of-file on communication channel
    Using the following SQL
    SELECT ufi FROM ROADLINE A
    WHERE MDSYS.SDO_RELATE(
    A.GEOMETRY, mdsys.sdo_geometry( 2003,null,null,
    mdsys.sdo_elem_info_array(1,1003,3),
    mdsys.sdo_ordinate_array(132,-12,133,-11)),
    'mask=ANYINTERACT querytype=WINDOW') = 'TRUE'
    A similar search using the SDO_FILTER instead of SDO_RELATE and removing the mask=ANYINTERACT works ok.
    Can anyone suggest anything?
    Thanks in advance.
    Gunter

    Hi Gunter,
    It looks like there may be other issues. Can you post the version of Oracle you are using, and try debugging just a little bit more to try to narrow the problem down?
    This might help to determine which geometry the failure is occuring at:
    create table tt as select ufi,geometry
    from roadline where rownum < 1;
    declare
    ufi number ;
    window_geom mdsys.sdo_geometry := mdsys.sdo_geometry( 2003,null,null, mdsys.sdo_elem_info_array(1,1003,3),
    mdsys.sdo_ordinate_array(132,-12,133,-11));
    theGeom mdsys.sdo_geometry ;
    TYPE geomcursor is REF CURSOR ;
    aCursor geomcursor;
    relationship varchar2(30);
    begin
    open aCursor FOR 'SELECT ufi, geometry from roadline A WHERE SDO_filter( A.GEOMETRY,:WINDOW_GEOM, ''querytype=WINDOW'') = ''TRUE''' using window_geom;
    loop
    FETCH aCursor INTO ufi, theGeom ;
    EXIT WHEN aCursor%NOTFOUND ;
    execute immediate 'insert into tt values (:ufi,:theGeom)'
    using ufi,theGeom;
    execute immediate 'commit';
    relationship := sdo_geom.relate(theGeom,'anyinteract',window_geom,0.05);
    end loop;
    end;
    If you see the same error, hopefully it will be determining the relationship between the last geometry in the table tt and the query window. If you can check this, and if this is the case post the geometry that is failing as well as the contents of user_sdo_geom_metadata for roadline that would be great.
    Dan

  • Sdo.intersection ... problems

    Hi all,
    I use this simple query:
    CREATE TABLE INTER2 AS
    SELECT SDO_GEOM.SDO_INTERSECTION(G1.SHAPE, G2.SHAPE, 0.005) SHAPE
    FROM RAIL G1, ROADS G2;
    to find the intersections between these two layers. The first layer (rail) contains 47 lines and the second one (roads) 78 lines.
    The new table that is constructed by running this query has 3666 rows (I think that this is because 78x47=3666) but when I visualize the layer in the spatial in the spatial index advisor I can see that only 40 points (intersections) exists.
    So, I suppose that this query checks every possible pair from the two layers and creates a row which either has a point (intersection) in the shape column or has null value in this column.
    My problem is that this layer cannot be inserted into ARCINFO (throught ARCSDE) because of its structure (every row must have a shape - geometry).
    Can anyone tell me how can I perform this query and have as a result ONLY the rows with the points (intersections of the two layers)so I can visualize it in ARCINFO?
    Thanks in advance

    Hello John:
    Seems like you are missing something from your query. I think it would help eliminate those records that do not return a SHAPE by using SDO_RELATE in your where clause. The query would look something like this:
    CREATE TABLE INTER2 AS
    SELECT SDO_GEOM.SDO_INTERSECTION(G1.SHAPE, G2.SHAPE, 0.005) SHAPE
    FROM RAIL G1, ROADS G2
    WHERE
    MDSYS.SDO_RELATE(G1.SHAPE, G2.SHAPE, 'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
    BUT - you may have to "trick" ArcSDE into recognizing the table (or should I say "feature class"). You may have to use an ArcSDE command to create the feature class, then go into SQL and drop the table. This has the effect of putting the correct metadata into the SDE schema tables, such as LAYERS and SPATIAL_REFERENCES. When you drop the table using SQL, the metadata will remain.
    Then, use the CREATE TABLE... to create and populate the "feature class". Be sure to create a spatial index - we have found that you do not have to use the same name for the index as the one created by ArcSDE when you did the ArcSDE command to create the "feature class".
    This trickery is necesarry because ArcSDE really prefers that EVERYTHING is created and populated via ArcSDE commands or ArcCatalog, but there are ways to "fool" the ESRI software.
    Let me know if this helps.
    R Clement
    Alaska DNR

  • Geomtry to mdsys.sdo_geometry

    Hi, i'm a newbie of Oracle Spatial, i'm working with sdoapi, i need to convert
    geometries encoded with GML into valid geometries encoded in msdsys.sdo_geometry
    to perform query throug SQL over other geoemtries stored into a table.
    For example, if i've a box geometry in GML like this:
    <gml:Box>
         <gml:coord>
              <gml:X>-103</gml:X>
              <gml:Y>31</gml:Y>
         </gml:coord>
         <gml:coord>
              <gml:X>-103.5</gml:X>
              <gml:Y>31.5</gml:Y>
         </gml:coord>
    </gml:Box>
    I would make a query like:
    SELECT a.geometry
    FROM My_Spatial_Table a
    WHERE mdsys.sdo_relate(a.geometry, mdsys.sdo_geometry (2003, null, null,mdsys.sdo_elem_info_array (1,1003,3),mdsys.sdo_ordinate_array (-103,31,-103.5,31.5)),'querytype=WINDOW layer_gtype=notpoint') = 'TRUE';
    I've look in sdoapi's samples that i can make an adapter from my
    GML (XML) to Oracle's geometry, now i would know if i can map
    this geometry into a mdsys.sdo_geometry form.
    For geometries like point, box, there's no problems, but for geometries
    like polygon, linestring, multipolygon i don't know how do this! :-(
    Any tips or documentation for my problem?
    Best Regards
    Luigi

    Are you positive that the data is only being saved
    with 6 places of precisions ?
    As far as I remember SQLPlus only displays up to 6
    decimal points, although there are more in the data.
    I remember a similar thread on this before where
    there was a Tip that suggested setting the SQLPlus
    number format highr in order to display the full
    coordinates.
    e.g. SET NUMFORMAT 9999999999999999.99999999999999999999999;
    Ro

  • HELP!! SDO_RELATE inside Oracle procedure - ORA-13207: incorrect use of the

    Hello,
    I need help !
    I have a problem with queries inside procedures/packages.
    When execute sql
    SQL> SELECT LOC_OBJ_ID
    2 FROM VORO_LOC X, LBS_OZ_AREAS OZ
    3 WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, 'MASK=ANYINTERACT') = 'TRUE'
    4 AND OZ.OZ_NAME='PTK' AND OZ.OZ_GROUP='GORCZEWSKA';
    LOC_OBJ_ID
    2211379
    i have results - it's OK
    The next sql is same, but with agregation
    SQL> SELECT COUNT(*) ILOSC
    2 FROM VORO_LOC X, LBS_OZ_AREAS OZ
    3 WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, 'MASK=ANYINTERACT') = 'TRUE'
    4 AND OZ.OZ_NAME='PTK' AND OZ.OZ_GROUP='GORCZEWSKA';
    ILOSC
    1
    it's OK
    But when i want use this SQL inside proedurees in store result in variable i have problem
    SQL> declare
    2 V_NUMBER_NEI_LOC number;
    3 begin
    4 SELECT COUNT(*) ILOSC
    5 INTO V_NUMBER_NEI_LOC
    6 FROM VORO_LOC X, LBS_OZ_AREAS OZ
    7 WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, 'MASK=ANYINTERACT') = 'TRUE'
    8 AND OZ.OZ_NAME='PTK' AND OZ.OZ_GROUP='GORCZEWSKA';
    9 end;
    10 /
    declare
    ORA-13207: incorrect use of the [SDO_RELATE] operator
    ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 259
    ORA-06512: at line 4
    ORA-06512: at line 4
    Please help!

    This might be some issue with SQL in PL/SQL. We will check into this.
    In the meantime, can you try the dynamic SQL to execute that
    sdo_relate query to see if it works?
    Here is the example with dynamic SQL:
    declare
    V_NUMBER_NEI_LOC number;
    begin
    EXECUTE IMMEDIATE
    ' SELECT COUNT(*) ILOSC ' ||
    ' FROM VORO_LOC X, LBS_OZ_AREAS OZ ' ||
    ' WHERE MDSYS.SDO_RELATE(X.SHAPE, OZ.GEOLOC, ' ||
    ' ''MASK=ANYINTERACT'') = ''TRUE'' ' ||
    ' AND OZ.OZ_NAME=''PTK'' AND OZ.OZ_GROUP=''GORCZEWSKA'' '
    INTO V_NUMBER_NEI_LOC;
    end;
    /

  • Splitting dataset into regions using sdo_relate

    Hi all,
    I am having difficulty subdividing my dataset into different regions. I have the spatial data of the city auckland and found the co-ordinates of the lower left and upper right limits of the data. What I want to do now is to break up this dataset into 9 individual regions and assign an ID for each region. I have been trying to use to following query with not much luck...
    select a.link_id from nz_testlinks_auck a where mdsys.sdo_relate(a.GEOM,
    mdsys.SDO_GEOMETRY (2003,null,null,mdsys.SDO_ELEM_INFO_ARRAY(1,1003,3),
    mdsys.SDO_ORDINATE_ARRAY(174.7083,-37.0141,174.7910,-36.9544)), 'mask=ANYINTERACT querytype=WINDOW')='TRUE';
    When i put the outputted data into a table and view the data i notice that the rectangle has selected a lot more data than what was actually defined in the query. I have been using the network data model editor and MapBuilder to check the data and the co-ordinates.
    And when i try to create another rectangle for another region next to the previous one like this...
    select a.link_id from nz_testlinks_auck a where mdsys.sdo_relate(a.GEOM,
    mdsys.SDO_GEOMETRY (2003,null,null,mdsys.SDO_ELEM_INFO_ARRAY(1,1003,3),
    mdsys.SDO_ORDINATE_ARRAY(174.7910,-37.0141,174.8736,-36.9544)), 'mask=ANYINTERACT querytype=WINDOW')='TRUE';
    it again selects a larger rectangle selecting about half the data from the previous rectangle selection as well.
    Please assist me to solve this problem.
    Look forward to your replies.
    Avinash

    Avinash,
    Do you have geometries that cross your rectangle boundary, like a long line, or a large polygon? Which rectangle would you expect such a line or polygon to appear in?
    Or are you saying that geometries that are completely disjoint from your rectangle are getting selected? If you think that's the case, try the sdo_geom.relate function with the 'determine' mask to verify the relationship between your rectangle and one of the unexpected geometries.
    http://download.oracle.com/docs/html/B14255_01/sdo_objgeom.htm#BGHCDIDG
    If you want to be sure that nothing gets selected twice by your rectangles the ANYINTERACT mask probably isn't a good choice. A mask of mask=INSIDE+COVEREDBY will be better, but you'll still have to decide what to do with stuff that crosses.
    Matt

  • Problems with geometries of type 0

    Hi All,
    We have a problem with Oracle Spatial (8.1.6 Object-relational) Functions and operators on data consisting both
    standard Oracle geometry types and elements of "unknown" type, wich the functions seem not to ignore, as the
    documentation says it is supposed to do.
    Below you can se examples with extent_of analysis of layers and sdo_relate queries. It seems the "unknown" type
    elements are read as geometries, and when an "unknown" is present following geometries are ignored. Have any of you
    seen this before or even better have a solution?
    Thanks
    -- Test with extent_of
    -- Create table for test geometries
    Drop table geom_test;
    create table geom_test
    (id number,
    GEOMETRY mdsys.sdo_geometry);
    -- Populate sdo_geom_metadata
    delete from user_sdo_geom_metadata
    where table_name='GEOM_TEST'
    and column_name='GEOMETRY';
    insert into user_sdo_geom_metadata
    values ('GEOM_TEST', 'GEOMETRY',
    MDSYS.SDO_DIM_ARRAY(
    MDSYS.SDO_DIM_ELEMENT('X', -380000000, 10, 1),
    MDSYS.SDO_DIM_ELEMENT('Y', 0, 380000000, 1)),
    null);
    -- Test with no "unknown" elements
    delete from geom_test;
    insert into geom_test (id,geometry)
    values(148855,
    mdsys.sdo_geometry
    (1, null, null,
    mdsys.sdo_elem_info_array(1,1,1),
    mdsys.sdo_ordinate_array(-253423935,216615534))
    Select mdsys.sdo_tune.extent_of('GEOM_TEST', 'GEOMETRY') from dual;
    -- Test with one "unknown" elements
    delete from geom_test;
    insert into geom_test (id,geometry)
    values(148855,
    mdsys.geometry
    (2004, null, null,
    mdsys.sdo_elem_info_array
    (1,0,6000,
    4,1,1),
    mdsys.sdo_ordinate_array
    (.956304,.292373,0,
    -253423935,216615534))
    Select mdsys.sdo_tune.extent_of('GEOM_TEST', 'GEOMETRY') from dual;
    -- Test with two "unknown" elements
    delete from geom_test;
    insert into geom_test (id,geometry)
    values(148855,
    mdsys.geometry
    (2004, null, null,
    mdsys.sdo_elem_info_array
    (1,0,6000,
    4,1,1,
    6,0,6000,
    9,1,1),
    mdsys.sdo_ordinate_array
    (.956304,.292373,0,
    -253423935,216615534,
    .956304,.292373,0,
    -254019015, 216442514))
    select mdsys.sdo_tune.extent_of('GEOM_TEST', 'GEOMETRY') from dual;
    -- sdo_relate test
    -- Create table for test geometries
    Drop table geom_test2;
    create table geom_test2
    (id number,
    GEOMETRY mdsys.sdo_geometry);
    -- Populate sdo_geom_metadata
    delete from user_sdo_geom_metadata
    where table_name='GEOM_TEST2'
    and column_name='GEOMETRY';
    insert into user_sdo_geom_metadata
    values ('GEOM_TEST2', 'GEOMETRY',
    MDSYS.SDO_DIM_ARRAY(
    MDSYS.SDO_DIM_ELEMENT('X', -380000000, 10, 1),
    MDSYS.SDO_DIM_ELEMENT('Y', 0, 380000000, 1)),
    null);
    -- Populate dataset
    delete from geom_test2;
    insert into geom_test2 (id,geometry)
    values(1,
    mdsys.sdo_geometry
    (1, null, null,
    mdsys.sdo_elem_info_array(1,1,1),
    mdsys.sdo_ordinate_array(-253423935,216615534))
    insert into geom_test2 (id,geometry)
    values(2,
    mdsys.sdo_geometry
    (2004, null, null,
    mdsys.sdo_elem_info_array
    (1,0,6000,
    4,1,1),
    mdsys.sdo_ordinate_array
    (.956304,.292373,0,
    -253423935,216615534))
    insert into geom_test2 (id,geometry)
    values(3,
    mdsys.sdo_geometry
    (2004, null, null,
    mdsys.sdo_elem_info_array
    (1,0,6000,
    4,1,1,
    6,0,6000,
    9,1,1),
    mdsys.sdo_ordinate_array
    (.956304,.292373,0,
    -253423935,216615534,
    .956304,.292373,0,
    -254019015, 216442514))
    select mdsys.sdo_tune.extent_of('GEOM_TEST2', 'GEOMETRY') from dual;
    drop index g_test2_spatidx;
    create index g_test2_spatidx on geom_test2(GEOMETRY)
    indextype is mdsys.spatial_index parameters
    ('sdo_level=4, sdo_commit_interval=1000, tablespace=indx');
    -- Query by expected coordinates
    select id
    from geom_test2
    where mdsys.sdo_relate
    (geometry,
    mdsys.sdo_geometry
    (3,null,null,
    mdsys.sdo_elem_info_array(1,3,3),
    mdsys.sdo_ordinate_array(-250000000,210000000,-260000000,220000000)),
    'mask=ANYINTERACT')='TRUE';
    --Query by "unknown" type values
    select id
    from geom_test2
    where mdsys.sdo_relate
    (geometry,
    mdsys.sdo_geometry
    (3,null,null,
    mdsys.sdo_elem_info_array(1,3,3),
    mdsys.sdo_ordinate_array(0,0,1,1)),
    'mask=ANYINTERACT')='TRUE';
    null

    Hi,
    This is a bug in the Oracle Spatial object model. A workaround for now is to
    declare you etype 0's at the end of your ordinate array.
    Correct expected behavior is for Oracle Spatial is for any non-zero SDO_GTYPE,
    ignore all zero ETYPES.
    We will try to get a fix into 8.1.7, and definitely into 8.2. Hope this helps. Thanks.
    Dan
    null

  • SDO_FILTER and SDO_RELATE combined in the same query

    Is it possible to combine these two operations?
    I have a query that ideally should use SDO_RELATE for polygon data (some 25 million records). However it takes too long to run.
    For curiosity's sake I tried using SDO_FILTER and again this takes hours. Again for curiosity's sake I combined the two and records are returned in about 2 mins. Please see the query below (to simplify matters I have used point data).
    SELECT
    FROM
    table t
    WHERE
    MDSYS.SDO_RELATE(
    t.geometry,
    MDSYS.SDO_GEOMETRY( 2001,
    null,
    MDSYS.SDO_POINT_TYPE( 501900, 308000, null ),
    null,
    null
    'mask=anyinteract querytype=WINDOW'
    ) = 'TRUE'
    AND MDSYS.SDO_FILTER(
    t.geometry,
    MDSYS.SDO_GEOMETRY( 2001,
    null,
    MDSYS.SDO_POINT_TYPE( 501900, 308000, null ),
    null,
    null
    'mask=anyinteract querytype=WINDOW'
    ) = 'TRUE'
    As I see it, in this case SDO_FILTER is doing the primary filtering part. SDO_RELATE is doing primary filtering again followed by secondary filtering the resulting data which is why it is quicker. The data does appear to be correct.
    Now am I barking up the wrong tree? Whether I am or not, why is this combination faster than individual use? I would appreciate any thoughts on this please.
    Cheers guys
    James

    something else is going on, although without seeing the real query it is hard to know.
    SDO_RELATE is a supoerset of SDO_FILTER. With SDO_FILTER and index query is done, with SDO_RELATE an index query is done, then the relate is done on the geometries returned by the filter query.
    What kind of index are you using?
    What version of spatial are you using?
    Can you post the query window?
    Are your geometries valid?

Maybe you are looking for