How did you confirm that the two datasets are exactly match in 3 decimal places precision?
You could try the Lenient Geometry matching option in the ChangeDetector (which will disregard a different order of points in a line or polygon but I'm with @takashi: are you sure there should be matches in those 29542 features?
What's the history of the original featureclass? Anything done to it in the past that may have slightly altered geometry that's now causing mismatches?
You could try the Lenient Geometry matching option in the ChangeDetector (which will disregard a different order of points in a line or polygon but I'm with @takashi: are you sure there should be matches in those 29542 features?
What's the history of the original featureclass? Anything done to it in the past that may have slightly altered geometry that's now causing mismatches?
@redgeographics I did use the Lenient Geometry matching when doing the comparisons and the list of fields I was comparing was exactly the same.
The revised featureclass (TXC_StagingOwnershipParcels) that I was doing the comparison with was unchanged from the previous day. NO edits have been made to it or the target featureclass (Teranet_OwnershipParcels).
Hi @chris_rmw -- if this remains a puzzle, can you post for us the settings of your change detector? I'm wondering if there is a geometry or attribute "jiggle" that is going on that is causing the changes to be flagged -- maybe try it with no attribute comparisons and see if that makes any difference. Failing that, I'd suggest carefully inspecting a record that says it has changed by adding a Tester after the Added/Deleted ports of the ChangeDetector and picking out just one Feature (via whatever your unique key is) and routing that to the Inspector to see what is up.
Hi @daleatsafe I received the following response from Mark Stoakes at Safe Support:
Chris:
I've reproduced what you're seeing.
The issue is very slight dithering on the coordinates.
This probably occurs because ArcSDE is an integer based coordinate system and
switching back to a floating point coordinate representation that FME uses will
cause very slight changes in the small decimal values. Why there would be
differences between your SDE databases I don't know, possibly a slight different
coordinate grid origin, tolerance or 64 vs 32 bit coordinates.
You can see the slight differences in parcel PIN:
037650316:
0: 557306.32529999968,
4808232.6072000004 0: 557306.32529999968, 4808232.6072000004
1: 557308.90749999974,
4808220.6876999997 1: 557308.90749999974, 4808220.6876999997
2: 557274.77460000012,
4808213.2971999999 2: 557274.77460000012, 4808213.2971999999
3: 557272.19330000039,
4808225.2166999998 3: 557272.19330000039, 4808225.2167000007
4: 557306.32529999968,
4808232.6072000004 4: 557306.32529999968, 4808232.6072000004
Note the very slight difference in coordinate 3 Y:
4808225.2166999998 vs 4808225.2167000007
Adding in a CoordinateRounder with a decimal precision of
8 is enough to fix the issue in your sample data.
I added the co-ordinate rounder with a precision of 8 to my workbench and the geometry change issue has gone.
Thanks!