+11Using FME 2018.1 (build 18528 x64)
I'm noticing that two seemingly identical features are showing as updated when comparing them using Update Detector.
The geometry is what is being detected as a difference, even when using lenient geometry matching.
Any ideas why?
- unzips to ffs file type, ffs attachments apparently aren't allowed using the file uploader
Thanks in advance!
Best answer by nathanatsafe
Hi @carmijo,
I'm seeing your result as well. Looking inside the UpdateDetector, I think this boils down to a limitation in "lenient geometry matching" within the ChangeDetector. Are you open to trying your workflow in our latest beta release? The ChangeDetector (core FME transformer) has been overhauled to totally replace the UpdateDetector, which will be deprecated. A quick test in the beta shows that the ChangeDetector now correctly detects your similar features as "unchanged". Let me know if you can test and if you get good results. If not, perhaps we can find an acceptable workaround in the latest stable release.
Here's my FME Beta test workspace: 20703-seemingly-identical-test-fmebeta.fmw
Best,
Nathan
+7Hi @carmijo,
I'm seeing your result as well. Looking inside the UpdateDetector, I think this boils down to a limitation in "lenient geometry matching" within the ChangeDetector. Are you open to trying your workflow in our latest beta release? The ChangeDetector (core FME transformer) has been overhauled to totally replace the UpdateDetector, which will be deprecated. A quick test in the beta shows that the ChangeDetector now correctly detects your similar features as "unchanged". Let me know if you can test and if you get good results. If not, perhaps we can find an acceptable workaround in the latest stable release.
Here's my FME Beta test workspace: 20703-seemingly-identical-test-fmebeta.fmw
Best,
Nathan
+17Are the geometries stored with exactly the same precision. Often the coordinates are off after a large number of decimals.
In that case I often use the CoordinateRounder transformer to limit the number of decimals on the coordinates to a number that really matters.
Hope this helps.
+11Hi @carmijo,
I'm seeing your result as well. Looking inside the UpdateDetector, I think this boils down to a limitation in "lenient geometry matching" within the ChangeDetector. Are you open to trying your workflow in our latest beta release? The ChangeDetector (core FME transformer) has been overhauled to totally replace the UpdateDetector, which will be deprecated. A quick test in the beta shows that the ChangeDetector now correctly detects your similar features as "unchanged". Let me know if you can test and if you get good results. If not, perhaps we can find an acceptable workaround in the latest stable release.
Here's my FME Beta test workspace: 20703-seemingly-identical-test-fmebeta.fmw
Best,
Nathan
Hi @NathanAtSafe. Yes, I was able to confirm your test in FME 2019. Thank you for sharing that.
However, i'm still seeing a difference detected when turning off lenient geo matching. I even rounded the coordinates to 3 decimal places and change detector is still detecting a difference. I attempted to use the CoordinateExtractor to extract all coordinates but the list attribute isn't being detected by a ListConcatenator placed after it.
+11Are the geometries stored with exactly the same precision. Often the coordinates are off after a large number of decimals.
In that case I often use the CoordinateRounder transformer to limit the number of decimals on the coordinates to a number that really matters.
Hope this helps.
+7Hi @NathanAtSafe. Yes, I was able to confirm your test in FME 2019. Thank you for sharing that.
However, i'm still seeing a difference detected when turning off lenient geo matching. I even rounded the coordinates to 3 decimal places and change detector is still detecting a difference. I attempted to use the CoordinateExtractor to extract all coordinates but the list attribute isn't being detected by a ListConcatenator placed after it.
I think the behaviour you're seeing in the ChangeDetector is expected. In "Lenient Geometry Matching: No" mode we want to respect the precision of the data, which in this case does have coordinates that differ by a few hundred units (for an example, look at the coordinates of Inner Boundary 11).
BUT! We included a "Vector Tolerance" parameter which is only used in this mode. Set the tolerance to 1000 and you should get features out of the "Unchanged" port again, even if you're not using lenient geometry matching. This parameter determines how close together vertices must be in order for them to be considered identical (ie matching).
Let me know if this makes sense or not.
Best,
Nathan
+11I think the behaviour you're seeing in the ChangeDetector is expected. In "Lenient Geometry Matching: No" mode we want to respect the precision of the data, which in this case does have coordinates that differ by a few hundred units (for an example, look at the coordinates of Inner Boundary 11).
BUT! We included a "Vector Tolerance" parameter which is only used in this mode. Set the tolerance to 1000 and you should get features out of the "Unchanged" port again, even if you're not using lenient geometry matching. This parameter determines how close together vertices must be in order for them to be considered identical (ie matching).
Let me know if this makes sense or not.
Best,
Nathan
Also, do you know what may be happening with the ListConcatenator?
+7
Also, do you know what may be happening with the ListConcatenator?
You're right that rounding the coordinates to the appropriate significant figure would eventually give you the same results. The major difference in using the CoordinateRounder vs. using the tolerance parameter, is that the CoordinateRounder actually alters your data. The tolerance does not change the data at all, but simply introduces some "wiggle room".
I took a look at the ListConcatenator and it seems you've uncovered a bug that exists only in our latest beta. I've filed a request for our development team to take a look at it. If your goal is to have all the coordinates in one attribute, try the CoordinateConcatenator, which should replace the CoordinateExtractor > ListConcatenator combo.
Hope this helps!
Nathan
+11You're right that rounding the coordinates to the appropriate significant figure would eventually give you the same results. The major difference in using the CoordinateRounder vs. using the tolerance parameter, is that the CoordinateRounder actually alters your data. The tolerance does not change the data at all, but simply introduces some "wiggle room".
I took a look at the ListConcatenator and it seems you've uncovered a bug that exists only in our latest beta. I've filed a request for our development team to take a look at it. If your goal is to have all the coordinates in one attribute, try the CoordinateConcatenator, which should replace the CoordinateExtractor > ListConcatenator combo.
Hope this helps!
Nathan
+7
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
