Calling geoMercator.center sets the wrong automatic clipExtent. about d3-geo HOT 7 CLOSED

Well, that was a pretty trivial fix. Sorry it took so long!

from d3-geo.

Related d3/d3#1317.

from d3-geo.

There are two issues here.

The first is that d3.geoMercator has an automatic internal clipExtent (if the projection.clipExtent is null, which is it by default). The code that sets the internal clip extent assumes that the projection center is [0, 0], and if the clip extent is set incorrectly, Bad Things™ can happen with Mercator because it goes to infinity at the poles. You can workaround this issue until it is fixed by using projection.translate instead of projection.center.

The second is that older versions of world-50m.json and world-110m.json may have had some coordinates slightly outside of [±180°, ±90°], which can cause the interpreted winding order to be inverted. I’ve fixed this in world-atlas 1.0 and d3-geo-projection 1.1.1:

I’ve retitled this issue to clarify that it now only applies to the first issue. That’s a lot easier to fix than d3/d3#1317, and I believe that d3/d3#1317 might even be unnecessary thanks to the clamping that is now employed by d3.geoStitch.

from d3-geo.

The problem seems to happen even if projection.center is not set. I switched to d3 v4 and i can't get my map to display. Filling is inverted. The problem doesn't seem to be only related to the topojson i use. When i set projection.clipExtent, even the sphere is inverted :

sel.select("#sphere")
        .datum({type: "Sphere"})
        .attr("d", path);

It seems that reducing the extent by a 15% resolves the problem with the sphere (but hides some parts of my map).

from d3-geo.

@apezel You’re probably setting the clip extent outside the defined bounds of the Mercator projection. The Mercator projection extends towards infinity at the poles, but it is only defined on x in [tx - k × π, tx + k × π] where tx is the x-translate (projection.translate) and k is the scale (projection.scale). This is set automatically by default (with a null clip extent), so if you’re setting the clip extent manually, you can break the projection.

For example, this is good:

var projection = d3.geoMercator()
    .scale(150)
    .translate([480, 480])
    .clipExtent([[480 - 150 * Math.PI, 100], [480 + 150 * Math.PI, 860]]);

This is bad:

var projection = d3.geoMercator()
    .scale(150)
    .translate([480, 480])
    .clipExtent([[0, 100], [960, 860]]);

Of course, it might be possible to clamp a user-specified clip extent automatically, or to apply multiple clip extents so that we don’t have to special-case an automatic clip extent (instead, it would always be applied in addition to an optional user-specified clip extent). However, the former feels a bit hacky, and the latter probably wants something like #78 which is a big undertaking.

from d3-geo.

I’ve implemented clamping on x for Mercator’s clip extent in #88. It should be pretty easy to fix #55, too… I just need to think through how the projection.center affects the automatic clip extent and update the math accordingly.

from d3-geo.

It works perfectly ! Thanks a lot for your quick fix.

from d3-geo.