4

The GeoJSON specification (RFC 7946) states that for polygons:

A linear ring MUST follow the right-hand rule with respect to the area it bounds, i.e., exterior rings are counterclockwise, and holes are clockwise.

However, this erratum published in July 2017, states:

It seems like the clockwise/counterclockwise descriptions are the opposite of the right-hand rule. Walking an exterior ring in a counterclockwise direction would have the exterior of the ring to the right of the observer.

This is a pretty significant issue, that does not appear to have been resolved (judging from the "reported" status of the erratum).

Is this correct? What exactly is the "right-hand rule" anyway?

10

There are TWO "right hand rules" (well, scores, if not hundreds, but the direction of magnetic force induced on a positive charge isn't relevant to this discussion).

One asserts that vertices be ordered in rings so that, if you walked the perimeter, with one hand within the figure, and one hand outside, that the right hand be inside: the exterior ring is clockwise. Shapefiles use this right hand rule (file and enterprise geodatabase use the left hand form of this rule natively, though the SDE API libraries allow for extraction in either order, and the File Geodatabase API uses the shapefile geometry specification for coordinate encoding).

The other rule asserts that if you place a balled fist on the plane of the geometry, and extend the thumb upward, away from the face, then the exterior rings will follow in the rotation of the unclasped fingers: the exterior ring is counter-clockwise. The KML specification uses this right hand rule (which would be considered left-hand if walking the perimeter).

It appears that the first reference to "right hand rule" by the GeoJSON spec refers to the thumb/finger-curl rule, and the erratum refers to the body-on-boundary method. I was only taught the body-on-boundary form, but I've met engineers who were only taught the hand-curl form.

The nice part of the first example is that it applies to interior rings ("holes") as well, without the need to assert that interior rings are wound in the opposite direction of exterior rings. For what it's worth, the GML specification is explicit that the winding order isn't required to be in either handedness, but does insist that interior be opposite of exterior, and that interior rings immediately follow their exterior ring.

The specification you cited states:

Note: the [GJ2008] specification did not discuss linear ring winding order. For backwards compatibility, parsers SHOULD NOT reject Polygons that do not follow the right-hand rule.

so it's probably not worth getting worked up over. If you use the Shoelace Formula (or the Trapezoid Rule) on the vertices of a ring, the area will be of opposite sign for exterior and interior rings. So long as you place the interior ring vertices following the exterior ring to which they define an exclusion, most parsers should be able to handle your input.

One place where difficulty may occur is if the ring touches itself at a point. In some libraries, the enscribed shape may be encoded as a hole, but Esri's libraries consider this an "inversion" and handle it as described in this question.

  • Thanks. That's kind of crazy that the spec would casually refer to "THE right-hand rule", when the there exact two mutually contradictory definitions. (Personally I think it's important to know what the spec actually dictates, regardless of whether "most parsers" can deal with either version. Backward compatibility should be a temporary transition, not a permanent state of confusion...) – Steve Bennett Jun 29 '18 at 4:46
  • GeoJSON spec is also using terms counterclockwise and clockwise. I think it makes clear what the spec dictates. – user30184 Jun 29 '18 at 5:09
  • Yes, thank you, I tweaked the answer to mention how the spec uses one, and the erratum the other. – Vince Jun 29 '18 at 12:24
2

No, the report is unverified and incorrect. The right hand rule in the spec is precisely what the GeoJSON Working Group intended. There may be errors in the spec, but this is not one. If Mr. Archer had checked the GeoJSON WG email list archive, he would have seen ample discussion of the issue. This report will not lead to any published erratum for RFC 7946.

  • Thanks. It sounds like including reference to "the right-hand rule" caused some confusing ambiguity, which fortunately the clearer statement of clockwise vs counterclickwise resolves. – Steve Bennett Jul 1 '18 at 12:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.