Buffer & Proximity: How Far Is Within Reach

An interactive lab with Python, R and MapLibre — buffer a point, a line, and a polygon at the same distance, see why the three results end up different shapes, and why the distance has to be a real one, not degrees.

“What’s within 300 meters of this store?” and “what falls within 50 meters of this road?” are the same question underneath: draw a zone at a fixed distance around a feature, then check what’s inside it — a buffer. The distance is fixed, but what comes out depends entirely on what went in.

Want to try it on your own file instead of reading through the code? Use the standalone tool — same engine, less prose.

1. Why the coordinate system matters here

A buffer distance is a real distance — meters, not degrees of longitude/latitude, where the same number of degrees covers very different real distances depending on where on Earth you are. Both languages below pick a working UTM zone from the data’s own bounding-box center and reproject into it first — same reasoning, same formula, as this site’s Viewshed and Spatial Clustering tools: a reasonable default for one local dataset, not a universally correct choice for data spanning multiple UTM zones or very large areas.

2. Same spatial question, two languages

Three features, one distance (30m), deliberately different geometry types: a point (a shop), a line (a road segment), and a polygon (a building footprint). Fixed coordinates, not uploaded — the point here is the algorithm and what it does to each shape, not file handling (the standalone tool covers uploading a real file).

Python

R

mutable pySummary = null

mutable rSummary = null

pyResult = WebGeoDS.getCellValue("buffer-proximity-py", Generators)
{
  if (pyResult) mutable pySummary = pyResult;
}

rResult = WebGeoDS.getCellValue("buffer-proximity-r", Generators)
{
  if (rResult) mutable rSummary = rResult;
}

statCard = (label, s) => {
  const wrap = document.createElement("div");
  wrap.style.flex = "1";
  wrap.style.minWidth = "260px";

  const heading = document.createElement("div");
  heading.className = "webgeods-label";
  heading.textContent = label;
  wrap.appendChild(heading);

  const box = document.createElement("div");
  box.className = "webgeods-stat-grid";
  wrap.appendChild(box);

  const row = (rowLabel, value) => {
    const dt = document.createElement("div");
    dt.className = "webgeods-stat-label";
    dt.textContent = rowLabel;
    const dd = document.createElement("div");
    dd.className = "webgeods-stat-value";
    dd.textContent = value;
    box.append(dt, dd);
  };

  if (!s) {
    row("Calculation CRS", "—");
    return wrap;
  }

  row("Calculation CRS", s.calculationCrs);
  row("Input geometry", s.geometryTypes.join(", "));
  row("Buffer geometry", s.bufferGeometryTypes.join(", "));
  row("Buffer areas (m²)", s.bufferAreas.join(", "));

  return wrap;
}

statCardsRow = {
  const row = document.createElement("div");
  row.style.display = "flex";
  row.style.flexWrap = "wrap";
  row.style.gap = "16px";
  row.append(statCard("Python", pySummary), statCard("R", rSummary));
  return row;
}

3. One distance, three different shapes

Both cards above ran the exact same 30m buffer on the exact same three features. The shapes agree exactly; the areas don’t — by a small, fully explainable margin, not a disagreement about the answer:

• The point’s buffer is a circle: every direction from a single location is equally “within reach.”
• The line’s buffer is a stadium shape (a rectangle with two rounded ends): every point along its length gets its own circle of reach, and they merge into one continuous zone.
• The polygon’s buffer is the original shape, expanded outward, with its corners rounded off: everywhere already inside stays inside, plus a 30m halo all the way around the boundary.

Note

Why the point buffer’s area isn’t quite identical. A circle can’t be drawn exactly with straight line segments — every buffer implementation approximates it with a many-sided polygon, and how closely depends on how many segments it uses per quarter-circle. GeoPandas’ .buffer() defaults to resolution=16; sf::st_buffer() defaults to nQuadSegs=30 — almost double. A true 30m-radius circle has an area of 2827.4 m² (π × 30²). Python’s 16-segment approximation lands at 2822.9 m²; R’s 30-segment one at 2826.1 m² — closer to the true value, because it’s a finer approximation of the same circle, not a different formula. Passing resolution=30 in Python reproduces R’s default result almost exactly (2826.1416 m², verified) — the defaults just don’t happen to agree out of the box.

Every geometry type buffers into a polygon, regardless of what it started as — there’s no such thing as a “buffered point” that’s still a point. That’s also why dissolving several overlapping buffers into one shape (the standalone tool’s own checkbox) is meaningful: once everything is already a polygon, merging overlapping ones is a single, well-defined operation, the same one used to answer “what’s the total area within reach of any of these features,” not “within reach of each one separately.”

4. Where to next

• Just needed to buffer a file? → The standalone Buffer & Proximity tool runs the same computation on an uploaded point/line/polygon file (or its own example), with an adjustable distance and an optional dissolve, colored on the map, downloadable.
• Wondering why the coordinate system needed picking at all? → Coordinate Reference Systems covers the geographic/projected distinction this article leaned on in section 1.