Spatial Queries & Select by Location

The first way to select is by the attribute table - by the facts in the columns, ignoring geography entirely. You write a condition and the GIS highlights every row (and its shape) that satisfies it. The language is essentially SQL's WHERE clause: land_use = 'commercial', or population > 20000, or road_class = 'arterial' AND lanes >= 4.

This is the fastest, cheapest kind of query, and often the first move even in a spatial problem - narrow the layer to the features worth testing before you do any geometry. Two habits save grief: quote text values ('commercial') but not numbers, and be deliberate with AND versus OR. A AND B returns only rows meeting both; A OR B returns rows meeting either, which is almost always a bigger set than beginners expect. An attribute query is a question about the table; it does not know or care where anything is.

The second way is what makes GIS special: select by location picks features in one layer based on their spatial relationship to features in another. Select plots that fall inside a ward. Select bus stops that lie on an arterial road. Select buildings that touch a flood polygon. No shared ID, no common column - the relationship is pure geometry.

This is different from overlay (Lesson 4.2) in an important way: select by location does not create new geometry. It leaves both layers untouched and simply flags the features in the target layer that satisfy the relationship. You get a selection you can then export, count, or refine - not a cut-up new layer. When your question is 'which existing features qualify?', select by location is lighter and cleaner than an intersect.

'Where they sit' has to be made precise, and GIS does it with a small vocabulary of spatial predicates - the exact relationship you are testing:

- Intersects - the two features touch or overlap in any way at all. The most permissive, and a safe default when you are unsure. - Within - feature A lies entirely inside feature B (a plot within a ward). - Contains - the mirror of within: feature B holds A inside it (a ward contains a plot). - Touches - they share only a boundary, no interior (two adjacent plots). - Crosses / Overlaps - partial passage or partial overlap.

Within and contains are the same relationship read from opposite ends, which is a frequent source of confusion - keep straight which layer is your target. Choosing the wrong predicate is how you end up with a selection that looks plausible but is quietly wrong: 'intersects a ward boundary' catches plots straddling the edge that 'within a ward' correctly excludes.

Real questions usually need both kinds of query, chained. Take the brief from the hook - commercial plots within 100 m of a school. You build it in steps: first an attribute query on plots (land_use = 'commercial') to narrow the field; then a select-by-location using the predicate 'within a distance of 100 m' against the schools layer; the two combine with AND. Read back to front, the selection is a plain English sentence: select plots that are commercial AND within 100 m of a school.

Most tools let you refine a selection incrementally - add to, subtract from, or select within the current selection - which lets you assemble a complex condition without one monstrous expression. And when the data lives in a spatial database, the same logic becomes a single SQL statement with functions like STWithin and STDWithin. The mental model never changes: name the target, name the relationship, name the reference. Query built.

Two things separate a query that runs in a second from one that hangs for minutes. The first is a spatial index - a structure the software builds so it can skip features that are nowhere near your reference, instead of testing every one of forty thousand plots against every school. Desktop tools index automatically for most operations; in PostGIS you create it once and every spatial query gets faster. The second is doing the cheap work first: a permissive predicate like intersects is faster than an exact one, so narrow with an attribute query, then apply the spatial test to the small survivor set. On city-scale data these habits are the difference between analysis you can iterate and analysis you dread re-running.