Comments (11)
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.
from d3-geo.
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
?
from d3-geo.
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
.
from d3-geo.
from d3-geo.
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.
from d3-geo.
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
.
from d3-geo.
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
.
from d3-geo.
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
.
from d3-geo.
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
from d3-geo.
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
.
from d3-geo.
from d3-geo.
Related Issues (20)
- How can I clamp a geodesic to between a max/min latitude? HOT 1
- fit-test.js Remove duplicate test HOT 1
- Geojson to SVG offset HOT 1
- Geojson to SVG offset
- Cannot import d3-geo in node with typescript HOT 8
- Geographic or Geodetic HOT 1
- D3 uses GeoJSON to represent geographic features in JavaScript HOT 2
- postclip with polygon path maybe... HOT 10
- Error [ERR_REQUIRE_ESM]: Must use import to load ES Module / require() of ES modules is not supported HOT 2
- geoAzimuthalEqualArea not rendering straight lines HOT 2
- clipCircle's precision is too low
- Configurable precision for d3.geoPath
- Mercator. Getting boundary values by longitude HOT 2
- Mercator with rotate. Incorrect conversion from projection to geographic coordinates HOT 3
- Сonvert geographic points considering antimeridian and pole HOT 1
- geoContains function doesn't seem to handle MultiPolygons HOT 9
- path.bounds should return numbers even when input coordinates are strings
- [Question] API for chekcing if point is in view or not given projection HOT 3
- Mercator Map centered on the Pacific HOT 1
- geoCircle produces an open LinearRing
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from d3-geo.