3D City Models & CityGML

For most of its history, the authoritative record of a city was flat: plans, cadastral maps, zoning drawings, each a 2D projection of a three-dimensional place. These are powerful - a cadastre records who owns what, a plan records what may be built - but they force the reader to imagine the third dimension. A 3D city model lifts that record into space: it represents the buildings, terrain, transport, water and vegetation of an urban area as three-dimensional objects placed in a shared, georeferenced coordinate frame, so that the model can be viewed from any angle and measured in all three dimensions.

The phrase 'shared coordinate frame' is doing quiet but essential work. A 3D city model is not a single sculpture; it is a set of themed layers - terrain, buildings, transport, vegetation, water bodies, city furniture - each modelled separately but all pinned to the same real-world coordinates, so that a roof sits correctly above its plot, a tree stands beside its road, a drain runs under its street. Because everything is georeferenced, the model can be overlaid with other spatial data and can answer questions about relationships in space: what is next to what, what overshadows what, what drains into what. This is what makes a 3D city model more than a rendering - it is a spatial database you can see.

It is also, always, a selection. A city model does not contain the city; it contains the themes someone chose to model, at the detail they chose, as of the day the source data was captured. A model built for solar analysis may have beautiful roofs and no interiors; one built for flooding may have superb terrain and crude buildings. This is not a flaw to be apologised for - it is the first principle of honest modelling, carried from Lesson 0.1: a model is a purposeful simplification built to answer particular questions. Before you trust any 3D city model, ask what it was built for, what it leaves out, and how old its data is. The temptation to treat a convincing 3D view as 'the city' is exactly the false confidence this course warns against; a model can be incomplete, stale or wrong, and a pretty model most of all.

If a bare 3D model is geometry that happens to look like a city, CityGML is the standard that turns that geometry into a city the computer can understand. CityGML is an open data model and exchange format for storing and sharing 3D city models, and its defining idea is semantics: it represents the urban world not as anonymous surfaces but as a structured set of real-world object classes - Building, Road, WaterBody, Vegetation, Bridge, Tunnel, CityFurniture, Terrain - each with a defined meaning, its own attributes and defined relationships to the others.

Consider a single building. In a purely geometric model it is a cluster of triangles. In CityGML it is a Building object, and that building can be decomposed into semantically labelled parts: a RoofSurface, WallSurfaces, a GroundSurface, and at finer detail the Windows and Doors set into those walls. Each object carries attributes - a function (residential, commercial, civic), a measured height, a year of construction, a storey count, a roof type - and each attribute is a fact the model can be queried on. Geometry tells you the shape of the roof; semantics tells you that it is a roof, which way it faces, what it is made of, and which building it belongs to.

That distinction is the whole point, and we devote Lesson 2.3 to it, but feel its force now. Because CityGML objects know what they are, you can ask the model questions no bare mesh can answer: every south-facing roof above a certain area (for solar suitability), every building over a certain height within a flood zone, every residential block within 300 metres of a proposed metro exit. You can attach live data to the right objects - a temperature feed to a building, a count to a road - and you can run simulation on meaningful entities rather than undifferentiated surfaces. This is precisely why a semantic model, not a bare mesh, is the foundation of a twin: a twin has to reason, query and simulate, and you can only reason about things the model knows are things. CityGML gave cities a common, open language for that meaning - though, honestly, a CityGML file is only as truthful as the data poured into it, and an attribute left blank or entered wrong is a fact the twin will happily get wrong.

CityGML did not appear from nowhere, and understanding where it sits explains why it matters. It is a standard of the Open Geospatial Consortium (OGC) - an international, not-for-profit body whose members (government agencies, companies, universities) agree on open standards so that geospatial data and software from different sources can work together. CityGML is implemented as an application schema of the Geography Markup Language, which is itself an OGC standard; in plain terms, it is an openly published, vendor-neutral specification for what a semantic 3D city model should contain and how it should be written down.

Why does 'open' and 'standard' matter so much here? Because a city model is a long-lived, shared public asset, built at great cost from many sources and meant to outlast any one piece of software or any one supplier. If a city's model lives only in a proprietary format that one vendor controls, the city is locked in: it cannot easily move the data, combine it with a neighbour's model, feed it to a new simulation tool, or guarantee it will still be readable in twenty years. An open standard is insurance against that lock-in and the foundation of interoperability - the ability of different systems to exchange and make use of the same data. It lets a survey department, a planning authority, a university and a simulation vendor all speak about the same building and mean the same thing.

CityGML is not the only player, and honesty requires naming the landscape rather than selling one format. Other relevant OGC and industry standards sit alongside it: 3D Tiles and the indexed i3s format are geared to streaming massive models to the web (Module 5); IFC, the open BIM standard, describes individual buildings in construction-grade detail (Lesson 2.3); and glTF is common for visual geometry. Real city programmes usually juggle several, converting between them, each with strengths and losses in translation. The lesson for a designer is not to memorise formats but to grasp the principle: insist that a city's model rests on open, documented standards you could walk away with, because the alternative quietly hands control of a public asset - and of the twin built on it - to whoever owns the file format. Which standards are authoritative for official data remains a matter for the data custodians and the relevant authorities, not a vendor's claim.

A semantic 3D city model, built on an open standard, is genuinely useful long before any live data arrives - and seeing that clearly keeps the hype in check. As a static but semantically rich model it already supports a great deal: visualising proposals in real context, measuring heights and distances, analysing sunlight and shadow and sightlines, estimating roof area for solar, running early flood or wind studies, checking a design against planning envelopes, and giving citizens a shared 3D picture to react to. Much of what city-twin platforms demonstrate is, in truth, exactly this: a good semantic model with analysis run on it. That is valuable work - but it is important to name it honestly, because a static model with a dashboard is not yet a twin. It becomes a twin only when live data keeps it current and simulation feeds back into decisions, as Module 0 insisted and Module 3 will build.

It is equally important to be clear-eyed about where the model stops. First, coverage and currency: a model captures what was surveyed when it was surveyed, so new construction, demolitions and changes drift it out of date the moment it is made (Lesson 2.4 tackles this). Second, the informal city: in India and much of the world, a large part of the real city - informal settlements, unauthorised construction, the street-level economy - is poorly represented in the formal data a model is built from, so the model can quietly render invisible the very places and people most in need of attention. A model is a map of what its makers chose and were able to capture, and its silences are not neutral. Third, authority: a working city model is not the legal record. Ownership boundaries, statutory infrastructure data and survey-grade positions come from the official custodians - in India, bodies such as the Survey of India and the relevant authorities - not from a twin's convenient working layers, and binding decisions must rest there.

So hold both halves together. A 3D city model, made semantic by a standard like CityGML, is the indispensable foundation of an urban digital twin and a powerful tool in its own right. It is also a selective, possibly stale, possibly biased simplification whose authority is limited and whose gaps have consequences. The skill this module builds is to use the foundation well while never mistaking it for the city.