Solved

Strange clipper behaviour - perplexed

ebygomm
Rank
Userlevel 1
Badge +21
An issue that's got me puzzled

 

 

A geometry from an oracle table a (Object a1) is used to clip a geometry from another oracle table b (Object b1)

 

 

These geometries visually appear identical, they are valid geometries and Oracle returns their relationship as EQUAL when tolerance is set to 0.005

 

 

If you clip object b1 with object a1, object b1 remains untouched and it is output untouched via the outside port.

 

 

if you clip object a1 with object b1, object a1 is clipped as expected, with geometry exiting both the input and output ports

 

 

A spatialrelator gives the interactions as OVERLAPS and INTERSECTS irrespective of which object is the requestor/supplier

 

 

Any ideas?
icon

Best answer by ebygomm 17 July 2018, 17:27

View original

12 replies

david_r
Rank
Userlevel 4
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
ebygomm
Rank
Userlevel 1
Badge +21
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.
david_r
Rank
Userlevel 4
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
ebygomm
Rank
Userlevel 1
Badge +21
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.

 

 

 

 

 

 

 

 

 

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

 

 

David
G
Badge +3
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(?)
ebygomm
Rank
Userlevel 1
Badge +21
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)
david_r
Rank
Userlevel 4
I suspect you could apply the CoordinateRounder without having to chop the polygon first, that should save some precious CPU cycles...

 

 

David
ebygomm
Rank
Userlevel 1
Badge +21
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 :-)
ebygomm
Rank
Userlevel 1
Badge +21

PR58870 was raised as a result of this, any update on when this may be fixed?

ebygomm
Rank
Userlevel 1
Badge +21

Does anyone else encounter this issue? I need to boost its popularity to get it fixed :-)

Rounding coordinates resolves the problem in 99% of cases but this can be problematic for other reasons. It also relies on anyone else in the organisation using the clipper/area on area overlayer knowing about the issue and accounting for it in anything they build.

clipper-issue.fmw

ebygomm
Rank
Userlevel 1
Badge +21

Woohoo, this is fixed in 2018 :-)

Reply


Community Stats

28,706
Posts
109,463
Replies
36,551
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.