Clarify definition of "smaller than a hemisphere"

[urschrei]

In https://github.com/d3/d3-geo/pull/79#issuecomment-281130284, @mbostock clarified the required winding order of polygons as dependent upon their size (smaller than, or larger than a hemisphere). Could someone state this in more concrete terms? I.e. is "smaller than" in this context less than half the area of the WGS84 ellipsoid?

[Fil]

The text that was commited just mentions that “Spherical polygons can be larger than a hemisphere” and links to an example where the polygon covers the Oceans https://bl.ocks.org/mbostock/6713736

In my understanding the winding order does not change with the polygon's size: if you project a small circle centered on [0,0] with a radius r going from 0 to 180°, there is no discontinuity at 90° when r crosses that threshold: the circle continues to grow in area and radius (though its circumference reverses). Of course it depends from which point of reference you define the "winding order" 👿

If we go to that ocean example, an analysis of the topojson shows that it is composed of two features:

• 0 = Caspian Sea
• 1 = the rest of the ocean(s)

Feature 1 is the most interesting: it is a Polygon (i.e. a list of rings); its first ring follows the coast of main Antarctic land in the reverse winding order, and thus defines an enormous surface covering almost all the Earth. Next rings are (lots of) holes, which correspond to the land polygons, in reverse winding order. (Which explains why the Caspian sea, being "a hole in a hole", is shown as an independent feature.)

I hope this clarifies rather that muddies the issue :)

I feel this situation with the two geojson defs is really painful. Maybe we'll need to add another set of convenience tools (similar to geoStitch), that would reverse geometries, maybe based on their area. There are sometimes geojson in the wild where the winding order changes from one polygon to the next… there is also in a dark corner of d3-geo-projection a test on the area to decide which way to look ;-)

[mbostock]

Yes, Philippe.

Perhaps we should avoid the terms “clockwise” and “counterclockwise” because these terms don’t make sense in the context of spherical polygons: depending on the point of reference, a spherical polygon is both clockwise and counterclockwise. You can talk about clockwise-ness after projecting to the plane, but even in that case a spherical polygon can become multiple planar polygons after clipping, and our definition of a spherical polygon should likewise be spherical.

Perhaps the definition should be something like “the area that is bounded by the polygon is to the right of the boundary” (per ST_ForceRHR). So, if you walk the boundary of the polygon (in the defined order) along the surface of the sphere, the face of the polygon will be to your right.

Of course, it is tempting to call this the “right-hand rule” (as PostGIS does), but GeoJSON says it follows the right-hand rule with the opposite interpretation (for planar polygons).

[mbostock]

(Clockwise-ness is also confusing because in WGS84 +y points North (typically up) and in Canvas/SVG +y points down.)

[urschrei]

Ah, so that means you can't re-orient an RFC 7946 planar polygon based on area (because both windings are valid in d3-geo, with effects as Philippe and you have explained)? To use them as spherical polygons, the only safe thing to do is to assume that the first coordinates ring is the exterior and orient it CW, and the subsequent rings are interior, orienting them CCW, before giving them to d3-geo?

[Fil]

"if you walk the boundary of the polygon (in the defined order) along the surface of the sphere, the face of the polygon will be to your right"

this is exactly how I picture it in my head when I work with examples ; I'm not using the clock metaphor at all (I'm the kind of person who always shakes the right or left hand before writing or saying "left" or "right").

(You need to keep your head orientated towards the sky and feet towards the Earth's center, but maybe that goes without saying? A drawing would be nice though.)

The milky way geojson is an example that shows you cannot do "test area < 2π" as a generic solution: https://github.com/d3/d3-geo-projection/issues/116 https://bl.ocks.org/mbostock/15a373ce034cbc4ad604767c0eac05cb

A simpler example: the area between the two tropics: it can only be defined as a polygon with first ring > 2π, and a hole < 2π.

[listenzcc]

In geometric, a spherical polygon is both clockwise and counterclockwise. And in practice, we can not make sure every datasets are providing coordinates in clockwise order.

So, is it possible to assume the polygons are of convex in prior? Then the order of the coordinates can be detected automatically. If it is provided as the 'wrong' order, just use the reverse of the list of points.

The demo code can be found at https://observablehq.com/@listenzcc/untitled.

[Fil]

See also https://github.com/mapbox/geojson-rewind

[listenzcc]

See also https://github.com/mapbox/geojson-rewind

It’s a great solution. But there aren’t npm components in my web server. So It seems the rewind process has to be left to the front end in my case.

A tiny hope is that D3 geo package may consider to perform rewind optionally. Since it will inevitably unpack the json for each polygon to formulate the pathways. It is convenient to do the job, isn’t it?

[jrus]

This description of 'right' vs. 'left' is very exactly the opposite of what I would expect, which would be: if you walk along the boundary in the specified direction, is the boundary to the right of the shape or the left of the shape.

I think clockwise / anticlockwise is clearer. You have to consider the direction compared to a point inside the shape though.

For folks coming from a physics context, the "right-hand rule" means that when you are looking down at a shape from "above" (in a "right-handed" coordinate system), a positive area is associated to an anticlockwise loop, and a negative area is associated to a clockwise loop. This follows the direction of a right hand held out with the thumb pointed upward and the fingers curling leftward.

Computer graphics sometimes starts from a left-handed coordinate system (but there is not a super strong convention), whereas mathematics and science usually assume a right-handed coordinate system.

[Fil]

another helper for this: https://observablehq.com/@fil/normalize-winding and a convenience app: https://observablehq.com/@saneef/fix-geojson (thanks, @saneef!)

[Fil]

A better solution: https://observablehq.com/@fil/rewind

[matkoniecz]

As mentioned in #229 which got closed with message to post here:

It would be useful to have functionality with d3 to rewind right-hand geojson into left-hand geojson. Or even ability to opt in in using RFC 7946 geojson, not d3 geojson.

Right now displaying RFC 7946 geojson requires importing extra library.

And while https://github.com/d3/d3-geo/pull/79#issuecomment-280935242 comments

I’m disappointed that RFC 7946 standardizes the opposite winding order to D3, Shapefiles and PostGIS. And I don’t see an easy way for D3 to change its behavior, since it would break all existing (spherical) GeoJSON used by D3. I’d be interested to see an empirical analysis of GeoJSON use in practice to see what winding order is commonly used.

right-hand winding order seems to be clearly more and more standard to me (see for example QGIS which will not open them at all) and D3 seems to growing oddity. Especially as

result is the same whether the exterior ring is clockwise or anticlockwise

appears to not be true in many cases