Buffers & Proximity

A buffer is a new polygon drawn at a chosen distance around an existing feature. Feed it a point and a distance of 250 m and it hands you back a circle of radius 250 m. Feed it a line — a road, a drain, a rail alignment — and you get a corridor of that half-width on each side. Feed it a polygon and you get a fatter version of the same shape, grown outward (or, with a negative distance, shrunk inward).

Why bother turning a distance into a shape? Because a shape is something you can overlay and select against. Once the 250 m circle exists as a polygon, you can ask the GIS: which plots fall inside it? How many households? Which of them also flood? The buffer is the bridge between proximity (a fuzzy human idea — near, walkable, too close) and geometry (a hard edge the computer can test). It converts a rule of thumb into a boundary you can defend in a meeting.

The simplest buffer uses one fixed distance for every feature: every bus stop gets the same 250 m. That is right when the rule itself is fixed — a service standard, a single walk radius, a blanket exclusion zone.

But real rules rarely treat everything the same. A statutory road setback is 30 m from an arterial, 15 m from a collector, 6 m from a local street. A variable (data-driven) buffer solves this in a single pass: instead of typing a distance, you point the tool at a field in the attribute table — a setback_m column — and each feature is buffered by its own value. This is the difference between running the tool sixty times and running it once. It is also how you encode a whole rulebook — noise contours by road class, protection zones by heritage grade — without cloning your data.

A buffer answers a yes/no question — inside or outside 250 m? Sometimes you want the number itself: exactly how far is each plot from the nearest hospital? That is proximity analysis, and the tools that produce it are close cousins of the buffer. A distance to nearest tool (nearest-neighbour join, or a distance matrix) writes the measured distance back onto every feature, so you can rank, colour or threshold by it later.

Here it helps to remember Waldo Tobler's first law of geography: everything is related to everything else, but near things are more related than distant things. Proximity is not just bookkeeping; it is the assumption underneath most site logic. Rent, noise, footfall, land value and risk almost all decay with distance from something. Measuring that distance is often the whole analysis.

One honest caveat before you trust a proximity number in India: it is only as good as the completeness of the layer you measure against. If your hospitals layer from OpenStreetMap is missing half the clinics in a peri-urban ward, your 'distance to nearest hospital' will be systematically too large exactly where coverage is thinnest. Straight-line proximity also flatters reality - it measures through walls and across drains that no one can cross. Treat the buffer and the distance-to-nearest as a fast first read, and remember that Lesson 4.4 replaces the straight line with distance along the actual street network.

Here is the mistake that quietly ruins more buffers than any other. Your data is very likely stored in EPSG:4326 (WGS 84) — degrees of latitude and longitude. If you type 250 into a buffer tool while the layer is in degrees, the software cheerfully buffers by 250 degrees, or by a distance that means nothing on the ground. Even when a tool lets you say 'metres', on a geographic CRS it must approximate, and the result stretches — a circle becomes an ellipse, wider east-west than north-south.

The fix is a habit, not a setting: reproject to a projected, metre-based CRS before you buffer. For most of India that means a UTM zone on WGS 84 — EPSG:32643 / 32644 / 32645 (zones 43N-45N) — or the national EPSG:7755 (India NSF LCC). In a metre CRS, 250 means 250 m in every direction, and your catchment is a true circle. Check the layer's CRS first, every single time.