CoordinateConcatenator bug for fme_donut

I don't see the same behaviour in 2019 with a simple donut feature.

Are you able to share the feature?

It seems that the CoordinateConcatenator outputs the outer ring coordinates followed by the hole coordinates, which is why the end coordinate doesn't match the start coordinate.

If you only need the outer ring you can consider using the DonutHoleExtractor before the CoordinateConcatenator.

Actually I need a hole shape, because I'm going to send the feature to server using Rest api, in order to overlay between the donut feature and another features in the Server.

Would you not be better extracting the geometry as well known text rather than concatenating the coordinates?

I think, David is right. Thanks David.

Although I need the whole shape donut, I will use Transormation DonutHoleExtractor to use only external ring, because I don't see any other solution.

Why not use WKT (well-known text) as suggested by @ebygomm​ ? It supports donuts just fine and it's available through the GeometryExtractor.

I tried it with GeometryExtractor and the result is similar to the result of CoordinateConcatenator.

_geometry (string): POLYGON ((32530145.1722 5954079.369999999,32530239.1908 5954001.2794,32530248.1807 5953970.6044,32530236.6286 5953941.0699000005,32530073.1333 5954070.6778,32530112.696000002 5954042.5732,32530145.1722 5954079.369999999),(32530197.0194 5953989.3423,32530190.3101 5953980.2355,32530210.6928 5953964.037799999,32530233.7237 5953992.898800001,32530208.8859 5954003.4429,32530197.0194 5953989.3423))

I'm not sure I follow how you expect coordinates to be listed for a shape that is a donut. It lists the closed outer ring followed by the closed inner ring. I would never expect anything different.

If you look closely you will see that there are two paranthesis in there, one containing the outer ring and one containing the inner ring. So it's exactly as it should, and it can be recovered very easily using the GeomtetryReplacer. Try it out!

Thank you, your suggestion was helpful. But the main porblem is I'm going to send the built geometry using get request (Rest API service) to server. Firstly I don't know, whether Rest service support donut geometry. Secondly I'm not sure, whether the geometry url is correct.

Note: the url is correct for normal polygon. But for donut geometry get error:

Error: code 400, unable to complete operation.

URL: http://intranet.../.../rest/services/FeatrueServer/11001/query?geometry={"rings":[[[x1,y1],...,[xn,yn]],[[ x1,y1],...,[xn,yn]]]}&geometryType=esriGeometryPolygon&inSR=4647&spatialRel=esriSpatialRelIntersects&time=&outSR=4647&gdbVersion=&returnDistinctValues=false&returnGeometry=true&maxAllowableOffset=&returnIdsOnly=false&returnCountOnly=false&returnZ=false&returnM=false&geometryPrecision=&f=pjson

Could you not simply use the dedicated reader/writer for ArcGIS FeatureServer?

https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/arcgisfeatures/arcgisfeatures.htm

If you need to filter by an input polygon, look into using the FeatureReader and simply pass the polygon into the initiator.

Do you know, whether it is applicable or better performance. The features counts in the server are very big (1897089). In the first senario every feature is sent to server using Rest Service and is done overlay between sent feature and every feature in the server (DB).

I would expect that the FeatureServer reader/writer is using the exact same API internally, so it would surprise me if there are significant differences in the performance. But as always, the best is to test with your own data, on your own infrastructure.