Andrea Aime wrote: > Senthil wrote: >> Hi Andrea >> >> I had gone through the Oracle connector codes and fine to do > changes >> to that. In meantime did some manual testing for earlier sql statement >> with SDO_GEOM.RELATE. It worked without any issues. >> >> SELECT count(*) AS gt_result_ FROM (SELECT * FROM (SELECT * FROM >> (SELECT b.GROUP_ID as GRP_ID, SDO_AGGR_UNION(SDOAGGRTYPE(a.LOCATION, >> 0.005)) as GRP_LOCATION FROM GIS.PART_TABLE a, GIS.GROUP_TABLE b WHERE >> a.PART_ID=b.PART_ID Group by b.GRP_ID ) *VTABLE WHERE >> SDO_GEOM.RELATE*(GRP_LOCATION, 'anyinteract', >> >> MDSYS.SDO_GEOMETRY(2003,2193,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3), >> MDSYS.SDO_ORDINATE_ARRAY(- 154768.4241380731,4257259.84132448,3240947.5 >> 44118471,6614572.798694815)), 0.005 ) = 'TRUE' ) WHERE ROWNUM <= >> 1000000) gt_limited_; >> >> For above command used following format of SDO_GEOM.RELATE: >> SDO_GEOM.RELATE( >> geom1 IN MDSYS.SDO_GEOMETRY, >> mask IN VARCHAR2, >> geom2 IN MDSYS.SDO_GEOMETRY, >> tolerance IN NUMBER >> ) RETURN VARCHAR2; >> >> To implement this change as patch to Oracle connector, i wish to get >> the advice on that. Can we consider another configuration for >> SDO_GEOM.RELATE such currently used loose box field for SDO_FILTER or >> any other suggestions? > > It seems to me having just a global flag for it would be a major > limitation. As far as I know SDO_GEOM.RELATE never uses spatial > indexes so it should be a last resort solution to be used only when > the geometries are manufactured). > > Even when using views I guess only a small fraction of the geometries > used are really manufactured, the others might be coming from joined > tables, but that should not prevent the usage of SDO_RELATE. > > So I think it should be a per column flag. The easiest way to set it > up is probably to try and run a test with spatial query using > SDO_RELATE (using probably the bbox of the first geometry in the > result set) and fall back on the SDO_GEOM.RELATE only if that query > fails with a SQL exception > > Plus, that function has to be used with attention as Oracle Locator does > not support it: > http://download.oracle.com/docs/cd/E14072_01/appdev.112/e11830/sdo_loc > ator.htm > > Cheers > Andrea
I agree 100%. I didn't actually realise that it wasn't a part of locator (I don't use locator but that makes sense). Besides, it is always going to be faster to use a function that relies on indexes and/or spatial metadata over one that compares actual data, but using it *if it works and is available* as a last resort sounds good. I'm pretty sure Oracle would need to create an index for manufactured geometries anyway but that process takes time too. The absolute best reference for this stuff is this book - I highly recommend it if you don't already have it: http://books.google.com.au/books?id=-ZDAcf-h3VgC&pg=PA318&lpg=PA318&dq=sdo_geom.relate&source=bl&ots=HP2jtPFENL&sig=0BJRfoUBFBCVM_vTkWn14EKB-Ns&hl=en&ei=qv1ETPywBIPEvQP3tuzHDA&sa=X&oi=book_result&ct=result&resnum=4&ved=0CCcQ6AEwAw#v=onepage&q=sdo_geom.relate&f=false Regards, Miles ___________________________________________________________________________ Australian Antarctic Division - Commonwealth of Australia IMPORTANT: This transmission is intended for the addressee only. If you are not the intended recipient, you are notified that use or dissemination of this communication is strictly prohibited by Commonwealth law. If you have received this transmission in error, please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and DELETE the message. Visit our web site at http://www.antarctica.gov.au/ ___________________________________________________________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
