Network Analysis & Walkability

Network analysis begins with a change of view: stop seeing streets as lines on a map and start seeing them as a graph - the mathematician's word for a set of connected things. Junctions become nodes (also called vertices); the street segments between them become edges (or links). Every edge carries a weight - its cost of travel. The simplest weight is length in metres; a richer one is travel time, which lets you set different speeds for walking, cycling and driving, or penalise a steep or unlit segment.

Once the street system is a weighted graph, decades of well-understood algorithms apply. The city stops being a picture and becomes a routable structure - one where 'how far' and 'how long' have exact, computable answers that respect every wall, dead-end and one-way street.

The first thing a graph lets you compute is the shortest path between two points - the route with the least total weight. The classic method, Dijkstra's algorithm, effectively considers every possible route and keeps the cheapest, whether 'cheap' means shortest in metres or fastest in minutes.

Note the word: shortest path, not shortest line. The result almost never matches the straight line between origin and destination, because it must follow real edges. Change the weights - switch from distance to time, add a speed limit, block an edge for construction - and the shortest path can change completely. This is the engine behind every routing you have ever used, and in analysis it answers concrete questions: what is the true walking distance from this housing block to the nearest school, and by which streets?

Run the shortest-path logic outward in all directions from a point until you exhaust a budget - 400 m of walking, or 10 minutes - and trace the boundary of everywhere you could reach. That boundary is a service area; when the budget is time, it is often called an isochrone (a line of equal travel time).

This is the true replacement for the buffer. A 400 m buffer is a smooth circle that assumes you can walk in any direction through anything. A 400 m network service area is a ragged, blob-like shape that pushes far down open streets and stops dead at the walled campus and the uncrossable drain. On the same site the service area is always smaller than the buffer, and the gap between them is the barrier effect - the severance a plan should be trying to fix. For access questions, always prefer the service area.

Put these together and you can measure walkability honestly. The pedestrian catchment - the 'ped shed' - of a station or a school is its walking service area, and how much of it is real (versus the tidy circle) is a direct measure of how connected the street fabric is. A fine grid of small blocks yields a service area that nearly fills its buffer; a fabric of superblocks, gated layouts and missing crossings yields a shrunken, spiky one.

This is exactly the analysis behind the 15-minute city - the idea, drawn on older 'neighbourhood unit' thinking, that daily needs should sit within a short walk of home. In GIS terms it is a set of overlapping service areas around shops, schools, clinics and parks, tested against where people live. It also connects to the deeper structural reading of streets - Bill Hillier and Julienne Hanson's space syntax, which we take up in Module 9 - where how a street sits in the whole network predicts how many people move along it. Network analysis is where the felt idea of a walkable neighbourhood becomes a measured, mappable claim.

A closing dose of India realism, because network analysis is only as trustworthy as the network. In many Indian cities the routable data has real gaps: footpaths are missing or discontinuous in OpenStreetMap, informal shortcuts that everyone uses are unmapped, and a segment tagged as a road may in practice be unwalkable - no footpath, no safe crossing, waterlogged in the monsoon. A service area computed from an incomplete or optimistic network can quietly overstate walkability just as a buffer does. So validate against the ground: walk a sample of the routes, add the missing footways, and be explicit in your report about what the network does and does not include. An honest, slightly rough service area beats a precise one built on data you never checked.