1. 16 Oct, 2013 3 commits
  2. 09 Oct, 2013 3 commits
  3. 26 Sep, 2013 5 commits
    • Mike Bostock's avatar
      Merge branch '3.3.6' · 2c93d9c1
      Mike Bostock authored
    • Mike Bostock's avatar
      Update dependencies. · c6f99320
      Mike Bostock authored
    • Mike Bostock's avatar
    • Mike Bostock's avatar
      Don’t pollute an ordinal scale’s domain. · d2ad436f
      Mike Bostock authored
      Fixes #1550. By using the copy of the new scale (which we make anyway for a
      snapshot) we avoid polluting the scale’s domain with the old values when using
      the scale as the key function for the tick data-join.
    • Jason Davies's avatar
      Fix clipping bug for complex polygons. · 9eb878ec
      Jason Davies authored
      Intersection points are sorted along the clipping region edge relative
      to a particular point.  In the case of antimeridian clipping, this point
      is the South pole.  Previously, the first intersection was assumed to be
      an entering intersection, but this is not always the case.
      The fix is to see whether the clip region start point (the point
      relative to which sorting occurs) is inside or outside the polygon being
      drawn.  If it is inside, then the first intersection point must be
      outside, and so forth.
      The same applies to d3.geo.clipExtent.  Provision was already made for
      this, but this has now been optimised to use a single point instead of
      picking one of the four corners.
      Another optimisation was to reuse this clip region start point to
      determine whether to interpolate all the way around the clip region
      edge.  Previously, this was done by testing an arbitrary point in the
      clip region.
      The above fix seemed to have broken one of the tests, and this has been
      fixed by modifying the point-in-polygon routine slightly to handle
      points that might lie exactly on the polygon edge.
      Finally, I noticed a regression with the recent clipExtent fix, where a
      polygon incorrectly being marked as “clean” (no intersections) on a
      per-ring instead of per-polygon basis.
  4. 25 Sep, 2013 9 commits
  5. 24 Sep, 2013 3 commits
    • Jason Davies's avatar
      Perform winding order check on unrotated polygons. · 31ea7dc0
      Jason Davies authored
      We remove the rotation step that occurred prior to clipping, so that
      clipping processes unrotated polygons.  Note that clip regions are
      defined relative to the rotated globe, so clipping now needs a rotation
      Rather than moving the rotation step so it occurs after clipping, the
      rotation occurs as part of clipping, using the rotation parameter to
      rotate streamed points.  Alternatively, points could be clipped against
      a rotated clip region, and then subsequently rotated as a separate step,
      but this seems slightly less efficient.
      Fixes #1453.
    • Jason Davies's avatar
      Simplify. · ba48daa1
      Jason Davies authored
    • Jason Davies's avatar
      Fix clipExtent bug. · b89c2d97
      Jason Davies authored
      If a polygon does not intersect with the extent, but has one or more
      rings inside the extent, then the extent should be checked to see
      whether it is inside the polygon: if so, an additional exterior ring is
      Previously, this check was only made if there were no visible rings at
      Fixes an issue noticed in #1453.
  6. 21 Sep, 2013 2 commits
    • Mike Bostock's avatar
      Merge branch 'fix-implicit-ordinal-domain' · 7bb322f6
      Mike Bostock authored
    • Mike Bostock's avatar
      Restrict implicit domains to explicit ranges. · 113032bc
      Mike Bostock authored
      When an ordinal scale’s range is explicitly defined as an array of values, we
      can build the domain implicitly by progressively assigning values from the
      range; this is commonly done with color palettes, for example.
      However, when an ordinal scale’s range is rather implied by chopping a
      continuous range into a series of points or bands, then the domain must be
      specified explicitly: for the scale to be consistent, we need to know the
      cardinality of the domain to compute the implied range values.
      Thus, it only makes sense to extend the domain implicitly when the range is
      specified explicitly. Fixes #1536 #1535.
  7. 18 Sep, 2013 6 commits
  8. 16 Sep, 2013 1 commit
    • Jason Davies's avatar
      Fix point-in-polygon for multiple polar rings. · eff0a116
      Jason Davies authored
      Instead of detecting if any single polygon ring winds around a pole, we
      consider the cumulative winding of all polygon rings together.  This is
      consistent with the area calculation, which considers the cumulative
      area total of all rings.
      This fixes #1521: an issue with the Hammer Retroazimuthal projection,
      which uses such a polygon with two rings, covering most of the globe.
      In addition, drop the special handling of points at the south pole,
      which might have been there to pass an incorrect test: a CCW triangle
      touching the south pole, which was probably incorrectly thought to be
      clockwise.  This fixes an issue with a “stripe” polygon rotated so that
      a point is at the south pole, mentioned in #1453.
  9. 05 Sep, 2013 8 commits