Using FME Form 2025.1.1.0, I have some 30.000 features that have an attribute containing a polygon in Well-Known Text form. For about 4000 of those, GeometryReplacer rejects them with the fme_rejection_code of ‘INVALID_PARAMETER_GEOMETRY_SOURCE.
If I check the WKT, I can’t find any problems with it, and if I use https://wktmap.com/ (with an EPSG:28992) the handful of polygons I’ve checked show up just fine without any errors.
Example of one that goes wrong but looks good to me (and wktmap):
POLYGON ((78388.897 419890.033, 78421.563 419868.628, 78426.311 419875.727, 78429.69 419880.662, 78426.428 419884.195, 78422.297 419888.73, 78417.812 419891.98, 78413.315 419895.15, 78401.216 419903.072, 78397.477 419905.515, 78379.315 419917.4, 78377.366 419915.657, 78378.144 419913.401, 78379.163 419910.789, 78381.446 419908.255, 78384.409 419905.029, 78389.638 419899.094, 78392.82 419895.507, 78388.897 419890.033))
As far as I can work out, it does seem to always be the same features (this is from the pre-processing part of the workspace), so it either must be something with the WKT or with GeometryReplacer imho, but I can’t figure out what it is.
Edit: changing the OGC WKT Precision setting from 64-bit to 32-bit does not make any difference, btw.
Edit 2: these features come from an SQLCreator connecting to an MS SQL Server. The WKT attribute is created using ::geometry.STASText(). If I add STAsBinary(), then use the binary in the geometryreplacer, there’s no problem. In the logs of FME Form I see an entry “Invalid WKT encountered: P”. It almost seems like the buffer (which is the FME data type the WKT-attribute receives) is not fully read. What I don’t understand though is that it always seem to be the same features, it’s definitely always the same amount of features. I don’t want to use Binary however, since we sometimes get EMPTY POLYGON geometries in our database - and that is easy to check if it is WKT… But for now I’ll use it as a workaround.
