Strange clipper behaviour - perplexed

Hi,

 

 

just be aware that FME has no overarching notion of tolerance, all geometric operations are performed with full floating point precision unless the transformer specifically gives a setting for tolerance.

 

 

For your case, this means that although Oracle says the two geometries are identical to a tolerance of 5mm per vertex, it might be that they have differences <5mm that FME will act upon.

 

 

Consider using the Snapper or the AnchoredSnapper with a 5mm tolerance before any Clippers if you want to avoid clipping operations on differences smaller than this.

 

 

David

If the clipper and clippee are exactly equal you would expect only geometry to exit via the inside port and no clipping to occur

 

If the clipper and clippee are equal in oracle terms but with very tiny differences you would expect that the polygon is clipped, with geometry exiting from both the inside and outside port.

 

What you do not expect is that a clippee that is almost exactly the same as the clipper to remain unclipped and be output from the outside port!!

 

 

It is this last scenario that we are experiencing.

Difficult to say without having the geometries at hand, but it is of course possible that you've found a bug.

 

 

How about trying to install the FME 2015 release candidate (in a separate directory, of course) and see if the behavior has changed?

 

 

David

I'm not sure whether it's a problem with the clipper, how the geometry is stored in oracle or how fme is interpreting the geometry.

 

 

If i use an sqlcreator to return the wkb of the object, and then use a geometryreplacer to recreate the object, the clipper works as expected.

 

 

I've got few examples of the same issue, none involving particulary complex geometries, simple polygons with between 100 and 200 vertices.

 

 

 

 

 

 

 

 

 

 

That is strange. Consider sending the case to Safe support, stating the differences in using WKB and the reader...

 

 

David

If they are both in a spatial database, have you tried clipping using oracle SDO?

 

To see if this issue holds in oracle as well?

 

 

IF they are equal, the relator should also state EQUALS. So they are at some level of resolution not equal(?)

The objects are not exactly equal if no tolerance is used. Calculating the area of intersect within oracle, it returns a figure that appears to be correct, i.e. the area of intersect is 99.999999999999% of the object area.

 

 

It is difficult to demonstrate the issue as writing the object out to other formats sorts the problem.

 

 

The only thing I have noticed is the coordinates listed in the inspector under IFMELine display with 11 decimal places, the maximum precision held in the sdo_ordinate_array

 

 

If I chop the object into points, and then join the points back to make a polygon the error remains.

 

 

If i chop the object into points, use a coordinate rounder with a precision of 9 and join the points back to make a polygon the error disappears.

 

 

FME 2014 SP 2 (20140623 - Build 14339 - WIN32 btw)

I suspect you could apply the CoordinateRounder without having to chop the polygon first, that should save some precious CPU cycles...

 

 

David

Unfortunately, the coordinate rounder does not solve all cases of this issue. On the positive side, it does mean I can recreate it to send to Safe support :-)