Add .contain() method? about d3-geo

[mbostock]

Yes, I think this is a great idea. I filed this as d3/d3-geo-projection#30 previously but that was back when I was planning on keeping the projection-related code in that module (which won’t be possible until the new geo pipeline is implemented for 5.0), so anyway, it’s fine to move that issue over here.

That issue has my proposed API: path.fit(feature, extent). But I haven’t thought about it too much so it might need redesigning.

[veltman]

Oh great, I hadn't seen that one. It seems to me like it would be a little more intuitive to attach it to the projection rather than the path since the projection's what's getting modified. How about something like:

projection.fit(feature, extent[, padding])

Where feature is the geometry, extent is [width, height], and padding is an optional percentage padding a la the old rangeBands?

[mbostock]

You’ll need path.bounds to compute the bounding box, and potentially the
results could be affected by path.pointRadius although I don’t think that’s
the case for the current implementation of path.bounds.

Perhaps path.area, path.bounds and path.centroid should move to the
projection instance. I don’t think these need to be on a path. (Though we’d
need to retain them until 5.0 for backwards-compatibility.)
On Tue, Jul 12, 2016 at 8:49 AM Noah Veltman [email protected]
wrote:

Oh great, I hadn't seen that one. It seems to me like it would be a little
more intuitive to attach it to the projection rather than the path since
the projection's what's getting modified. How about something like:

projection.fit(feature, extent[, padding])

Where feature is the geometry, extent is [width, height], and padding is
an optional percentage padding a la the old rangeBands?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#49 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAOEjXHCUJu_Zk4IIgNOFk99ELzCU5tMks5qU41hgaJpZM4JJ4Qx
.

[mbostock]

An extent is [[x0, y0], [x1, y1]]. A size is [dx, dy] but I wouldn’t want to do automatic inference to distinguish them; I’d require an extent. Unless we create a separate d3.geoFit object and then you could specify either an extent or a size. But that feels a little overkill. I’m not wild about the optional padding argument as I tried to remove those in D3 4.0. It might be okay, but I think it’s equally likely you might want a fixed size margin rather than a percentage of width and height. One option would be helper methods which derive a new extent from an existing extent (to scale or subtract) but that might be clunky too.

[veltman]

A separate geoExtent or geoFit object definitely feels like overkill. Skipping the padding works for me. Will probably lead to lots of code along the lines of:

projection.fit(feature, [[margin.left, margin.top], [width - margin.right, height - margin.bottom]])

In cases where the container hadn't been pre-translated. Not the neatest but it's nice and explicit and seems particularly appropriate for a canvas context or insets/small multiples.

Moving path.area, path.bounds, and path.centroid to projection in 5.0 makes sense to me, if none of them are affected by any path-specific options. I only wonder whether having both projection.fit for fitting and projection.bounds for calculating bounds might be a little confusing.

[mbostock]

We can move the methods in 4.2 and leave the old ones as deprecated aliases
for backwards compatibility.
On Tue, Jul 12, 2016 at 12:40 PM Noah Veltman [email protected]
wrote:

A separate geoExtent or geoFit object definitely feels like overkill.
Skipping the padding works for me. Will probably lead to lots of code along
the lines of:

projection.fit(feature, [[margin.left, margin.top], [width - margin.right,
height - margin.bottom]])

In cases where the container hadn't been pre-translated. Not the neatest
but it's nice and explicit and seems particularly appropriate for a canvas
context or insets/small multiples.

Moving path.area, path.bounds, and path.centroid to projection in 5.0
makes sense to me, if none of them are affected by any path-specific
options. I only wonder whether having projection.fit for fitting and
projection.bounds for calculating bounds might be a little confusing.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#49 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAOEjTAFHFyISLhjKDyPlDKNJriGQZpFks5qU8N4gaJpZM4JJ4Qx
.

[mbostock]

A related consideration here is whether projection.fit should set
projection.center or projection.translate, or both. (In addition to setting
projection.scale.)

I guess it should set only projection.translate, but I did find it useful
to set a default projection.center in some of the extended projections to
make it easier to rescale and recenter them without having to compute a
complicated translate.

But in general it might be hard to set projection.center to the unprotected
point at the center of the projected feature’s bounds, since it could be
undefined if you have a weird projection like Hammer retroazimuthal.
On Tue, Jul 12, 2016 at 12:55 PM Mike Bostock [email protected] wrote:

We can move the methods in 4.2 and leave the old ones as deprecated
aliases for backwards compatibility.
On Tue, Jul 12, 2016 at 12:40 PM Noah Veltman [email protected]
wrote:

A separate geoExtent or geoFit object definitely feels like overkill.
Skipping the padding works for me. Will probably lead to lots of code along
the lines of:

projection.fit(feature, [[margin.left, margin.top], [width -
margin.right, height - margin.bottom]])

In cases where the container hadn't been pre-translated. Not the neatest
but it's nice and explicit and seems particularly appropriate for a canvas
context or insets/small multiples.

Moving path.area, path.bounds, and path.centroid to projection in 5.0
makes sense to me, if none of them are affected by any path-specific
options. I only wonder whether having projection.fit for fitting and
projection.bounds for calculating bounds might be a little confusing.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#49 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAOEjTAFHFyISLhjKDyPlDKNJriGQZpFks5qU8N4gaJpZM4JJ4Qx
.

[mbostock]

Actually I forgot that path.area and related methods are sometimes used
outside of projections, as with d3.geoTransform. So it's fine to have
projection.fit but I wouldn't move the other methods.
On Tue, Jul 12, 2016 at 1:03 PM Mike Bostock [email protected] wrote:

A related consideration here is whether projection.fit should set
projection.center or projection.translate, or both. (In addition to setting
projection.scale.)

I guess it should set only projection.translate, but I did find it useful
to set a default projection.center in some of the extended projections to
make it easier to rescale and recenter them without having to compute a
complicated translate.

But in general it might be hard to set projection.center to the
unprotected point at the center of the projected feature’s bounds, since it
could be undefined if you have a weird projection like Hammer
retroazimuthal.
On Tue, Jul 12, 2016 at 12:55 PM Mike Bostock [email protected] wrote:

We can move the methods in 4.2 and leave the old ones as deprecated
aliases for backwards compatibility.
On Tue, Jul 12, 2016 at 12:40 PM Noah Veltman [email protected]
wrote:

A separate geoExtent or geoFit object definitely feels like overkill.
Skipping the padding works for me. Will probably lead to lots of code along
the lines of:

projection.fit(feature, [[margin.left, margin.top], [width -
margin.right, height - margin.bottom]])

In cases where the container hadn't been pre-translated. Not the neatest
but it's nice and explicit and seems particularly appropriate for a canvas
context or insets/small multiples.

Moving path.area, path.bounds, and path.centroid to projection in 5.0
makes sense to me, if none of them are affected by any path-specific
options. I only wonder whether having projection.fit for fitting and
projection.bounds for calculating bounds might be a little confusing.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#49 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAOEjTAFHFyISLhjKDyPlDKNJriGQZpFks5qU8N4gaJpZM4JJ4Qx
.

[veltman]

One thing to note, it seems like that project to bounding box approach goes haywire with a gnomonic projection:

https://gist.github.com/veltman/a1d532a697764f05d0093dec40c571b2

[mbostock]

Yes. Many projections extend to infinity if you’re not careful.
On Tue, Jul 12, 2016 at 6:36 PM Noah Veltman [email protected]
wrote:

One thing to note, it seems like that project to bounding box approach
goes haywire with a gnomonic projection:

https://gist.github.com/veltman/a1d532a697764f05d0093dec40c571b2

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#49 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/AAOEjRvYXVUdRzfmHher7g9awMVBBVSwks5qVBbbgaJpZM4JJ4Qx
.

[mbostock]

Fixed in #50 by @veltman! 🎉