Skip to main content
  • EN

I am unable to run data from a PostGIS reader through a change detector against another reader type and get a match. I have an AutoCAD line layer that has been loaded into a PostGIS_linestring feature. When I compare the two features using the change detector, there are no matched features. I have tried several things:

  • Removed all attributes from each feature
  • Extracted the geometry to an attribute and only compare on that attribute
  • Force both feature to 2D

I have also tried pushing the AutoCAD data into SQL Server (GeoMedia format) and using that to compare against the PostGIS feature, with the same results.

Can anyone provide any suggestions? Has anyone successfully used the change detector against a PostGIS reader?

This is possible for sure as I have done this before, but it might not be easy. The problem you have might be caused by the different ways coordinates are stored in different formats. Also see this blog post.

One of the ways I solved this was to temporary write the cad data to a postgis table, then read the postgis table and then compare postgis vs postgis.

Other ways might be the ArcSDEGridSnapper. Push both sets through it before change detection.

Did you try setting Lenient Geometry matching to yes and setting an extra vertex tolerance?

This is possible for sure as I have done this before, but it might not be easy. The problem you have might be caused by the different ways coordinates are stored in different formats. Also see this blog post.

One of the ways I solved this was to temporary write the cad data to a postgis table, then read the postgis table and then compare postgis vs postgis.

Other ways might be the ArcSDEGridSnapper. Push both sets through it before change detection.

Just be careful with the ArcSDEGridSnapper if you have geometries containing arcs: they will automatically be stroked without warning.

Just be careful with the ArcSDEGridSnapper if you have geometries containing arcs: they will automatically be stroked without warning.

What I did was geometryextractor, then snap, then changedetector, then geometryreplacer to return to original geometry.

What I did was geometryextractor, then snap, then changedetector, then geometryreplacer to return to original geometry.

Yeah, I agree, that's a pattern I use quite a lot.

Did you try setting Lenient Geometry matching to yes and setting an extra vertex tolerance?

Thanks for the suggestion but I had tried that with no success.

This is possible for sure as I have done this before, but it might not be easy. The problem you have might be caused by the different ways coordinates are stored in different formats. Also see this blog post.

One of the ways I solved this was to temporary write the cad data to a postgis table, then read the postgis table and then compare postgis vs postgis.

Other ways might be the ArcSDEGridSnapper. Push both sets through it before change detection.

Genius! An initial test and this seems to work. I am doing a deeper test now and will report back.

This is possible for sure as I have done this before, but it might not be easy. The problem you have might be caused by the different ways coordinates are stored in different formats. Also see this blog post.

One of the ways I solved this was to temporary write the cad data to a postgis table, then read the postgis table and then compare postgis vs postgis.

Other ways might be the ArcSDEGridSnapper. Push both sets through it before change detection.

I have confirmed that using the geometry extractor, then ArcSDEGridsnapper, then change detector, then geometryreplacer did what I needed. I did find that the change detector was very slow, so I moved the geometry out to a CRC using the CRCCalculator and compared that value instead of the actual geometry. The performance increase was significant (orders of magnitude). More details on that here: https://knowledge.safe.com/articles/1124/creating-a-unique-identifier-crccalculator.html

I would also recommend that you consider trying out the brand new ChangeDetector in FME 2019, not only does it now have an Updated port, but most importantly it now supports a vector tolerance parameter which should, ideally, make the ArcSDEGridSnapper etc superfluous.

We'd love to hear from you here if you get to test it with your data!

Reply


Community Stats

30,109
Posts
114,295
Replies
37,744
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.