Question

Change Detector Geometry Comparison

  • 27 November 2015
  • 5 replies
  • 36 views
chris_rmw
Rank
Badge +1

I have a change detection workbench that I ran yesterday. Both the source and target featureclasses are in the same SDE database (all in same projection - UTM NAD83 Zone 17). As a test today I thought I would run it by redirecting to the Data Inspector as I have concerns about the number of updates being returned when using the Match Geometry comparison option in the Change Detector. Here are the record counts:

2D - Unchanged: 4,971 ; Updated: 165,077

Full - Unchanged: 4,971 ; Updated: 165,077

None - Unchanged: 170,048

Now I've added a co-ordinate rounder with 3 decimal places of precision before the change detector. However, when I do 2D comparison there are still 29, 542 updates?

Just wondering if there is something else I'm not considering in terms of matching the geometry. I know there can be issues when doing geometry comparisons between SDE datasets and a file geodatabase or shapefile, but when both datasets are in SDE (the precision should be the same) ??

5 replies

takashi
Rank
Userlevel 2
Badge +17

How did you confirm that the two datasets are exactly match in 3 decimal places precision?

redgeographics
Rank
Userlevel 5
Badge +25

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?

chris_rmw
Rank
Badge +1

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).

fmelizard
Rank
Userlevel 4
Badge +13

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.

chris_rmw
Rank
Badge +1

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!

Reply


Community Stats

28,670
Posts
109,365
Replies
36,531
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.