FYI - High precision data issue with sdo_anyinteract on 11.2.0.3 with 8307

Question

For anyone that may happen to be experiencing issues with SDO_ANYINTERACT on 11.2.0.3 with high-precision geodetic data, I currently have a service request in to fix it.
The issue we have is with locating small polygons ("circles" from 0.5"-4") in the 8307 space. The metadata we have specifies a 1mm tollerance for this data, which has worked fine since (as I remember) 10.1. Support verified it works fine up to 11.2.0.2, then is broken in 11.2.0.3.
So if you are pulling your hair out - stop. ;-) The SR# is 3-5737847631, and the bug# (will be) 14107534.
Bryan

Answer 1

Here is the resolution to this issue...
Oracle came back and said what we have at that tolerance is unsupported and we were just lucky for it to have worked all these years. They are not going to fix anything because it technically isn't broke. We pointed out that the documentation is a little unclear on what exactly supports higher precision, and they noted that for future updates.
When asked if they would entertain a feature request for a set of high-precision operators (basically the old code) in future release - they basically said no. So for the few items that we much have higher precision - we are on our own.
What still makes us puzzled is that apparently no one else is using high-precision data in lat/lon. Amazing, but I guess true.
Anyhow, here is what we used to use (up to 11.2.0.3) which worked fine at a 1mm tollerance:
Where mask_geom is:
mask_geom      :=
         sdo_geometry (2001,
                       8307,
                       sdo_point_type (x_in, y_in, 0),
                       NULL,
                       NULL);
SELECT copathn_id
  INTO cpn
  FROM c_path_node a
WHERE     sdo_anyinteract (a.geometry_a2, mask_geom) = 'TRUE'
       AND node_typ_d = 'IN_DUCT'
       AND ROWNUM < 2;Basically this finds indexed geometry and compares it to a single mask geometry (a simple point for the x/y given). Only one row is returned (in case they overlapped duct openings - not normal).
Since this no longer returns any rows reliably for items less than 5cm in size, here is our work-around code:
SELECT copathn_id
  INTO cpn
  FROM (  SELECT copathn_id,
                 node_typ_d,
                   ABS (ABS (x_in) - ABS (sdo_util_plus.get_mbr_center (a.geometry_a2).sdo_point.x))
                 + ABS (ABS (y_in) - ABS (sdo_util_plus.get_mbr_center (a.geometry_a2).sdo_point.y))
                    distdiff
            FROM c_path_node a
           WHERE sdo_nn (a.geometry_a2,
                         mask_geom,
                         'distance=0.05 unit=m') = 'TRUE'
        ORDER BY distdiff)
WHERE node_typ_d = 'IN_DUCT'
   AND ROWNUM < 2;Essentially we use sdo_nn to return all results (distance usually is 0) at the 5cm level. At first we though just this would work - then we found that in many cases it would we return multiple results all stating a distance of 0 (not true).
For those results we then use our own get_mbr_center function that returns the center point for each geometry, and basically compute a delta from the given x_in,y_in and that geometry.
Then we order the results by that delta.
The outer select then makes sure the row is of the correct type, and that we only get one result.
This works, and is fast (actually it is quicker than the original code).
Bryan