Skip to main content
  • EN

In FME 2016 there were a possibility to set how geometries would be stored in the MSSQL writer.

For instance, Arcs could be stroked with a setting within the writer when stored in the table, without using the Arcstroker-transformer.

However, in recent version this isn´t possible any more.

 

My problem:

I have a set of polygons in a MSSQL-database table (let's call it table 1) that was written thru the 2016 MSSQL-writer.

(The original data is stored in a different database (oracle) which i use to update and create new data)

 

I then use FME-server to write all the data (edited, new, untouched ) from Oracle to a different table i MSSQL (let's call it table 2) each night .

The MSSQL database then comapers the areas of the original table (1) and the comparison table (2) which I'm writing data to each night.

I do this check to see if I got any new, deleted or changed geometries (area comparison) before posting them to the "correct" MSSQL-Table (1).

 

When I changed to a newer version of FME-server the arcs in the polygons isn't stroked in the MSSQL writer, so I receive a message from the database which says that every polygon that contains an arc has to be updated, because the areas differs.

 

I've tried to use arcstroker, that dosen´t stroke the arcs the same way as MSSQL 2016 writer = goes to "update" even if they havn´t been updated.

 

I've also tried to use geometrycorecerer to separate arcs from polylines, stroked the arcs and then built the polygons back together. But it only results in the same sequence of events. The stroking of arcs dosen´t match the former MSSQL-writer.

 

Is it possible to replicate the type of stroking that occured in the 2016 MSSQL writer in any way?

Have you tried using Stroke By = Maximum Deviation in the ArcStroker? That might match what the SQL writer was doing, and the default deviation should be 0 I think (or likely whatever is set under Workspace Parameters > Translation > Stroking Tolerance in the Navigator window)

Hi ​@mark2atsafe it seems we have a similar problem, while having implemented your suggestion of using an ArcStroker with a Maximum Deviation. After we changed version of FME Flow from 2023.1.2 to 2024.2.3, we suspect that the results that are stroked by FME 2023 are different from FME 2024, within tolerance, of course. Yet the intermittend coordinates are different and our change detection mechanism flags nearly all geometries as different. Do you know if this behaviour could be expected using this new FME Flow version? And of course, suggest a solution?

Hi ​@helmoetz 

There were minor bugs in our arc stroking, including off-by-one errors and incorrect assumptions about rounding. This occasionally caused the stroked results to fall just outside the specified tolerance, although they were very close. These issues were fixed in 2024.0, which slightly changed how most arcs are stroked.

Are you using MSSQL to compare the curves using exact matching? 
Doing the comparison in FME (e.g., with a ChangeDetector), you could use a very small vector tolerance. Could you please try this once to confirm that the new results are equivalent, and then update the "truth" stored in SQL Server?

Hi Crystal, Thanks for answering. I forwarded it to the collegue that was involved.

Community Stats

31,853
Posts
120,983
Replies
39,485
Members

Latest FME

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.