GeometryReplacer rejects valid WKT

The WKT you posted works without issue in a GeometryReplacer for me in 2025.1. 

If it’s coming from STASText() i wouldn’t expect there to be any rogue characters that have been lost when you’ve posted here. 

That’s why I don’t understand this one. I don’t see any strange characters, the WKB works fine, and the polygons aren’t even strange or invalid ones.

For now I select both WKT (to check for EMPTY polygons) and WKB (to catch this strange problem: use the 1st GeometryReplacer’s Rejected port, send that into a second GeometryReplacer that uses the WKB), and that seems to work. But it remains a mysterious one..

Just noticed that it does not happen in FME 2022.2.6.0. So whatever it is, it was introduced sometime after that.

I have seen attribute truncations in other cases that were due to the encoding of the attribute. Please try sending the rejected output of the GeometryReplacer to a Logger, then pasting a sample of the logged features.

Personally I would think that rather strange, seeing as all features come from the exact same SQLCreator using ‘select <snip> geom.STAsText() as WKT from <schema.tablename>’. So if what you say is the cause, then that would mean that either SQL Server or SQLCreator arbitrarily assigned encodings.

But, for the record, I logged 10 Rejected and 10 accepted features, below are 1 of each:

Logger_6: WKT is Rejected

2025-11-25 09:05:39|   8.8|  0.0|INFORM|Attribute(string: UTF-16LE)  : `WKT' has value `POLYGON ((142263.43 415230.511, 142243.062 415232.832, 142183.362 415238.22, 142162.184 415184.308, 142163.012 415156.642, 142165.404 415076.768, 142222.659 415078.312, 142266.986 415079.564, 142284.727 415080.223, 142273.421 415160.009, 142263.43 415230.511))'

Logger_7: WKT is OK

2025-11-25 09:05:40|   8.9|  0.0|INFORM|Attribute(string: UTF-16LE)  : `WKT' has value `POLYGON ((142284.727 415080.223, 142318.94 415081.494, 142318.685 415087.235, 142290.319 415160.525, 142283.594 415178.12, 142278.46 415193.675, 142268.535 415229.929, 142263.43 415230.511, 142273.421 415160.009, 142284.727 415080.223))'

Note that it is the FME Form log window that adds the ` in front of any text, instead of a regular ‘ as it does at the end (Still find that a strange one, btw). This is a straight copy and paste from FME, some spaces removed for legibility.

Both polygons, when checked on https://wktmap.com, using EPSG:28992, are valid and show up properly on the map, so should be accepted imho.

That does solve it, except for one single feature which remains rejected (WKT attribute for that one contains only a P). So for now I am staying with my own workaround, selecting both WKT and WKB, and using the WKB when any feature is coming out the Rejected-port of the GeometryReplacer. Because that allows me to have every feature coming through.

BTW: We only use Windows 11, no Macs in sight.

It looks like we have just released FME 2025.2 (safe.com/download). If you are able to update your FME, it would be helpful to know if you still get the same issue in the new version.

I can’t update unfortunately, so not able to check that version.

I tried changing the encoding from the database side, but it appears that SQL Server only introduced support for UTF-8 in 2019 (ridiculously late, if you ask me), and our version is an earlier one (which we have to use due to mission critical legacy software unfortunately). So that didn’t work either. Selecting both WKT and WKB, then using the WKB when the first GeometryReplacer rejects the WKT, works fine though. And an AttributeRemover right after the second GeometryReplacer prevents too much memory to be consumed, so for now we’re good.

I Had the same issue.. I found the error by extracting geometry the WKT of something related to get the format..

My gotcha was I was encoding as
Polygon ( x1 y2,x2 y2….)
should have been with double brackets
Polygon (( x1 y2,x2 y2….))