Skip to main content
  • EN

I am using the GeometryExtractor transformer to extract the geometry as WKT (OGC Well Known Text, version 1.2, precision 64-bit).

 

The geometry is created by FME using the Dissolver, Sorter, Aggregator and GeometryRefiner transformers based on a geometry from ArcSDE Geodatabase - on Oracle DB.

 

Vertices are aligned using ArcSDEGridSnapper and CoordinateRounder, so there are no issues with vertices geometry, as all of them are matching.

 

An example of a WKT created by FME is the following:

 

MULTIPOLYGON (((22.5462822 47.250064,22.5467275 47.25037864,22.546993 47.24920386,22.5468165 47.24918507,22.5463433 47.24908748,22.5460432 47.24890993,22.5459305 47.24885194,22.5455702 47.24880224,22.545533 47.24879591,22.5453175 47.24953065,22.5459866 47.24989446,22.5462822 47.250064)),((22.5493802 47.25255987,22.5494253 47.25113137,22.5494042 47.25081984,22.5494009 47.25078482,22.5487585 47.25060518,22.548664 47.2507213,22.5477242 47.2505618,22.5472852 47.25204817,22.5472769 47.25207047,22.5480557 47.25250925,22.5495008 47.2533228,22.5493708 47.25285712,22.5493802 47.25255987)))

 

However, when reading the geometry from the database (SDE MS SQL in Azure) the parts of sequence of the polygons in the multipart polygon are inversed:

 

MULTIPOLYGON (((22.5493802 47.25255987,22.5494253 47.25113137,22.5494042 47.25081984,22.5494009 47.25078482,22.5487585 47.25060518,22.548664 47.2507213,22.5477242 47.2505618,22.5472852 47.25204817,22.5472769 47.25207047,22.5480557 47.25250925,22.5495008 47.2533228,22.5493708 47.25285712,22.5493802 47.25255987)),((22.5462822 47.250064,22.5467275 47.25037864,22.546993 47.24920386,22.5468165 47.24918507,22.5463433 47.24908748,22.5460432 47.24890993,22.5459305 47.24885194,22.5455702 47.24880224,22.545533 47.24879591,22.5453175 47.24953065,22.5459866 47.24989446,22.5462822 47.250064)))

 

I know that setting the "Lanient Geometry Matching" to "Yes" in the ChangeDetector transformer will not pick anymore this as a geometry change, but still the WKT is different.

 

I use the WKT to describe the geometry change in a Log table. Therefore this change is indicated for a certain number of multipart polygons simply because the order of the parts in the multipart is changed when writing the geometry in the destination.

 

Is there any solution to have the same sequence of the polygons in the multipart geometry produced by FME as the one that is written in the database by FME?

 

Or there is any solution to change the order of multipart geometry when reading it into FME, to match with the one that is produced by FME?

My understanding is that a multipart geom is in the order each part is added. if you have part(s) A B C and they're fed in to an aggregator in that order, the output would be MULTIPART(A,B,C). If they're fed in in the order of C B A, the output would be MULTIPART(C,B,A). So to get the geometries in the order you want them, you'll need to ensure they enter the aggregator in that order

Hi hkingsbury,

Thank you for your valuable comment, as my understanding is the same. However either the FME writer, either the SDE on Azure MS SQL DB is changing the order of the parts as I explained above. So MULTIPART (A,B) feed into SDE Azure MS SQL DB is written as MULTIPART (B,A) for some records, while for other records the order is maintained. The coordinates that I provided are from a real example.

These are picked by the ChangeDetector transformer as geometry changes when  setting the "Lanient Geometry Matching" to "No" (default). I transformed geometries in WKT with FME in order to understand why some multipart polygons are indicated that are changed, even if no change exist.

Could it be related to GeometryRefiner (IFME)?

Here it is a print screen from the ETL Log table that is storing all updates in the database. It can be seen that the revised value is MULTIPOLYGON (A,B), while the originalValue (in the destination) is MULTIPOLYGON (B,A). FME Desktop Version used: 2021.0.0.1 (20210315 - Build 21306)FME

Reply


Community Stats

30,168
Posts
114,524
Replies
37,824
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.