Speeding up of spatial Queries - SDO_Intersection

HI, I'm running a basic query - calculating the area of spatial intersection sbetween two polygonal datasets:
select s.Designation, SUM (
sdo_geom.sdo_area(
sdo_geom.sdo_intersection (s.geoloc, m.geoloc, 0.0005),
*0.0005, 'unit = HECTARE')) total_overlap_area*
**from SPA_v s, os_bdyline_mlw m*
where sdo_relate (s.geoloc, m.geoloc, 'mask=overlapbdyintersect') = 'TRUE'
The problem is that the query is taking a long, long time to run > 8 hours
First of all the datasets are quite complex, they've been captured at a scale of 1:2500 and 1:10,000 on the Ordnance Survey British National Grid, (the formerbeing of 1mm accuracy, therefore the tolerances involved).
Spatial Indexes have been created on the Geoloc - (geometry) - column.
Is there anything I can do to speed this query up (I'm going to have to create this for further datasets) - I've tried reducing the tolerances to 0.5, but hten have problems where I get this error messages:
ERROR at line 4:
ORA-13050: unable to construct spatial object
ORA-06512: at "MDSYS.SDO_3GL", line 715
ORA-06512: at "MDSYS.SDO_GEOM", line 3016
ORA-06512: at "MDSYS.SDO_GEOM", line 3065
Any help gretfully received :-)
Thanks,
Bruce

Hi Ivan, thanks for the response.
Yep, I've validated all of the geometries.
There are 21 SPA's in Wales, and am only using the Boundaryline data for Wales - principally because there are far fewer nodes in this dataset than there would be if I had used the Mean Low Water Mark, derived from OS Mastermap (at 1:2500.
Obviously this is going cause some small errors creeping in where the two datsets do not precisely meet, but this would probably be within the acceptable range. The other thing I could do would be to thin the SPA dataset so that it would be at 0.05 tolerance (OS 1:10,000 has a node separation of 10 cm)
Thanks,
Bruce

Similar Messages

Data Retrieval Speed in Oracle Spatial vs. ESRI ArcSDE

I would appreciate any opinions regarding data retrieval
performance between Oracle Spatial and ESRI ArcSDE. Would an end-
user (using ESRI software) experience significant differences in
data retrieval speed depending on how the data were stored in
Oracle (MDSYS.SDO_GEOMETRY verses ESRI Binary/Blob formats).
Knowing that the ESRI binary formats are tailored to their
software front-end apps (ArcGIS, ArcMap, ArcCatalog, and
ArcInfo), wouldn't this be a "non-issue" until the spatial
dataset gets "large", and even then, wouldn't performance be
(almost) equal if the spatial indexes were created properly?
Thanks for your inputs,
Bruce

John,
You can't do that type of query in sql from sql*plus using
SDEBINARY. HOwever, you can perform spatial queries in ArcMap
if you are using SDEBINARY.
You can use the query builder to perform point-in-polygon type
queries.
Hope that helps.
For my two cents, I think SDO_GEOMETRY gives you a more robust
database to work with, because you have the added power of
Oracle Spatial functions. If you are using SDEBINARY you are
limited to only what you can do thru ArcGIS.
If you are concerned more about performance than accessibility,
especially with a large number of users, then SDEBINARY might
be the better choice.
I love Oracle Spatial and am hoping that the performance issue
will not be a serious one when we start putting ArcIMS developed
apps into production.
Dave

Spatial Queries Not Always Producing Accurate Results

Hi,
Spatial queries are not always producing accurate results. Here are the issues. We would appreciate any clarification you could provide to resolve these issues.
1. When querying for points inside a polygon that is not an MBR (minimum bounded rectangle), some of the coordinates returned are not inside the polygon. It is as though the primary filter is working, but not the secondary filter when using sdo_relate. How can we validate that the spatial query using sdo_relate is using the secondary filter?
2. SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT returns true when validating geometries even though we find results that are invalid.
3. Illegal geodetic coordinates can be inserted into a table: latitude > 90.0, latitude < -90.0, longitude > 180.0 or longitude < -180.0.
4. Querying for coordinates outside the MBR for the world where illegal coordinates existed did NOT return any rows, yet there were coordinates of long, lat: 181,91.
The following are examples and information relating to the above-referenced points.
select * from USER_SDO_GEOM_METADATA
TABLE_NAME      COLUMN_NAME      DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE)      SRID
LASTKNOWNPOSITIONS      THE_GEOM SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05), SDO_DIM_ELEMENT('Y', -90, 90, .05))      8307
POSITIONS     THE_GEOM SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05), SDO_DIM_ELEMENT('Y', -90, 90, .05))      8307
Example 1: Query for coordinates inside NON-rectangular polygon includes points outside of polygon.
SELECT l.vesselid, l.latitude, l.longitude, TO_CHAR(l.observationtime,
'YYYY-MM-DD HH24:MI:SS') as obstime FROM lastknownpositions l where
SDO_RELATE(l.the_geom,SDO_GEOMETRY(2003, 8307, NULL,
SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(-98.20268,18.05079,-57.30101,18.00705,-57.08229,
54.66061,-98.59638,32.87842,-98.20268,18.05079)),'mask=inside')='TRUE'
This query returns the following coordinates that are outside of the polygon:
vesselid : 1152 obstime : 2005-08-24 06:00:00 long : -82.1 lat : 45.3
vesselid : 3140 obstime : 2005-08-28 12:00:00 long : -80.6 lat : 44.6
vesselid : 1253 obstime : 2005-08-22 09:00:00 long : -80.0 lat : 45.3
Example 2a: Using SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
Select areaid, the_geom,
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(the_geom, 0.005) from area where
areaid=24
ResultSet:
AREAID THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO,
SDO_ORDINATES) SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(THE_GEOM,0.005)
24 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(-98.20268, 18.05079, -57.30101, 18.00705, -57.08229, 54.66061, -98.59638, 32.87842, -98.20268, 18.05079)) TRUE
Example 2b: Using SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
Select positionid, vesselid, the_geom,
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(the_geom, 0.005) from positions where vesselid=1152
ResultSet:
POSITIONID VESSELID THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z),
SDO_ELEM_INFO, SDO_ORDINATES) DO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(THE_GEOM,0.005)
743811 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-82.1, 45.3, NULL), NULL, NULL) TRUE
743812 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-82.1, 45.3, NULL), NULL, NULL) TRUE
743813 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-80.2, 42.5, NULL), NULL, NULL) TRUE
743814 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-80.2, 42.5, NULL), NULL, NULL) TRUE
Example 3: Invalid Coordinate values found in POSITIONS table.
SELECT p.positionid, p.latitude, p.longitude, p.the_geom FROM positions p
WHERE p.latitude < -180.0
2 lines from ResultSet:
POSITIONID LATITUDE LONGITUDE THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
714915 -210.85408 -79.74449 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-79.74449, -210.85408, NULL), NULL, NULL)
714938 -211.13632 -79.951256 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-79.951256, -211.13632, NULL), NULL, NULL)
SELECT p.positionid, p.latitude, p.longitude, p.the_geom FROM positions p
WHERE p.longitude > 180.0
3 lines from ResultSet:
POSITIONID LATITUDE LONGITUDE THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
588434 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
589493 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
589494 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
Example 4: Failure to locate illegal coordinates by querying for disjoint coordinates outside of MBR for the world:
SELECT p.vesselid, p.latitude, p.longitude, p.the_geom,
TO_CHAR(p.observationtime, 'YYYY-MM-DD HH24:MI:SS') as obstime,
SDO_GEOM.RELATE(p.the_geom, 'determine',
SDO_GEOMETRY(2003, 8307, NULL,SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(-180.0,-90.0,180.0,-90.0,180.0,90.0,
-180.0,90.0,-180.0,-90.0)), .005) relationship FROM positions p where
SDO_GEOM.RELATE(p.the_geom, 'disjoint', SDO_GEOMETRY(2003, 8307,
NULL,SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(-180.0,-90.0,180.0,-90.0,180.0,90.0,-80.0,90.0,
-180.0,-90.0)),.005)='TRUE'
no rows selected
Carol Saah

Hi Carol,
1) I think the results are correct. Note in a geodetic coordinate system adjacent points in a linestring or polygon are connected via geodesics. You are probably applying planar thinking to an ellipsoidal problem! I don't have time to do the full analysis right now, but a first guess is that is what is happening.
2) The query window seems to be valid. I don't think this is a problem.
3) Oracle will let you insert most anything into a table. In the index, it probably wraps. If you validate, I think the validation routines will tell you is is illegal if you use the signature with diminfo, where the coordinate system bounds are included in the validation.
4) Your query window is not valid. Your data is not valid. As the previous reply stated, you need to have valid data. If you think in terms of a geodetic coordinate system, you will realize that -180.0,-90.0 and 180.0,-90.0 are really the same point. Also, Oracle has a rule that polygon geometries cannot be greater than half the surface of the Earth.
Hope this helps.

Spatial Queries are CPU bound and show very heavy use of query buffers

Hi,
Spatial Queries:
When using tkprof to analyse spatial queries it is clear that
there are implicit queries being done by Oracle spatial which
use vast amounts of buffers, and seem unable to cache basic
information from query to query - thus resulting in our machine
being CPU bound when stress testing Oracle Spatial, for example
the example below shows how information which is fixed for a
table and not likely to change very often is being retrieved
inefficiently (note the 26729 query buffers being used to do 6
executions of what should be immediately available!!!):
TKPROF: Release 8.1.7.0.0 - Production on Tue Oct 16 09:43:38
2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SELECT ATTR_NO, ATTR_NAME, ATTR_TYPE_NAME, ATTR_TYPE_OWNER
FROM
ALL_TYPE_ATTRS WHERE OWNER = :1 AND TYPE_NAME = :2 ORDER BY
ATTR_NO
call count cpu elapsed disk query rows
Parse 6 0.00 0.01 0 0 0
Execute 6 0.00 0.01 0 0 0
Fetch 6 0.23 0.41 0 26729 5
total 18 0.23 0.43 0 26729 5
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE)
Rows Row Source Operation
0 SORT ORDER BY
0 FILTER
1 NESTED LOOPS
1 NESTED LOOPS
290 NESTED LOOPS
290 NESTED LOOPS
290 NESTED LOOPS
290 NESTED LOOPS
290 TABLE ACCESS FULL ATTRIBUTE$
578 TABLE ACCESS CLUSTER TYPE$
578 TABLE ACCESS CLUSTER TYPE$
578 INDEX UNIQUE SCAN (object id 255)
578 TABLE ACCESS BY INDEX ROWID OBJ$
578 INDEX RANGE SCAN (object id 35)
578 TABLE ACCESS CLUSTER USER$
578 INDEX UNIQUE SCAN (object id 11)
289 TABLE ACCESS BY INDEX ROWID OBJ$
578 INDEX RANGE SCAN (object id 35)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN (object id 11)
0 FIXED TABLE FULL X$KZSPR
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN (object id 101)
error during parse of EXPLAIN PLAN statement
ORA-01039: insufficient privileges on underlying objects of the
view
and again:
SELECT diminfo, nvl(srid,0)
FROM
ALL_SDO_GEOM_METADATA WHERE OWNER = 'NAGYE' AND TABLE_NAME =
NLS_UPPER('TILE_MED_LINES_MBR') AND '"'||COLUMN_NAME||'"'
= '"GEOM"'
call count cpu elapsed disk query
current rows
Parse 20 0.00 0.04 0
0 0 0
Execute 20 0.00 0.00 0
0 0 0
Fetch 20 0.50 0.50 0 5960
100 20
total 60 0.50 0.54 0 5960
100 20
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE) (recursive depth: 1)
Rows Row Source Operation
1 FILTER
2 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE
2 INDEX RANGE SCAN (object id 24672)
1 UNION-ALL
1 FILTER
1 NESTED LOOPS
1 NESTED LOOPS
1 NESTED LOOPS OUTER
1 NESTED LOOPS OUTER
1 NESTED LOOPS OUTER
1 NESTED LOOPS OUTER
1 NESTED LOOPS
1 TABLE ACCESS FULL OBJ$
1 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN (object id 3)
0 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX UNIQUE SCAN (object id 33)
0 INDEX UNIQUE SCAN (object id 33)
0 TABLE ACCESS CLUSTER USER$
1 INDEX UNIQUE SCAN (object id 11)
1 TABLE ACCESS CLUSTER SEG$
1 INDEX UNIQUE SCAN (object id 9)
1 TABLE ACCESS CLUSTER TS$
1 INDEX UNIQUE SCAN (object id 7)
1 TABLE ACCESS CLUSTER USER$
1 INDEX UNIQUE SCAN (object id 11)
0 FILTER
0 NESTED LOOPS
0 NESTED LOOPS OUTER
0 NESTED LOOPS
0 TABLE ACCESS FULL USER$
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX RANGE SCAN (object id 34)
0 INDEX UNIQUE SCAN (object id 97)
0 INDEX UNIQUE SCAN (object id 96)
0 FIXED TABLE FULL X$KZSPR
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN (object id 101)
0 FIXED TABLE FULL X$KZSPR
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN (object id 101)
error during parse of EXPLAIN PLAN statement
ORA-01039: insufficient privileges on underlying objects of the
view
Note: The actual query being performed is:
select a.id, a.geom
from
tile_med_lines_mbr a where sdo_relate(a.geom,mdsys.sdo_geometry
(2003,NULL,
NULL,mdsys.sdo_elem_info_array
(1,1003,3),mdsys.sdo_ordinate_array(151.21121,
-33.86325,151.21132,-33.863136)), 'mask=anyinteract
querytype=WINDOW') =
'TRUE'
call count cpu elapsed disk query
current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.08 0.08 0 4 0 0
Fetch 5 1.62 21.70 0 56 0 827
total 7 1.70 21.78 0 60 0 827
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE)
Rows Row Source Operation
827 TABLE ACCESS BY INDEX ROWID TILE_MED_LINES_MBR
828 DOMAIN INDEX
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
827 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
'TILE_MED_LINES_MBR'
828 DOMAIN INDEX OF 'TILE_MLINES_SPIND'
CPU: none, I/O: none
call count cpu elapsed disk query
current rows
Parse 1 0.00 0.00 0 92
Execute 1 0.00 0.00 0 22
Fetch 1 0.00 0.00 38 236
total 3 0.00 0.00 38 350
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE)
Rows Row Source Operation
12 TABLE ACCESS BY INDEX ROWID ROADELEMENT_MBR
178 DOMAIN INDEX
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
12 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
'ROADELEMENT_MBR'
178 DOMAIN INDEX OF 'RE_MBR_SPIND'
CPU: none, I/O: none
Can Oracle improve the performance of Oracle spatial by
improving the implementation so as to perform alternative
implicit queries so as not to use these vast amounts of memory?
Cheers
Alex Eadie

Hi Ravi,
Thankyou for your reply.
Here are some more details for you:
Yes the queries are cached in that it gets its data from RAM and
not from disk however the number of buffers used internally by
Oracle RDBMS/Spatial is rather large and results in significant
CPU usage (namely > 5000 per query or >40MByte). Which I'm sure
you'd agree? Those numerous internal queries taking >10ms CPU
time each, which is culmulative.
A single real of ours query of will take between 180ms and 580ms
depending on the number of results returned.
An example query is:
select a.id, a.geom
from tile_med_lines_mbr a where sdo_relate
(a.geom,mdsys.sdo_geometry
(2003,NULL, NULL,mdsys.sdo_elem_info_array
(1,1003,3),mdsys.sdo_ordinate_array(151.21121,
-33.86325,151.21132,-33.863136)), 'mask=anyinteract
querytype=WINDOW') = 'TRUE'
Our 500Mhz PC Server database can only execute 3 processes
running these queries simultaneously to go to 100% CPU loaded.
The disk is hardly utilized.
The data is the main roads in Sydney, Australia.
The tables, data and indexes were created as shown below:
1.     Create the Oracle tables:
create table tile_med_nodes_mbr (
     id     number not null,
     geom     mdsys.sdo_geometry not null,
     xl     number not null,
     yl     number not null,
     xh     number not null,
     yh     number not null);
create table tile_med_lines_mbr (
     id     number not null,
     fromid     number not null,
     toid     number not null,
     geom     mdsys.sdo_geometry not null,
     xl     number not null,
     yl     number not null,
     xh     number not null,
     yh     number not null);
2.     Use the sqlldr Oracle loader utility to load the data
into Oracle.
% sqlldr userid=csiro_scats/demo control=nodes.ctl
% sqlldr userid=csiro_scats/demo control=lines.ctl
3.     Determine the covering spatial extent for the tile
mosaic and use this to create the geometry metadata.
% sqlplus
SQLPLUS>     set numw 12
SQLPLUS>     select min(xl), min(yl), max(xh), max(yh)
     from (select xl, yl, xh, yh
          from tile_med_nodes_mbr union
          select xl, yl, xh, yh
          from tile_med_lines_mbr);
insert into USER_SDO_GEOM_METADATA
     (TABLE_NAME, COLUMN_NAME, DIMINFO)
     VALUES ('TILE_MED_NODES_MBR', 'GEOM',
     MDSYS.SDO_DIM_ARRAY
     (MDSYS.SDO_DIM_ELEMENT('X', 151.21093421,
               151.21205421, 0.000000050),
     MDSYS.SDO_DIM_ELEMENT('Y', -33.86347146,
               -33.86234146, 0.000000050)));
insert into USER_SDO_GEOM_METADATA
     (TABLE_NAME, COLUMN_NAME, DIMINFO)
     VALUES ('TILE_MED_LINES_MBR', 'GEOM',
     MDSYS.SDO_DIM_ARRAY
     (MDSYS.SDO_DIM_ELEMENT('X', 151.21093421,
               151.21205421, 0.000000050),
     MDSYS.SDO_DIM_ELEMENT('Y', -33.86347146,
               -33.86234146, 0.000000050)));
4.     Validate the data loaded:
create table result
(UNIQ_ID number, result varchar2(10));
execute sdo_geom.validate_layer
('TILE_MED_NODES_MBR','GEOM','ID','RESULT');
select result, count(result)
from RESULT
group by result;
truncate table result;
execute sdo_geom.validate_layer
('TILE_MED_LINES_MBR','GEOM','ID','RESULT');
select result, count(result)
from RESULT
group by result;
drop table result;
5.     Fix any problems reported in the result table.
6.     Create a spatial index, use the spatial index advisor to
determine the sdo_level.
create index tile_mlines_spind on
tile_med_lines_mbr (geom) indextype is
mdsys.spatial_index parameters
( 'sdo_level=7,initial=1M,next=1M,pctincrease=0');
7.     Analyse table:
analyze table TILE_MED_LINES_MBR compute statistics;
8.     Find the spatial index table name:
select sdo_index_table, sdo_column_name
from user_sdo_index_metadata
where sdo_index_name in
(select index_name
from user_indexes
where ityp_name = 'SPATIAL_INDEX'
and table_name = 'TILE_MED_LINES_MBR');
9.     Analyse spatial index table:
analyze table TILE_MLINES_SPIND_FL7$
compute statistics;
I hope this helps.
Cheers
Alex Eadie

Clipping algorithm implemented in Oracle Spatial for SDO_INTERSECTION

Hi!
Does anybody knows which clipping algorithm is implemented in Spatial for SDO_INTERSECTION function in 10g or 11g? It's probably some of well-known algorithm (Sutherland–Hodgman, Weiler–Atherton, Vatti ...) with some modifications made to it. I'm just not sure which one. I'm doing a short presentation on Oracle Spatial clipping capabilities so that info might come in handy.
Thanks!
rawcofe

Thanks for your post. Yes, Sutherland-Hodgman is good and easy to implement if you have convex clipping polygons. However, i do not need to implement it. I just want to know which algorithm Oracle Spatial uses for clipping so I can describe it in greater detail during my presentation. :-)

Continual library cache misses in trace file for spatial queries

Hi all,
Could somebody explain to me how the SQL parse engine works for spatial queries.
My understanding is that Oracle creates a hash value for SQL that is parsed with no errors. This hash value is then stored in the library cache ready to be matched against other incoming SQL statements. This provides one of the main reasons for using parametising SQL in languages such as PL/SQL, .Net etc and improves performance on query intensive applications.
However i have noticed that for spatial, any queries except for refreshes of identical ones already sent, the SQL engines re parses the query. This can take upto 0.2 seconds which is causing a performance bottle neck.
When looking at the full trace file of a single spatial query using SDO_FILTER with a query window the amount of additional internal queries that are performed is quiet a lot. Are these additional queries included in the total parse time?
I am wondering why for spatial queries the only way to get a hit in the library cache was to refresh an exact same SQL that had been previously sent?
Thanks
Daniel

Those additional internal queries are not included in the parse time,
if they are used in the execution time.
Edited by: yhu on Mar 4, 2011 10:52 AM

Spatial queries using Discoverer 3i

We are looking for a web reporting tool for an Oracle 8i Spatial database. Spatial queries are very important to us. Would it make sense and would it be possible to use Oracle Discoverer 3i? This product does not seem to talk the language of a 'spatial user'.

Thanks Dan,
Presumably, it would currently be possible to use Discoverer on database views with fixed spatial where-clauses. Is that right? If so, would it currently also be possible to have a parameterised spatial where-clause, allowing a user for instance to define the spatial view for his particular region. Does Discoverer somehow allow for this?
null

Combining 2 spatial queries into 1

Hi there. I want to merge two different spatial queries both of which return a single aspect of what I need. The first query returns the distinct group feature ids of all those geometries falling within a specified tolerance of a particular point, i.e. each geometry belongs to one feature id type:
select distinct a2.cfcc from GEOMETRY_MAP.GEOM_POINT$_TABLE a1,
attribute_map.landmark_table a2 where SDO_WITHIN_DISTANCE
(location, (MDSYS.SDO_GEOMETRY(2001, 8265, MDSYS.SDO_POINT_TYPE(-104.9,39.9,null),NULL, NULL)), 'DISTANCE = 10000')='TRUE'
and a1.land = a2.land order by cfcc;
The following results are returned (one for each feature id) e.g. D43 is the id for schools but many schools may have fallen within the specified distance:
CFCC
D43
D44
D61
D65
The second query returns the feature ids of geometries AND their distances from the specified point and looks as follows:
select distinct a2.cfcc, sdo_geom.sdo_distance(location, b.pgeom, 0.005) distance from GEOMETRY_MAP.GEOM_POINT$_TABLE a1, attribute_map.landmark_table a2, (select MDSYS.SDO_GEOMETRY(2001,8265,MDSYS.SDO_POINT_TYPE(-104.9,39.9,null), NULL, NULL) pgeom from dual)b where a1.land = a2.land and SDO_WITHIN_DISTANCE (location, b.pgeom, 'DISTANCE = 10000')='TRUE' order by cfcc, distance;
The results of this query are:
CFCC DISTANCE
D43 4025.459
D43 5585.05361
D43 5589.70435
D61 7770.4209
D65 6223.59763
D65 7929.03858
As you can see the second query returns not just the feature id but the associated distance of each individual feature of that type. What I would like to do is to merge the two result sets so that only the closest individual feature of a particular type and its distance from the input point is returned, i.e. I only need the closest school as oppose to all the closest schools. Any ideas? Thanks a lot, Joe

Hi Richard. Thnaks for your reply. I should have mentioned that more than one feature type is returned, i.e. not just schools, and so ROWNUM = 1 would not work in this scenario. Any other ideas. Cheers, Joe

Sample SQL code ( Oracle Spatial queries)

Hi All,
Can anyone tell me where can I get sample spatial queries.
Please tell me the urls for spatial queries.
Thank you
Anju

Hi All,
Can anyone tell me where can I get sample spatial queries.
Please tell me the urls for spatial queries.
Thank you
AnjuHow about the spatial users guide which is available on
http://technet.oracle.com/doc/inter.815/a67295/toc.htm
It also contains example statements.
There is also a
spatial_users_guide_817.pdf available
Gerjan

How to speed up SQL spatial query (spatial index error)

Hi,
Im trying to split polylines by points which have a small buffer around them. Currently i have over 370,000 lines and 320,000 nodes and the query is running really slowly (ive left it for 3 days and it still hasnt completed). I have tried forcing a spatial
index using with (Index(SI_tempPD)) but i get the following error:
"The query processor could not produce a query plan for a query with a spatial index hint. Reason: Could not find required binary spatial method in a condition. Try removing the index hints or removing SET FORCEPLAN."
below is the snippet of code that im trying to run when i get the error:
BEGIN INSERT INTO TempLines ( [linenum] ,[ogr_geometry] ) SELECT lines.[linenum] ,lines.[ogr_geometry].STDifference(points.[ogr_geometry].STBuffer(0.005)) AS ogr_geometry FROM dbo.TemplineData AS lines with(Index(SI_tempPD)) INNER JOIN dbo.[TemplineNodes] AS points ON lines.[ogr_geometry].STIntersection(points.[ogr_geometry]).STDistance(points.[ogr_geometry]) < 1 WHERE (lines.[linenum] <> points.[linenum]) END
is there anyway i can speed up the query? (I also have a clustered primary key) the execution plan shows that a filter takes up 36% of the cost and the insert takes up 64%
Any help would be greatly appreciated! (im using SQL Server 2008 (SQL server Management studio 10.50.1600.1))

SQL Server spatial indexes don't support STDifference or STIntersection, see
https://technet.microsoft.com/en-us/library/bb895373(v=SQL.105).aspx, which is why you get the error.
Your query is doing multiple expensive spatial operations against some fairly good-size tables in a join. You might get better results by either breaking the query into multiple simpler queries (SELECT into a temporary table and move the STDifference and
STBuffer and INSERT off to a separate statement), and (if possible) rearchitecting the query to use STIntersects (which does support spatial index) rather than STIntersection.
Hope this helps, Bob

Memory Leak With Spatial queries

We are using 8.1.6 on NT (4.0) for spatial data queries. We are facing memory leak problems. At the starting our job will run very fast and after some time it will start slipping. I'm monitoring PGA size from v$sessionstat/v$sysstat and it is regularly increasing. Same is the case for memory on NT machine when I'm monitoring thru performance monitor. I have already applied the spatial patch available for 8.1.6 but no improvement.
Please let me know If there is any workaround. When I'm submitting my job in parts and shutdown the database in between then It is releasing all the memory and It is working fine. Without shutting the database it is not relasing the memory even though I stop my spatial data batch job.
null

Hi,
Thanks for your responses.
This is the query:
SELECT a.geo_id, mdsys.sdo_geom.sdo_length(
mdsys.sdo_cs.transform(
mdsys.sdo_geometry(2002, 8307, null,
mdsys.sdo_elem_info_array(1,2,1),
mdsys.sdo_ordinate_array(' | |
longi | |
', ' | |
lati | |
a.geo_geometry.sdo_point.x,
a.geo_geometry.sdo_point.y )),
mdsys.sdo_dim_array(mdsys.sdo_dim_element(' | |
'''' | |
'X' | |
'''' | |
',-180,180, .00000005),
mdsys.sdo_dim_element(' | |
'''' | |
'Y' | |
'''' | |
',-90,90, .00000005)), 41004),
.00000005) * 6.213712e-04 distance_in_miles
FROM ' | |
t_name | |
' a
WHERE mdsys.sdo_nn(a.geo_geometry,
mdsys.sdo_geometry(1, 8307,
mdsys.sdo_point_type(' | |
longi | |
', ' | |
lati | |
', null),
null, null),' | |
'''' | |
'SDO_NUM_RES=5' | |
'''' | |
') = ' | |
'''' | |
'TRUE' | |
'''' | |
AND a.geo_id ' | |
filter | |
ORDER BY 2;
Here we are passing the tname and filter dynamically based on certain conditions and the memory leak is almost 100K to 200K per query.
First I tried to closing the session only but that didn't work. Database shutdown is only able to release the memory. I'm monitoring v$sysstat/v$sesstat and size of oracle.exe in NT performance monitor. Please let me know If something else need to be monitor.
Thanks.
Sandeep
null

Geodetic spatial queries - sdo_relate

Hello,
The following script populates a spatial table with points on a query boundary and then queries that table using the query boundary. When using a srid of 8307 not all of the points are returned using sdo_relate. If the srid is NULL then all points 'on' the query boundary are returned.
In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
Thanks in advance,
Rick
========= Script follows ============
geomdetic relate test case
This script demonstrates cases where sdo_relate, in a geodetic coordate system where
"A two point line on a given meridian, doesn't necessarily follow that meridian,
so any feature touching that meridian between those two points is not necessarily
touching that line""
The script generates an input query boundary using max and min values. It inserts
point features on the query boundary at input interval into a test table. '
A spatial query is executed against the test table using the query boundary.
DECLARE
TYPE ord_type IS TABLE OF NUMBER
INDEX BY BINARY_INTEGER;
x_tab ord_type;
y_tab ord_type;
maxlon NUMBER DEFAULT 65;
minlon NUMBER DEFAULT 64;
maxlat NUMBER DEFAULT 45 ;
minlat NUMBER DEFAULT 44;
INCREMENT NUMBER DEFAULT 0.001;
offset number default 0;
srid number default 8307;
curval NUMBER;
objectnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (objectnotexists, -942);
indexnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (indexnotexists, -1418);
PROCEDURE populate_array (
p_minval IN NUMBER,
p_maxval IN NUMBER,
p_increment IN NUMBER,
p_array IN OUT ord_type
IS
i BINARY_INTEGER DEFAULT 0;
BEGIN
curval := p_minval;
LOOP
p_array (i) := curval;
curval := curval + INCREMENT;
i := i + 1;
EXIT WHEN curval > p_maxval;
END LOOP;
END populate_array;
PROCEDURE insert_points_on_tangent (
p_tangent IN NUMBER,
p_ords IN ord_type,
orientation IN VARCHAR
IS
v_geom MDSYS.SDO_GEOMETRY;
i BINARY_INTEGER;
BEGIN
i := p_ords.FIRST; -- get subscript of first element
WHILE i IS NOT NULL
LOOP
IF orientation = 'Y'
THEN
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_tangent,
p_ords (i)
ELSE
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_ords (i),
p_tangent
END IF;
EXECUTE IMMEDIATE 'insert into sdo_relate_geom_test (geom, geom_type) values (:boundary, :geom_tag)'
USING v_geom, orientation || ' ' || i;
i := p_ords.NEXT (i); -- get subscript of next element
END LOOP;
END insert_points_on_tangent;
-- Create a table to hold the geometries.
PROCEDURE TEST
IS
v_geom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_viewportgeom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
0,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_expected NUMBER;
v_relate_results NUMBER;
v_filter_results NUMBER;
v_relate_results_arc NUMBER;
v_dimino MDSYS.SDO_DIM_ARRAY;
v_count_sql VARCHAR2 (1000)
DEFAULT 'select count(*) from sdo_relate_geom_test';
v_filter_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_filter '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
v_relate_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_relate '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
BEGIN
EXECUTE IMMEDIATE v_count_sql
INTO v_expected;
EXECUTE IMMEDIATE v_filter_sql
INTO v_filter_results
USING v_geom;
EXECUTE IMMEDIATE v_relate_sql
INTO v_relate_results
USING v_geom;
DBMS_OUTPUT.put_line ( ' boundary minLat '
|| minlat
|| ' minLon '
|| minlon
|| ' maxLat '
|| maxlat
|| ' maxLon '
|| maxlon
||' increment '
|| INCREMENT
DBMS_OUTPUT.put_line ( 'expected '
|| v_expected
|| ' relate returned '
|| v_relate_results
|| ', '
|| 'filter returned '
|| v_filter_results
|| '. '
DBMS_OUTPUT.put_line('');
END TEST;
BEGIN
BEGIN
EXECUTE IMMEDIATE 'drop table sdo_relate_geom_test';
EXCEPTION
WHEN objectnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create table sdo_relate_geom_test(geom mdsys.sdo_geometry, geom_type VARCHAR2(100))';
-- generate the points we want to test
populate_array (minlon, maxlon, INCREMENT, x_tab);
populate_array (minlat, maxlat, INCREMENT, y_tab);
-- insert the points on the query boundary
insert_points_on_tangent (minlon + offset, y_tab, 'Y');
insert_points_on_tangent (maxlon - offset, y_tab, 'Y');
insert_points_on_tangent (minlat + offset, x_tab, 'X');
insert_points_on_tangent (maxlat - offset, x_tab, 'X');
DELETE user_sdo_geom_metadata
WHERE table_name = 'SDO_RELATE_GEOM_TEST';
INSERT INTO user_sdo_geom_metadata
(table_name, column_name,
diminfo,
srid
VALUES ('SDO_RELATE_GEOM_TEST', 'GEOM',
MDSYS.sdo_dim_array (MDSYS.sdo_dim_element ('x',
-180,
180,
.00000005
MDSYS.sdo_dim_element ('y',
-90,
90,
.00000005
srid
BEGIN
EXECUTE IMMEDIATE 'drop index SDO_RELATE_GEOM_TEST_spa_idx';
EXCEPTION
WHEN indexnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create index SDO_RELATE_GEOM_TEST_spa_idx on SDO_RELATE_GEOM_TEST(geom) indextype is mdsys.spatial_index';
TEST;
END;
/

In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
In Oracle Spatial's support for geodetic coordinates, the line segments connecting consecutive vertices of a polygon or line string are geodesics - the shortest paths between the vertices on the earth spheroid. The shortest path between {30, 50} and {35, 50) does not coincide with the 50 latitude parallel, but goes to higher latitude. Only at the equator does the geodesic connecting points of constant latitude coincide with the latitude parallel.

Example Oracle Spatial Queries for NAVTEQ Data

Hi,
I recently installed NAVTEQ RDF data into an Oracle database. I am new to Oracle Spatial and am looking for some example queries using the NAVTEQ data in the Oracle database.
For example, suppose I have a point (latitude,longitude). What are the queries for each of these:
1) find roads or faces within 5 miles of that point;
2) find roads or faces that cover that point
Thanks!
Bowden

Hi,
There are a lot of of ways to license the data (county, state, country), there are different flavors (mapping, geocoding, and routing), and there are different licensing options for the Oracle platform (user based and cpu/core based). I cannot think of a use case that would approach the cost below.
Feel free to drop me an email (daniel dot abugov at navteq dot com) and we can discuss.
Dan Abugov
NAVTEQ Enterprise Business Development and Consulting

Error while running spatial queries on a table with more than one geometry.

Hello,
I'm using GeoServer with Oracle Spatial database, and this is a second time I run into some problems because we use tables with more than one geometry.
When GeoServer renders objects with more than one geometry on the map, it creates a query where it asks for objects which one of the two geometries interacts with the query window. This type of query always fails with "End of TNS data channel" error.
We are running Oracle Standard 11.1.0.7.0.
Here is a small script to demonstrate the error. Could anyone confirm that they also have this type of error? Or suggest a fix?
What this script does:
1. Create table object1 with two geometry columns, geom1, geom2.
2. Create metadata (projected coordinate system).
3. Insert a row.
4. Create spacial indices on both columns.
5. Run a SDO_RELATE query on one column. Everything is fine.
6. Run a SDO_RELATE query on both columns. ERROR: "End of TNS data channel"
7. Clean.
CREATE TABLE object1
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
'OBJECT1',
'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(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 object1_geom2_sidx ON object1(geom2) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
SELECT *
FROM object1
WHERE
SDO_RELATE("GEOM1", SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), 'MASK=ANYINTERACT') = 'TRUE';
SELECT *
FROM object1
WHERE
SDO_RELATE("GEOM1", SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), 'MASK=ANYINTERACT') = 'TRUE' OR
SDO_RELATE("GEOM2", SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), 'MASK=ANYINTERACT') = 'TRUE';
DELETE FROM user_sdo_geom_metadata WHERE table_name = 'OBJECT1';
DROP INDEX object1_geom1_sidx;
DROP INDEX object1_geom2_sidx;
DROP TABLE object1;
Thanks for help.

This error appears in GeoServer and SQLPLUS.
I have set up a completly new database installation to test this error and everything works fine. I tried it again on the previous database but I still get the same error. I also tried to restart the database, but with no luck, the error is still there. I geuss something is wrong with the database installation.
Anyone knows what could cause an error like this "End of TNS data channel"?

Spatial queries slow

Hi,
I'm working with a point table with approximately 6100 tuples (each has a point geometry)
When I run the query:
SELECT ID, shape FROM POINT_TAB WHERE SDO_FILTER(shape, MDSYS.SDO_GEOMETRY(2003, 1000001, null, MDSYS.SDO_ELEM_INFO_ARRAY( 1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY( 568220.418621453, 8628249.80447949, 575257.418621453, 8632873.80447949) ), 'querytype=window') = 'TRUE';
it takes about 12 seconds.
However when I run an equivalent query using the Spatial Index Advisor it takes about 1 second to draw the points on screen.
I've created an R-Tree index on this table.
Please any cues?
Thanks a lot,
Claudio.

Hi Daniel,
Here it is the info youÂ´ve requested:
USER_SDO_GEOM_METADATA
table_name: POINT_TAB
column_name: SHAPE
SDO_DIMINFO: SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -47302, 630691,6, ,5), SDO_DIM_ELEMENT('Y', 8013976, 9044443, ,5))
SRID: 1000001
Oracle Version: 9.2.0.1.0
INDEX creation:
CREATE INDEX Point_RTREE_IDX ON POINT_TAB(shape)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
The query returns 134 rows (out of 6151)
We are using a customized SRID:
WKTEXT: PROJCS["UTM Zone 24, Southern Hemisphere (Aratu)", GEOGCS [ "Aratu", DATUM ["Aratu", SPHEROID ["International 1924", 6378388.000000, 297.000000]], PRIMEM [ "Longitude of Origin", -39.000000 ], UNIT ["Decimal Degree", 0.00048481368110953599]], PROJECTION ["Transverse Mercator"], PARAMETER ["Scale_Factor", 0.999600], PARAMETER ["Central_Meridian", -39.000000], PARAMETER ["False_Easting", 500000.000000], PARAMETER ["False_Northing", 10000000.000000], UNIT ["Meter", 1.000000000000]]
TRACE:
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=70 Card=405 Bytes=15 96915)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'POCOS_TAB' (Cost=70 Card=405 Bytes=1596915)
2 1 DOMAIN INDEX OF 'POCOS_RTREE_IDX'
Many thanks,
Claudio.

Speeding up of spatial Queries - SDO_Intersection

Similar Messages

Maybe you are looking for