The Bufferer documentation says:

“Output area buffers will always have a Right Hand Rule orientation”.

Although to add to the confusion around “Right Hand Rule”, FME defines RHR and LHR in the “If extend arm out to the right / If extend arm out to the left” definition, whereas the GeoJSON spec talks about RHR as “If put arm out straight in front of you and extend thumb”, leading to FME Right Hand Rule not equalling  GeoJSON Spec Right Hand Rule.

The GeometryExtractor will just follow the orientation of the input geometries, so if using a Bufferer, then they will be encoded that way:

“GeometryExtractor does not perform any repairs to feature geometries during extraction. Geometries are extracted in their current state”

Technically as well, the original GeoJSON spec did not have a rule as to vertex order so GeometryExtractor is still kind-of obeying the spec, and many downstream applications using GeoJSON are written to be neutral to vertex order as a consequence.

Several Writers in FME though will re-orient the vertex order during the write, usually because some data formats require an explicit convention to be followed.  Eg. The ESRI GDB Writers will convert all polygons to Eg. Exterior Ring as counter-clockwise (FME Left Hand Rule), and bizarrely the ESRI Open FGDB API does the opposite and follows SHP file “rules” of exterior rings being clockwise and will also flip any incoming features within the Writer to re-orient them that way.  This is why you get a difference in vertex order between the Workspace Features and the Features that are actually Written.

As an aside I discovered this the hard way when first using ChangeDetector when it started flagging differences in the features in the Geodatabase I had only just written out from a workspace, so now in our ESRI environment “Lenient Geometry Matching” is the default setting we use so that it will disregard differences in orientation between workspace features going into the Revised port vs the GDB features going into the Original Port.

I suspect to “enforce” a rule to make the Workspace Features oriented in the same direction as a Writer enforces for a particular format is to use GeometryValidator with “Attempted Repair” on Area Orientation.  The  latest GeoJSON spec that mandates “Right Hand Rule” convention is equal to FME Left Hand Rule convention, so this Transformer after say, the sample workspace Bufferer should orient the features that need re-orienting and output on the “Repaired” Port.

 

Orientor (should?) also force it for all Features as an alternative.

 

thank you for the long explanation - I was confused by the LHR / RHR mismatch, I did not know it… Orientator does the job, but it would be nice to have an option in the GeometryExtractor to specify if you want the “geoJSON RHR” when writing the geoJSON string.

Hi @amelchiorre  FYI, I’ve filed FMEENGINE-84181 to ask that the option to force polygons counterclockwise be added to the GeometryExtractor as well as the GeoJSON writer.