Skip to main content
  • EN

Hi all!

I'm reading spatial data from a MapServer hosted in organizations ArcGIS Portal. The query is made with HTTPCaller, and the response is in EsriJSON (by default).

I then extract the "geometry" part of the response json, as well as some other attributes from the response, with PythonCaller and replace the geometry with GeometryReplacer to FME Feature Geometry, so that I can perform other spatial tasks with FME later in the translation.

 

However, I noticed that some polygons returned from the query contains holes inside of them, or they should contain (this is confirmed from the source data), but after the GeometryReplacer, the holes are not holes, but filled with a polygon, and the Geometry returned is a multiarea with polygon part of it on top of the polygon itself! This behaviour happens, when the Geometry source encoding is EsriJSON.

The MapServer can be queried so, that the response format is in GeoJSON, and when I perfomed the same method with the GeoJSON encoding, the holes were actually holes as they should be, and the geometry type is Donut as expected.

 

So, is this a FME bug with EsriJSON and GeometryReplacer, or something that is natural behaviour with the EsriJSON format?

 

I attached a sample workspace of the workflow with both EsriJSON and GeoJSON examples, just a random polygon somewhere over Finland with a hole in it.

 

I'm running the translation with FME 2022.2.4 Build 22792

The EsriJSON reader has a parameter to construct donuts from multiple polygon geometries. This implies that the distinction between a multipolygon geometry and a donut is not contained within the EsriJSON itself. It would be useful if the geometry replacer had something similar.

 

If you create a donut from two overlapping shapes and then extract the EsriJSON you get exactly the same result as if you aggregate the same two overlapping shapes and extract the EsriJSON

 

image

I thought the only thing that what distinct the "polygons" from being a hole or a part of a multipolygon, is the orientation of the coordinates in the EsriJSON. The holes coordinates order is opposite to polygons. This can be examined and seen in e.g. the Data Inspector. This applies also to the GeoJSON, the coordinate orientation is the only thing telling that it is an interior boundary for a hole (besides also that it falls inside another polygon, but that is not mentioned in the JSON), but only with GeoJSON the GeometryReplacer creates a hole.

 

It seems like the GeometryReplacer just does not detect this with EsriJSON format

 

 

Using EsriJSON reader would not be a convenient way in this kind of operation. Another fix is to use DonutBuilder and filter out holes. It is strange that DonutBuilder can detect the holes automatically but GeometryReplacer can't.

Reply


Community Stats

30,108
Posts
114,295
Replies
37,745
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.