Building the City Model

The least glamorous source is often the most important: the official, authoritative records of the city, held in cadastral systems and GIS (Geographic Information System) databases. The cadastre records land parcels, ownership and boundaries; GIS layers hold building footprints, road networks, administrative zones, land-use classifications, utility networks and much else. These 2D (and increasingly 3D) datasets are the skeleton a city model is built on: the footprints tell you where buildings are and often their permitted use; the road network gives you the transport layer; the zoning and land-use layers supply crucial semantic attributes. A great deal of a usable LOD1 or LOD2 model can be generated by taking footprints from GIS and extruding them to heights derived from other sources.

What makes this data special is that it carries authoritative meaning, not just shape. A building footprint in an official cadastre is not a guess; it is a record with legal and administrative weight, linked to ownership, use and permissions. This is precisely the semantic richness Lesson 2.3 prized - and it comes from records, not from looking at the city. It is also why the official custodians matter so much: in India, bodies such as the Survey of India and the relevant state and municipal authorities are the keepers of authoritative geospatial and cadastral data, and a twin's working layers are never a substitute for that record. Binding questions of who owns what and where a boundary lies stay there, with the custodians and the law.

But this foundation has honest cracks, sharply so in the Indian context. Cadastral and GIS data can be incomplete, out of date, inconsistent between agencies, or simply wrong - and vast portions of the real city may be missing from it altogether. Informal settlements, unauthorised construction and the organically grown parts of a city are frequently absent from or misrepresented in official records, which means a model built faithfully on that data will faithfully reproduce its blind spots, rendering the informal city invisible exactly as Module 0 warned. So the records are the indispensable semantic foundation of a city model, and also the first place its biases and gaps are baked in. A competent modeller treats official data as authoritative for what it covers and openly uncertain about what it omits - and never mistakes 'not in the data' for 'not in the city.'

Records tell you where things are and what they are meant to be; to capture the actual three-dimensional shape of the city as it physically stands, you need reality capture - measuring the real world directly. Three technologies dominate. Aerial and satellite imagery provides the view from above: orthophotos for footprints and textures, and, through remote sensing, a stream of data about land cover, change over time and surface conditions across huge areas. Overlapping aerial photographs also feed photogrammetry - the technique of reconstructing 3D geometry from many 2D images taken from different angles - which can produce detailed textured meshes of whole cities, the photorealistic models you may have flown through online.

The other workhorse is LiDAR (Light Detection and Ranging), which fires laser pulses and times their return to measure distances with high precision, producing a dense point cloud - millions of 3D points describing surfaces. Airborne LiDAR flown over a city yields accurate terrain and building-height data ideal for generating LOD1-LOD2 models; terrestrial and mobile LiDAR (from vehicles or tripods) captures streets and facades at the detail needed for LOD3; and the same principle underlies the scan-to-BIM work that captures existing buildings. Photogrammetry and LiDAR are often combined - LiDAR for accurate geometry, imagery for texture and classification - and processing their output into clean, structured models is a substantial automated pipeline in its own right.

Two honest points frame reality capture. First, what it gives you is overwhelmingly geometric: a point cloud or a mesh is shape, not meaning, and turning it into semantic objects (this cluster of points is a building; this plane is a roof) is the hard, partly automated step that Lesson 2.3's distinction lives inside. Reality capture is brilliant at the 'where and what shape'; it needs the records and further processing for the 'what it is'. Second, capture is a snapshot: a scan or an image records the city on the day it was flown or driven, so reality capture is not a one-time act but something that must be repeated to stay current - and flying LiDAR or commissioning fresh imagery across a city is expensive, which is why currency is so often sacrificed. As ever, survey-grade, binding positional data comes from the proper surveyors and custodians under their standards; a twin's captured geometry is a working model, not a legal survey.

Building the model means fusing these sources through a pipeline, and understanding what that pipeline automates well versus badly is the practical heart of this lesson. At the easy, well-automated end: generating coarse city-wide models. Take building footprints from GIS, add heights from LiDAR or stereo imagery, extrude, drape with aerial texture, and you can produce a LOD1 or LOD2 model of an entire city largely automatically - this is routine, and increasingly machine-learning methods detect footprints, roof planes and land cover from imagery and point clouds with useful (if imperfect) accuracy. For the coarse, geometric, city-scale base, automation genuinely does the bulk of the work, fast and at scale.

Then automation stalls, and it stalls precisely at meaning and precision. Reconstructing accurate LOD3 facades and LOD4 interiors still demands intensive capture and heavy manual modelling, building by building. Correctly classifying every object, filling authoritative attributes (legal use, ownership, year built, heritage status), and resolving the messy real world - buildings that touch, a bus mistaken for a structure, a demolished building still in the data, two agencies that disagree - resist full automation and need human judgement and record-matching. And fusing sources that disagree (the footprint says one thing, the LiDAR another) requires decisions about which to trust. The result is that the glamorous, queryable, high-value parts of a semantic model remain substantially manual and expensive, even as the coarse base gets cheaper. Anyone promising a fully automatic, richly semantic, accurate city twin at the press of a button is overselling, and the gap between the coarse auto-model and the rich semantic twin is where budgets quietly disappear.

This is also where BIM enters the pipeline from the other direction. For new and significant buildings, a detailed BIM/IFC model already exists, built during design and construction, and it can be generalised into the semantic city-model objects the twin needs - feeding rich, authoritative building data straight in rather than reconstructing it from the outside. As BIM becomes standard practice, this becomes a growing, high-quality source for keeping the model current, though the IFC-to-CityGML mapping is lossy and imperfect (Lesson 2.3). The honest summary of the pipeline: automation has transformed the cheap, coarse, geometric layer; the meaningful, accurate, semantic layer still rests on records, skilled people and good BIM - and it is worth being sceptical of any claim that the whole thing is now push-button.

Here is the discipline that separates a living twin from an expensive ornament, and it is the one most often neglected because it is unglamorous and never finished: keeping the model current. A city changes every single day - buildings rise, fall, extend, change use - so a model captured once begins drifting out of date the moment it is delivered, and a model that has quietly gone stale is not merely less useful; it is dangerously misleading, because it looks authoritative while describing a city that no longer exists. A twin's entire value rests on being a faithful, current mirror, and currency, far more often than resolution, is what actually determines whether a twin can be trusted.

Keeping a model current means treating capture as an ongoing process, not a one-off project - and that requires sustained money, institutional responsibility and, ideally, automated feeds, none of which are as exciting to fund as the initial build. The good news is that several update streams can help: recurring aerial and satellite imagery flags where change has happened (remote sensing is excellent at change detection), so re-survey can be targeted rather than blanket; planning and building-permit systems can feed approved changes in; completed-building BIM models can flow up as described above; and GIS updates from the custodians refresh the records. The hard news is that all of this needs to be organised, paid for and governed on a permanent basis, and many city-model programmes simply do not - they fund a glorious initial build and starve the maintenance, so the twin decays into a fading photograph within a few years. This is one of the commonest forms of twin-washing: a model that was true once and is now quietly fiction.

For a designer the lessons are concrete and a little sobering. Always ask of any city model: how old is this, when was each layer last updated, and is there a funded process keeping it current? Trust a current coarse model over a stale detailed one. Recognise that in fast-growing Indian cities the drift is especially rapid and the informal, fast-changing parts of the city are the least likely to be re-captured - so the model is freshest exactly where change is slowest and stalest where it is fastest. And remember the standing boundary: authoritative, binding, survey-grade data and its updates remain the province of the official custodians and surveyors under their own standards, and lawful handling of any captured data sits with the governing law. A city model is never built; it is only ever being kept - or quietly allowed to die.