Spatial Polygon Desgin Approach

We have 10 spatial geometry "polygon" value types we need to store for point/polygon queries, as in county boundaries, psap boundaries, ilec boundaries, etc.
The boundary sizes will vary in size.
There will be appx 100,000 boundary records.
As a design approach, would it be acceptable to place all of the different boundaries in a single sdo_geometry column, identifying each boundary record with a "type" and foreign key value back to the type table.
As an example, for a "country" geometry we'd have a TYPE=COUNTY, a FOREIGN KEY back to the counties table to pull county data for that geometry, and the county sdo_geometry boundary value. For a "PSAP" geometry we'd have a TYPE=PSAP, a FOREIGN KEY back to the PSAP table to pull PSAP data for that geometry, and the PSAP sdo_geometry boundary value.
We like the idea of storing all boundary data in a single sdo_geometry because we can run a single query against the sdo_geometry column and return all boundaries where a point interacts.
Thanks in advance...

Hi
Design and data model all depends on use cases and according queries you will run on that data model or structure.
you could also "classify" your data and store the polygon in different tables depending on their admin level or your types. you could then, if not yet available run the a series of spatial queries once to identify the admin structure of the polygons.
Once you have that in place you could use the lowest level of admin polygon (table) to run the point in polygon spatial query and use that result back to find the higher level admins using non-spatial queries, which should still be faster.
just again all depends on the "questions" and use cases you will have to tackle.
just my 2cts
Luc

Similar Messages

Spatial Performance

'm building a system which stores Geographical data, and trying to use the spatial functions in the Oracle database. Amongst the tables there are:
blpu - one row per property in the county, each row has a spatial point object indicating its position. Has 480,000 rows.
lcc_boundary - one row per region in the county (parishes, wards, districts, etc.), each row has a spatial polygon indicating its boundary. Has 537 rows.
Now, if I want to determine which parish (say) a given property is in, I do this:
SELECT b.uprn,lb.name area
FROM blpu b,osmm.lcc_boundary lb
WHERE MDSYS.SDO_GEOM.RELATE(lb.geoloc,'CONTAINS',b.geometry, 0.005) = 'CONTAINS'
AND lb.area_code = 'CPC'
AND b.uprn = 100030723225
So far so good - it comes back with the right answer - but it takes 1 second to do so. If I changed the last line to bring back 100 properties, it takes about 100 seconds. Clearly performance is going to be extremely sluggish when doing real queries on thousands of addresses.
Is there anything I can do - e.g. indexes that can be built - that will speed up these spatial functions; or am I just going to have to "denormalise" the spatial data into an ordinary table that cross-references each row in blpu with the rows in lcc_boundaries that enclose it?
I find it hard to believe that Oracle would be selling a product that's so unusably slow.
This is on Oracle9i Enterprise Edition Release 9.2.0.6.0, btw.

Feedback and progress so far...
asturbcn: Yeah, I think that's what I know as a spatial index. I've built them on the relevant columns.
Bryan: I'm building it on 9i 'cos that's what I've got. The "powers that be" here tend to be pretty cautious about database upgrades, so I dunno when the DB in question will go to 10g. Maybe I can use this issue as leverage, but I still need to get something going today.
As noted, I already had spatial indexes, but not optimised for the polygon type. I've recreated them with that refinement added - thanks.
Richard: I wouldn't normally consider area_code as a candidate for an index, as it only has a few distinct values, but I created one anyway.
Dan: Applying all the above advice, and some I got locally, I've ended up with this statement:
SELECT b.uprn,lb.name area
FROM blpu b,osmm.lcc_boundary lb
WHERE sdo_relate(lb.GEOLOC, b.geometry, 'mask=CONTAINS querytype=WINDOW') = 'TRUE'
AND lb.area_code = 'CPC'
AND b.uprn = 100030723225
This runs about three times faster than my original one, the biggest improvement seeming to come from the use in SDO_RELATE instead of MDSYS.SDO_GEOM.RELATE (I tried adding Bryan's /*+ ordered */ hint, but that slowed the query to 1.5mins. A place to trust the optimiser, I think!).
So that's a good result - but it's not yet good enough to be usable in my particular situation. I think I'm still going to use a batch job to create a conventional this-property-is-in-this-region lookup table, and populate it (and maintain it) using spatial functions. Since neither of the tables concerned change much, I think this will be a workable approach - the lookup table will in effect be a kind of spatial index. Maybe when we go to 10g I can investigate a pure spatial solution.
Unless, of course, you know different...

Create a polygon via SQL

I have an existing spatial/polygon table in my database. I want to join it to a view and load the join into a new spatial enabled polygon table. In case you are wondering the join is very slow. I am new to SQL Server spatial and cant find anything describing
how to do this. Ultimately I will use SSIS to perform these steps for me. I have been able to do this with point data but not polygon. The existing polygon coordinates are in a Shape field and will load into another field of the same name. Here is the query
I have built so far:
select name, geography::Polygon(Shape, 4326) as Shape
FROM View as c inner join ExistingPolygonTable as v
on C.Name = v.Name
Thanks in advance.
Scott

There is no Polygon static method like there is with Point. You can create a polygon from WKT (well-known text format) using these methods:
http://technet.microsoft.com/en-us/library/bb933988.aspx Or use well-known binary, a standard binary format. But you don't have to convert a polygon from ExistingPolygonTable to string
just to store it, just store it with the TSQL insert...select statement
http://technet.microsoft.com/en-us/library/ms174335.aspx
Or maybe I've misunderstood the question, or don't know what's in the ExistingPolygonTable. Or what format it's in in that table.
Cheers, Bob

PL/SQLXMLgeneration

Hallo,
I am trying to generate xml from oracle. I tried through differrent approaches and i have finally ended up using XSU for PL/SQL, generating XML with DBMS_XMLQuery().
The stored procedure i am running from Application Developement SQLPlus Worksheet follows right after. I use it to generate XML from tables holding spatial polygon information as well.It works just fine for tables containing up to 30-40 records but produces not well-formed xml documents for tables whose records exceed this number.In such cases, it repeats previously extracted row tags. For example after tag <row num="41"> it goes on with <row num="30"> again, until it reaches <row num="41"> again and goes on.Does anyone have any idea about the cause of this
problem?
At first i thought it might be a memory problem so i tried increasing the shared pool size from Initialization parameters from approximately 50 MB to 100 MB, but Oracle responded with an error:applying dynamic parameters failed ORA-02097-This parameter cannot be modified because there is inneficient memory for increasing shared pool size parameter.I also tried increasing memory used by applications from performance options - virtual memory but nothing changed.It still does not accept the modification of shared pool size parameter, producing the same error.
I am working on a PC with Windows 2000, 29 Gb free hard disk and 256 ram. Can the the operating system or the computer memory be the cause??
The stored PL/SQL procedure:
(tablename varchar2)
as
queryCtx DBMS_XMLquery.ctxType;
result CLOB;
errorNum NUMBER;
errorMsg VARCHAR2(200);
PROCEDURE printClobOut(result IN OUT NOCOPY CLOB, flname IN varchar2) IS
xmlstr varchar2(32767);
line varchar2(2000);
offset number;
counter number;
flag boolean;
filename SYS.UTL_FILE.FILE_TYPE;
PROCEDURE recNgo(str IN VARCHAR2) IS
BEGIN
DBMS_OUTPUT.PUT_LINE('UTL_FILE error'||str);
UTL_FILE.FCLOSE(filename);
END;
BEGIN
filename:=SYS.UTL_FILE.FOPEN('c:\TEMP', flname, 'W');
offset:=1;
flag:=false;
loop
xmlstr:=dbms_lob.SUBSTR(result,32767,offset);
exit when xmlstr is null;
DBMS_OUTPUT.PUT_LINE(DBMS_LOB.GETLENGTH(result));
loop
exit when xmlstr is null;
line:=substr(xmlstr,1,instr(xmlstr,chr(10))-1);
if instr(xmlstr,chr(10))=0 then
line:=xmlstr;
flag:=true;
else
flag:=false;
end if;
if flag then
SYS.UTL_FILE.PUT(filename, line);
else
SYS.UTL_FILE.PUT_LINE(filename, line);
end if;
xmlstr:=substr(xmlstr,instr(xmlstr,chr(10))+1);
if flag then
xmlstr:=null;
end if;
end loop;
offset:=offset+16383;
end loop;
UTL_FILE.FCLOSE(filename);
EXCEPTION
WHEN UTL_FILE.INVALID_PATH THEN recNgo('invalid_path');
WHEN UTL_FILE.INVALID_MODE THEN recNgo('invalid_mode');
WHEN UTL_FILE.INVALID_FILEHANDLE THEN recNgo('invalid_filehandle');
WHEN UTL_FILE.INVALID_OPERATION THEN recNgo('invalid_operation');
WHEN UTL_FILE.READ_ERROR THEN recNgo('read_error');
WHEN UTL_FILE.WRITE_ERROR THEN recNgo('write_error');
WHEN UTL_FILE.INTERNAL_ERROR THEN recNgo('internal_error');
END;
begin
queryCtx:=DBMS_XMLQUERY.newContext('select * from '||tablename);
DBMS_XMLquery.setRaiseException(queryCtx, true);
DBMS_XMLquery.setRaiseNoRowsException(queryCtx, true);
result:=DBMS_XMLQUERY.getXML(queryCtx);
printClobOut(result, tablename||'.xml');
DBMS_XMLQUERY.closeContext(queryCtx);
exception
when others then
DBMS_XMLquery.getExceptionContent(queryCtx, errorNum, errorMsg);
dbms_output.put_line('Exception caught '||TO_CHAR(errorNum)||errorMsg);
end;
Is there anything wrong with the code?
Another problem that i am facing, is that i want my generated xml, to start with the xml declaration and a specific encoding. To be more specific, i need the first line of the generated xml to be like:
<?xml version="1.0" encoding="ISO-8859-7"?>
I need this in order for the greek characters to get recognised by the used parser.The problem is that i haven't found a way to produce the encoding attribute as well, through the PL/SQL procedure.Any suggestions??
Regards
Manousos
Athens

Eric, I cannot find a specific documentation reference to guarantee this, but in every sample I've run, the result has been in the native "order" of the collection if an ORDER BY clause is not specified in the query.

Extrude 3D polygons in Oracle spatial

Dear Everyone,
I have two data sets of the city footprints imported in the Oracle Spatial already. One is a 2D polygon layer with only x and y, and the other is a 3D polygon layer with z values (the x and y are identical to the first one).
Now I am trying to extrude the 3D polygon to 3D composites based on the z value. I can successfully extrude the 2D polygons with specifying the ground heights (say sdo_ordinate_array(0)) and topheights (say, sdo_ordinate_array(20.0)).
However, how to extrude the 3D polygon taking each vertex's z value as the ground heights to an specified top heights is a problem for me. Since, I am very new to use PL/SQL, besides, I am not sure if it is possible to do this.
Here is the sample data extracted from the sample data:
select sample.geom.sdo_ordinates from sample2d_polygon sample
NUMBER(715202.739577727,733492.909091357,715206.759608945,733492.412077086,715208.666575034,733506.889047512,715204.72752625,733507.364066093,715202.739577727,733492.909091357)
select sample.geom.sdo_ordinates from sample3d_polygon sample
NUMBER(715202.739577727,733492.909091357,12.4890003204346,715206.759608945,733492.412077086,12.4890003204346,715208.666575034,733506.889047512,12.4540004730225,715204.72752625,733507.364066093,12.4320001602173,715202.739577727,733492.909091357,12.4890003204346)
Can anybody help me about this
select sdo_util.extrude(sample.geom, sdo_ordinate_array(), sdo_ordinate_array(20.0), 'true', 0.05) from sample2d_polygon sample, where the first sdo_ordinate_array is the array of corresponding vertex's z value?
Any suggestions is anticipated and highly appreciated.
Sincerely
Jun

Hi Jun,-
I hope the following code solves your problem.
Please also make sure your geometries are valid using sdo_geom.validate_geometry_with_context or
sdo_geom.validate_layer_with_context for 3D geometries.
Please let us know if you have questions.
Best
baris
drop table myGeoms;
drop table extruded_myGeoms;
create table myGeoms(i number, geom sdo_geometry);
insert into myGeoms(i, geom) values(1,
MDSYS.SDO_GEOMETRY(3003, null,null,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
MDSYS.sdo_ordinate_array(
715202.739577727,733492.909091357,12.4890003204346,
715206.759608945,733492.412077086,12.4890003204346,
715208.666575034,733506.889047512,12.4540004730225,
715204.72752625, 733507.364066093,12.4320001602173,
715202.739577727,733492.909091357,12.4890003204346
insert into myGeoms(i, geom) values(2,
MDSYS.SDO_GEOMETRY(3003, null,null,
MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
MDSYS.sdo_ordinate_array(
715202.739577727,733492.909091357,14.4890003204346,
715206.759608945,733492.412077086,14.4890003204346,
715208.666575034,733506.889047512,14.4540004730225,
715204.72752625, 733507.364066093,14.4320001602173,
715202.739577727,733492.909091357,14.4890003204346
insert into myGeoms(i, geom) values(3,
mdsys.sdo_geometry(3003, null, null,
mdsys.sdo_elem_info_array(1,1003,1),
mdsys.sdo_ordinate_array(1,1,10, 0,1,10, 0,0,10, 1,0,10, 1,1,10))
create table extruded_myGeoms(id number, geom sdo_geometry);
-- This program assumes that each geometry in myGeoms table
-- has only 1 ring per polygon ie, 1003 etype element.
set serveroutput on;
declare
type cursor_type is REF CURSOR;
query_crs cursor_type ;
-- For each extruded geometry (result), this array has the ground heights
ords_bottom_z_array sdo_number_array := null;
-- For each extruded geometry (result), this array has the top heights which is set to 20 for each element.
-- Both arrays must have the same number of elements.
ords_top_z_array sdo_number_array := null;
ords2d mdsys.sdo_ordinate_array := null;
result sdo_geometry;
g1 sdo_geometry;
g2d sdo_geometry;
stmt varchar2(100);
id1 number;
cnt integer;
k integer;
l integer;
the_dim        number;
gtype_2d       number;
begin
stmt := ' select i, geom from myGeoms ';
OPEN query_crs FOR stmt;
LOOP
BEGIN
   FETCH query_crs into id1, g1;
   EXIT when query_crs%NOTFOUND ;
   ords2d := mdsys.sdo_ordinate_array();
   ords_bottom_z_array := SDO_NUMBER_ARRAY();
   ords_top_z_array := SDO_NUMBER_ARRAY();
   k:=ords_bottom_z_array.count;
   l:=ords2d.count;
   FOR cnt in 1..g1.sdo_ordinates.count LOOP
     if (mod(cnt, 3) = 0) then
       -- Get z values of polygon
       ords_bottom_z_array.extend(1);
       ords_top_z_array.extend(1);
       k:=k+1;
       ords_bottom_z_array(k) := g1.sdo_ordinates(cnt);
       ords_top_z_array(k) := 20.0; -- Constant
     else
       -- To have 2D geometry for input to sdo_util.extrude
       ords2d.extend(1);
       l := l+1;
       ords2d(l) := g1.sdo_ordinates(cnt);
     end if;
   end loop;
   the_dim := floor(g1.sdo_gtype / 1000);
   gtype_2d := (the_dim-1)*1000 + mod(g1.sdo_gtype, 10);
   g2d:= sdo_geometry(gtype_2d, null, null,
           mdsys.sdo_elem_info_array(1,1003,1),
           ords2d);
   result:= sdo_util.extrude(g2d, ords_bottom_z_array, ords_top_z_array, 'FALSE', 0.05);
   -- insert the extruded geometry (result) into new table
   insert into extruded_myGeoms(id, geom) values(id1, result);
   dbms_output.put_line('id = '||id1);
END;
END LOOP;
end;
/

Conversion of spatial links to polygons

Hi,
I have a table of SDO_GEOMETRY objects of TYPE 2002 that represent a polygon . I have another table that holds their order. Is there any SDO function or does someone have some PLSQL that I can use to build the polygon (Type 2003) from these links? Do I have to create this PL/SQL myself. Any help is appreciated.
Thanks

Jeff,
Profuse apologies, this was a mistake that I made at last upload when adding:
Function ST_Dimension(STRUCT _geom)
    Return Number Deterministic;
Function ST_CoordDim(STRUCT _geom)
    Return Number Deterministic;
..... BODY....
Function ST_Dimension(STRUCT _geom)
    Return Number
        As language java name
           'com.spatialdbadvisor.dbutils.ora.JTS.ST_Dimension(oracle.sql.STRUCT) return int';
Function ST_CoordDim(STRUCT _geom)
    Return Number
        As language java name
           'com.spatialdbadvisor.dbutils.ora.JTS.ST_CoordDim(oracle.sql.STRUCT) return int';This, of course, should be:
Function ST_Dimension(p_geom in mdsys.sdo_geometry)
    Return Number Deterministic;
Function ST_CoordDim(p_geom in mdsys.sdo_geometry)
    Return Number Deterministic;
..... BODY ...
Function ST_Dimension(p_geom in mdsys.sdo_geometry )
    Return Number
        As language java name
           'com.spatialdbadvisor.dbutils.ora.JTS.ST_Dimension(oracle.sql.STRUCT) return int';
Function ST_CoordDim(p_geom in mdsys.sdo_geometry )
    Return Number
        As language java name
           'com.spatialdbadvisor.dbutils.ora.JTS.ST_CoordDim(oracle.sql.STRUCT) return int';I had not fixed it as I am in the middle of a big cleanup of my PL/SQL packages (CENTROID/GEOM etc) to align
shared types created and enhanced over the years.
I would suggest you make these changes yourself and let me know the result.
Finally, I have changed the name of the JTS package to SC4O (Spatial Companion For Oracle) which is ready to be released
with an announcement on OTN. This is why I have not released a fix to the problem but have done so now.
Again, apologies
Simon

Any Spatial Method which can Insert Polygon Geometry in Table

Hi All,
Is there any Method of Oracle Spatial which can insert a polygon plotted with polygon tool on the map directly into any database table or do we have to resort to get each of the co-ordinates from the map and create a procedure to insert the ordinates value into mdsys.sdo_ordinates as we do for varrays.

Hi,
On one way you can create unique number by selecting the maximum employee number before creation of a record and then increment one to assign to the new record.
The other way you can create a number range in tcode SNRO and use FM NUMBER_GET_NEXT to get the next number from the number range.
Search SDN with NUMBER_GET_NEXT, you will get example codes.
Regards
Karthik D

How do I split or explode polygons in Oracle Spatial?

OK So SDO_AGGR_UNION is the function that merges lots of polygons into one multipart polygon. But is there a way to seperate a multipart polygon into its parts?
I have merged all the polygons that match an attribute, and this works well using SDO_AGGR_UNION. I now want to seperate into seperate geographic area. Splitting one multipart polygon into several single part polygon.
Any Ideas?
Thanks in advance
Glenn

Hi,
SDO_UTIL.EXTRACT
SDO_UTIL.GETNUMELEM
details in spatial documentation
and You should read following article.
http://www.spatialdbadvisor.com/oracle_spatial_tips_tricks/87/how-to-extract-elements-from-the-result-of-an-sdo_intersection-of-two-polygons
Regards,
Tomek

Extrude 3D polygons with multiple rings in Oracle spatial

In this thread Extrude 3D polygons in Oracle spatial Baris provided a sample script to extrude a polygon with one ring into a 3D solid.
How do I extrude a polygon with multiple rings?
Given this polygon
! http://public.johnnyotoole.fastmail.fm/Polygon_with_hole.jpg !
, I tried to create a solid as follows:
SQL> select * from v$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
PL/SQL Release 11.1.0.7.0 - Production
CORE    11.1.0.7.0      Production
TNS for 32-bit Windows: Version 11.1.0.7.0 - Production
NLSRTL Version 11.1.0.7.0 - Production
5 rows selected.
SQL> DECLARE
2    l_base_geom      SDO_GEOMETRY;
3    l_solid SDO_GEOMETRY;
4   BEGIN
5
6    l_base_geom :=
7     SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1, 21, 2003, 1),
8     SDO_ORDINATE_ARRAY(568758.064, 835364.907, 568735.12, 835362.873, 568735.897, 835354.404, 568737.264, 835334.554,
9     568738.711, 835317.612, 568758.063, 835319.294, 568790.598, 835322.124, 568787.473, 835358.924, 568786.671, 835367.888,
10     568758.064, 835364.907, 568758.063, 835354.97, 568758.811, 835355.046, 568759.253, 835349.107, 568764.952, 835349.529,
11     568764.51, 835355.468, 568778.388, 835356.625, 568778.627, 835353.883, 568778.681, 835353.252, 568778.757, 835352.388,
12     568780.648, 835330.63, 568758.063, 835328.714, 568747.322, 835327.804, 568744.841, 835353.627, 568758.063, 835354.97));
13
14     DBMS_OUTPUT.PUT_LINE('Valid? ' || SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(l_base_geom, 0.005));
15
16     l_solid :=
17     SDO_UTIL.EXTRUDE(
18             l_base_geom,
19             SDO_NUMBER_ARRAY(0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0),
20             SDO_NUMBER_ARRAY(5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5,5),
21             'FALSE',
22             0.005);
23
24 DBMS_OUTPUT.PUT_LINE('Volume: ' || sdo_geom.sdo_volume(l_solid,0.005));
25
26 END;
27 /
Valid? TRUE
DECLARE
ERROR at line 1:
ORA-29532: Java call terminated by uncaught Java exception: java.lang.ArrayIndexOutOfBoundsException
ORA-06512: at "MDSYS.SDO_UTIL", line 241
ORA-06512: at line 16Any ideas?

Would you please have only 10 elements in your sdo_number_arrays in your case?Is this what you mean?
SQL> DECLARE
2    l_base_geom      SDO_GEOMETRY;
3    l_solid SDO_GEOMETRY;
4   BEGIN
5
6    l_base_geom :=
7     SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1, 21, 2003, 1),
8     SDO_ORDINATE_ARRAY(568758.064, 835364.907, 568735.12, 835362.873, 568735.897, 835354.404, 568737.264, 835334.554,
9     568738.711, 835317.612, 568758.063, 835319.294, 568790.598, 835322.124, 568787.473, 835358.924, 568786.671, 835367.888,
10     568758.064, 835364.907, 568758.063, 835354.97, 568758.811, 835355.046, 568759.253, 835349.107, 568764.952, 835349.529,
11     568764.51, 835355.468, 568778.388, 835356.625, 568778.627, 835353.883, 568778.681, 835353.252, 568778.757, 835352.388,
12     568780.648, 835330.63, 568758.063, 835328.714, 568747.322, 835327.804, 568744.841, 835353.627, 568758.063, 835354.97));
13
14     DBMS_OUTPUT.PUT_LINE('Valid? ' || SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(l_base_geom, 0.005));
15
16     l_solid :=
17     SDO_UTIL.EXTRUDE(
18             l_base_geom,
19             SDO_NUMBER_ARRAY(0,0,0,0,0,0,0,0,0,0),
20             SDO_NUMBER_ARRAY(5,5,5,5,5,5,5,5,5,5),
21             'FALSE',
22             0.005);
23
24 DBMS_OUTPUT.PUT_LINE('Volume: ' || sdo_geom.sdo_volume(l_solid,0.005));
25
26 END;
27 /
Valid? TRUE
DECLARE
ERROR at line 1:
ORA-29532: Java call terminated by uncaught Java exception: java.lang.Exception: 54550
ORA-06512: at "MDSYS.SDO_UTIL", line 241
ORA-06512: at line 16
If the heights and ground heights are all the same in your sdo_number_arrays (as in this case), then you can just specify one number in each array instead of specifying a height/ground height for each vertex.Ok, I see what you mean. This works when I use just the outer ring.
SQL> DECLARE
2    l_base_geom      SDO_GEOMETRY;
3    l_solid SDO_GEOMETRY;
4   BEGIN
5
6    l_base_geom :=
7     SDO_UTIL.EXTRACT(
8     SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1, 21, 2003, 1),
9        SDO_ORDINATE_ARRAY(568758.064, 835364.907, 568735.12, 835362.873, 568735.897, 835354.404, 568737.264, 835334.554,
10        568738.711, 835317.612, 568758.063, 835319.294, 568790.598, 835322.124, 568787.473, 835358.924, 568786.671, 835367.888,
11        568758.064, 835364.907, 568758.063, 835354.97, 568758.811, 835355.046, 568759.253, 835349.107, 568764.952, 835349.529,
12        568764.51, 835355.468, 568778.388, 835356.625, 568778.627, 835353.883, 568778.681, 835353.252, 568778.757, 835352.388,
13        568780.648, 835330.63, 568758.063, 835328.714, 568747.322, 835327.804, 568744.841, 835353.627, 568758.063, 835354.97)),
14     1,1);
15
16     DBMS_OUTPUT.PUT_LINE('Valid? ' || SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(l_base_geom, 0.005));
17
18     l_solid :=
19     SDO_UTIL.EXTRUDE(
20             l_base_geom,
21             SDO_NUMBER_ARRAY(0),
22             SDO_NUMBER_ARRAY(5),
23             'FALSE',
24             0.005);
25
26 DBMS_OUTPUT.PUT_LINE('Volume: ' || sdo_geom.sdo_volume(l_solid,0.005));
27
28 END;
29 /
Valid? TRUE
Volume: 11839.18887702For the purposes of what I'm doing now, I think I'll just use the outer ring to create my solids, but it would be useful if SDO_UTIL.EXTRUDE works on polygons with multiple rings (maybe it does, I'm probably doing something wrong...).

Oracle Spatial Performance with 10-20.000 users

Does anyone have any experience when Oracle Spatial is used with say 20.000 concurrent users. I am not interested in MapViewer response time, but lets say there is:
- an app using 800 different tables each having an sdo_geometry column
- the app is configured with different tables visible on different view scales
- let's say an average of 40-50 tables is visible at any given time
- some tables will have only a few records, while other can hold millions.
- there is no client side caching
- clients can zoom in/out pan.
Anwers I am interested in:
- What sort of server would be required
- How can Oracle serve all that data (each Refresh renders the map and retrieves the data over the wire as there is no client side caching).
- What sort of network infrastructure would be required.
- Can clients connect to different servers and hence use load balancing or does Oracle have an automatic mechanism for that?
Thanks in advance,
Patrick

Patrick, et al.
There are lots of things one can do to improve performance in mapping environments because of a lot of the visualisation is based on "background" or read-only data. Here are some "tips":
1. Spatially sort read-only data.
This tip makes sure that data that is close to each other in space are next to each other on disk! Dan gave a good suggestion when he referenced Chapter 14, "Reorganize the Table Data to Minimize I/O" pp 580- 582, Pro Oracle Spatial. But just as easily one can create a table as select ... where sdo_filter() where the filtering object is an optimized rectangle across the whole of the dataset. (This is quite quick on 10g and above but much slower on earlier releases.)
When implementing this make sure that the created table is created such that its blocks are next to each other in the tablespace. (Consider tablespace defragmentation beforehand.) Also, if the data is READ ONLY set the PCTFREE to 0 in order to pack the data up into as small a number of blocks as possible.
2. Generalise data
Rendering spatial data can be expensive where the data is geometrically detailed (many vertices) esp where the data is being visualised at smaller scales than it was captured at. So, if your "zoom thresholds" allow 1:10,000 data to be used at 1:100,000 then you are going to have problems. Consider pre-generalising the data (see sdo_util.simplify) before deployment. You can add multiple columns to your base table to hold this data. Be careful with polygon data because generalising polygons that share boundaries will create gaps etc as the data is more generalised. Often it is better to export the data to a GIS which can maintain the boundary relationships when generalising (say via topological relationships).
Oracle's MapViewer has excellent on-the-fly generalisation but here one needs to be careful. Application tier caching (cf Bryan's comments) can help here a lot.
3. Don't draw data that is sub-pixel.
As one zooms out objects become smaller and smaller until they reach a point where the whole object can be drawn within a single pixel. If you have control over your map visualisation application you might want to consider setting the SDO_FILTER parameter "min_resolution" flag dynamically so that its value is the same as the number of meters / pixel (eg min_resolution=10). If this is set Oracle Spatial will only include spatial objects in the returned search set if one side of a geometry's MBR is greater than or equal to this value. Thus any geometries smaller than a pixel will not be returned. Very useful for large scale data being drawn at small scales and for which no selection (eg identify) is required. With Oracle MapViewer this behaviour can be set via the generalized_pixels parameter.
3. SDO_TOLERANCE, Clean Data
If you are querying data other than via MBR (eg find all land parcels that touch each other) then make sure that your sdo_tolerance values are appropriate. I have seen sites where data captured to 1cm had an sdo_tolerance value set to a millionth of a meter!
A corollary to this is make sure that all your data passes validation at the chosen sdo_tolerance value before deploying to visualisation. Run sdo_geom.validate_geometry()/validate_layer()...
4. Rtree Spatial Indexing
At 10g and above lots of great work went in to the RTree indexing. So, make sure you are using RTrees and not QuadTrees. Also, many GIS applications create sub-optimal RTrees by not using the additional parameters available at 10g and above.
4.1 If your table/column sdo_geometry data contains only points, lines or polygons then let the RTree indexer know (via layer_gtype) as it can implement certain optimizations based on this knowledge.
4.2 With 10g you can set the RTree's spatial index data block use via sdo_pct_free. Consider setting this parameter to 0 if the table/column sdo_geometry data is read only.
4.3 If a table/column is in high demand (eg it is the most commonly used table in all visualisations) you can consider loading (a part of) the RTree index into memory. Now, with the RTree indexing, the sdo_non_leaf_tbl=true parameter will split the RTree index into its leaf (contains actual rowid reference) and non-leaf (the tree built on the leaves) components. Most RTrees are built without this so only the MDRT*** secondary tables are built. But if sdo_non_leaf_tbl is set to true you will see the creation of an additional MDNT*** secondary table (for the non_leaf part of the rtree index). Now, if appropriate, the non_leaf table can be loaded into memory via the following:
ALTER TABLE MDNT*** STORAGE(BUFFER_AREA KEEP);
This is NOT a general panacea for all performance problems. One should investigate other options before embarking on this (cf Tom Kyte's books such as Expert Oracle Database Architecture, 9i and 10g Programming Techniques and Solutions.)
4.4 Don't forget to check your spatial index data quality regularly. Because many sites use GIS package GUI tools to create tables, load data and index them, there is a real tendency to not check what they have done or regularly monitor the objects. Check the SDO_RTREE_QUALITY column in USER_SDO_INDEX_METADATA and look for indexes with an SDO_RTREE_QUALITY setting that is > 2. If > 2 consider rebuilding or recreating the index.
5. The rendering engine.
Whatever rendering engine one uses make sure you try and understand fully what it can and cannot do. AutoDesk's MapGuide is an excellent product but I have seen it simply cache table/column data and never dynamically access it. Also, I have been at one site which was running Deegree and MapViewer and MapViewer was so fast in comparison to Deegree that I was called in to find out why. I discovered that Deegree was using SDO_RELATE(... ANYINTERACT ...) for all MBR queries while MapViewer was using SDO_FILTER. Just this difference was causing some queries to perform at < 10% of the speed of MapViewer!!!!
6. Consider "denormalising" data
There is an old adage in databases that is "normalise for edit, denormalise for performance". When we load spatial data we often get it from suppliers in a fairly flat or normalised form. In consort with spatial sorting, consider denormalising the data via aggregations based on a rendering attribute and some sort of spatial unit. For example, if you have 1 million points stored as single points in SDO_GEOMETRY.SDO_POINT which you want to render by a single attribute containing 20 values, consider aggregating the data using this attribute AND some sort of spatial BUCKET or BIN. So, consider using SDO_AGGR_UNION coupled with Spatial Analysis and Mining package functions to GROUP the data BY <<column_name>> and a set of spatial extents.
6. Tablespace use
Finally, talk to your DBA in order to find out how the oracle database's physical and logical storage is organised. Is a SAN being used or SAME arranged disk arrays? Knowing this you can organise your spatial data and indexes using more effective and efficient methods that will ensure greater scalability.
7. Network fetch
If your rendering engine (app server) and database are on separate machines you need to investigate what sort of fetch sizes are being used when returning data from queries to the middle-tier. Fetch sizes for attribute only data rows and rows containing spatial data can be, and normally are, radically different. Accepting the default settings for these sizes could be killing you (as could the sort_area_size of the Oracle session the application server has created on the database). For example I have been informed that MapInfo Pro uses a fixed value of 25 records per fetch when communicating with Oracle. I have done some testing to show that this value can be too small for certain types of spatial data. SQL Developer's GeoRaptor uses 100 which is generally better (but this one can modify this). Most programmers accept defaults for network properties when programming in ADO/ODBC/OLEDB/JDBC: just be careful as to what is being set here. (This is one of the great strengths of ArcSDE: its TCP/IP network transport is well written, tuneable and very efficient.)
8. Physical Format
Finally, while Oracle's excellent MapViewer requires data its spatial data to be in Oracle, other commercial rendering engines do not. So, consider using alternate, physical file formats that are more optimal for your rendering engine. For example, Google Earth Enterprise "compiles" all the source data into an optimal format which the server then serves to Google Earth Enterprise clients. Similarly, a shapefile on local disk to the application server (with spatial indexing) may be faster that storing the data back in Oracle on a database server that is being shared with other business databases (eg Oracle financials). If you don't like this approach and want to use Oracle only consider using a dedicated Oracle XE on the application server for the data that is read only and used in most of your generated maps eg contour or drainage data.
Just some things to think about.
regards
Simon

Export with embedded spatial query

I am trying to use the exp utility to export spatial data. I am using the "query" parameter to specify a spatial query based on another spatial layer.
I have two layers. Admin1 has lots of administrative boundaries. PE has three polygons in it over different sections of my data set. I want to get the data extracted from admin1 that exists in these areas to an export file(along with all the triggers and other related database objects). I was hoping this approach would work
I am getting errors saying that the identifier is too long.
Here is the par file:
file=1.exp
log=1.log
tables=(admin1, pe)
query="""WHERE mdsys.SDO_RELATE(GEOM1,pe.GEOM, 'MASK=INSIDE QUERYTYPE=WINDOW')='TRUE' OR SDO_RELATE(GEOM2,pe.GEOM, 'MASK=INSIDE QUERYTYPE=WINDOW')='TRUE'"""
I get:
Export: Release 10.2.0.1.0 - Production on Wed May 10 11:56:14 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Produc
tion
With the Partitioning, OLAP and Data Mining options
Export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
About to export specified tables via Conventional Path ...
. . exporting table ADMIN1
EXP-00056: ORACLE error 972 encountered
ORA-00972: identifier is too long
. . exporting table PE
EXP-00056: ORACLE error 972 encountered
ORA-00972: identifier is too long
Export terminated successfully with warnings.
Is this even possible? Can you use the exp query parameter to perform a spatial operation? Did this work? I am accustom to seeing record counts next to the exported tables, and they are not present in the output from exp. The export file is not empty. It exported all the features, not the subset I had requested.
How can I structure the query differently so that I get the export file with just the lines that fall within the polygons?
Thanks,
John

I am trying to use the exp utility to export spatial data. I am using the "query" parameter to specify a spatial query based on another spatial layer.
I have two layers. Admin1 has lots of administrative boundaries. PE has three polygons in it over different sections of my data set. I want to get the data extracted from admin1 that exists in these areas to an export file(along with all the triggers and other related database objects). I was hoping this approach would work
I am getting errors saying that the identifier is too long.
Here is the par file:
file=1.exp
log=1.log
tables=(admin1, pe)
query="""WHERE mdsys.SDO_RELATE(GEOM1,pe.GEOM, 'MASK=INSIDE QUERYTYPE=WINDOW')='TRUE' OR SDO_RELATE(GEOM2,pe.GEOM, 'MASK=INSIDE QUERYTYPE=WINDOW')='TRUE'"""
I get:
Export: Release 10.2.0.1.0 - Production on Wed May 10 11:56:14 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Produc
tion
With the Partitioning, OLAP and Data Mining options
Export done in WE8MSWIN1252 character set and AL16UTF16 NCHAR character set
About to export specified tables via Conventional Path ...
. . exporting table ADMIN1
EXP-00056: ORACLE error 972 encountered
ORA-00972: identifier is too long
. . exporting table PE
EXP-00056: ORACLE error 972 encountered
ORA-00972: identifier is too long
Export terminated successfully with warnings.
Is this even possible? Can you use the exp query parameter to perform a spatial operation? Did this work? I am accustom to seeing record counts next to the exported tables, and they are not present in the output from exp. The export file is not empty. It exported all the features, not the subset I had requested.
How can I structure the query differently so that I get the export file with just the lines that fall within the polygons?
Thanks,
John

How to calculate the area of a large number of polygons in a single query

Hi forum
Is it possible to calculate the area of a large number of polygons in a single query using a combination of SDO_AGGR_UNION and SDO_AREA? So far, I have tried doing something similar to this:
select sdo_geom.sdo_area((
select sdo_aggr_union (   sdoaggrtype(mg.geoloc, 0.005))
from mapv_gravsted_00182 mg
where mg.dblink = 521 or mg.dblink = 94 or mg.dblink = 38 <many many more....>),
0.0005) calc_area from dualThe table MAPV_GRAVSTED_00182 contains 2 fields - geoloc (SDO_GEOMETRY) and dblink (Id field) needed for querying specific polygons.
As far as I can see, I need to first somehow get a single SDO_GEOMETRY object and use this as input for the SDO_AREA function. But I'm not 100% sure, that I'm doing this the right way. This query is very inefficient, and sometimes fails with strange errors like "No more data to read from socket" when executed from SQL Developer. I even tried with the latest JDBC driver from Oracle without much difference.
Would a better approach be to write some kind of stored procedure, that adds up all the single geometries by adding each call to SDO_AREA on each single geometry object - or what is the best approach?
Any advice would be appreciated.
Thanks in advance,
Jacob

Hi
I am now trying to update all my spatial table with SRID's. To do this, I try to drop the spatial index first to recreate it after the update. But for a lot of tables I can't drop the spatial index. Whenever I try to DROP INDEX <spatial index name>, I get this error - anyone know what this means?
Thanks,
Jacob
Error starting at line 2 in command:
drop index BSSYS.STIER_00182_SX
Error report:
SQL Error: ORA-29856: error occurred in the execution of ODCIINDEXDROP routine
ORA-13249: Error in Spatial index: cannot drop sequence BSSYS.MDRS_1424B$
ORA-13249: Stmt-Execute Failure: DROP SEQUENCE BSSYS.MDRS_1424B$
ORA-29400: data cartridge error
ORA-02289: sequence does not exist
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 27
29856. 00000 - "error occurred in the execution of ODCIINDEXDROP routine"
*Cause:    Failed to successfully execute the ODCIIndexDrop routine.
*Action:   Check to see if the routine has been coded correctly.
Edit - just found the answer for this in MetaLink note 241003.1. Apparently there is some internal problem when dropping spatial indexes, some objects gets dropped that shouldn't be. Solution is to manually create the sequence it complains it can't drop, then it works... Weird error.

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

Creating spatial index on spatial table

Hi there. Just a quick query on creating spatial indexes on spatial tables. I have a table called System_Sessions which has the following four fields and types:
USER_ID NUMBER(10)
SESSION_ID NUMBER(10)
SESSION_BOUNDARY MDSYS.SDO_GEOMETRY (polygon)
START_POINT MDSYS.SDO_GEOMETRY (point)
I am inserting one row per user session into this table. I also need to retrieve the session ids of previous sessions involving a particular user based on the session's start point. The query i am running is an sdo_within_distance query which looks as follows:
Select session_id from joeweaker.system_sessions where user_id = 1003 and SDO_WITHIN_DISTANCE(start_point,
(MDSYS.SDO_GEOMETRY(2001, 8265, MDSYS.SDO_POINT_TYPE
(-105.0,40.0, NULL),NULL, NULL)), 'DISTANCE = 10000')='TRUE';
However I encounter the following error whenever I attempt to execute this query:
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 255
I know I haven't built the spatial index on the table so I was hoping that somebody might show me how to do this. Thnaks a lot, Joe

Thnaks a lot Dan for the prompt reply. I have done as you advised and everything appears to be fine. However I have a second table called Session_Interest_Areas which appears as follows:
USER_ID----NUMBER(10)
SESSION_ID----NUMBER(10)
AREA_ID----NUMBER(10)
AREA_BOUNDARY----MDSYS.SDO_GEOMETRY
I inserted the necessary detail into the user_sdo_geom_metadata table and then attempted to create the index as follows (exactly the same format as my other spatial tables:
create index session_interest_areas_idx on
session_interest_areas (area_boundary)
indextype is mdsys.spatial_index;
When I execute this query I get the following stream of error messages:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13249: Error in Spatial index: index build failed
ORA-13249: Error in spatial index: [mdrcrtxfergm]
ORA-13249: Error in spatial index: [mdpridxtxfergm]
ORA-13200: internal error [ROWID:AAAHocAAJAAAAC8AAA] in spatial indexing.
ORA-13206: internal error [] while creating the spatial index
ORA-13373: Element of type Extent is not supported for Geodetic data
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 7
ORA-06512: at line 1
Why does this give me an error when the same approach worked fine for my other spatial tables? Is it something to do with the SRID? Also the index appears to have been created so I presume it has been created incorrectly. Thanks for your time, Joe

Different Spatial Features in same layer.

Hi,
I'm going storing some spatial data in oracle, all the data is of the same type(same attribution) just some are represented by points and some are represented by polygons.
My inclination is that all the data should be held in the same table as I would do with any other piece of data.
The problem is that the GIS consultants I have consulted on this system all want the data split up by feature type as this is a traditional GIS standard. e.g. all the Points in one table and all the polygons in another table.
Are there any technical Pros or Cons to storing all feature types in the same table in Oracle, indexing, storage, querying etc.
Any recommendations or past experiences are welcomed
Regards,
John

Oracle has no restriction on storage of different geometry types (point, linestring, polygon) in the same column in the same table. As mentioned earlier, some GIS systems do.
Also, Oracle lets you store more than one geometry column in a table (see -.1). This could be useful in this scenario, and others as well (some customers like to store data in different coordinate systems in the same table, some like to store data at different granularity with lots of detail for close viewing, and very coarse when zoomed out).
I believe ESRI tools have the restriction associated the top paragraph, i.e. only one geometry type can be stored in a column.
Other GIS tools have restrictions on the multicolumn approach - they only allow one geometry column on a table.
Hope this helps.

Spatial Polygon Desgin Approach

Similar Messages

Maybe you are looking for