ORA-13000: dimension number is out of range when using SDO_GEOM.RELATE

Question

Dear everyone
I am attempting to workout which polygons cover the same area in order to determine distinct polygons. This is so I can then have just one copy of a polygon to a new table and delete all the duplicate polygons in the current table.
I ran the following first to check something:
SELECT SDO_GEOM.RELATE
   (A.geographical_coordinates,
    'DETERMINE',
    B.geographical_coordinates,
    0.05) relationship
FROM MAP_INDEX A,
      MAP_INDEX B
where A.geographical_coordinates is not NULL
and B.geographical_coordinates is not NULL;but got the error message:
Error starting at line 1 in command:
SELECT DISTINCT A.mi_prinx,
SDO_GEOM.RELATE
   (A.geographical_coordinates,
    'EQUAL',
    B.geographical_coordinates,
    0.05)
FROM MAP_INDEX A,
      MAP_INDEX B
where A.geographical_coordinates is not NULL
and B.geographical_coordinates is not NULL
Error report:
SQL Error: ORA-13000: dimension number is out of range
ORA-06512: at "MDSYS.SDO_GEOM", line 70
ORA-06512: at "MDSYS.SDO_GEOM", line 2647
13000. 00000 -  "dimension number is out of range"
*Cause:    The specified dimension is either smaller than 1 or greater than
           the number of dimensions encoded in the HHCODE.
*Action:   Make sure that the dimension number is between 1 and the maximum
           number of dimensions encoded in the HHCODE.I then tried the following:
SELECT DISTINCT A.mi_prinx,
SDO_GEOM.RELATE
   (A.geographical_coordinates,
    'EQUAL',
    B.geographical_coordinates,
    0.05)
FROM MAP_INDEX A,
      MAP_INDEX B
where A.geographical_coordinates is not NULL
and B.geographical_coordinates is not NULLwhich produced the following error message:
Error starting at line 1 in command:
SELECT
SDO_GEOM.RELATE
(A.geographical_coordinates,
'EQUAL',
B.geographical_coordinates,
0.05) relationship
  FROM MAP_INDEX A,
       MAP_INDEX B
Error report:
SQL Error: ORA-13050: unable to construct spatial object
ORA-06512: at "MDSYS.SDO_3GL", line 4
ORA-06512: at "MDSYS.MD2", line 771
ORA-06512: at "MDSYS.SDO_GEOM", line 2622
ORA-06512: at "MDSYS.SDO_GEOM", line 2649
13050. 00000 -  "unable to construct spatial object"
*Cause:    This is an internal error.
*Action:   Contact Oracle Support Services.Does anyone have any idea as to what I might doing wrong? The original polygons were created in MapInfo Professional 8 and I am working in 10.2g
I believe Imust be doing something wrong. I looked into SDO_GEOM_VALIDATE but again that produce the same error message as the first one. I have previously created a spatial index and inserted the values into the USER_SDO_GEOM_METADATA view.
I have been able to get the following to work, I was testing out examples online just to see if I could produce a result on an sdo function:
SELECT NAME_OF_FEATURE, SDO_GEOM.SDO_AREA(GEOGRAPHICAL_COORDINATES,M.DIMINFO)
FROM MAP_INDEX, user_sdo_geom_metadata M
WHERE M.TABLE_NAME='MAP_INDEX' AND M.COLUMN_NAME='GEOGRAPHICAL_COORDINATES'
AND geographical_coordinates is not null;When I drew my polygons in MapInfo, they are likely to have gone partly outside of the boundary dimension values inserted in USER_SDO_GEOM_METADATA. Is that likely to be the cause of my problems or something else?
If it is the cause, is there away of setting up Oracle or MapInfo so that anything drawn outside of the dimension area is clipped.
Kind regards
Tim

Answer 1

Hi Tim,
Since Oracle 8.1.6 Oracle has suggested the use of 4 digit SDO_GTYPE values, which encode the number of dimensions in the geometry. Examples of 4 digit SDO_GTYPES include 2001 for a 2D point, 3001 for a 3D point, 2002 for a 2D linestring, 3002 for a 3D linestring, 2003 for a 2D polygon and 3003 for a 3D polygon.. Contrast these with single digit values of 1 for a point, 2 for a linestring, and 3 for a polygon.
My guess is that at least some of your data is loaded using single digit SDO_GTYPE values, and in the function Oracle does not know the dimensionality of the data (is a vertex identified by 2, 3, or four numbers?). You can check this by doing a:
select distinct a.geographical_coordinates.sdo_gtype from MAP_INDEX A;
If any of the values returned are single digit values then you will know this is the problem.
You have a few options.
You can have Oracle automatically fix the data by migrating the data:
execute sdo_migrate.to_current('MAP_INDEX','GEOGRAPHICAL_COORDINATES');
This will not only set the SDO_GTYPE correctly but will also fix any ring rotation problems (ensures exterior rings are stored counter-clockwise, and interior rings are stored clockwise), it will fix ring ordering problems (ensuring an exterior ring is followed by its interior rings), and it will appropiately set values in the SDO_ELEM_INFO_ARRAY.
After you do this you should be good to go. However, if you are using a tool to update the data and it resets the information back, then the problem will continue to plague you. You should check with your vendor if that is the case.
Another option is to change the query to a different signature which uses the SDO_GEOM_METADATA to get the dimensionality of the data. Instead of writing the query as you have, you would change it to:
SELECT SDO_GEOM.RELATE
(A.geographical_coordinates,
C.DIMINFO,
'DETERMINE',
B.geographical_coordinates,
C.DIMINFO) relationship
FROM MAP_INDEX A,
MAP_INDEX B,
USER_SDO_GEOM_METADATA C
WHERE A.geographical_coordinates is not NULL
and B.geographical_coordinates is not NULL
and C.TABLE_NAME='MAP_INDEX'
and C.COLUMN_NAME='GEOGRAPHICAL_COORDINATES';
So either of those should fix the problem you are seeing, but neither of those are the best way to accomplish what you want to do.
If I were you I would follow first set of directions (migrate your data), make sure I have a spatial index on my table:
select index_name
from user_sdo_index_info
where table_name='MAP_INDEX';
If no rows are returned, create the index:
create index MAP_INDEX_SIDX on MAP_INDEX(GEOGRAPHICAL_COORDINATES)
indextype is mdsys.spatial_index;
You could use SDO_JOIN to perform a self-join:
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_operat.htm#BGEDJIBF
using the EQUAL mask. Note the section on optimizing self-joins.
If you don't have too much data, this might be a start to doing what you want:
create table dups_rowids as
select /*+ ordered */ a.rowid rowid1,b.rowid rowid2
from MAP_INDEX A,
MAP_INDEX B
where SDO_EQUALS (a.geographical_coordinates,b.geographical_coordinates)='TRUE'
and a.rowid <> b.rowid;
create table nodup_rowid (noduprid VARCHAR2(24));
create table dup_rowid (duprid VARCHAR2(24));
set serveroutput on;
declare
rowida varchar2(24);
rowidb varchar2(24);
rowidt varchar2(24);
type myCursor is ref cursor;
acursor myCursor;
cursor c1 is select rowid1,rowid2 from dups_rowids;
begin
for r in c1 loop
rowida := r.rowid1;
rowidb := r.rowid2;
rowidt := NULL;
open acursor for 'select duprid from dup_rowid where duprid = :rowida' using rowida;
fetch acursor into rowidt;
if rowidt is null
then
execute immediate 'insert into nodup_rowid values (:rowida)' using rowida;
execute immediate 'insert into dup_rowid values (:rowida)' using rowida;
execute immediate 'commit';
end if;
close acursor;
rowidt := NULL;
open acursor for 'select duprid from dup_rowid where duprid = :rowidb' using rowidb;
fetch acursor into rowidt;
if rowidt is null
then
execute immediate 'insert into dup_rowid values (:rowidb)' using rowidb;
execute immediate 'commit';
end if;
close acursor;
end loop;
end;
Then your final table would have the geometries from the original table that had no match:
create table MAP_INDEX_NODUPS
as select * from MAP_INDEX where rownum < 1;
insert into MAP_INDEX_NODUPS
(select *
from MAP_INDEX
where ROWID not in
(select ROWID1 from DUPS_ROWIDS));
plus only one of the geometries that were equal:
insert into MAP_INDEX_NODUPS
(select *
from MAP_INDEX
where ROWID in
(select ROWID1 from NODUP_ROWID);
Hope this helps.