The equator is broken (missing some parts, and bleeding out in other parts) at
http://blockbuilder.org/Fil/ee9bf16bf8b2fa56057733c443832c5d

It’d be nice if this library were easier to use when saving spherically-clipped GeoJSON. For example:

https://beta.observablehq.com/d/d706c7f9c6e46907

The tedious parts are:

• You need to wrap the d3.geoClipPolygon instance with an object that has a stream method.

• You need to compose the d3.geoClipPolygon instance with streams that transform from degrees to radians and then back again.

Part of me wonders if it’s worth revisiting a more composable geographic projection pipeline…

(Also, I think d3.geoProject sometimes breaks polygon semantics, but that’s a separate issue.)

example code that works (at least in one test case):

var c = projection.lobes().map(d => d3.merge(d.map(q => {
  var centroid = d3.geoCentroid({type:"MultiPoint", coordinates:q});
  return q.map(p => d3.geoInterpolate(p,centroid)(1e-7)); // pull inside each lobe
})));
c = d3.merge([c[0], c[1].reverse()]); // north, south
projection.preclip(d3.geoClipPolygon({ type: "Polygon", coordinates: [c] }));

the projection was defined by:

    var lobes = [
      [
        [[-180, 0], [-130, 90], [-95, 0]],
        [[-95, 0], [-30, 90], [55, 0]],
        [[55, 0], [120, 90], [180, 0]]
      ],
      [
        [[-180, 0], [-120, -90], [-60, 0]],
        [[-60, 0], [20, -90], [85, 0]],
        [[85, 0], [140, -90], [180, 0]]
      ]
    ];
    projection = d3.geoInterrupt(d3.geoHomolosineRaw, lobes).rotate([-204, 0])
    .fitExtent([[10, 10], [width-10, height-10]], {type: "Sphere"});

Namely, d3.geoAlbers? I am trying to use preclipping and am getting very strange results.

More to the point.
Polygon 1:
[ [ [ 30, 60 ], [ 90, 60 ], [ 90, 30 ], [ 30, 30 ], [ 30, 60 ] ] ]
Polygon 2:
[ [ [ 45, 75 ], [ 75, 75 ], [ 75, 15 ], [ 45, 15 ], [ 45, 75 ] ] ]

Projection:
d3.geoAlbers() .rotate([-105, 0]) .center([-10, 65]) .parallels([52, 64]);

Below is a picture made in qGis, cyan polygon (P2) is being clipped, green is the one doing the clipping (P1) (the one passed to geoClipPolygon and the result passed to preclip). Both polygons are already projected (but not preclipped).

After projecting, P2 is null.

See https://beta.observablehq.com/@fil/an-equal-area-projection-for-the-cubic-earth

Is there any interest in integrating this equal-area square face projection? (It can be fun to use on something else than the 1/6th square face of the cube.) If so, should it be integrated in this module or in d3-geo-projection?

Hello,

the inverse of the Tetrahedral Lee does not seem to work.
I’ve used the script by @cambecc – see here – to try this. Here is a demo, on top is the Imago projection where the inverse works (everything’s filled with blue pixels) but on the Lee, I only get a red triangle.

Am I doing something wrong or is the inverse broken?

Kind regards,
Tobias

while these first two could be solved by clipping to the sphere, the last one shows we still sometimes have inversions:

(reported by @mootari @ https://imgur.com/a/Km2wK6m)

The Imago projection needs to use polygon clipping; but it seems a bit absurd that we are doing spherical clipping (with 200 control points computed as the inverse of 200 planar points) just to do what is in the end a simple rectangular clipping. The thing is tricky because, so close to the limit, the spherical interpolation between control points might jump from one side to the other.

I was playing around and got some clipping problem.
This code map(d3.geoCubic().parents([-1, 2, 0, 2, 5, 2]).rotate([0,0,45])) produces some artefacts:

map() as per https://beta.observablehq.com/@fil/polyhedral-projections-with-d3-geo-polygon

Can we use this to cut (instead of clipping) to the polygon.

Would be useful to avoid disappearing points that are just on the edge of the polygon in polyhedral projections.
See d3/d3-geo-projection#132 (comment)

https://beta.observablehq.com/@fil/cahill-keyes-projection

see https://beta.observablehq.com/@fil/speed-of-the-voronoi-projection

The projection is 100x faster if it can use geovoronoi.find() to know to which face a point belongs. In my local branch, I've solved this by allowing to pass a faceFind function.

But should we limit ourselves to this, or be bolder and pass a full geoVoronoi object (which would also help in finding shared edges much faster, by using the delaunay topology)?

https://observablehq.com/@fil/markley

https://beta.observablehq.com/@fil/cahill-keyes-projection#Antarctica

https://github.com/d3/d3-geo-projection#geoHealpix could use a clipPolygon

This package is constrained to node ">=6.0.0 <=10.17.0". Using this package with maintained node versions without ignoring engines constraint isn't possible. Is there any reason why this constraint is present in d3-geo-polygon package.json?

Part of API doesn't seem to rely on node internals eg. geoArcIntersect. Maybe if part of API needs old node version it'll be good idea to move independent code parts into other package.

http://blockbuilder.org/Fil/90c1d39fa1b92281fd119c02188da858 shows how to use this plugin. It calls a modified version of d3.polyhedral (in d3-geo-projection) that in turn uses d3.geoClipPolygon(). More soon on this.

Older examples are available from https://bl.ocks.org/Fil/fc967d8ac6aa246863c6f2a4b7dbe41c and will be updated progressively.

Examples should go in the README when they're ready.

From Jason Davies's code (ported in 82d9481#diff-1955ba130f17ffd3f1a5db97ee798e02R13 ), there was an epsilon2 test in this function.

Somehow it allowed lines to escape the clipping on some occasions, so I lowered it to epsilon3 in 202e604 and got much less errors.

But it still happens, and the fix is to get rid of any epsilon and compare the values with 0.

I wonder what I'm missing (in which cases this value should be st. positive), but testing in all my examples seems to be OK with 0 instead of epsilon3.

Sorry noob question here...how do i inverse the clipping of d3.geoClipPolygon with preclip?...any example would be appreciate

Trying to bundle this in a webpack-based app, I find it breaks because it assumes a hardcoded location for node_modules in many places, eg (from here).

import {abs, degrees, epsilon, radians} from "../../node_modules/d3-geo-projection/src/math";
import {default as matrix, multiply, inverse} from "../../node_modules/d3-geo-projection/src/polyhedral/matrix";

yielding many errors like

ERROR in ./node_modules/d3-geo-polygon/src/polyhedral/waterman.js
Module not found: Error: Can't resolve '../../node_modules/d3-geo-projection/src/math' in '/home/bschmidt/project/node_modules/d3-geo-polygon/src/polyhedral'

Since I'm also requiring d3-geo-projection, these files are not inside the d3-geo-polygon folder: they're located at something like '../../../node_modules', maybe a level higher.

I'm able to get a successful install by just removing the prefix in all javascript files and importing straight from (eg) d3-geo-projection/src/math

~/project/node_modules/d3-geo-polygon/ find . -name "*.js" | xargs -I {} -n 1 perl -pi -e 's/\..\/\..\/node_modules\///g' {}

Can file a pull request if desired, but I don't know if that fix will break in other locations.

Thanks!

The issue is described here: d3/d3-geo-projection#125

To sum up this would need to:

• introduce geoCahill1909 (which would be geoPolyhedralWaterman but with the inferior choice of angles from Cahill's original — and that could be a parameter of course), and be mindful of the face projection used in 1909
• create a "true" geoWaterman with Antarctica cut out (see also #11)
• obsolete geoPolyhedralWaterman

South aspect of Lee’s conformal projection in a tetrahedron shows all black.

From the tweet exchange @Fil has verified that

it doesn't happen with [email protected] but with [email protected]

First, thanks for your great contributions regarding projections in D3. I have been playing with your new added projections in this d3-geo-polygon extension in combination with vega. Firstly I used the airocean projection to cut and engrave some wood using laser and liked the result¹.

But now having seen these maps on https://beta.observablehq.com/@fil/speed-of-the-voronoi-projection I would love to play with this projection as well.

I used the method as mentioned in the notebook:

The following map was made with the Voronoi projection — available as d3.geoVoronoi() in d3-geo-polygon.

When I try to use this:
projection = d3.geoVoronoi()

I receive:
TypeError: d3.geoVoronoi is not a function

Question: I'm trying features that are not yet available? or do I call them wrongly?

https://github.com/mourner/robust-predicates

We could use the Schwarz-Christoffel transformation. http://www.genekeyes.com/CAHILL-VARIANTS/Cahill-Conformal.html shows one made by @jrus

In https://observablehq.com/@fil/oronce-fines-triangle-projection the graticule was properly clipped until [email protected], but it failed with release 1.8.0.
I think the offending commit is eb1e663 (#160).

Test @ https://observablehq.com/d/fd5d0ec326b1d538

The multipolygon branch is a first step towards #9 and #11.

There is a demo here:
https://beta.observablehq.com/d/368627e7d1bcc0cb

each polygon is processed in turn.

There are still a few bugs though — as you can see if you rotate the map in the demo, there are sometimes mix-ups in the variables that control the points' visibility, resulting in dots for points that should belong to a polygon, or in full-white surfaces that should be full-black.

Hi, many of the links to examples on scratchpad don't work. In particular, I want the https://beta.observablehq.com/@fil/icosahedral-projection