The Douglas-Peucker Algorithm

Open any map app and pan to a coastline. That jagged silhouette is built from thousands — sometimes millions — of GPS coordinates recorded by survey ships and satellites. Draw them all and your phone grinds to a halt; throw them all away and the shape becomes a smooth lie.

The Douglas-Peucker algorithm (also called Ramer–Douglas–Peucker, published independently in 1972–73) solves this tension with a single elegant idea: keep a point only if it bends the line enough to matter. Everything else is redundant and can be dropped.

The result is a simplified polyline — a chain of straight segments that approximates the original curve within a user-chosen tolerance. Zoom in and the app quietly swaps in a less simplified version; zoom out and it uses a heavily thinned one. Douglas-Peucker makes that swap possible without storing a different dataset for every zoom level — just re-run the algorithm with a different threshold.

The algorithm is solved and efficient: it was published by David Douglas and Thomas Peucker in 1973, runs in $O(n \log n)$ time on average, and is guaranteed to produce a result within the specified tolerance. No open questions, no NP-hardness — just a beautifully simple recursion that compresses geography without losing its soul.

The canvas below shows a jagged polyline. Drag the Tolerance slider to change how aggressively the algorithm simplifies it. Kept points light up in blue; dropped points fade out. Watch how the skeleton of the shape survives even at high tolerance.

<div class="controls">
  <label for="eps">{{tolerance_prefix}} <span id="eps-val">20</span> {{px_unit}}</label>
  <input id="eps" type="range" min="1" max="80" value="20" step="1">
  <span id="stats" class="stats"></span>
</div>
<canvas id="c" width="560" height="320"></canvas>
<div class="legend">
  <span class="dot kept"></span> {{kept_point}} &nbsp;
  <span class="dot dropped"></span> {{dropped_point}} &nbsp;
  <span class="line-seg kept-line"></span> {{simplified_line}} &nbsp;
  <span class="line-seg orig-line"></span> {{original_path}}
</div>

* { box-sizing: border-box; }
body { font-family: system-ui, sans-serif; color: #222; margin: 0; background: #f4f6f8; }
.controls { display: flex; align-items: center; gap: .8rem; flex-wrap: wrap;
            padding: .6rem .4rem .4rem; background: #fff; border-bottom: 1px solid #dde3ea; }
label { font-size: .88rem; white-space: nowrap; }
input[type=range] { width: 140px; cursor: pointer; }
.stats { font-size: .82rem; color: #555; }
canvas { display: block; width: 100%; max-width: 560px; margin: 0 auto;
         background: #fff; border-bottom: 1px solid #dde3ea; cursor: crosshair; }
.legend { display: flex; align-items: center; gap: .4rem 1rem; flex-wrap: wrap;
          font-size: .8rem; color: #555; padding: .5rem .6rem; background: #fff; }
.dot { display: inline-block; width: 10px; height: 10px; border-radius: 50%; }
.dot.kept   { background: #1d6fc9; }
.dot.dropped { background: #bbb; border: 1.5px solid #999; }
.line-seg { display: inline-block; width: 28px; height: 3px; border-radius: 2px; vertical-align: middle; }
.line-seg.kept-line  { background: #1d6fc9; }
.line-seg.orig-line  { background: #e0e0e0; }

// Code not found

Notice how the algorithm is local and recursive: it never looks at the whole curve at once — it just asks, at each step, whether the farthest point from the current baseline strays far enough to matter. That single question, repeated recursively, is the entire algorithm.

Douglas-Peucker is a solved, efficient algorithm — but the surrounding landscape has interesting edges worth exploring.

• Time complexity: $O(n \log n)$ on average (when the recursion divides the polyline roughly in half each time), and $O(n^{2})$ in the degenerate worst case (a spiral where every recursive call splits off just one point). For practical geographic data the average case dominates.
• Correctness: the algorithm is guaranteed to produce a simplified polyline where every dropped point lies within ε of the simplified line. This is a hard mathematical guarantee, not a heuristic — and it was proven by Douglas and Peucker in their 1973 paper.
• Optimality — a subtler question: Douglas-Peucker does not guarantee the minimum number of points that keep all dropped points within ε. Finding the true minimum-point simplification within a given tolerance is a more expensive problem, solvable in $O(n^{2})$ time using dynamic programming (the Imai–Iri algorithm, 1988). In practice, Douglas-Peucker's output is close enough to optimal that the difference rarely matters.
• Self-intersections: the simplified polyline can cross itself even when the original does not. This is acceptable for rendering but matters for geometric algorithms that assume simple polygons.

Douglas-Peucker sits in the comfortable zone of P vs NP: it is polynomial, deterministic, and correct. The only price is that it is not always minimal, and a truly optimal simplification costs a bit more to compute. For the billions of map tiles served every day, that trade-off is entirely worth it.

Douglas-Peucker is one of the most widely deployed geometric algorithms in the world, appearing wherever a curve needs to be approximated cheaply:

• Web and mobile maps: OpenStreetMap, Google Maps, Apple Maps and every tile-based mapping system use it (or a derivative) to generate simplified geometries at each zoom level. Without it, rendering a world map would require transmitting terabytes of coordinates.
• GPS track compression: fitness apps and navigation systems record a GPS point every second. Douglas-Peucker strips the redundant samples for storage and display, keeping turns and bends while discarding straight-line noise.
• SVG and vector graphics: illustration software and CAD tools use it to clean up hand-drawn curves and scanned outlines, reducing the point count before export.
• Computer vision: contour detection pipelines (OpenCV's approxPolyDP) use Douglas-Peucker to turn pixel-level contours into compact polygons for shape recognition.
• Robot path planning: motion planners simplify recorded demonstration paths before replaying them, removing jitter while preserving the intended trajectory.
• Scientific data visualization: time-series charts with millions of samples use it to render only the detail the screen can actually show.

Every time your navigation app draws a smooth road with far fewer vertices than the raw survey data, there is a good chance Douglas-Peucker made that decision — one recursive question at a time.

Douglas-Peucker is a reminder that the most powerful algorithms are often the simplest ones: find the farthest point from the baseline, keep it if it matters, and recurse on the two halves. That is the whole idea, and it is enough to compress the world's coastlines into something a phone can render in milliseconds.

It is also a gentle contrast to harder problems on this site. Unlike P vs NP or the halting problem, Douglas-Peucker is fully solved — fast, correct, and proven. The only open edge is optimality, and even that has a clean polynomial solution. Sometimes computation is kind, and a beautiful recursive idea is genuinely all you need.