Comments and answers for "Comparing Geometry of Two File Geodatabases"

Answer by revesz

revesz — Wed, 05 Sep 2018 06:22:26 GMT

AnchoredSnapper may also help by setting the tolerance to a very short distance (eg 1m or 10 cm).

Comment by xiaomengatsafe on xiaomengatsafe's comment

xiaomengatsafe — Wed, 05 Sep 2018 00:20:20 GMT

Hi @josephjose, This is possibly due to the two format having different precisions.Have you considered Itay's idea of using a CoordinateRounder?Similar to the suggestion Mark2AtSafe mentioned, it's recommenced to examine two features that appear to be a match visually, but not reported as matches using the above method.This should give you clues as to where the differences are, and whether they are actual geometry differences, or only differences in coordinate precision.

Comment by josephjose on josephjose's answer

josephjose — Tue, 04 Sep 2018 03:40:29 GMT

When one is in SDE and the other source is in Fgdb, this method doesn't work.Any cool options like you mentioned or did I do something wrong?

Answer by mairesse

mairesse — Thu, 15 Sep 2016 07:57:00 GMT

Hi,

Another way to know which feature has changed is to extract the geometry of both data set after loading them with a "GeometryExtractor".The geometry is stored in an attribute "_geometry" by default.Then you can use a FeatureMerger in which you merge both data sets based on their "_geometry" attribute.You will then find the feature with a different geometry in the following output port: "NotMerged" and "Unreferenced".To get back the geometry, you can use a GeometryReplacer after the FeatureMerger.

See the attatchment for a visualization.

All the best,

Aurélien

Answer by mark2atsafe

mark2atsafe — Wed, 14 Sep 2016 18:30:45 GMT

It's difficult to know exactly what is happening from a screenshot.It might be - as Itay suggests - that the two datasets have differing coordinate precisions and fixing that will solve the issue.

Really it's best to filter the data down to two features that you think should match, but don't.

Then examine those features in detail.You could write their coordinates out to a CSV or text file, for example, where it is easier to visually inspect them.Or you could look at the list of coordinates in the FME Data Inspector.

The order of coordinates is important;so a feature with coordinates a,b,c is not the same as one with coordinates c,b,a - even if they do visually appear to be identical.

A quick way to show whether FME sees a feature differently is to use a CRCCalculator transformer.That will give a checksum type value for a geometry.If the values for two geometries are different, then FME is seeing something different in the data.If the values are the same - but the ChangeDetector or Matcher don't register a difference - then something is going wrong in FME.

I hope this helps.If you can isolate a couple of features and post them here then we could be able to investigate in a little more depth for you.

Comment by mark2atsafe on mark2atsafe's answer

mark2atsafe — Wed, 14 Sep 2016 18:24:11 GMT

The CoordinateRounder is usually only necessary when you are working with two formats, particularly when one format stores data as integers (eg shape) and the other uses floating point (eg dwg).The same format of data should produce the same results - even if it is to 15 decimal places - as long as the data is a proper match.

Answer by itay

itay — Tue, 13 Sep 2016 18:11:12 GMT

Hi,

As FME is very aware of spatial features, some pre-processing is usually needed before change detection.

So for example the use of the coordinaterounder on both inputs to bring them both to the same decimal precision.

Change detection remains a challenge and is not always as straight forward as it seems.