SDO_AGGR_MBR

Folks,
I am getting the following errors when I use the SDO_AGGR_MBR function on some of my tables.
SELECT SDO_AGGR_MBR(c.GeoLoc)
FROM fhm_towns c;
ORA-06533: Subscript beyond count
ORA-06512: at "MDSYS.SDO_3GL", line 760
ORA-06512: at "MDSYS.SDOAGGR", line 43
ORA-06512: at "MDSYS.AGGRMBR", line 14
ORA-06512: at line 1
The data was imported into a 9.2.0.6 database from a 9.2.0.1 where the query worked fine.
I can run the next 2 queries fine but the third one fails:
SELECT SDO_AGGR_MBR(c.GeoLoc)
FROM fhm_towns c
where town_id = 3845
SELECT SDO_AGGR_MBR(c.GeoLoc)
FROM fhm_towns c
where town_id = 4342
SELECT SDO_AGGR_MBR(c.GeoLoc)
FROM fhm_towns c
where town_id = 3845
or town_id = 4342
The SDO_AGGR_MBR function seems to fail when I try to aggregate more than 1 row in these tables.
This works fine on another table in the same database which covers the same geographic area and has more rows in it.
I tried dropping the spatial index and recreating it but that didnât resolve the issue either.
Any help would be great.
Thanks,
John.

Hi Dan,
Heres the results of the query:
SELECT c.GeoLoc
FROM fhm_towns c
where town_id = 3845 or town_id = 4342;
GEOLOC(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
SDO_GEOMETRY(2001, 82086, SDO_POINT_TYPE(236502, 279631.997, NULL), NULL, NULL)
SDO_GEOMETRY(2001, 82086, SDO_POINT_TYPE(84808.9967, 123049.996, NULL), NULL, NULL)
Thanks,
John.

Similar Messages

SDO_AGGR_MBR returns line instead of rectangle in oracle 10g

select sdo_aggr_mbr(
SDO_GEOMETRY(3003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3),
SDO_ORDINATE_ARRAY(-10, -10, 0, 10, 10, 0))
from dual;
In Oracle 10.2.0.2, 10.2.0.4, 10.2.0.5, Wndows server 2003, Windows vista we get a line
SDO_AGGR_MBR(SDO_GEOMETRY(3003,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1003,3),SDO_OR...
SDO_GEOMETRY(*3002*, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(-10, -10, 0, 10, 10, 0))
In Oracle 11.2.0.1 Windows Server 2008 the result is a rectangle
SDO_AGGR_MBR(SDO_GEOMETRY(3003,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1003,3),SDO_OR...
SDO_GEOMETRY(*3003*, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARRAY(-10, -10, 0, 10, 10, 0))

Confirmed. If you use 2D input, or change the Z dimensions so they are different, you will get the results you expect in 10g. Otherwise - a line.
I'm not sure why, and can't see a bug report on that in support, but obviously it was recognized and fixed as you indicate.
Try it with 2D input, and it will work:
select sdo_aggr_mbr(
SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3),
SDO_ORDINATE_ARRAY(-10, -10, 10, 10))
from dual;
Or with different Z values:
select sdo_aggr_mbr(
SDO_GEOMETRY(3003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3),
SDO_ORDINATE_ARRAY(-10, -10, 1, 10, 10, 11))
from dual

Operand value exceeds system limits in sdo_aggr_mbr

Hi-- i'm trying to get the MBR of a fairly large geometry (1429 vertices) and run into a strange problem:
when i:
select sdo_aggr_mbr(shape)
from FEEDER_LINES_SDO
where subname = 'OCEANO';
i get what i expect:
SDO_GEOMETRY(2003, 82212, NULL, SDO_ELEM_INFO_ARRAY(1,1003, 3),SDO_ORDINATE_ARRAY(712103.736,3876977.34, 733591.744, 3896557.18))
however when i try to get the subname in my query as well:
select subname ,sdo_aggr_mbr(shape)
from FEEDER_LINES_SDO
where subname = 'OCEANO'
group by subname;
i get
ERROR at line 1:
ORA-22813: operand value exceeds system limits
The query fails with "ORA-00937: not a single-group group function" when i leave out the group by clause
i can get around it with a kludge, but would like to know why the group by fails
the kludge:
select subname,min(t.x) minx, min(t.y) miny, max(t.x) maxx, max(t.y) maxy from
FEEDER_LINES_SDO c,
TABLE(SDO_UTIL.GETVERTICES(c.shape)) t
where subname = 'OCEANO'
group by subname;
SUBNAME MINX MINY MAXX MAXY
OCEANO     712103.736 3876977.34 733591.744 3896557.18
where minx(), miny() etc are variations on:
function minx (geom_in mdsys.sdo_geometry)
return number DETERMINISTIC IS
begin
return sdo_geom.sdo_min_mbr_ordinate(geom_in,1);
end;
the group by expression seems to work fine on geometries with less than 1200 vertices. Is there a system parameter i can change?
elvis{44}% oerr ora 22813
22813, 00000, "operand value exceeds system limits"
// *Cause: Object or Collection value was too large. The size of the value
// might have exceeded 30k in a SORT context, or the size might be
// too big for available memory.
// *Action: Choose another value and retry the operation.
i am running oracle 9.2.0.1 on solaris8
any insight on this will be greatly appreciated
cheers
--kassim

Hi Kassim,
At KMS I recently ran into the same ORA-22813, when running this cursor SQL
     CURSOR lcur_montage IS
     select m.mont_id, m.sys_PK, m.krtp_id, m.mont_geom, m.til_dato_id , m.forloeb
     from MTK_montage m
     where m.fra_dato_id = in_dato_id
     and m.krtp_id = 1
     order by m.mont_id;
Omitting the order by clause makes it work fine. If I alternatively omit the SDO_geometry m.mont_geom as a select item, the query also works.
Our problem seems to arise when trying to sort selected rows, which contain large objects such as SDO_geometry.
Yesterday we played around with SORT_AREA_SIZE, but to no avail. It turns out to be a known bug.
When I today search for ORA-22813 in MetaLink, the first list item is
1.
9.2.0.X Patch Sets - List of Bug Fixes by Problem Type
Type: Note
Doc ID: 217194.1
Score: 63%
Modified Date: 18-FEB-2003
Status: PUBLISHED
Platform: Generic issue
Product: Oracle Server - Enterprise Edition
which unfortunately will not open and reveal its content.
On the other hand trying MetaLink -> Bugs -> search for 'ORA-22813' gives amongst others Bug 2656107, which looks a lot like my problem.
For Oracle eyes: - when will this bug be fixed? Does it solve the problem at hand?
- regards
Jens Ole Jensen
Kort & MatrikelStyrelsen (WWW: http://www.kms.dk)
Danmark
version: (32 bit) Oracle9i Enterprise Edition Release 9.2.0.2.0 - Production on Sun/SunOS 5.8 (64 bit)

Error with SDO_TUNE.EXTENT_OF on a table with more than one geometry.

Hello,
I'm using a GeoServer with Oracle Spatial database, and I run into some problems. GeoServer uses SDO_TUNE.EXTENT_OF to calculate the maximum extent of features you add. It works fine for all object with only one geometry, but fails for objects that has two geometry columns. The error is ORA-01422.
Is this a bug in Oracle, or am I doing something wrong? I know SDO_AGGR_MBR works fine, but I'd rather not use it, since if it is possible I would like to avoid changing the GeoServer functions.
Here is a small script I created to show this error:
1. Create two tables, object1 with one geometry and object2 with two geometry columns.
2. Create metadata (projected coordinate system).
3. Insert two rows, one in each table.
4. Create spacial indices.
5. Calculate extent, on object1 it will succeed, on object2 it will fail.
6. Clean.
CREATE TABLE object1
     id NUMBER PRIMARY KEY,
     geom1 SDO_GEOMETRY
CREATE TABLE object2
     id NUMBER PRIMARY KEY,
     geom1 SDO_GEOMETRY,
     geom2 SDO_GEOMETRY
INSERT INTO user_sdo_geom_metadata (table_name, column_name, srid, diminfo)
VALUES
     'OBJECT1',
     'GEOM1',
     2180,
     SDO_DIM_ARRAY
          SDO_DIM_ELEMENT('X', 400000, 700000, 0.05),
          SDO_DIM_ELEMENT('Y', 300000, 600000, 0.05)
INSERT INTO user_sdo_geom_metadata (table_name, column_name, srid, diminfo)
VALUES
     'OBJECT2',
     'GEOM1',
     2180,
     SDO_DIM_ARRAY
          SDO_DIM_ELEMENT('X', 400000, 700000, 0.05),
          SDO_DIM_ELEMENT('Y', 300000, 600000, 0.05)
INSERT INTO user_sdo_geom_metadata (table_name, column_name, srid, diminfo)
VALUES
     'OBJECT2',
     'GEOM2',
     2180,
     SDO_DIM_ARRAY
          SDO_DIM_ELEMENT('X', 400000, 700000, 0.05),
          SDO_DIM_ELEMENT('Y', 300000, 600000, 0.05)
INSERT INTO object1 VALUES(1, SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(450000, 350000, NULL), NULL, NULL));
INSERT INTO object2 VALUES(1, SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(550000, 450000, NULL), NULL, NULL));
CREATE INDEX object1_geom1_sidx ON object1(geom1) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
CREATE INDEX object2_geom1_sidx ON object2(geom1) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
CREATE INDEX object2_geom2_sidx ON object2(geom2) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
SELECT SDO_TUNE.EXTENT_OF('OBJECT1', 'GEOM1') FROM DUAL;
SELECT SDO_TUNE.EXTENT_OF('OBJECT2', 'GEOM1') FROM DUAL;
SELECT SDO_TUNE.EXTENT_OF('OBJECT2', 'GEOM2') FROM DUAL;
DELETE FROM user_sdo_geom_metadata WHERE table_name IN ('OBJECT1', 'OBJECT2');
DROP INDEX object1_geom1_sidx;
DROP INDEX object2_geom1_sidx;
DROP INDEX object2_geom2_sidx;
DROP TABLE object1;
DROP TABLE object2;
Thanks for help.

Hi,
As a workaound to avoid the ORA-01422 errors, you could try to create views on your object2 table, and insert their geom metadata (with view names as table names!))
create view view2_1 as select * from object2;
create view view2_2 as select * from object2;
INSERT INTO user_sdo_geom_metadata (table_name, column_name, srid, diminfo)
VALUES
'VIEW2_1',
'GEOM1',
2180,
SDO_DIM_ARRAY
SDO_DIM_ELEMENT('X', 400000, 700000, 0.05),
SDO_DIM_ELEMENT('Y', 300000, 600000, 0.05)
INSERT INTO user_sdo_geom_metadata (table_name, column_name, srid, diminfo)
VALUES
'VIEW2_2',
'GEOM2',
2180,
SDO_DIM_ARRAY
SDO_DIM_ELEMENT('X', 400000, 700000, 0.05),
SDO_DIM_ELEMENT('Y', 300000, 600000, 0.05)
SELECT SDO_TUNE.EXTENT_OF('OBJECT1', 'GEOM1') FROM DUAL;
SELECT SDO_TUNE.EXTENT_OF('VIEW2_1', 'GEOM1') FROM DUAL;
SELECT SDO_TUNE.EXTENT_OF('VIEW2_2', 'GEOM2') FROM DUAL;
Results in 11.1.0.7.0
SDO_TUNE.EXTENT_OF('OBJECT1','GEOM1')(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), S
SDO_GEOMETRY(2003, 2180, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR
AY(450000, 350000, 450000, 350000))
SQL>
SDO_TUNE.EXTENT_OF('VIEW2_1','GEOM1')(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), S
SDO_GEOMETRY(2003, 2180, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR
AY(500000, 400000, 500000, 400000))
SQL>
SDO_TUNE.EXTENT_OF('VIEW2_2','GEOM2')(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), S
SDO_GEOMETRY(2003, 2180, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR
AY(550000, 450000, 550000, 450000))jack

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.

Doubts in GeoRaster Concept.

Hi everybody,
I have few doubts in GeoRaster concepts.
I did mosaicing of multiple Georasater objects using "sdo_geor.getRasterSubset()" and able to display image properly. But while doing this I come across few people suggestions. They said that mosaicing multiple rows together in a GeoRaster table is not going produce meaningful results because the interpolation methods wont have access to the data in the adjacent cells at the seams because cell needed exist in a different row (i.e. where two rows of GeoRaster either abut or overlap).
I assume Oracle takes care of all this. Please suggest wheather my assumption is true or the statement given is true?
Regards,
Baskar
Edited by: user_baski on May 16, 2010 10:49 PM

Hi Jeffrey,
Requirements:-
I have to do mosaicing of 'n' number of Georaster objects. For eg, if table has 4 rows of GeoRaster object, then i have to create single image by mosaicing all the Georaster object based on the Envelope provided. (Note: I have to do this with Queries without using GeoRaster API)
Workflow:-
1. Get the connection and table details.
2. Retrieve necessary information from the db like SRID, MAXPYRAMID, SPATIALRESOLUTION, EXTENT etc. For getting extent, I used SDO_AGGR_MBR function.
3. With the help of "MDSYS.SDO_FILTER" and bouding box values, I create arraylist which contains raster id's retrieved from raster data table which covers the bouding box value provided in the filter command.
4. Then I passed bounding box value into "sdo_geor.getCellCoordinate" function and I retrieved row and column number of Georaster image and created a number array which contains starting and ending row/column numbers.
5. Then I had written a PL/SQL with "sdo_geor.getRasterSubset" function which takes the number array and raster id as input parameters, which inturn returns BLOB object.
6. I am executing step 5 in a loop with all the raster id's that I got at step 3. For eg, arraylist size is 4, then I will have four BLOB object.
7. Finally, I creating new image from the BLOB objects after some scaling and cropping based on the individual GeneralEnvelope of each raster id object.
I had followed all the above steps and successfully created mosaic image.However, few people suggested that mosaicing in this way does not produce meaningful results because the interpolation methods wont have access to the data in the adjacent cells at the seams because cell needed exist in a different row. I assume Oracle will take care of these things. Moreover, they suggested to keep single row in GeoRaster table instead of muliple rows of Georaster object and suggested to use "SDO_GEOR.updateRaster" function to update a part of the raster object and the pyramids are rebuild automatically.
So Please suggest which is the better way to do mosaicing. Wheather my assumption is correct or not?

How can I get a full extent of a map?

Hi, does anyone know how I can get a full extent (the orignal complete map) after zooming in/out? Is there a methode available to manage this?

You could use the function SDO_AGGR_MBR to get the full extent of several geometries. Maybe there is a function to get the full extent of a layer also, but I'm not sure. Try searching the manual.
/Magnus

Mapviewer map_request limitations for when using wms and jdbc themes?

Are there limitations to not use either the bounding_themes or the center option when a basemap requests both a jdbc and a wms theme? I would like to have the bounding_theme be the jdbc theme. I can see how this could pose challenges in that there would be a need to retrieve the jdbc theme and calc the mbr before issuing the wms requests w/ the correct bbox. Would be a nice feature though.

woops, sorry LJ -- it works. Do you have suggestions though for dealing w/ case where the jdbc theme returns one point? id like to use something like the border_margin to pad the point out to a box, but seems to always just return just the point. mkaes sense since multiplying 0 by anything is zero. we are planning on writing a servlet that instead uses sdo_buffer then construct the coordinates tag w/ the sdo_aggr_mbr. that should accommodate 1..n points returned.
<bounding_themes border_margin="0.05">

8.1.5 query execution problem

Hello,
I am using the following:
Oracle database ver 8i
Oracle spatial Ver 8.1.5
windows 2000 server
I have a Polygon fatured layer in the db , exported from the Java SDO-sample programs 'sampleshapefileToSDO.java'.
when I run the "desc MJM_Parcel" I get
SQL> desc mjm_parcel;
Name Null? Type
GID NUMBER
GEOMETRY MDSYS.SDO_GEOMETRY
when I query a simple query like
"select sdo_aggr_mbr(geometry)from MJM_parcel where GID=100;"
I get the following error:
select sdo_aggr_mbr(GEOMETRY) from MJM_PARCEL where
GID=100
ERROR at line 1:
ORA-00904: invalid column name
any problem with respect to Installation...how to correct it ? or problems with the query itself...n how do I do?
Plz help me ...
Thanx in advance

The function sdo_aggr_mbr does not exist in 8i, it is a new function in 9i.

Simon Greener's Morton Key Clustering in Oracle Spatial

Hi folks,
Apologies for the rambling. With mattyschell heading for greener open source big apple pastures I am looking for new folks to bounce ideas and code off. I was thinking this week about the discussion last autumn over spatial clustering.
https://community.oracle.com/thread/3617887
During the course of the thread we all kind of pooh-poohed spatial clustering as not much of solution, myself being one of the primary poohers. Yet the concept certainly remains as something to consider regardless of our opinions. The yellow book, the Greener/Ravada book, Simon's recent treatise (http://download.oracle.com/otndocs/products/spatial/pdf/biwa_2015/biwa2015_uc_comparativeperformance_greener.pdf), they all put forward clustering such that at the very least we should consider it a technique we should be able as professionals to do - a tool in the toolbox whether or not it always is the right answer. I am mildly (very mildly) curious to see if Kothuri, Godfrind and Beinat will recycle their section on spatial clustering with the locked-down MD.HHENCODE into their 12c revision out this summer. If they don't then what is the replacement for this technique? If they do then we return to all of our griping about this ancient routine that Simon implies may date back to the CHS and their hhcode indexes - at least its not written in Java!
Anyhow, so I've been in the midst this month of refreshing some of the datasets I manage and considering clustering the larger tables whilst I am at it. Do I really expect to see huge performance gains?   Well... not really. But it does seem like something that should be easy to accomplish, certainly something that "doesn't hurt" and shows that I am on top of things (e.g. "checks the box"). But returning to the discussion from last fall, just what is the best way to do this in Oracle Spatial?
So if we agree to ignore poor old MD.HHENCODE, then what? Hilbert curves look nifty but no one seems to be stepping up with the code for them. And this reroutes us back around to Simon and his Morton key code.
http://www.spatialdbadvisor.com/oracle_spatial_tips_tricks/138/spatial-sorting-of-data-via-morton-key
So who all is using Simon's code currently? If you read that discussion from last fall there does not seem to be anyone doing so and we never heard back from Cat Person on either what he decided to do or what his name is.
I thought I could take a stab at streamlining Simon's process somewhat to make things easier for myself to roll this onto many tables. I put together the following small package
https://github.com/pauldzy/DZ_SDO_CLUSTER/tree/master/Packages
In particular I wanted to bundle up the side issues of how to convert your lines and polygons into points, automate things somewhat and provide a little verification function to see what results look like. So again nothing that Simon does not already walk through on his webpage, just make it bit easier to bang out on your tables without writing a separate long SQL process for each one.
So for example to use Simon's Morton key logic, you need to know the extent envelope of the data (in order to define a proper grid). So if its a large table, you'd want to stash the envelope info in the metadata. You can do this with the update_metadata_envelope procedure or just suffer through the sdo_aggr_mbr each time if you don't want to go that route (I have one table of small watershed polygons that takes about 9 hours to run sdo_aggr_mbr upon). So just run things at the sql prompt
SELECT
DZ_SDO_CLUSTER.MORTON_UPDATE(
    p_table_name => 'CATCHMENT_NP21'
   ,p_column_name => 'SHAPE'
   ,p_grid_size => 1000
FROM dual;
This will return the update clause populated with the values to use with the morton_key wrapper function, e.g. "morton_key(SHAPE,160.247133275879,-17.673722530871,.0956820001136141,.0352063207508021)". So then just paste that into an update statement
UPDATE foo
SET my_morton_key = dz_sdo_cluster.morton_key(
    SHAPE
   ,160.247133275879
   ,-17.673722530871
   ,.0956820001136141
   ,.0352063207508021
Then rebuild your table sorting on the morton_key. I just use the TOAD rebuild table tool and manually add the order by clause to the rebuild script. I let TOAD do all the work of moving the indexes, constraints and grants to the new table. I imagine there are other ways to do this.
The final function is meant to be popped into Oracle mapviewer or something similar to show your family and friends the results.
SELECT
dz_sdo_cluster.morton_visualize(
    'NHDPLUS'
   ,'NHDFLOWLINE_NP21_ACU'
   ,'SHAPE'
   ,'OBJECTID'
   ,'100'
   ,10000
   ,'MORTON_KEY'
FROM dual;
Look Mom, there it is!
So anyhow this is first stab at things and interested in feedback or suggestions for improvement. Did I get the logic correct? Don't spare my feelings if I botched something. Note that like Simon I passed on the matter of just how to determine the proper grid size. I've been using 1000 for the continental US + Hawaii/PR/VI and sitting here this morning I think that probably is too large. Of course it depends on the size of the geometries and thus the density of the resulting points. With water features this can vary a lot from place to place, so perhaps 1000 is okay. What would the algorithm be to determine a decent grid size? It occurs to me I could tell you the average feature count per morton key value, okay well its about 10. That seems small to me. So I could see another function in this package that returns some kind of summary on the results of the keying to tell you if your grid size estimate was reasonable.
Cheers and Happy Saturday,
Paul

I've done some spatial clustering testing this week.
Firstly, to reiterate the purpose of spatial clustering as I see it: spatial clustering can be of benefit in situations where frequent window based spatial queries are made. In particular it can be very useful in web mapping scenarios where a map server is requesting data using SDO_FILTER or SDO_ANYINTERACT and there is a need to return the data as quickly as possible. If the data required to satisfy the query can be squeezed into as few blocks as possible, then the IO overhead is clearly reduced.
As Bryan mentioned above, once the data is in the buffer cache, then the advantage of spatial clustering is reduced. However it is not always possible to get/keep enough of the data in the buffer cache, so I believe spatial clustering still has merits, particularly if it can be implemented alongside spatial partitioning.
I ran the tests using an 11.2.0.4 database on my laptop. I have a hard disk rather than SSD, so the effects of excessive IO are exaggerated. The database is configured with the default 8kb block size.
Initially, I created a table PARCELS:
create table parcels (
id            integer,
created_date date,
x            number,
y            number,
val1          varchar2(20),
val2          varchar2(100),
val3          varchar2(200),
geometry      mdsys.sdo_geometry,
hilbert_key number);
I inserted 2.8 million polygons into this table. The CREATED_DATE is the actual date the polygons were captured. I populated val1, val2 and val3 with string values to pad the rows out to simulate some business data sitting alongside the sdo_geometry.
I set X,Y to the first ordinate of the polygon and then set hilbert_key = sdo_pc_pkg.hilbert_xy2d(power(2,31), x, y).
I then created 4 tables to base the tests upon:
PARCELS_RANDOM: Ordered by dbms_random.random - an absolute worst case scenario. Unrealistic, but worthwhile as a benchmark.
PARCELS_BASE_DATE: Ordered by CREATED_DATE. This is probably pretty close to how the original source data is structured on disk.
PARCELS_RTREE: Ordered by RTree. Achieved by inserting based on an SDO_FILTER query
PARCELS_HILBERT: Ordered by the hilbert_key attribute
As a first test, I counted the number of blocks required to satisfy an SDO_FILTER query. E.g.
select count(distinct(dbms_rowid.rowid_block_number(rowid)))
from parcels_rtree
where sdo_filter(geometry,
                sdo_geometry(2003, 2157, null, sdo_elem_info_array(1, 1003, 3),
                                sdo_ordinate_array(644232,773809, 651523,780200))) = 'TRUE';
I'm assuming dbms_rowid.rowid_block_number(rowid) is suitable for this.
I ran this on each table and repeated it over three windows.
Results:
So straight off we can see that the random ordering gave pretty horrific results as the data required to satisfy the query is spread over a large number of blocks. The natural date based clustering was far better. RTree and Hilbert based clustering reduced this by a further 50% with Hilbert just nosing out RTree.
Since web mapping is the use case I am most likely to target, I then setup a test case as follows:
Setup layers in GeoServer for each of the tables
Used a script to generate 1,000 random squares over the extent of the data, ranging from 200m to 500m in width and height.
Used JMeter to make a WMS request for a png of the each of the 1,000 windows. JMeter was run sequentially with just one thread, so it waited for each request to complete before starting the next. I ran these tests 3 times to balance out the results, flushing the buffer cache before each run.
Results:
Again the random ordering performed woefully bad - somewhat exacerbated by the quality of the disk on my laptop. The natural date based clustering performed far better. RTree and hilbert based clustering further reduced the time by more than half.
In summary, the results suggest that spatial clustering is worth the effort if:
the data is not already reasonably well clustered
you've got a decent quantity of data
you're expecting a lot of window based queries which need to be returned as quickly as possible
you don’t expect to be able to fit all the data in the buffer cache
When it comes to deciding between RTree and Hilbert (or Morton/z-order or any other space filling curve method).... I found that the RTree method can be a bit slow on large datasets, although this may not matter as a one off task. Plus it requires a spatial index on the source table to start off with. The key based methods are based on an xy, so for lines and polygons there is an intermediate step to extract an xy. I would tend to recommend this approach if you also partition the data based on a subset of the cluster key.
Scripts are available here: https://github.com/john-otoole/oracle_spatial_cluster_test
John

SDO_FILTER / SDO_RELATE - no rows returned

Hi, I'm having some troubles with SDO_FILTER and SDO_RELATE functions.
I inserted some spatial data into a table and I can see that spatial information in mapbuilder, but when I query de same data with SQL command line, there are no rows returned. The spatial data isn't georeferenced.
I used this SQL query:
SELECT g.GEOM.Get_WKT() FROM SHPSDO2 g
WHERE sdo_filter(g.GEOM, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(-180, 180, -90, 90)),
'querytype=window') = 'TRUE';
and also this one:
SELECT g.GEOM.Get_WKT() FROM SHPSDO2 g
WHERE SDO_RELATE(g.GEOM, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(-180, 180, -90, 90)),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
When I execute this query: SELECT SDO_AGGR_MBR(g.GEOM).Get_WKT() FROM SHPSDO2 g
the following row is returned:
POLYGON ((-179.144806 -14.60521, 179.76416 -14.60521, 179.76416 71.332649, -179.144806 71.332649, -179.144806 -14.60521))
That means the data is inside the GEOMETRY filter that I passed.
Can some one help me please ???
Operator
Thanks in advance

when using an optimized rectangle enter lower left x,y, then upper right x,y (or long/lat).
so change:
mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(-180, 180, -90, 90))
to:
mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(-180, -90, 180, 90)),

Editable views with instead of triggers in Oracle 10G

Hi,
We are attempting to migrate our database application from Oracle 9i to Oracle 10G. We have found that we are getting the error [ORA-03113 end-of-file on communication channel] when we attempt to insert multiple rows into database tables using editable views equipped with INSTEAD OF triggers. When inserting multiple rows, we are using a single insert statement of the form insert into...select from. Strangely enough, when the select query within the insert statement returns a single row, the insert statement is successful. We also noticed that if we issue a commit right before executing the insert statement, the insert statement is successful regardless of the number of rows being inserted. But this is not a viable workaround as the current transaction contents needs to be maintained. We did not have these issues in Oracle 9i. Does Oracle 10G have any known issues with editable views equipped with INSTEAD OF triggers? Are there any settings in the INIT.ORA file that can resolve these issues? Thanks for your help.

Confirmed. If you use 2D input, or change the Z dimensions so they are different, you will get the results you expect in 10g. Otherwise - a line.
I'm not sure why, and can't see a bug report on that in support, but obviously it was recognized and fixed as you indicate.
Try it with 2D input, and it will work:
select sdo_aggr_mbr(
SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3),
SDO_ORDINATE_ARRAY(-10, -10, 10, 10))
from dual;
Or with different Z values:
select sdo_aggr_mbr(
SDO_GEOMETRY(3003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3),
SDO_ORDINATE_ARRAY(-10, -10, 1, 10, 10, 11))
from dual

Validating data in spatial

Hi,
I converted a shape file to oracle format and loaded the data . But when i validated it it gives me 13011 error which means out of bounds. I not sure what srid (i chose 8307) and the bounds for it ???
data which looks as follows:(open_sapce.dat file)
=================================================
State Of Oregon|Southern Oregon University|SOU Baseball / Softball Fields|Public|Athletic Field|0|
#3|8307|
#1|3|1|/
#4327093.427897|198680.415369|4327104.000246|199110.295040|
#4327234.802757|199108.527439|4327270.154787|199237.562348|
#4327554.738629|199223.421536|4327648.421509|199154.485078|
#4327706.752358|199242.865153|4328270.294421|198845.513395|
#4328263.777394|198642.399376|4328171.631553|198647.183447|
#4327093.427897|198680.415369|/
Could somebody please help me with this.

The SRID 8307 is for lat/long (WGS84) and the data sample you provided appears to be some kind of State Plane data set (X,Y in feet or metres). If you are unable to ascertain the coordinate system from your data provider, and you have no immediate need for reprojection I would recommend loading your data without the SRID (i.e. remove the -s 8307 from your shp2sdo command). A null SRID is generally fine for most spatial data visualisation tools.
Once you have all the data loaded you can update your SDO_GEOM_METADATA record with the actual extents derived using the SDO_AGGR_MBR function (Ref: http://download-west.oracle.com/docs/cd/B14117_01/appdev.101/b10826/sdo_aggr.htm#g997489)
An example of how this function returns results is:
SQL> select sdo_aggr_mbr(geom) from mvdemo.counties;
SDO_AGGR_MBR(GEOM)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_O
SDO_GEOMETRY(2003, 8265, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR
AY(-179.14481, -14.60521, 179.76416, 71.332649))Once you have the MBR coordinates, you can then replace the USER_SDO_GEOM_METADATA record for the table.
For example (note I have used something resembling the data you have)
SQL> DELETE from USER_SDO_GEOM_METADATA where table_name = 'OPEN_SPACE';
SQL> INSERT INTO USER_SDO_GEOM_METADATA
VALUES ('STATES','GEOM',
     MDSYS.SDO_DIM_ARRAY(
          MDSYS.SDO_DIM_ELEMENT('X', 4300000 , 4400000 , 0.05),
          MDSYS.SDO_DIM_ELEMENT('Y', 198000, 200000 , 0.05)),
     NULL
     );     Once you know the correct SRID (I am hoping someone more familiar with U.S. data responds, and you can find the SRID you need in the MDSYS.CS_SRS table) you can modify the script with the correct SRID and you can update your data with accordingly using a script like:
SQL>Update STATES c set c.GEOM.SDO_SRID=99999;Cheers,
Ross.

SDO_RELATE command with 'coveredby' option doesnt return record as expected

Hi all,
I use oracle spatial 10.2. I use sdo_relate to compare 2 tables' geometries. The case is table 1 has ~2000 records, each is a retangle and has sdo_geometry field. 'Table 2' is transient geometry defined by sdo_geometry to a rectengle.
The definition of the table 2 is:
SDO_GEOMETRY(2003, NULL,NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(-50,50, 50,-50)), 'mask=COVEREDBY') = 'TRUE';
I am working in world coordinates.
and the whole SQL for comparison is:
select name from KMK.summary where sdo_relate(mbr,SDO_GEOMETRY(2003, NULL,NULL, SDO_ELEM_INFO_ARRAY(1,1003,3), SDO_ORDINATE_ARRAY(-50,50, 50,-50)), 'mask=COVEREDBY') = 'TRUE';
The problem is that this command doesnt return any values, i.e no records are selected from table 1. I am sure that there are features that evaluate to true for 'mask=COVEREDBY'.
here is one of them:
SQL> SELECT SDO_AGGR_MBR(mbr) FROM kmk.summary where name = ' GETDB_GLOBAL_004065_00O';
SDO_AGGR_MBR(SHAPE)(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_
SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARR
AY(-50, -25.25, -48.25, -24.5))
this teature's MBR goes to -50 and it should be selected.
What do I wrong?
Thanks

Hi I will give it a try on Monday for the numwidth20
I tried with inside mask and it returns the right number of records - only those that are completely within/inside the mask. Thisone record is still not selected.
I use ARCGIS on the same table with SDE so I know what number of records to expect.
When you did the test was GETDB_GLOBAL_004065_00O selected with coveredby mask?
We are running v 10.2.0.3 could this make a difference?
It seems to me that when the coordinates are evaluated the algorithm uses the following for comparison:
(in case of coveredby/inside) it comapres every point to the mask pounts and if it is less than it returns FALSE, it doesn't check if is is equal as well to return TRUE. On the other hand it checks if it is more or equal and if it is returns TRUE. That is why it selects record that have one boundary on top of the search window but extent outside it.
EDIT: It seems it is the precision. When I set it to 25 it returned -50.0000000003723 for the Xmin.
Now, this table has been created from and ESRI shp file, imported to oracle using ArcSDE. Do you have any idea of shp files and how the precisions are utilized in oracle?
Edited by: garnet on Mar 16, 2009 10:13 AM
Edited by: garnet on Mar 16, 2009 4:31 PM

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

SDO_AGGR_MBR

Similar Messages

Maybe you are looking for