About Situ

A process book on urban rhythm and spatial culture in Griffintown, Montréal

Author

Mohamed Gharbia

Published

October 17, 2026

What Situ is

Situ is the prototype for my PhD research-creation project. It asks whether the spatial culture and urban rhythm of Griffintown, Montréal, can be mediated and archived through a game-like 3D experience. I look at two eras: today, and the 1920s to 1940s. I work from the city’s open data and from observation, and I read both through urban theory. Game design carries the result to a player.

Nothing in Situ archives anything yet. So far there is a foundation: the street network with its rules and buildings, and the measures I will test it against.

The idea

Spatial culture

Hillier described a spatial culture as “a distinctive way of ordering space” (Hillier 1989, quoted in Griffiths & von Lünen 2016, p. xxiii). Griffiths and von Lünen see the field as the link between how a built place works and what it comes to mean to the people who live in it (2016, p. xxi). Adams (2024, introduction) wants spatial culture to be “qualified and documented”, which is close to what an archive needs.

Rhythm

A street layout holds no time. Space syntax, the method Hillier and Hanson started for measuring how a street network is arranged (What space syntax is), tends to strip social practice of its time (Griffiths & von Lünen 2016, p. xxiii). In Rhythmanalysis, Lefebvre finds rhythm wherever energy is spent in a particular place and time (2004, p. 15). His own example is a Paris junction seen from his window: on red the pedestrians cross, on green the cars rush (p. 28). The light cycles in S3 model that beat. He also holds that where there is rhythm there is measure (p. 8), so counts and timings belong in Situ. I add time on purpose: when places are open and when streets are busy.

Archiving

An archive keeps two things: the evidence records give of how their maker worked, and the information they hold about people and places (Schellenberg 1956, pp. 139 to 140). Situ keeps both. The city data says what Griffintown is. My decision files and tests record how I turned it into a model, the layer that the London Charter, a set of principles for visualising cultural heritage by computer, calls paradata (2009, principle 4.6). The Seville principles ask that a reconstruction show what is real and what is not (López-Menchero & Grande, principle 4), and that others can test it (principle 7). So every decision in my files carries a status, such as confirmed, assumed, likely or open.

Rhythm is the hard part. Taylor separates the archive of lasting things from the repertoire of embodied practice, like walking to work or lingering at a corner, which needs people to be present (2003, pp. 19 to 20). Situ cannot store a rhythm the way it stores a street. It can keep traces such as counts and timings, and offer a place where the rhythm can be performed again: the game. The Seville principles warn against showing “lifeless cities” (principle 5.3).

What Situ has and what it lacks

Lefebvre describes three moments of social space (1991, pp. 38 to 40). Each kind of source in Situ lines up with one of them, so I use them as a checklist, with every row open to revision.

Lefebvre In Situ Status
conceived space: plans, maps, data the network and its rules (S1 to S3), building types (S4) and street objects (S6), from city data, OpenStreetMap and street photos built
perceived space: daily routines rhythm and movement (S5 to S9), from the city’s counts, the census and later computer vision a weekday measured in S5; commuters counted by the census in S7; a morning on foot imagined in S9
lived space: space as its users live it the game, and what people say about the place, through play and later interviews not started

These are my own interpretations of the sources, each with the strongest objection I know and what would show me wrong.

Lefebvre’s triad as a checklist

Lefebvre warns that his three moments lose their force as an abstract model (1991, p. 40), and laying them over software comes close to that. So I use the table only to see what is missing; for now the lived row is empty. The rows also leak: the counts are observation, yet the city decided where to count. If the rows cannot be kept apart at all, the table should show the crossings.

Where layout and movement disagree

A gap between space syntax and observed movement points to something besides the layout, such as a shop or a rule. Griffiths and von Lünen ask research to spell out that kind of gap (2016, p. xxi). The 1993 paper on natural movement, the share of walking the layout alone produces, itself shows shops multiplying the layout’s effect (Hillier et al. 1993, p. 31). A difference may also be plain error, from a wrong network or too few counts, so it counts only after each system’s tests. The reading is wrong if the differences vanish once errors are fixed, or follow no pattern.

Schellenberg’s two values

Schellenberg drew his distinction between evidence and information from government records (1956, pp. 139 to 140, 148), and a research model is no government agency. I borrow only the distinction, which he says he defines “quite arbitrarily” (p. 139), and the London Charter already carries it into visualisation. The borrowing fails if the two layers cannot be kept apart, so my corrections live in their own file and the city’s files stay untouched.

The game as a place to perform rhythm again

Taylor’s repertoire and Lefebvre’s rhythm both need bodies present, and play is embodied action too. Against this, a player alone in a simulation receives no memory from Griffintown’s people, and the game itself is code and data, an archive object. Lefebvre adds that the rhythmanalyst is closer to the poet than to “the statistician, who counts things” (2004, p. 23).

I accept most of this. The game keeps traces and sets up a new performance, without holding the original repertoire, so interviews and focus groups are in the plan. If players’ movement bears no relation to the recorded rhythms, the game performs nothing of Griffintown.

Space syntax as one measuring stick

Space syntax describes the layout. I use it only to measure, and the simulated walkers never read it. At the end, S9 compares where they went with what space syntax predicts and with the city’s counts. Where they agree, the layout may explain the movement. Where they differ, something else is at work, and that difference is what the archive should keep.

flowchart LR
  D[City data, OpenStreetMap,<br/>street photos]:::data --> S[Small systems<br/>S1 to S8]:::step
  O[Counts<br/>measured on the street]:::data
  S --> M[Flows built from<br/>the systems]:::step
  M --> C{S9 Observer<br/>compare}:::test
  SS[Space syntax]:::data --> C
  O --> C
  C --> G[The game:<br/>a place to play<br/>and to keep]:::out
  L[Lived accounts<br/>interviews, play]:::data --> G
  classDef data fill:none,stroke:#8a8a8a,color:#e6e6e6
  classDef rule fill:none,stroke:#8a8a8a,stroke-dasharray:4 3,color:#a6a6a6
  classDef step fill:none,stroke:#e6e6e6,color:#e6e6e6
  classDef out fill:none,stroke:#e6e6e6,stroke-width:2px,color:#ffffff
  classDef test fill:none,stroke:#fe83cc,color:#fe83cc

I build Situ as small systems, each with a single job. Each has a blueprint and its own tests, and I try it in the Lab before the next one starts.

The systems

System Job Status
Walking network Add the city’s off-street paths before space syntax is calculated built, tested
S1 Streets Which streets connect, and who may use them in which direction built, tested
S2 Scores Attach the space syntax values to each street built, tested
S3 Rules Stop signs, traffic lights, forbidden turns, speed limits built, tested
S4 Buildings What each building is, so people have places to go built, tested
S5 Rhythm When the streets are busy, and which places say they are open built, tested
S6 Streetscape What stands on the streets: trees, hydrants, lights, cameras, crossings, sidewalks, benches, road works built, tested
S7 Commuters Who commutes, how and when, and how far homes are from transit built, tested
S8 Views What a walker can see from each point of the streets built, tested
S9 Observer Imagines walkers and drivers from what the other systems say, and compares them with the counts and space syntax first slice: the morning on foot

Where to start

Reading the diagrams

Every blueprint uses the same key. A grey outline is data coming in, and a dashed grey one is a decision I made and kept in a file. A white outline is a processing step, and a thick white one is a result written to disk. Pink marks a test.

On the map sheets, labels never overlap. When a label has to move, a thin line points back to what it names.