Attribute Tables & Joins

Open any vector layer's attribute table and you see a spreadsheet where each row is one feature and each column is one field (attribute). The ward polygon you click on the map is the same object as its highlighted row — shape and facts, two views of one thing, as Module 0 established.

Every layer carries at least a hidden identifier and a geometry reference; the useful fields are the ones you add: name, population, land use, area. The table is where selection, calculation and joining happen. Select rows here and the shapes highlight on the map; compute a new field here and every shape gains a value. Most "GIS analysis" is, underneath, disciplined work on this table.

Each field has a data type, and choosing it correctly is quietly critical. An integer holds whole numbers (a ward id, a count). A real (float/double) holds decimals (area in hectares). A text (string) holds names and codes. A date holds calendar values.

Two traps recur. First, numbers stored as text will not sum, sort or compare numerically — "100" sorts before "99" as text. Second, and the cause of most failed joins: the key field must have the same type in both tables. A ward code stored as an integer in your boundaries but as text (with a stray leading zero or trailing space) in the Census file will simply refuse to match, and the join fails silently — rows drop with no error. Decide the type of every field, and above all the type of your key, before you join anything.

A table join (attribute join) appends the columns of a second table onto your layer wherever a chosen key field matches. The key is a value both tables share — a ward code, a census location code, a village id. You tell the software: join the Census table to the ward layer where wardid equals wardid, and every matched boundary inherits the population, literacy and household columns.

Most joins are one-to-one (one boundary, one matching row) or many-to-one (many features share a lookup value). The result is usually a virtual join — live and unsaved — so remember to export to a new file to make it permanent. Watch the match rate the software reports: if only 190 of 198 wards matched, eight keys disagree somewhere, and those eight wards will be blank on your map.

This is the workhorse of Indian urban analysis, and it has a specific discipline. India's Census releases data keyed by standardised location codes; your boundary layer must carry the same codes for the join to bite. Before joining: confirm both sides use the identical code field (not the name — names have spelling variants, "Bengaluru" vs "Bangalore"); strip stray spaces; match the data types; and note the Census year and administrative vintage, because ward and district boundaries are periodically redrawn.

One conceptual caution carries into everything you map from such data. Values reported per ward or per zone depend on how those units are drawn — change the boundaries and the pattern can change too. This is the Modifiable Areal Unit Problem (MAUP), and it means a choropleth of joined Census data is a statement about the units as much as the phenomenon. Report your unit and year; do not over-read a pattern that the zoning itself may have created.

Sometimes there is no shared code — you have bus-stop points and ward polygons and want to know how many stops fall in each ward. A spatial join matches features by their geometry instead of a key: for each ward, it finds the points that fall within it and, say, counts them or sums an attribute. The spatial relationship you choose — intersects, within, contains, nearest — defines the match.

Spatial joins are how you attach context that only geography can supply: stops per ward, jobs within a catchment, which zone each building sits in. They demand two things you already know to check — both layers in the same CRS (next lesson) and clean topology, so a point on a boundary is not ambiguously in two wards. Get those right and a spatial join answers questions no shared key ever could.