There is also a greatCircle as an alias, whose angle defaults to 90 degrees. (Or
should, but some projections cannot handle 90 degrees so we use 89 instead.)
The greatArc class is the new name for greatCircle, which actually represents
great arcs. Meanwhile, a new greatCircle class is for great circles. The new
greatCircle class replaces the old clip class, providing clipping and resampling
functionality (using greatArc internally). This isn't backwards-compatible, but
I may forgo the major version number bump in light of the fact that greatCircle
was just added, and not used in any (official) examples or documented.
Note that the Werner projection is a special case with standard parallel
at 90°N, and the Sinusoidal projection is also a special case with
standard parallel at 0°N.
We can interpolate the exact distance to the clipping edge, and use this
to interpolate the point exactly instead of computing a full path and
picking the closest point.
This can be used to process output from d3.geo.clip to ensure clipped
polygons are correctly curved.
The "n" option has been replaced with precision, which denotes the
approximate angular length of great-circle segments. This is much
faster than using a fixed number of segments, particularly when
processing a large number of polygons, only a few of which may have
edges long enough to warrant being converted into a geodesic.
This can be used with d3.geo.path.clip to clip the input coordinates of
geographical shapes using a given origin and angular radius, e.g. for
hemispherical or near-hemispherical views. Geodesics are inserted as
necessary.
This also includes a minor bugfix and test for d3.geo.path: the last
coordinate of Polygon features was being included unnecessarily
(MultiPolygon already handled this correctly).
Higher-order programming! This makes it more akin to d3.svg.chord i.e.
it can take "d" and "i" arguments. Thanks for the suggestion, Mike!
Also made "n" and "radius" configurable, too.
Can be used to generate great circle paths. Similar to R's
geosphere.gcIntermediate (in which I discovered a bug, while writing the
test case for this!)
Includes d3.geo.greatcircle().distance for computing the shortest geo
path distance using the Haversine formula.
For a tutorial on using great circles, see:
http://flowingdata.com/2011/05/11/how-to-map-connections-with-great-circles/
UglifyJS requires Node.js to run, but it's a lot faster than Google's
compiler and produces smaller gzipped sizes. Some of the non-gzipped
sizes are a bit larger than Google's but I think the gzipped size is
more important. Faster runtime is also good when we start testing the
minified versions too.
This method can be used for computing the bounding box of arbitrary GeoJSON
objects. This commit also fixes a bug in d3.geo.path, such that it will accept
any GeoJSON object, rather than requiring GeoJSON feature objects.
The renaming of attributes is totally not worth the hassle of maintaining an
externs file (or using the awkward `foo["bar"]` syntax). The file size
reduction from the advanced optimizations was negligible, besides!
This computes the projected area (in square pixels) of the given GeoJSON
object. This is useful for producing choropleth maps that area normalized to
the visible area.
Jason Davies
Mike Bostock