WKT polygon returns extra records on intersect query

Question

We have spatially enabled table with min/max lat/long with 1 degree cell data on which we perform queries coming from an application using well known text. We need to use WKT because we need to support user defined shapes of point, line, polygon, etc. (My test cases uses a rectangle). Our WKT data is accurate to 4 decimal places.
//WKT version returns 100 records: (this is bad result)
SELECT COUNT(*) from (select * from MAP_TABLE WHERE series='downunder') where sdo_relate(geometry,sdo_util.rectify_geometry(mdsys.sdo_geometry
('POLYGON((117.0627 -31.8451,117.0627 -27.0075,134.5875 -27.0075, 134.5875 -31.8451, 117.0627 -31.8451)))',8307),0.00005),'mask=anyinteract,querytype=window') = 'TRUE'
// array version returns 90 records: (this is expected result)
SELECT COUNT(*) from (select * from MAP_TABLE WHERE series='downunder') where sdo_relate(geometry,mdsys.sdo_geometry(2003,8307,null,mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(117.0627, -31.8451,134.5875,-27.0007)),'mask=anyinteract,querytype=window') = 'TRUE'
The WKT seems to return extra records as if a .5 rounding error on the spatial query. We checked for tolerance; in USER_SDO_GEOM_METADATA, SDO_TOLERENCE for lon and lat in DIMINFO column are set to .0000005, and SRID of 8307, and the spatial index for the table has been recreated with .0000005 (just in case).
Why is WKT not accurate?

Answer 1

Hi Mike,
Well, I'll be the first to line up and say that the WKT implementation has some issues. You already know them as you are doing that rectify_geometry step to account for some of them (incorrectly rotated rings which is what your example has).
Noel is right that your example is not pushing along your case since an optimized rectangle is not the same as a regular rectangle, particularly in a geodetic cs. And that is one tiny tolerance in the rectify step! Is all your data at that tolerance? That's 0.0019685 inches! Wikipedia says the width of a human hair is 0.003937 inches so your tolerance is 1/3 of the width of a human hair. :)
Anyhow, the second link Noel posted has the blurb we want: "When Spatial constructs the MBR internally for the query, lines along latitude lines are densified by adding points at one-degree intervals. This might affect results for objects within a few meters of the edge of the MBR (especially objects in the middle latitudes in both hemispheres)." So your optimized rectangle when its used internally by Oracle spatial looks like the results from this query:
SELECT
SDO_CS.TRANSFORM(
   MDSYS.SDO_GEOMETRY(2003,8307,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(117.0627, -31.8451,134.5875,-27.0007)),
   8307
FROM
dualSo you can probably expect some differences in query results in comparison to the four point rectangle that your WKT input creates. And certainly will happen at the follicle scale!
Could you post a different example that does not use an optimized rectangle where the SDO and WKT produce different outputs?
If your data is stored as WKT, how did an optimized rectangle get into this story in the first place? If you need to store an optimized rectangle as WKT - well you can't do that. You could do the above transform trick on any optimized rectangles in your data and then put all the resulting points into your WKT. Then things should match on the output query side. But that would mean chucking out the whole concept of optimized triangles from your dataset.
Cheers,
Paul