Sdo_relate question

Hello all,
thank you for taking the time to read my question.
I have a shapefile called pppoly.shp. It contains objects of type polygon. I would like to do a query that would find ploygons in pppoly.shp that spatially interact in any way with a given point.
Here is the query that I was using:
SELECT geom FROM pppoly WHERE sdo_relate(geom,mdsys.sdo_geometry(2001, 8307, mdsys.sdo_point_type(33.359997,35.17496, NULL) ,NULL, NULL), 'mask=anyinteract querytype=window') = 'TRUE';
The problem is that from looking at this shapefile in ArcView, I know that the point (33.359997,35.17496) is actually within one of the polygons in pppoly.shp. However when I run this query in SQL-Plus , I get no rows returned.
I am really sorry if this is a stupid question. If anyone could suggest anything I would very much appreciate it.
Thank you very much for your time,
Trish.

you have to specify a tolerance as an argument in Relate function (the last argument) which will overrides tolerance in DIMINFO col in GEOM_METADATA(XXX_SDO_GEOM_METADATA) table
if you didn't specify this value in your metadata table you have to specify this in Relate function, or you get nothing in result see Part No. A96630-01 page1-24 ,SDO_GEOM.Relate is similar to other spatial function(e.g. Aggregation) which deals with tolerance
Hope this works!!!

Similar Messages

Question about sdo_relate function

My application has to check if a point geometry is inside (MASK='ANYINTERACT') a polygon geometry. I am trying to figure out if sdo_relate function works with rectangle only or if it works with polygon. I have wrote a few sql test and it seems to work with polygons, but I dont know how it works.
My question is, if the geometry is not a rectangle, why dont I have to use projection to project both geometry into a plane first?
For example if I have a polygon (-140, 35, -139, 36, -139, 35, -140, 34, -140, 35) and a point(-139.3, 35.6) how does sdo_relate finds out if the point is within the polygon without projecting them?
Thanks.

how does oracle connects the points in a polygon that's not on the same latitude or longitude?Your question is a little ambiguous. What do you mean by 'not on the same latitude..'? Are you talking about different coordinate systems? Or do you just mean how does Oracle know whether your point is inside the polygon or not?
If its the former then read:
http://download-uk.oracle.com/docs/html/B14255_01/sdo_cs_concepts.htm#i882173
If the latter, then suffice to say that Oracle Spatial knows how to work these things out in order to return the correct result.
Have a read of the spatial concepts documentation:
http://download-uk.oracle.com/docs/html/B14255_01/sdo_intro.htm

SDO_RELATE ERROR QUESTION 2

I posted a question about the SDO_RELATE function on April 4th, and got back a response that worked, but now I have another one that utilizes the function, but the difference is that now I am relating a table with a MDSYS.SDO_GEOMETRY column with a table that does not have a MDSYS.SDO_GEOMETRY column.
My basic select is this:
select
TC.tc_x_coord X, TC.tc_y_coord , G.NAME
from
TIS_coordinates TC, MT_COUNTIES G
where
SDO_RELATE(GEOMETRY,
MDSYS.SDO_GEOMETRY(2001,41079,
MDSYS.SDO_POINT_TYPE(TC.tc_x_coord,TC.tc_X_coord,NULL),NULL,NULL),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE'
The basic answer to my first post was to place the Geometry with the most records as the first geometry parameter. This did work for the 2 tables with MDSYS.SDO_GEOMETRY column in both. But I can not do this when the MDSYS.SDO_GEOMETRY is defined in the Select, because in order for it to be first there needs to be a spatial index on that table.
I do know that we could spatially enable this table -- But at this time we would prefer not to.
Can someone help or describe another way in which this can be accomplishes.

I'm going to assume this is the problem, since I don't quite follow what problem you are having. I'm assuming that the geometry column is in the mt_counties table.
Change:
SDO_RELATE(GEOMETRY,
to:
SDO_RELATE(G.GEOMETRY,

Problem with SDO_relate when using polygons with holes.

I'm having a problem with sdo_relate. I'm trying to extract all elements from a point table (bdtq_batim_p) that are inside a specific polygon from another table (SDA_MUNIC_SS). The spatial index for both table have been rebuilt and the data from both table is valid.
When I do a count on the query, I know the answer should be 1422 elements (Counted in ArcGIS). However, sdo_relate gives a smaller number of elements in the result set.
The query :
SELECT count(distinct t.identifiant) FROM bdtq_batim_p t, SDA_MUNIC_SS s WHERE s.mus_co_geo = '48015' and sdo_relate( t.SHAPE,s.SHAPE,'mask=anyinteract querytype=window') = 'TRUE'
returns 282 elements. The query with mask=inside, SDO_Anyinteract() and SDO_inside() all give the same result.
I did a test with the following query and the result is 1422 (which is the good result).
SELECT count(distinct t.identifiant) FROM bdtq_batim_p t, SDA_MUNIC_SS s WHERE s.mus_co_geo = '48015' and SDO_WITHIN_DISTANCE( t.SHAPE,s.SHAPE,'distance=0') = 'TRUE';
It's important to note that the polygone (from SDA_MUNIC_SS) that is used for this query have holes in it. I have the same problem with all the polygons from the SDA_MUNIC_SS table that have holes in it. For the polygon without holes, the results are the same for the 2 queries.
My question are :
Why are the result from the two queries different? A query with a buffer of 0 should always return the same result as a query with Anyinteract.
Is there a known problem with SDO_RELATE when using a polygon with holes in it?
Do you have any idea how to solve my problem.

Since i don't have much control on the version of Oracle and Patches that we use in the system, we used a workaround that detects the polygons with holes and uses the SDO_WITHIN_DISTANCE( t.SHAPE,s.SHAPE,'distance=0') = 'TRUE' operator in those case. We saw a slight decline in performance but it now returns the right results. When the system will be patched, we'll come back to the original version and see if the problem is solved.

Can you explain SDO_RELATE and SDO_GEOM.RELATE differences?

Ok, so I'm doing some spatial queries identifying geometries that interact with each other, and everything's groovy until the customer says, ok, get rid of the ones that just touch, which means that a call to SDO_RELATE with an ANYINTERACT mask no longer does the trick. First we tried setting a multiple mask and those queries ran like 9 hours. I figured that since we're burning that much time, we might as well build a table that stores the interaction as identified by DO_GEOM.RELATE with a DETERMINE mask.
Then I noticed an odd thing happening on the way to the forum. For some geometries I get SDO_RELATE with ANYINTERACT returning TRUE and then SDO_GEOM.RELATE returns DISJOINT with the same tolerance that is coded in the metadata (0.5). When tolerance is bumped up to 27, I get TOUCH back. The funny thing is that there are 3 geometries involved here, the reference geom, one that yields TOUCH, and the one that yields DISJOINT.
Stepping back from this behavior, doing some head-scratching and chin-stroking, I ran accross this statement in the Oracle® Spatial User's Guide and Reference 10g Release 2 (10.2) [here.|http://download.oracle.com/docs/html/B14255_01/sdo_operat.htm#i78531]
Unlike with the SDO_GEOM.RELATE function, DISJOINT and DETERMINE masks are not allowed in the relationship mask with the SDO_RELATE operator. This is because SDO_RELATE uses the spatial index to find candidates that may interact, and the information to satisfy DISJOINT or DETERMINE is not present in the index.
Now, how can a function that cannot determine DISJOINT relationships be reliable in determining ANYINTERACT relationships? Actually in this case, the answer we needed is given by SDO_RELATE, as we were looking for a touch relationship for all 3 geometries, except we got the DISJOINT with the SDO_GEOM.RELATE until we cranked up the tolerance.
These are the geometries involved:
Base geom:
SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.9497222222222, 32.0836111111111, -82.2163888888889, 31.7502777777778, -81.9997222222222, 31.4002777777778, -81.9997222222222, 31.8502777777778, -81.9497222222222, 32.0836111111111))
Geom that yields ANYINTERACT and TOUCH:
SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.77888889, 31.3330555608386, -81.59972222, 31.4252777808399, -81.99972222, 31.7997222208455, -81.99972222, 31.4002777808396, -81.88777778, 31.3330555608386, -81.77888889, 31.3330555608386))
Geom that yields ANYINTERACT and DISJOINT:
SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.39166667, 31.6836111108438, -81.34972222, 31.8502777808462, -81.99972222, 31.8500000008462, -81.99972222, 31.7997222208455, -81.59972222, 31.4252777808399, -81.52472222, 31.4377777808401, -81.45805556, 31.5419444408417, -81.47055556, 31.6252777808429, -81.39166667, 31.6836111108438))
Both should touch the base geom along the -81.99972222 or at least both should be disjoint at a tolerance of 0.5 but one is and the other isn't.
So how do I know when to trust SDO_RELATE? How do I know what tolerance will give me consistency?
Oh, yeah, we have the query down to about 45 mins, by using SDO_GEOM.RELATE with DETERMINE and SDO_FILTER in the where clause. (comparing each geometry to each geometry in a table of about 10K rows)

ConSolTed,
It looks to me like the geometries in question are disjoint by 0.000247 meters.
Check my math:
-81.9997222222222 - -81.99972222 = -0.0000000022222 degrees
111,000 meters/degree @equator * -0.0000000022222 * cos(31.4) = -0.000247
So I would expect sdo_geom.relate to return TOUCH for both geometries, and sdo_anyinteract to return TRUE for both, when the tolerance is around .0005 and up. But I've never been good at this math stuff.
Anyone know why ConSolTed's query below, now with a tolerance of 26 meters, returns Disjoint?
SQL> select version from v$instance;
VERSION
10.2.0.4.0
SQL> SELECT
2 SDO_GEOM.RELATE(
3 SDO_GEOMETRY(2003, 8265, NULL, SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.9497
222222222, 32.0836111111111, -82.2163888888889, 31.7502777777778, -81.9997222222222, 31.400277777777
8, -81.9997222222222, 31.8502777777778, -81.9497222222222, 32.0836111111111))
4 , 'determine',
5 SDO_GEOMETRY(2003, 8265, NULL, SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.391666
67, 31.6836111108438, -81.34972222, 31.8502777808462, -81.99972222, 31.8500000008462, -81.99972222,
31.7997222208455, -81.59972222, 31.4252777808399, -81.52472222, 31.4377777808401, -81.45805556, 31.5
419444408417, -81.47055556, 31.6252777808429, -81.39166667, 31.6836111108438))
6 , 26) relationship
7 FROM dual;
RELATIONSHIP
DISJOINT

Inconsistent results with SDO_RELATE and boundary conditions

Hello,
I am using SDO_RELATE to find all points in one table with any interaction with a polygon selected from a second table. Pretty basic stuff. I noticed one point which exactly matches a vertex on the query polygon was not getting selected as expected. Experimenting a bit I found if I embedded the polygon geometry in the query (rather than selecting it from its table) the query selected the point in question! Experimenting further I found if I changed the query relation from ANYINTERACT to TOUCH the point in question was not selected. So my 2 questions are:
1) What would cause this to fail when the query polygon is being selected from the table?
2) How can ANYINTERACT be true but TOUCH be false?
Here is the first query that fails:
SELECT a.point_id
FROM point_table a, poly_table b
WHERE a.point_id = <point which matches poly vertex>
AND b.poly_id = <poly_id>
AND SDO_RELATE (a.geom, b.geom, 'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
Here is the query that works:
SELECT a.point_id
FROM point_table a, poly_table b
WHERE a.point_id = <point which matches poly vertex>
AND SDO_RELATE (a.geom,
MDSYS.SDO_GEOMETRY(2003, 8265, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
MDSYS.SDO_ORDINATE_ARRAY(-82.414884, 28.0094323,
-82.387158, 28.0116258, -82.378891, 28.0131216,
-82.377988, 28.0133894, -82.37555, 28.0143994,
-82.329352, 28.0661089, -82.313207, 28.1006725,
-82.362246, 28.1261981, -82.445319, 28.1139363,
-82.428389, 28.0245891, -82.422103, 28.0117697,
-82.421382, 28.0109085, -82.419096, 28.0099741,
-82.414884, 28.0094323)),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
Here is the second query that fails (ANYINTERACT -> TOUCH):
SELECT a.point_id
FROM point_table a, poly_table b
WHERE a.point_id = <point which matches poly vertex>
AND SDO_RELATE (a.geom,
MDSYS.SDO_GEOMETRY(1003, 8265, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2003, 1),
MDSYS.SDO_ORDINATE_ARRAY(-82.414884, 28.0094323,
-82.387158, 28.0116258, -82.378891, 28.0131216,
-82.377988, 28.0133894, -82.37555, 28.0143994,
-82.329352, 28.0661089, -82.313207, 28.1006725,
-82.362246, 28.1261981, -82.445319, 28.1139363,
-82.428389, 28.0245891, -82.422103, 28.0117697,
-82.421382, 28.0109085, -82.419096, 28.0099741,
-82.414884, 28.0094323)),
'mask=TOUCH querytype=WINDOW') = 'TRUE';
The point geometry being selected from the point_table looks like this:
MDSYS.SDO_GEOMETRY(2001, 8265, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1),
MDSYS.SDO_ORDINATE_ARRAY(-82.445319, 28.1139363))
The metadata for these 2 tables looks like this:
POINT_TABLE
GEOM
SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05),
SDO_DIM_ELEMENT('Y', -90, 90, .05))
8265
POLY_TABLE
GEOM
SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05),
SDO_DIM_ELEMENT('Y', -90, 90, .05))
8265
Both tables have R-tree indexes built.
System is Oracle9i Enterprise Edition Release 9.2.0.5.0 with sdo_version = 9.2.0.5.0
Is it a problem that my points are stored as SDO_ORDINATES? Is the tolerance a factor? Is geodetic data a factor?
Let me know if any other information would be useful and thank you for your help!
James

I am continuing to struggle with this one. I gave up on the SDO_RELATE function under the assumption the tolerance does not come into play for this function (is this true?).
Now I am trying to use the SDO_GEOM.RELATE function with a tolerance to make this work and it is not working as I would expect.
The following 2 queries show the distance between this point and this polygon is 0 yet they are disjoint. How can this be??
Thanks, James
SQL> SELECT SDO_GEOM.SDO_DISTANCE(
2 MDSYS.SDO_GEOMETRY(2001, 8265, NULL,
3 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1),
4 MDSYS.SDO_ORDINATE_ARRAY(-82.445319, 28.1139363)),
5 MDSYS.SDO_GEOMETRY(2003, 8265, NULL,
6 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
7 MDSYS.SDO_ORDINATE_ARRAY(-82.414884, 28.0094323, -82.387158, 28.0116258,
8 -82.378891, 28.0131216, -82.377988, 28.0133894, -82.37555, 28.0143994,
9 -82.329352, 28.0661089, -82.313207, 28.1006725, -82.362246, 28.1261981,
10 -82.4453185022412,28.1139363297581, -82.428389, 28.0245891, -82.422103, 28.0117697,
11 -82.421382, 28.0109085, -82.419096, 28.0099741, -82.414884, 28.0094323)),
12 10)
13 FROM DUAL;
SDO_GEOM.SDO_DISTANCE(MDSYS.SDO_GEOMETRY(2001,8265,NULL,MDSYS.SDO_ELEM_INFO_ARRA
.00000000000000000000
SQL>
SQL> SELECT SDO_GEOM.RELATE(
2 MDSYS.SDO_GEOMETRY(2001, 8265, NULL,
3 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1),
4 MDSYS.SDO_ORDINATE_ARRAY(-82.445319, 28.1139363)),
5 'determine',
6 MDSYS.SDO_GEOMETRY(2003, 8265, NULL,
7 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
8 MDSYS.SDO_ORDINATE_ARRAY(-82.414884, 28.0094323, -82.387158, 28.0116258,
9 -82.378891, 28.0131216,-82.377988, 28.0133894, -82.37555, 28.0143994,
10 -82.329352, 28.0661089, -82.313207, 28.1006725,
11 -82.362246, 28.1261981, -82.4453185022412, 28.1139363297581,
12 -82.428389, 28.0245891, -82.422103, 28.0117697,
13 -82.421382, 28.0109085, -82.419096, 28.0099741, -82.414884, 28.0094323)),
14 10)
15 FROM DUAL;
SDO_GEOM.RELATE(MDSYS.SDO_GEOMETRY(2001,8265,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1,
DISJOINT

Can SDO_RELATE be used to join more than 2 tables?

I'm trying to run a query like this:
SELECT zip, sum(view1.column1), sum(view2.column2)
FROM view1, view2, ZIP_CODES
WHERE SDO_RELATE(view1.geoloc, ZIP_CODES.geoloc, 'mask=INSIDE')='TRUE'
AND SDO_RELATE(view2.geoloc, ZIP_CODES.geoloc, 'mask=INSIDE')='TRUE'
GROUP BY zip;
but get "column ambiguously defined" error. Investigation pointed that error starts to occur right after adding second SDO_RELATE statement. See that all columns are fully qualified. The question is - can I ever run a query which joins 3 tables like this, or should I have a subquery which joins 2 of them, then join that subquery with ZIP_CODES once again to get zip code region, and only then join with second view using SDO_RELATE?

Below, decribe of three dummy tables and the query on them.
The output result (the sum) is a "non-sense" (in my case), but the query has worked.
The geometry of my_tab1 is a POINT, the other two geometries are POLYGON.
hope this help, best regard
Carl
SQL> desc my_tab1
Name Null? Type
ID_TAB NOT NULL NUMBER(10)
PARCEL_CODE NOT NULL CHAR(5)
GEOMETRY MDSYS.SDO_GEOMETRY
SQL> desc my_tab2
Name Null? Type
ID_TAB NUMBER(10)
PARCEL_CODE NOT NULL CHAR(5)
AREA2 NUMBER(11,2)
GEOMETRY MDSYS.SDO_GEOMETRY
SQL> desc my_tab3
Name Null? Type
ID_TAB NUMBER(10)
PARCEL_CODE NOT NULL CHAR(5)
PARCEL_PROG NOT NULL NUMBER(5)
AREA3 NUMBER(11,2)
GEOMETRY MDSYS.SDO_GEOMETRY
SQL> SELECT my_tab1.parcel_code, sum(my_tab2.area2), sum(my_tab3.area3)
2 FROM my_tab1, my_tab2, my_tab3
3 WHERE SDO_RELATE(my_tab2.geometry, my_tab1.geometry, 'mask=CONTAINS')='TRUE'
4 AND SDO_RELATE(my_tab3.geometry, my_tab1.geometry, 'mask=CONTAINS')='TRUE'
5 GROUP BY my_tab1.parcel_code;
PARCE SUM(MY_TAB2.AREA2) SUM(MY_TAB3.AREA3)
00025 11528.38 8839
00090 2966.01 2966
00120 679.77 679.77
00130 3961.89 3962
00132 2866.47 2866.47
00204 6996 6949.04
00213 8256.02 8255.62
00214 2767.81 2767.81
00230 2014.15 2014.15
00232 378.63 378.63
00005 4563.64 4563.64
00020 1044.14 1044
00024 11485.02 11485
00079 709.6 709.6
00084 2373.58 1831.28
00106 12518.92 10199
00116 3210.12 3210.12
00127 2693.7 2693.7
00128 6222.39 6170.82
00137 2278.09 2278.09
00160 18556.94 36495
00166 16220.71 32373
00217 46.95 1870
00241 76167.45 73044.87
00243 76167.45 73044.87
00046 1837.22 1701.27
....

Cannot get sdo_relate to work in a procedure when outputting to MapViewer

Dear all
I am trying to write a query that returns all streets that geographically interact with streets on a chosen map. The following MapViewer XML works but when I run it as a procedure, I get an error message. I've tracked this to the SDO.RELATE part of programme. If I include that in the procedure, it brings up the error message. If I don't, it works. Would anyone know what I am doing wrong?
XML that works:<?xml version="1.0" encoding="UTF-8" ?>
<map_request
format="PNG_URL" width="800" height="600"
datasource="geg00001"
srid="81989">
<themes>
<theme name="map_index" >
   <jdbc_query
   spatial_column="geoloc"
   jdbc_srid="81989"
   datasource="geg00001"
   asis="true">
SELECT b.geoloc
FROM geg50160.map_index A, geg50160.map_index B
WHERE A.name_of_feature LIKE UPPER('%HIGH STREET%')
AND A.index_type_id=320001
AND B.index_type_id=320001
AND A.original_map_sheet_number_id=330017
AND SDO_RELATE
(B.geoloc,
A.geoloc,
'MASK=OVERLAPBDYINTERSECT+EQUAL+INSIDE+COVEREDBY+CONTAINS+COVEERS')
='TRUE'
   </jdbc_query>
</theme>
</themes>
</map_request>Procedure that failscreate or replace procedure procMap_index is
XMLrequest Varchar2(32767);
mapviewerHost varchar2(56) := 'http://tiger.iso.port.ac.uk:7785/mapviewer/omserver';
begin
--construct the xml request
XMLrequest := mapviewerHost||'?xml_request=
<?xml version="1.0" encoding="UTF-8" ?>
<map_request
format="PNG_URL" width="800" height="600"
datasource="geg00001"
srid="81989">
<themes>
<theme name="map_index" >
   <jdbc_query
   spatial_column="geoloc"
   jdbc_srid="81989"
   datasource="geg00001"
   asis="true">
SELECT b.geoloc
FROM geg50160.map_index A, geg50160.map_index B
WHERE A.name_of_feature LIKE UPPER(''%HIGH STREET%'')
AND A.index_type_id=320001
AND B.index_type_id=320001
AND A.original_map_sheet_number_id=330017
AND SDO_RELATE
(B.geoloc,
A.geoloc,
''MASK=OVERLAPBDYINTERSECT+EQUAL+INSIDE+COVEREDBY+CONTAINS+COVEERS'')
=''TRUE''
   </jdbc_query>
</theme>
</themes>
</map_request>';
--Escape the url
XMLrequest := utl_url.escape (XMLrequest);
-- output a link to the map
htp.print('<a href="'||XMLrequest||'">Map</a>');
end;Error message<oms_error>
Message:null
Wed Apr 29 12:13:13 BST 2009
Severity: 0
Description:
Message:null
Wed Apr 29 12:13:13 BST 2009
Severity: 0
Description:
Message:[SDOVIS] No spatial data to render!
Description:
at oracle.sdovis.DBMapMaker.renderEm(DBMapMaker.java:1304)
at oracle.sdovis.MapMaker.renderMap(MapMaker.java:1399)
at oracle.lbs.mapserver.core.RealWorker.generateMapImage(RealWorker.java:573)
at oracle.lbs.mapserver.core.RealWorker.process(RealWorker.java:236)
at oracle.lbs.mapserver.MapServerImpl.renderMap(MapServerImpl.java:189)
at oracle.lbs.mapserver.oms.doPost(oms.java:325)
at oracle.lbs.mapserver.oms.doGet(oms.java:235)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:765)
at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317)
at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:790)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:208)
at com.evermind.server.http.AJPRequestHandler.run(AJPRequestHandler.java:125)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
at java.lang.Thread.run(Thread.java:534)
</oms_error>If anyone has any ideas I would be grateful if you could post them.
Kind regards
Tim

Probably best to try this question over at the MapViewer forum ( MapViewer ).

Invalid results with SDO_RELATE

I am getting what appears to be invalid results when using the ANYINTERACT mask for the SDO_RELATE operator on our 8.1.7 system. The following query counts 85 linear geometries interacting with the "DC" polygon while the same spatial selection in ESRI's ArcGIS counts only 36.
SQL> SELECT COUNT(rch_code)
2 FROM os_linearrch r, state s
3 WHERE s.st = 'DC'
4 AND SDO_RELATE(r.fid, s.geom,
5 'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
COUNT(RCH_CODE)
85
I visualized the data with both ArcGIS and Oracle Spatial Index Advisor and it sure looks like ArcGIS got this one right and Oracle Spatial got it wrong. I can send some screen captures of those results if that would be helpful to anyone. Other evidence that OS is having problems is that if I take one of the linear geometries that doesn't really interact with DC (but OS says it does) and run a SDO_INTERSECTION with DC I get a NULL geometry back indicating that they don't really interact after all:
SQL> SELECT SDO_GEOM.SDO_INTERSECTION(lr.fid, m.diminfo, s.geom, n.diminfo)
2 FROM OS_LINEARRCH lr, state s, all_sdo_geom_metadata m, all_sdo_geom_metadata n
3 WHERE lr.rch_code = '02070010000016'
4 AND s.st = 'DC'
5 AND m.table_name = 'OS_LINEARRCH'
6 AND m.column_name = 'FID'
7 AND n.table_name = 'STATE'
8 AND n.column_name = 'GEOM';
SDO_GEOM.SDO_INTERSECTION(LR.FID,M.DIMINFO,S.GEOM,N.DIMINFO)(SDO_GTYPE, SDO_SRID
SQL>
I have validated the DC polygon and at least one linear geometry that is matching but shouldn't. The actual ordinates have 6-7 digits of precision so I don't think that is the problem (especially considering the fact that SDO_INTERSECTION seems to be working as expected). I'll also post the metadata for the two layers in question below. Any help would be appreciated.
Thanks, James
OWNER TABLE_NAME
COLUMN_NAME
DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE)
SRID
TW STATE
GEOM
SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, -60, .00000005), SDO_DIM_ELEMENT('Y', 1
0, 130, .00000005))
8265
OWNER TABLE_NAME
COLUMN_NAME
DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE)
SRID
RAD OS_LINEARRCH
FID
SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, -60, .00000005), SDO_DIM_ELEMENT('Y', 1
0, 130, .00000005), SDO_DIM_ELEMENT('M', 0, 1214748.37, .00000005))
8265

Further testing showed that I was getting bad results because the polygon geometries were defined using the old 1-digit values for SDO_GTYPE and SDO_ETYPE. When I redefined the polygon geometries using 4-digit values things started working as expected.
James

Question About Geodetic Metadata

Just a quick question about geodetic metadata.
I'm wondering why the documentation says SDO_LB and SDO_UB should be set to -180 and 180 for longitude and -90 and 90 for latitude. Is this just to accomodate geodetic around the globe? Is there any reason I shouldn't set SDO_LB and SDO_UB to values other than what the docs suggest? I can't seem to find a reason for using -180 and -90.
In my testing I've found that using values other than -180 and -90 works just fine as long as my LB and UB cover my MBR. Please let me know if I'm missing something...thanks in advance!

Hi dswing,
For the understanding with geodetic data i would like you reading
Different results using SDO_RELATE with polygon and rectangle type
Re: Size of Area of Interest - smaller equals more records - why?
Re: Different results using SDO_RELATE with polygon and rectangle type
and
http://download-uk.oracle.com/docs/cd/B19306_01/appdev.102/b14255/sdo_cs_concepts.htm#CIHHGHFH
This should answer most of your questions about;
Your question: The answer is inside the matehmatical calculations for some operations. How it is implemented i don'T know; But i think, this is the reason for.
btw: it makes no sense, defining more than/ less than -180 or -90. A circle is a circle is a circle ;) (for latitude/longitude)
regards, Andreas

Oracle Spatial performance question

All,
I am doing a performance test on Oracle 11g Spatial. I am simulating doing searches in 10 degree by 10 degree windows over 6M+ images, six arc minutes per side. Here is my spatial query construction:
String intersectSQL = "SELECT A.name, A.GEOMETRY.Get_WKT() " +
"FROM six_amin_polygons A " +
"WHERE SDO_RELATE(A.GEOMETRY,?, " +
"'mask=inside+coveredby+overlapbdyintersect')='TRUE'";
where the question mark is replaced by the geometry structure of the search window. The results for the first few searches are fast, then the query times balloon very quickly. PostGIS/PostgreSQL performs these searches in an average time of 30 s per window.
Here are the initial (first four rows) of Oracle Spatial results:
area_idx area_name sql_query_time number_results
0 S80.0W90.0 3890 10100
1 S80.0W80.0 3124 10100
2 S80.0W70.0 186484 10100
3 S80.0W60.0 183077 10100
Any ideas? Am I using the best mask for image/area intersection? Please advise.
Thanks,
Jeff

With anyinteract you get
inside+coveredby+overlapbdyintersect+touch
since you are comparing polygons to polygons.
Do you want polygons that touch the window geometry in the result ? Do you want all the geometries
that have some kind of intersection with the window query ? Then you should use ANYINTERACT mask.
siva

SDO_Relate different to SDO_GEOM.Relate

Hi,
I have posted a question in relation to differences in these 2 before, which was resolved, but this one is proving harder to get to the bottom of.
I have 2 queries:
--Query 1
select policy_number
FROM policies p, zones z
where POLICY_NUMBER in ('648050011','230201900','270706149')
and z.mi_prinx = 417 and z.id = 5084
and sdo_relate(p.geoloc,z.geom,'mask=ANYINTERACT') = 'TRUE';
--Query 2
select policy_number
FROM policies p, zones z
where POLICY_NUMBER in ('648050011','230201900','270706149')
and z.mi_prinx = 417 and z.id = 5084
and sdo_geom.relate(p.geoloc,'ANYINTERACT',z.geom,.001) = 'TRUE';
The tolerance for policies is set in USER_SDO_GEOM_METADATA as:
((X, -8048349.95154, 8448349.95154, 0.001), (Y, -15680948.9714, 4321303.19013, 0.001), , )
Query 1 returns one policy.
Query 2 returns all 3 policies.
If I change the order in the sdo_relate command in Query 1 to sdo_relate(z.geom,p.geoloc,'mask=ANYINTERACT') = 'TRUE';
I get all 3 policies returned.
The policies are points and they are valid.
The zone is a multipolygon and it is valid.
Any help on this would greatly appriciated.
Thanks,
David

Hi Yhu,
Thanks for your reply.
Apologies for the delay in getting back to you, but when I was looking at the shape to extract out for you I exported it to MapInfo and then re-imported it to Oracle. This newly re-imported multi-polygon, which looks to be identical, works as expected, returning the 3 items.
The only difference that I can see in the 2 shapes is a rounding difference to 9 decimal places, which I cant see as being an issue.
The 2 zones tables both have the same diminfo on user_sdo_geom_metadata.
((X, -8048349.95154, 8448349.95154, 8.24835E-5), (Y, -15680948.9714, 4321303.19013, 0.0001000113), , )
Below are the points and the 2 shapes (original and re-imported).
Again, I would be very pleased if you can provide any possible reason for the difference in sdo_relate results.
Thanks,
David
Points:
230201900 (2001, 82086, (170982, 71356, ), , )
648050011 (2001, 82086, (169266, 70340, ), , )
270706149 (2001, 82086, (171151, 70430, ), , )
Edited by: user11181430 on Sep 1, 2011 4:45 PM

Ques on SDO_RELATE with mask as "TOUCH

A Question on "SDO_RELATE" with mask as "TOUCH".
We do a SDO_RELATE Operation on two SDO Layer, to find all those polygons, which comes from different SDO Layer and share a common edge.
We using "SDO_RELATE(t2.geom,t1.geom,'mask=TOUCH querytype=JOIN')='TRUE'", it found what we needed , however at the same time , those polygons from two different sdo table which share only a common point is also included in the selection. How to limited selection to those only share a common edge.
Richard Lee

You might try intersecting the two geometries that touch. If a point geometry is returned then you can eliminate it.
The touch mask itself is working correctly - it won't discriminate between touch at a point, and touch along an edge.
Hope this helps.

SDO_RELATE issue

Hallo,
I have a question concerning the sdo_relate operator. I use it in the form SDO_RELATE(table_geom, geometry,
mask = INSIDE querytype = WINDOW) = TRUE. And what I get are all the areas from table_geom that are inside but there are also the areas selected that overlap. But I only wanted the areas that are inside and do not overlap. Hwat is the mistake? Another question is which query do I have to use if I wanna select all areas from table_geom that are not inside but overlap and toch the boundaries?
Regards, Katrin

Can you post the query geometry and some of the returned geometries
you think are not completely inside.
For the second question, you should CONTAINS mask.
siva

SDO_RELATE JOIN

Oracle9i Question: Has anyone anywhere ever actually seen this spatial operator use the spatial index from both the tables in the join?
(Full table scans just won't cut it.)
Any hints, help, sample SQL or other insights are greatly appreciated.
Thank you.

In Oracle9i it is recommended that window queries be used when doing a spatial join. In Oracle Spatial 10g a new pseudo-operator sdo_join is introduced which will further enhance performance of spatial joins.
In Oracle9i, lets say you want to get all of the city/county pairs. Using the sample tables used for the course, there are 195 cities, and 3230 counties.
To get all of the city/county pairs, I would write the query as follows:
select /*+ ordered */ a.city, b.county
from geod_cities a, geod_counties b
where sdo_relate(b.geom, a.location,
'querytype=window mask=anyinteract') = 'TRUE';
Some notes on the query:
1) Use the ordered hint, and put the table the window comes from (geometry2) first in the from clause.
2) Use the table with smaller cardinality as the window table (note that cities has 195 rows, counties has 3230 rows).
3) If both tables have the same cardinality, and one has polygons and the other is of some other type, use the polygon table as the window table to enable the largest number of optimizations within spatial.
Hope this helps.

Sdo_relate question

Similar Messages

Maybe you are looking for