SDO_3GL

Hello,
We are using Oracle Spatial and MapGuide.
Since a few days, we are encountered the following errors and we don't know the workflow behind:
An exception occurred in FDO component.
ORA-29925: cannot execute MDSYS.SDO_3GL.RELATE
ORA-21780: Maximum number of object durations exceeded.
An exception occurred in FDO component.
ORA-29900: operator binding does not exist
ORA-21780: Maximum number of object durations exceeded.
Have you already seen this and have you an idea what is the problem?
Thanks in advance.
Damien.

I haven't seen that error before. I suspect that MDSYS.SDO_3GL.RELATE is called from SDO_GEOM.RELATE, but I'm not 100% sure. I'm not sure why FDO would be calling SDO_GEOM.RELATE. I'd expect it to use SDO_RELATE, but not SDO_GEOM.RELATE.
Anyway, I'd suggest you trace the FDO session to try to get the exact SQL it is running. Then try to run that in SQL*Plus to reproduce it. If you can reproduce in SQL*Plus and take FDO out of the equation, then you'll have a much better chance of finding the problem.
Run a 10046 level 4 trace to get the bind variables too.
See: http://psoug.org/reference/trace_tkprof.html
Also, ensure the geometries you're querying are valid. Run sdo_geom.validate_geometry_with_context to check that.
The GeoRaptor (http://sourceforge.net/projects/georaptor/) plugin for SQLDeveloper is very useful for validating data. You can validate the data using its interface and then use it to zoom to the the exact point of the error.
John

Similar Messages

SDO_3GL error

Hi,
I'm using Oracle spatial (Oracle Database 10g Release 10.2.0.4.0 - 64bit Production) and GeoServer for a mapping application. GeoServer makes the following request as part of its geom boundary calculations:
select sdo_aggr_mbr(geom) from table;
but it's failing with the error:
ORA-04063: package body "MDSYS.SDO_3GL" has errors
ORA-06508: PL/SQL: could not find program unit being called: "MDSYS.SDO_3GL"
ORA-06512: at "MDSYS.SDO_GEOM", line 3398
ORA-06512: at "MDSYS.SDO_GEOM", line 3507
ORA-06512: at "MDSYS.SDOAGGR", line 41
ORA-06512: at "MDSYS.AGGRMBR", line 14
I get the same error even if I just run the select in an Oracle command window.
Does anyone understand the problem here or know of a fix?
Any help appreciated,
Dave

Did you included the interMedia Component or the Spatial component during the creation of your database? If so, are they valid? Check the results of this query, they should show either SDO/Spatial or ORDIM/interMedia as installed and VALID:
col comp_name format a35
col comp_id format a15
select comp_id, comp_name, status from dba_registry;
COMP_ID COMP_NAME STATUS
APEX Oracle Application Express VALID
CONTEXT Oracle Text VALID
EM Oracle Enterprise Manager VALID
ORDIM Oracle interMedia VALID
XDB Oracle XML Database VALID
EXF Oracle Expression Filter VALID
RUL Oracle Rules Manager VALID
OWM Oracle Workspace Manager VALID
CATALOG Oracle Database Catalog Views VALID
CATPROC Oracle Database Packages and Types VALID
JAVAVM JServer JAVA Virtual Machine VALID
XML Oracle XDK VALID
CATJAVA Oracle Database Java Packages VALID
13 rows selected.
Cheers,
Tino

Rebuilding spatial indexing fail after patch 9.2.0.8.0

Hi!
I did apply patchset, and after i did try to
set NLS_LANG=American_America.CL8MSWIN1251
sqlplusw ......
SQL> alter index XXXX.YYYYYYYY_g_idx rebuild; -- <- Russian name
alter index XXXX.YYYYYYYY_g_idx rebuild
ERROR at line 1:
ORA-29858: error occurred in the execution of ODCIINDEXALTER routine
ORA-29400: data cartridge error
¡a¤
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13205: internal error while parsing spatial parameters
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 259
ORA-06512: at line 1
As you can see, rebuilding was failed.
Before upgrade all did work fine.
If i will create table WITH_ENGLISH_NAME as SELECT from my table all working fine ;(
I DID apply all *.sql from patchset.
Any idea, gurus ?
P.S.
I did use script from metalink
verify_spatial_installation.sql :
SQL>
SQL> prompt Verify version and status
Verify version and status
SQL> select COMP_NAME, SCHEMA, VERSION, STATUS
2 from dba_registry where comp_id='SDO';
COMP_NAME SCHEMA VERSION STATUS
Spatial MDSYS 9.2.0.8.0 VALID
SQL>
SQL> prompt Number of objects
Number of objects
SQL> select count(*)
2 from dba_objects where owner='MDSYS';
COUNT(*)
250
SQL>
SQL> prompt Summary count of objects
Summary count of objects
SQL> select object_type, count(*)
2 from dba_objects where owner='MDSYS'
3 group by object_type;
OBJECT_TYPE COUNT(*)
FUNCTION 47
INDEX 17
INDEXTYPE 2
LIBRARY 12
LOB 12
OPERATOR 14
PACKAGE 25
PACKAGE BODY 25
SEQUENCE 2
TABLE 18
TRIGGER 7
TYPE 34
TYPE BODY 10
VIEW 25
14 rows selected.
SQL>
SQL> prompt Any invalid objects ?
Any invalid objects ?
SQL> select object_name, object_type, status
2 from dba_objects
3 where owner='MDSYS'
4 and status <> 'VALID'
5 order by object_name;
OBJECT_NAME OBJECT_TYPE STATUS
SDO_MIGRATE PACKAGE BODY INVALID
SQL>
SQL> prompt List of all spatial objects ordered by object_name
List of all spatial objects ordered by object_name
SQL> select object_name, object_type, status
2 from dba_objects where owner='MDSYS'
3 order by object_name;
OBJECT_NAME OBJECT_TYPE STATUS
AGGRCENTROID TYPE VALID
AGGRCENTROID TYPE BODY VALID
AGGRCONVEXHULL TYPE VALID
AGGRCONVEXHULL TYPE BODY VALID
AGGRLRSCONCAT TYPE VALID
AGGRLRSCONCAT TYPE BODY VALID
AGGRLRSCONCAT3D TYPE VALID
AGGRLRSCONCAT3D TYPE BODY VALID
AGGRMBR TYPE VALID
AGGRMBR TYPE BODY VALID
AGGRUNION TYPE VALID
AGGRUNION TYPE BODY VALID
ALL_GEOMETRY_COLUMNS VIEW VALID
ALL_SDO_GEOM_METADATA VIEW VALID
ALL_SDO_INDEX_INFO VIEW VALID
ALL_SDO_INDEX_METADATA VIEW VALID
ALL_SDO_LRS_METADATA VIEW VALID
ALL_SDO_MAPS VIEW VALID
ALL_SDO_STYLES VIEW VALID
ALL_SDO_THEMES VIEW VALID
CS_SRS TABLE VALID
DBA_GEOMETRY_COLUMNS VIEW VALID
DBA_SDO_INDEX_INFO VIEW VALID
DBA_SDO_INDEX_METADATA VIEW VALID
DBA_SDO_LRS_METADATA VIEW VALID
DBA_SDO_MAPS VIEW VALID
DBA_SDO_STYLES VIEW VALID
DBA_SDO_THEMES VIEW VALID
F81_INDEX_OBJECT TYPE VALID
F81_INDEX_OBJ_ARRAY TYPE VALID
F81_NT_IND_TYPE TYPE VALID
GEOCODER_HTTP PACKAGE VALID
GEOCODER_HTTP PACKAGE BODY VALID
GEOCODE_RESULT TYPE VALID
GEODETIC_SRIDS VIEW VALID
H81_INDEX_OBJECT TYPE VALID
H81_INDEX_OBJ_ARRAY TYPE VALID
H81_NT_IND_TYPE TYPE VALID
HHAND FUNCTION VALID
HHBYTELEN FUNCTION VALID
HHCBIT FUNCTION VALID
HHCELLBNDRY FUNCTION VALID
HHCELLSIZE FUNCTION VALID
HHCLDATE FUNCTION VALID
HHCOLLAPSE FUNCTION VALID
HHCOMMONCODE FUNCTION VALID
HHCOMPARE FUNCTION VALID
HHCOMPOSE FUNCTION VALID
HHDECODE FUNCTION VALID
HHDISTANCE FUNCTION VALID
HHENCODE FUNCTION VALID
HHENCODE_BYLEVEL FUNCTION VALID
HHGBIT FUNCTION VALID
HHGETCID FUNCTION VALID
HHGROUP FUNCTION VALID
HHGTBIT FUNCTION VALID
HHGTYPE FUNCTION VALID
HHIDLPART FUNCTION VALID
HHIDPART FUNCTION VALID
HHINCRLEV FUNCTION VALID
HHJLDATE FUNCTION VALID
HHLENGTH FUNCTION VALID
HHLEVELS FUNCTION VALID
HHMATCH FUNCTION VALID
HHMAXCODE FUNCTION VALID
HHNCOMPARE FUNCTION VALID
HHNDIM FUNCTION VALID
HHOR FUNCTION VALID
HHORDER FUNCTION VALID
HHPRECISION FUNCTION VALID
HHSBIT FUNCTION VALID
HHSETCID FUNCTION VALID
HHSTBIT FUNCTION VALID
HHSTYPE FUNCTION VALID
HHSUBDIVIDE FUNCTION VALID
HHSUBSTR FUNCTION VALID
HHXOR FUNCTION VALID
LOCATOR_WITHIN_DISTANCE OPERATOR VALID
MD PACKAGE VALID
MD PACKAGE BODY VALID
MD$RELATE TABLE VALID
MD1 PACKAGE VALID
MD1 PACKAGE BODY VALID
MD2 PACKAGE VALID
MD2 PACKAGE BODY VALID
MDERR PACKAGE VALID
MDERR PACKAGE BODY VALID
MDPRVT_IDX PACKAGE VALID
MDPRVT_IDX PACKAGE BODY VALID
MD_LRS PACKAGE VALID
MD_LRS PACKAGE BODY VALID
OGIS_GEOMETRY_COLUMNS TABLE VALID
OGIS_SPATIAL_REFERENCE_SYSTEMS TABLE VALID
ORDMD_AG_LIBS LIBRARY VALID
ORDMD_CS_LIBS LIBRARY VALID
ORDMD_IDX_LIBS LIBRARY VALID
ORDMD_LRS_LIBS LIBRARY VALID
ORDMD_MBR_LIBS LIBRARY VALID
ORDMD_MIG_LIBS LIBRARY VALID
ORDMD_PRIDX_LIBS LIBRARY VALID
ORDMD_REL_LIBS LIBRARY VALID
ORDMD_RTREE_LIBS LIBRARY VALID
ORDMD_UDT_LIBS LIBRARY VALID
ORDMD_UTL_LIBS LIBRARY VALID
ORDMD_WD_LIBS LIBRARY VALID
PK_SDO_MASK INDEX VALID
PK_SRID INDEX VALID
PRVT_IDX PACKAGE VALID
PRVT_IDX PACKAGE BODY VALID
RTREE_FILTER OPERATOR VALID
RTREE_IDX PACKAGE VALID
RTREE_IDX PACKAGE BODY VALID
RTREE_INDEX INDEXTYPE VALID
RTREE_INDEX_METHOD TYPE VALID
RTREE_INDEX_METHOD TYPE BODY VALID
RTREE_NN OPERATOR VALID
SAMPLE_SEQ SEQUENCE VALID
SDO PACKAGE VALID
SDO PACKAGE BODY VALID
SDOAGGR TYPE VALID
SDOAGGR TYPE BODY VALID
SDOAGGRTYPE TYPE VALID
SDO_3GL PACKAGE VALID
SDO_3GL PACKAGE BODY VALID
SDO_ADMIN PACKAGE VALID
SDO_ADMIN PACKAGE BODY VALID
SDO_AGGR_CENTROID FUNCTION VALID
SDO_AGGR_CONVEXHULL FUNCTION VALID
SDO_AGGR_LRS_CONCAT FUNCTION VALID
SDO_AGGR_LRS_CONCAT_3D FUNCTION VALID
SDO_AGGR_MBR FUNCTION VALID
SDO_AGGR_UNION FUNCTION VALID
SDO_ANGLE_UNITS TABLE VALID
SDO_AREA_UNITS TABLE VALID
SDO_CATALOG PACKAGE VALID
SDO_CATALOG PACKAGE BODY VALID
SDO_CONSTRUCT_DIM_ARRAY FUNCTION VALID
SDO_CS PACKAGE VALID
SDO_CS PACKAGE BODY VALID
SDO_DATUMS TABLE VALID
SDO_DIM_ARRAY TYPE VALID
SDO_DIM_ELEMENT TYPE VALID
SDO_DIST_UNITS TABLE VALID
SDO_DROP_USER TRIGGER VALID
SDO_ELEM_INFO_ARRAY TYPE VALID
SDO_ELLIPSOIDS TABLE VALID
SDO_FILTER OPERATOR VALID
SDO_GEOM PACKAGE VALID
SDO_GEOM PACKAGE BODY VALID
SDO_GEOMETRY TYPE VALID
SDO_GEOMETRY TYPE BODY VALID
SDO_GEOM_IDX INDEX VALID
SDO_GEOM_METADATA_TABLE TABLE VALID
SDO_GEOM_TRIG_DEL1 TRIGGER VALID
SDO_GEOM_TRIG_INS1 TRIGGER VALID
SDO_GEOM_TRIG_UPD1 TRIGGER VALID
SDO_IDX PACKAGE VALID
SDO_IDX PACKAGE BODY VALID
SDO_IDX_MDATA_IDX INDEX VALID
SDO_IDX_TAB_SEQUENCE SEQUENCE VALID
SDO_INDEX_METADATA_TABLE TABLE VALID
SDO_INDEX_METHOD_9I TYPE VALID
SDO_INDEX_METHOD_9I TYPE BODY VALID
SDO_INT2_FILTER OPERATOR VALID
SDO_INT2_RELATE OPERATOR VALID
SDO_INT_FILTER OPERATOR VALID
SDO_INT_RELATE OPERATOR VALID
SDO_LRS PACKAGE VALID
SDO_LRS PACKAGE BODY VALID
SDO_LRS_METADATA_TABLE TABLE VALID
SDO_LRS_META_IDX INDEX VALID
SDO_LRS_TRIG_DEL TRIGGER VALID
SDO_LRS_TRIG_INS TRIGGER VALID
SDO_LRS_TRIG_UPD TRIGGER VALID
SDO_MAPS_TABLE TABLE VALID
SDO_MBR TYPE VALID
SDO_META PACKAGE VALID
SDO_META PACKAGE BODY VALID
SDO_MIGRATE PACKAGE VALID
SDO_MIGRATE PACKAGE BODY INVALID
SDO_NN OPERATOR VALID
SDO_NN_DISTANCE OPERATOR VALID
SDO_NUMTAB TYPE VALID
SDO_ORDINATE_ARRAY TYPE VALID
SDO_POINT_TYPE TYPE VALID
SDO_PRIDX PACKAGE VALID
SDO_PRIDX PACKAGE BODY VALID
SDO_PROJECTIONS TABLE VALID
SDO_RELATE OPERATOR VALID
SDO_RELATEMASK_TABLE VIEW VALID
SDO_RELATE_MASK PACKAGE VALID
SDO_RELATE_MASK PACKAGE BODY VALID
SDO_RID_ARRAY TYPE VALID
SDO_RTREE_ADMIN PACKAGE VALID
SDO_RTREE_ADMIN PACKAGE BODY VALID
SDO_RTREE_FILTER OPERATOR VALID
SDO_RTREE_RELATE OPERATOR VALID
SDO_STAT TYPE VALID
SDO_STATTAB TYPE VALID
SDO_STYLES_TABLE TABLE VALID
SDO_THEMES_IDX INDEX VALID
SDO_THEMES_TABLE TABLE VALID
SDO_TUNE PACKAGE VALID
SDO_TUNE PACKAGE BODY VALID
SDO_UTIL PACKAGE VALID
SDO_UTIL PACKAGE BODY VALID
SDO_VERSION FUNCTION VALID
SDO_VPOINT_TYPE TYPE VALID
SDO_WITHIN_DISTANCE OPERATOR VALID
SPATIAL_INDEX INDEXTYPE VALID
SYS_C001565 INDEX VALID
SYS_C001571 INDEX VALID
SYS_C001706 INDEX VALID
SYS_LOB0000027008C00040$$ LOB VALID
SYS_LOB0000027008C00041$$ LOB VALID
SYS_LOB0000027053C00012$$ LOB VALID
SYS_LOB0000027053C00013$$ LOB VALID
SYS_LOB0000027209C00004$$ LOB VALID
SYS_LOB0000027216C00005$$ LOB VALID
SYS_LOB0000027216C00006$$ LOB VALID
SYS_LOB0000027216C00013$$ LOB VALID
SYS_LOB0000027216C00014$$ LOB VALID
SYS_LOB0000027229C00006$$ LOB VALID
SYS_LOB0000028651C00012$$ LOB VALID
SYS_LOB0000028651C00013$$ LOB VALID
TRANSFORM_MAP PACKAGE VALID
TRANSFORM_MAP PACKAGE BODY VALID
UNIQUE_ANGLE_UNITS INDEX VALID
UNIQUE_AREA_UNITS INDEX VALID
UNIQUE_DIST_UNITS INDEX VALID
UNIQUE_LAYERS INDEX VALID
UNIQUE_MAPS INDEX VALID
UNIQUE_STYLES INDEX VALID
UNIQUE_TABLES INDEX VALID
UNIQUE_THEMES INDEX VALID
USER_CS_SRS TABLE VALID
USER_GEOMETRY_COLUMNS VIEW VALID
USER_SDO_GEOM_METADATA VIEW VALID
USER_SDO_INDEX_INFO VIEW VALID
USER_SDO_INDEX_METADATA VIEW VALID
USER_SDO_LRS_METADATA VIEW VALID
USER_SDO_MAPS VIEW VALID
USER_SDO_STYLES VIEW VALID
USER_SDO_THEMES VIEW VALID
USER_TRANSFORM_MAP TABLE VALID
V81_INDEX_OBJECT TYPE VALID
V81_INDEX_OBJ_ARRAY TYPE VALID
V81_NT_IND_TYPE TYPE VALID
VERTEX_SET_TYPE TYPE VALID
VERTEX_TYPE TYPE VALID
250 rows selected.
SQL>
SQL> spool off

Sir! No Sir! :)
I will try to explain.
If I do have table with russian letter, than creating index creation will fail, no matter name of index :(
But if I will prepare copy of my table with english name (including meta-data) - index creations is succesfull.

SPATIAL_RELATE DOES NOT WORK ON VIEW ?

Hi
The following statement does not work correct - it claims that there are no spatial indexes. The view is very complex (including union all). The view is put into user_sdo_geom_metadata.
Whats wrong ?
SELECT GEOM FROM MISE_A_JOURPFP3 WHERE FID=70491;
This returns
GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1005, 11, 1, 2, 1, 3, 2, 2, 7, 2, 1, 13, 2, 2, 17, 2, 1, 27, 2, 2, 31, 2, 1, 103, 2, 2, 107, 2, 1, 111, 2, 2, 115, 2, 1, 119, 2005, 10, 119, 2, 1, 125, 2, 2, 129, 2, 1, 131, 2, 2, 135, 2, 1, 163, 2, 2, 167, 2, 1, 169, 2, 2, 173, 2, 1, 177, 2, 2, 183, 2005, 3, 183, 2, 1, 191, 2, 2, 195, 2, 1), SDO_ORDINATE_ARRAY(575526,016, 184396,522, 575522,171, 184370,728, 575522,191, 184370,674, 575522,247, 184370,662, 575678,571, 184417,747, 575774,588, 184446,858, 575869,409, 184475,451, 575869,442, 184475,474, 575869,452, 184475,513, 575866,134, 184514,875, 575863,237, 184550,71, 575863,237, 184550,712, 575863,236, 184550,715, 575855,625, 184597,93, 575855,603, 184597,968, 575855,56, 184597,98, 575817,694, 184594,079, 575817,693, 184594,079, 575779,647, 184589,561, 575779,644, 184589,56, 575779,642, 184589,56, 575760,713, 184585,669, 575760,711, 184585,668, 575760,709, 184585,668, 575742,776, 184580,811, 575742,774, 184580,81, 575711,463, 184571,042, 575681,849, 1845
61,823, 575681,848, 184561,823, 575653,299, 184552,366, 575653,299, 184552,366, 575624,364, 184542,482, 575624,362, 184542,481, 575608,52, 184536,628, 575608,518, 184536,627, 575608,516, 184536,626, 575594,546, 184530,149, 575594,544, 184530,149, 575594,542, 184530,148, 575580,796, 184522,588, 575580,794, 184522,586, 575580,792, 184522,585, 575568,694, 184514,569, 575568,692, 184514,568, 575568,69, 184514,566, 575557,75, 184506,036, 575557,748, 184506,035, 575557,747, 184506,033, 575547,93, 184497,069, 575547,928, 184497,068, 575547,927, 184497,067, 575540,772, 184489,753, 575540,755, 184489,711, 575540,773, 184489,668, 575541,753, 184488,693, 575539,485, 184486,399, 575539,474, 184486,384, 575539,469, 184486,366, 575526,016, 184396,522, 575456,142, 184567,991, 575581,098, 184603,851, 575663,938, 184627,624, 575753,329, 184653,277, 575753,375, 184653,271, 575753,404, 184653,236, 575770,26, 184594,501, 575770,254, 184594,454, 575770,216, 184594,426, 575759,18, 184591,871, 575741,055, 184586,909, 575709,707, 18
4577,166, 575680,93, 184568,419, 575679,878, 184568,099, 575651,254, 184558,428, 575622,3, 184548,627, 575606,091, 184542,531, 575599,557, 184539,564, 575591,605, 184535,955, 575577,419, 184528,038, 575564,828, 184519,711, 575553,658, 184510,986, 575543,325, 184501,439, 575543,313, 184501,43, 575543,299, 184501,425, 575479,972, 184484,946, 575479,927, 184484,952, 575479,899, 184484,987, 575465,302, 184535,853, 575456,101, 184567,916, 575456,107, 184567,962, 575456,142, 184567,991, 575490,379, 184553,269, 575487,99, 184561,46, 575516,025, 184569,447, 575519,283, 184558,023, 575495,012, 184551,068, 575494,977, 184551,039, 575494,971, 184550,993, 575495,03, 184550,79, 575494,928, 184550,761, 575490,379, 184553,269))
This select fails:
Select /*+ ordered */ A.fid from MISE_A_JOURPFP3 A, MISE_A_JOURPFP3 B where B.FID= 70491 AND mdsys.sdo_relate(B.geom, A.GEOM ,'mask = anyinteract querytype=window') = 'TRUE' ;
output:
Select /*+ ordered */ A.fid from MISE_A_JOURPFP3 A, MISE_A_JOURPFP3 B where B.FID= 70491 AND mdsys.sdo_relate(B.geom, A.GEOM ,'mask = anyinteract querytype=window') = 'TRUE'
FEHLER in Zeile 1:
ORA-13226: Oberfläche ohne räumlicher Index nicht unterstützt
ORA-06512: in "MDSYS.MD", Zeile 1723
ORA-06512: in "MDSYS.MDERR", Zeile 8
ORA-06512: in "MDSYS.SDO_3GL", Zeile 58
DB is 9.2.0.5 on Windows XP

This might be related to bug 3561140 - we are working with the appropriate folks in Oracle to try to resolve it. If you can post your view definition then we can try to ensure this is fixed at the same time (a small test case would be appreciated).

Validate_layer_with_context error

BEGIN sdo_geom.validate_layer_with_context('COPPER', 'GEOM', 'VAL_RESULTS', 100); END;
ERROR at line 1:
ORA-04030: out of process memory when trying to allocate 16408 bytes (koh-kghu sessi,mdvgrr elmbr)
ORA-06512: at "MDSYS.SDO_3GL", line 439
ORA-06512: at "MDSYS.SDO_GEOM", line 3848
ORA-06512: at line 1
Is this a known bug in Oracle 9.2.0.2? Will I need to got to 9.2.0.3 to get this to work?
R Clement
Alaska DNR

Hi Richard,
This is reported in bug 2698729, and I don't see any info about it being fixed as of today.
Sorry,
Dan

Using Mapviewer with Oracle Locator

We're currently using Oracle Locator as a datasource for Mapviewer 10g and we're running into a slight problem when loading simple points from a table. We have the table containing these ponits added to the USER_SDO_GEOM_METADATA table and the spatial index is created on the specific column with the SDO_GEOMETRY type. When the map loads up the following error is generated when a dynamic jdbc query is run:
MAPVIEWER-06009: Error processing an FOI request.
Root cause:FOIServlet:ORA-29900: operator binding does not exist
ORA-06540: PL/SQL: compilation error
ORA-06553: PLS-907: cannot load library unit MDSYS.SDO_3GL (referenced by MDSYS.SDO_FILTER)
I've looked in the database for the MDSYS.SDO_3GL object and it's definitely there, so I'm a little lost on what could be causing this. I thought perhaps that our user schema may not have execute privileges associated with that specific procedure, but I believe the entire point of MDSYS is that it's available to any user on the database.
Any help with this would be greatly appreciated.
Edited by: user1175540 on Oct 29, 2010 7:10 PM

We're currently using the javascript api for oracle maps (using the matching javascript file, oraclemaps.js, that came directly from the mapviewer application download). All that I'm calling is a single table and then getting some hidden info columns as well off of it too. I've tried this on a different schema and database that's also only running Locator and the query runs just fine with the points on the map displaying as intended.
Here's the current theme request that I'm submitting:
<theme name= 'lowerTheme' >
<jdbc_query spatial_column='GEOMETRY' jdbc_srid='8307' render_style= 'V.AVCD_BUILD' datasource='mvdemo' >
select * from build where subtype in('ABC','123','DEF')
<hidden_info>
<field column='SUBTYPE' name='Type'/>
<field column='NAME' name='Name'/>
<field column='ADDR' name='Address'/>
<field column='CITY' name='City'/>
<field column='STATE' name='State'/>
<field column='ZIP_CODE' name='ZIP Code'/>
</hidden_info>
</jdbc_query>
<rendering>
<style name='V.AVCD_BUILD' value_columns='SUBTYPE'/>
</rendering>
</theme>
Within the actual function adding that theme to the 'mapview' variable I'm creating a new MVThemeBasedFOI object using the name 'lowerTheme' and the above definition for the second parameter in the constructor.
Is there a listing of procedures on the MDSYS schema that I should check to make sure they're valid for spatial queries to work?
Thanks in advance for the help.

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

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.

Slow spatial query in oracle 11.2.0.3 [WAS 10.2.0.4 to 11.2.0.1 upgrade = SLOW sdo_geometry return]

Hi,
I've found a discussion ended last year.
I've Oracle 11.2.0.3 with the same problem: some query are very slow (in the Excecution plan I've found "PX COORDINATOR")
Others installation of Oracle 11.2.0.3 haven't same problem: in the excecution plan found "DOMAIN INDEX".
I 've solved using statement "ALTER TABLE table_name NOPARALLEL;" which disable parallel feature in the table
Can anyone tell me if it's a good (bad) solution ? thank you
Bye
Gabriele

Gabriele,
As indicated in the original post - the following work-around might work for you for bug 9743250. What this does is essentially force the optimizer to ALWAYS use the spatial index. That is usually good - unless the query is actually more efficient not using the index, such as when it is much cheaper to just to a FTS. Anyhow this is what you can do from 11.2.0.1 to 11.2.0.3 - fixed in 11.2.0.4 and 12.1.0.1:
connect /as sysdba
alter session set current_schema=MDSYS;
DISASSOCIATE STATISTICS FROM INDEXTYPES spatial_index FORCE
DISASSOCIATE STATISTICS FROM PACKAGES sdo_3gl FORCE;
DISASSOCIATE STATISTICS FROM PACKAGES prvt_idx FORCE;
Bryan

Basic query in Oracle Spatial

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 book, 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?
(P.S.: I couldn't find a specific board for Oracle Spatial, hence put this question here--if there's a better place for this question, then, admins, of course, feel free to move the thread to the appropriate spot)

Hi,
The SPATIAL forum is here : {forum:id=76}

ORA-13050:unable to construct spatial object in using SDO_INTERSECTION

Hi Specialists,
I am using Oracle Spatial and getting the ORA-13050 error when using the SDO_Intersection procedure. Below are the details of this.
Objective: To find the addresses whose boundary lie within a user defined polygon.
Input: List of coordinates for the user defined poygon.
Query I am using: SELECT SDO_GEOM.SDO_INTERSECTION (add.boundary, SDO_GEOMETRY(2003,8311,NULL, SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY( 149.986507,-36.727242,149.985898,-36.726819,149.986756,-36.726512,149.987288,-36.726803,149.986507,-36.727242)), 0.000001)
FROM address add
WHERE add.id = '254378298'
Error Received:
ORA-13050: unable to construct spatial object
ORA-06512: at "MDSYS.SDO_3GL", line 715
ORA-06512: at "MDSYS.SDO_3GL", line 745
ORA-06512: at "MDSYS.SDO_GEOM", line 3016
ORA-06512: at "MDSYS.SDO_GEOM", line 3065
Please can any one help me in this issue very urgent.
Thanks,
Ashish

Hi All,
The problem has been resolved by transforming the user defined polygon coordinates into the database specific coordinate system.
Thanks

How to use SDO_GEOM.WITHIN_DISTANCE with a geodetic CRS and degree as unit?

Hi,
I am trying to use SDO_GEOM.WITHIN_DISTANCE on geodetic data, but I don't want to use meter as unit for the tolerance. I thought I simply can set the unit to 'Degree', but this does not work:
select SDO_GEOM.WITHIN_DISTANCE(
MDSYS.SDO_GEOMETRY('POINT(0 0)', 4326),
+11,+
MDSYS.SDO_GEOMETRY('POINT(0 10)', 4326),
+0.00000000005,+
+'unit=Degree') from dual;+
ORA-13291: conversion error between the specified unit and standard unit
ORA-06512: at "MDSYS.SDO_3GL", line 985
ORA-06512: at "MDSYS.SDO_GEOM", line 1034
ORA-06512: at "MDSYS.SDO_GEOM", line 1049
ORA-06512: at line 1
+13291. 00000 - "conversion error between the specified unit and standard unit"+
*Cause: Cannot convert the specified unit from/to standard unit+
for linear distance, angle, or area.
*Action: Check the unit specification and respecify it.+
What am I doing wrong?
Update: How is the specified unit used? Is WITHIN_DISTANCE trying to convert my 10 degree into a meter value? Because then I would understand why it is not working.
Thanks,
Tobias
Edited by: tsauerwein on May 19, 2010 11:23 PM

HI Tobias,
"Degree" is an angle unit, not a distance unit of measurement. For within_distance operations you must use a valid distance unit, which are defined in sdo_dist_units view.
if you indeed want to represent a distance unit in "decimal degree", you may try to define one for that by yourself.
regards
Jeffrey

Sdo_filter fail when query against a spatial view in different schema

We have a table with X,Y coordinates and would like to run spatial query against it. We do not want to change the table structure, so we opt to use a function based index. USER_SDO_GEOM_METADATA is updated and index is built. Then we created a view with spatial column from the table. Everything works fine with the user who owns the table and view.
When we try to run a spatial query against the view from a different user, it failed with error. However, if we substitute the select from my_view* with the actual SQL statement that created the view, it works. So it looks like Oracle refuse to acknowledge the spatial index if accessed via view. Here is some simplified scripts:
--- connect as USER1.
--update meta data
INSERT INTO USER_SDO_GEOM_METADATA ( TABLE_NAME, COLUMN_NAME, DIMINFO, SRID ) VALUES
('LOCATIONS', 'MDSYS.SDO_GEOMETRY(2001,2264,SDO_POINT_TYPE(NVL(X_COORD,0),NVL(Y_COORD,0),NULL),NULL,NULL)',
SDO_DIM_ARRAY( SDO_DIM_ELEMENT('X', 1300000, 1600000, 1), SDO_DIM_ELEMENT('Y', 400000, 700000, 1) ), 2264 );
--created index
CREATE INDEX LOCA_XYGEOM_IDX ON LOCATIONS
( SDO_GEOMETRY(2001,2264,SDO_POINT_TYPE(NVL(X_COORD,0),NVL(Y_COORD,0),NULL),NULL,NULL)
) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
--create view
CREATE VIEW USER1.MY_VIEW AS SELECT ID ,X_COORD,Y_COORD, SDO_GEOMETRY(2001,2264,SDO_POINT_TYPE(NVL(X_COORD,0),NVL(Y_COORD,0),NULL),NULL,NULL) SHAPE
FROM USER1.LOCATIONS WHERE X_COORD>0 AND Y_COORD>0;
-- run spatial query from view, works fine by user1 by failed on user2.
SELECT SHAPE FROM (
SELECT * FROM USER1.MY_VIEW
) a WHERE sdo_filter (shape, sdo_geometry ('POLYGON ((1447000 540000, 1453000 540000, 1453000 545000, 1447000 545000, 1447000 540000))', 2264), 'querytype=window') = 'TRUE';
-- run spatial query from table directly, simply replace the view with actual statements that created the view. works fine by user1 AND user2.
SELECT SHAPE FROM (
SELECT ID ,X_COORD,Y_COORD, SDO_GEOMETRY(2001,2264,SDO_POINT_TYPE(NVL(X_COORD,0),NVL(Y_COORD,0),NULL),NULL,NULL) SHAPE
FROM USER1.LOCATIONS WHERE X_COORD>0 AND Y_COORD>0
) a WHERE sdo_filter (shape, sdo_geometry ('POLYGON ((1447000 540000, 1453000 540000, 1453000 545000, 1447000 545000, 1447000 540000))', 2264), 'querytype=window') = 'TRUE';
When run against the view by user2, the error is:
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 1173
13226. 00000 - "interface not supported without a spatial index"
*Cause: The geometry table does not have a spatial index.
*Action: Verify that the geometry table referenced in the spatial operator
has a spatial index on it.
Note, the SELECT SHAPE FROM (****) A WHERE SDO_FILTER(....) syntax is a third party application, all we have control is the part inside "(select ...)".
So it appears Oracle is treating view differently. Have attempted fake the view name into USER_SDO_GEOM_METADATA, did not work. Also, granted select on the index table to user2, did not work.
if we re-created the view in user2 schema, it worked for user2 but not user1, so it's not something we can do for every user.
Searched the forum, no good match found. A few posts talked about "union all" in view caused the problem but I do not have the union.
We are only use Oracle 10g Locator, not full spatial edition.
Any ideas?
Thanks!
Edited by: liu.284 on Oct 4, 2011 12:08 PM

It seems a bug, where a function-based spatial index is not correctly handled in a view query transformation.
Not sure if the following works for you or not.
add a new column "shape" (mdsys.sdo_geometry) in table locations, use a trigger and x_coord/y_coord
to set values for this new column, and just create a normal spatial index on this new column. (drop the
function-based spatial index). And create a view like:
CREATE VIEW USER1.MY_VIEW2 AS SELECT ID , X_COORD, Y_COORD, SHAPE
FROM USER1.LOCATIONS WHERE X_COORD>0 AND Y_COORD>0;

Spatial query inside the exists clause return ora-13226

The following does not work:
select b.state, b.county from counties b where exists
(select 's' from states a where a.state = 'New Jersey'
and mdsys.sdo_relate (b.geom, a.geom, 'mask=INSIDE querytype=WINDOW' ) = 'TRUE');
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 302
ORA-06512: at line 1
The following does work:
select b.* from states a,
counties b where a.state = 'New Jersey'
and mdsys.sdo_relate (b.geom, a.geom, 'mask=INSIDE querytype=WINDOW') = 'TRUE';
I found bug 1243095 telling that this is not a bug but a limitation of the spatial operator. It cannot be invoked on a table that is not spatially indexed. In fact, the table is indexed but oracle cannot find the spatial index because table b(counties) is declared outside the EXISTS clause.
In my case, I use object table. I cannot use the workaround specified above because I should use the DISTINCT clause but I cannot define the MAP and ORDER function (this is a general query).
I've found another workaround :
select b.state, b.county from counties b where exists
(select 's' from states a where a.state = 'New Jersey'
and mdsys.sdo_relate (a.geom, b.geom, 'mask=CONTAINS querytype=WINDOW') = 'TRUE');
but sdo_relate still doesn't use the spatial index of table b (even if I specify it explicitely in the operator) and the query is very slow (more than 15 minutes).
Is there a better workaround ?

OK but I work in object model.
And if I don't use the EXISTS clause, I must use the distinct clause.(I used the exists because of that)
If I will to retrieve all the country that have at least a state beginning with the C letter, I will wrote :
select c.* from country c, table(c.states) s where s.column_value.name like 'C%';
(It is a simplified request to express the problem)
In this case, I must use the distinct clause to select one occurence of each country objet (one country may contains more than one state beginning with C).
select distinct c.* from country c, table(c.states) s where s.column_value.name like 'C%';
For that, I must define a MAP or ORDER function for EACH type used in the country object.
My first question is : I must retrieve all different country objects. Why the request doesn't use the MAP or ORDER function of the country type to distinct them ? Is there another syntax (or a hint) to express that ?
In this case, it will make an ORA-00932 : incoherent datatype because the type of the nested table column cannot contain map or order method.
Any suggestion ?
Thanks in advance.

ORA-13199 Error on a spatial query

Hi,
I am getting following Error on a spatial query (on version 11.1.0.7)
"ORA-13199: Dimensionalities of geometry (GTYPE 3003) and diminfo (2) do not match.
ORA-06512: at "MDSYS.MD", line 1723
ORA-06512: at "MDSYS.MDERR", line 17
ORA-06512: at "MDSYS.SDO_CS", line 2809
ORA-06512: at "MDSYS.SDO_3GL", line 182 "
The same query used to work fine on 10.2.
My query looks like
Select Sfilt.GEOMETRY FROM
(Select TA.GEOMETRY FROM LANDPLAN.TOPOAREA TA, TEST.PLAN PL
WHERE PL.PLAN_ID = 12345 AND TA.LOC_CODE = 7
AND SDO_FILTER(TA.GEOMETRY,PL.GEOMETRY) = 'TRUE'
) Sfilt
,TEST.PLAN PL2 WHERE
PL2.PLAN_ID = 12345 AND
SDO_RELATE(PL2.GEOMETRY, sfilt.GEOMETRY, 'mask=anyinteract') = 'TRUE';
in the above data TEST.PLAN table is 2D table and LANDPLAN.TOPOAREA is 3D table and both are indexed.
Any help appriciated..

Siva,
Thank you for your response. Now I have tried by increasing the DIMINFO (rebuiding the index) to three.
Now it shows below error..
ORA-29902: error in executing ODCIIndexStart() routine
ORA-13243: specified operator is not supported for 3- or higher-dimensional R-tree
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 416
I didn't reason now...for clarity
Can I have 3d layer with 2d index's ?
If Yes, can Spatial query work using these 2d index's against other 2d layer and 3d layers ?

SDO_3GL

Similar Messages

Maybe you are looking for