Follow the GeoJSON specification or not?

[AntonGrafstrom]

Hi, I have some questions regarding turf and the GeoJSON specification (https://www.rfc-editor.org/rfc/rfc7946).

1. I may be wrong but it seems to me that exterior rings of polygons must be clockwise and interior counterclockwise (according to the errata of the specification). It also seems that most examples of GeoJSON polygons that I find online use the opposite direction. Which is correct? As the order easily can be checked, this is perhaps not a big issue.

2. A line (segment) is not a great circle according to the specification section 3.1.1. It is a cartesian line between the coordinates. This, of course, has impact on how to compute length and area and how to find intersects of segments. For example, in turf, I think length is computed using great circle distance between points in segments. This distance (length) will be shorter (as it is the shortest path on the surface) than the length we would get following the specification. This also has impact on e.g. testing if a point is in a polygon. It seems to me that following the specification would make some operations relatively easy (e.g. intersect, union, point in polygon) as they can be performed in a plane? But it seems to me that following the specification makes it more complicated to accurately compute length and area? So, how should segments be treated? As great circle segments or cartesian in longitude, latitude? Does anyone here know how other GIS software (e.g. QGIS) treat GeoJSON line segments in different operations?

[twelch]

I can share a little bit of what I've gathered. I think following the geojson spec is always the way to go to be safe for interoperability between software. That said:

(1), I think you'll find many libraries support clockwise or counterclockwise. I think that winding order guidance came in a later version of the spec (https://www.placemark.io/documentation/winding-order)

(2) As you may have noted, on a mercator map (which most web maps are), a straight cartesian line, is a rhumb line. And turf has rhumb functions that I think would interpret your line as the geojson spec suggests -

https://turfjs.org/docs/#rhumbDistance
https://en.wikipedia.org/wiki/Rhumb_line

That said, I gather there's nothing that says you have to stick to this. In my work, I want length and area computed on a sphere, not cartesian. Many of turfs functions assume a spherical model of the world. The turf.length() function uses turf.distance(), which uses the Haversine formula that accounts for global curvature. This could be better documented.

[twelch]

I think the GeoJSON spec actually states the opposite of what you suggested on order, specifically:

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.

So "most GeoJSON example you find online" are correctly using this rule.

That said, I understand that PostGIS interprets the opposite:
Right-Hand-Rule. In GIS terminology, this means that the area that is bounded by the polygon is to the right of the boundary. In particular, the exterior ring is orientated in a clockwise direction and the interior rings in a counter-clockwise direction.

Can force PostGIS to output with the CCW interpretation using ST_ForcePolygonCCW

More information here from someone else stumbling through this - https://dev.to/rodreegez/geojson-right-hand-rule-2idk