-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify definition of "smaller than a hemisphere" #138
Comments
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:
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 ;-) |
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). |
(Clockwise-ness is also confusing because in WGS84 +y points North (typically up) and in Canvas/SVG +y points down.) |
Ah, so that means you can't re-orient an RFC 7946 planar polygon based on area (because both windings are valid in |
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: 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π. |
In geometric, a spherical polygon is both clockwise and counterclockwise. So, is it possible to assume the polygons are of convex in prior? The demo code can be found at https://observablehq.com/@listenzcc/untitled. |
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? |
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. |
|
A better solution: https://observablehq.com/@fil/rewind |
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. Right now displaying RFC 7946 geojson requires importing extra library. And while #79 (comment) comments
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
appears to not be true in many cases |
In #79 (comment), @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?
The text was updated successfully, but these errors were encountered: