Skip to main content

Hi everyone,

 

The transformer Coordinateconcatenator return non closed ring geometry for donut featrues (fme_geometry: fme_donut, fme_type: fme_area). It means the first coordinate is not equal to end coordinate.

Is is a bug? I use Fme Workbench 2018.1. I need the closed ring coordinates, but I don't know how should I solve the problem?

 

Thanks in advance for any help.

 

 

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.


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.

 


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?


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.

 

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.


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.

 

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


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.

 

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))


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.

 

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.


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.

 

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!


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.

 

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


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.

 

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).


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.


Reply