Solved

Log message: which transformer fires 'Expression: !isPoly || curve->isClosed2D()' ?

  • 28 September 2020
  • 7 replies
  • 13 views

Badge +9

Hello,

I have a bigger workspace with a lot of spatial transformations writing into .ffs files. The process is running since two yeas on FME Server 2018. Now after migrating the workspace to FME 2020 the process ends with a FATAL 'Expression: !isPoly || curve->isClosed2D()'.

However the .ffs are written successfully.

Now I 'm searching for the transformer which might have fired the message to analyse what I have to change.

Any ideas?

thanks Klaus

 

icon

Best answer by kalbert 29 September 2020, 14:23

View original

7 replies

Userlevel 5
Badge +25

This is not an easy error message to interpret. Something geometry-related obviously, but as you're doing a lot of spatial transformation that doesn't narrow it down.

 

If it's at all possible I'd recommend running it in FME workbench (same build as your FME Server) and look at the feature counts to see if you can figure out where the error is happening.

Badge +9

My ultimate solution would be to do partial runs with feature caching in workbench. To reduce the amount of work I hope someone knows the error message and can point out the possible transformers. Would be very helpful to know if the message can come e.g. from a DonutHoleExtractor, a LineOnAreaOverlayer or a NeighborFinder (only to name some of the 'spatials' I use).

Userlevel 1
Badge +21

Do you have a dissolver? https://community.safe.com/s/question/0D54Q0000875JsP/curves-error-from-the-dissolver

Badge +9

It's the exact same error message. My workspace has three Dissolvers. That's a start point for debug. Thanks for the hint.

Userlevel 1
Badge +21

It's the exact same error message. My workspace has three Dissolvers. That's a start point for debug. Thanks for the hint.

From memory, the dissolver also underwent a fairly significant rebuild in 2019 so that would make sense if you're moving from 2018 to 2020

Badge +9

I've got it. It was not the Dissolver. It was a Bufferer that throws the error.

As a first step I replaced the old Bufferer (version 13) with the latest (version 16). But it still failed. As a second step I changed the buffer units from 'Ground Units (None)' to 'Meter' and the buffer distance accordingly to get approx. the same shapes (and added a Reprojector LL-WGS84 - EPSG3395 in front of the Bufferer). And now it works!

It seems FME2020 is a bit more picky (or positively said 'accurate') with incoming geometries.

Badge +6

I've got it. It was not the Dissolver. It was a Bufferer that throws the error.

As a first step I replaced the old Bufferer (version 13) with the latest (version 16). But it still failed. As a second step I changed the buffer units from 'Ground Units (None)' to 'Meter' and the buffer distance accordingly to get approx. the same shapes (and added a Reprojector LL-WGS84 - EPSG3395 in front of the Bufferer). And now it works!

It seems FME2020 is a bit more picky (or positively said 'accurate') with incoming geometries.

Thank you for posting this solution! You led me down the right path troubleshooting this, however my resolution ended up being different than yours:

 

I'll add from my own experience that my issue was with a Bufferer transformer as well. In my case I'm running FME(R) 2020.2.0.0 (20201027 - Build 20787 - WIN64) and the units were already set to 'Feet'. So I upgraded the Bufferer from version 15 to 16. Upgrading didn't fix the issue though.

 

In my case my process included 3 Bufferers along the same path. The first two had no errors, it was the third one that was throwing this error.

 

I found that the units in the first two Bufferers were set to 'Ground Units (None)'; however, the third (failing) Bufferer was set to 'Feet' (as mentioned above). Not sure why my units were different but I changed the units on the third one to match the other two ( 'Ground Units (None)') and that resolved the error.

 

I ran this same workbench a month ago back in November 2020 with no errors so there's something finicky going on.

 

Reply