Semantic vs Geometric Models

Take one building and represent it two ways. The geometric representation is a mesh: a set of points, edges and triangular or polygonal faces positioned in 3D space, perhaps draped with a photographic texture so it looks convincingly real. This is how a great deal of 3D content in games, film and photogrammetry is stored, and it is excellent at one thing - looking right. But a mesh is, semantically, mute. It contains no notion of 'wall' or 'roof' or 'building'; it is one continuous skin of faces. Split it in half and you get two meshes, not 'the north wing' and 'the south wing'. Nothing in it says what it is.

The semantic representation is an object model. The same building is now a Building object, decomposed into meaningful parts - RoofSurface, WallSurface, GroundSurface, and at higher detail rooms and openings - each of which is a named thing carrying attributes (function, height, year built, material, use) and standing in relationships (this wall belongs to this building; this building fronts this road; this room is inside this storey). The geometry is still there, attached to each object, but it is now organised by meaning. This is what CityGML does at city scale and what BIM does at building scale: it is the difference between a photograph of a filing cabinet and the files actually sorted and labelled inside it.

The reason the distinction hides so well is that rendering collapses it. On screen, a semantically rich CityGML building and a dumb textured mesh can be indistinguishable, even the mesh looking better because of its photo texture. The difference is entirely in what the computer knows, not in what the eye sees - which is precisely why a buyer dazzled by a beautiful fly-through can end up with a model that can never do the work of a twin. When you evaluate any city model, the test is never 'does it look real?' but 'can I select an object and does it tell me what it is?' The first is geometry; only the second is semantics, and only semantics is a foundation you can build a twin on. Appearances, here, are genuinely deceiving - by design.

Semantics is not an academic nicety; it is the thing that converts a model from scenery into an instrument. Three capabilities follow directly from objects knowing what they are, and each is load-bearing for a twin. The first is query. Because objects carry attributes and relationships, you can ask the model structured questions and get meaningful answers: every residential building over six storeys within a flood zone; every south-facing roof above 40 square metres for solar; every road segment within 300 metres of a proposed station. A mesh can answer none of these, because it has no 'building', 'roof', 'zone' or 'road' to filter on. Query is the everyday workhorse of a twin, and it exists only on top of semantics.

The second is connection to data. A twin stays alive because live data flows into it (Module 3), and that data has to attach to something meaningful: a temperature reading to a specific building, a traffic count to a specific road, an occupancy figure to a specific space. Semantics provides the hooks - the named objects the data binds to. Pour sensor data onto a featureless mesh and it has nowhere to land; pour it onto a semantic model and each reading finds its object. The third is simulation and reasoning (Module 4). To simulate shadow, energy, flood or traffic, the engine must know which surfaces are roofs, which volumes are buildings with a use and an occupancy, which lines are roads with a capacity. Simulation runs on meaning, not on anonymous geometry; it reasons about objects and their relationships.

Put the three together and the slogan writes itself: you cannot reason about things the model does not know are things. Monitoring, querying, analysing, simulating and the feedback loop into decisions - the entire definition of a twin from Lesson 0.1 - all depend on the model being semantic. This is also why twin-washing so often takes the form of a detailed geometric model with a dashboard: it looks like a twin and even does a little visualisation, but lacking real semantics it cannot genuinely query, connect or simulate, and its 'analysis' is often shallow or faked. Semantics is the dividing line between a mirror you can interrogate and a picture you can only admire - and it is the honest test to apply before believing any twin's claims.

If the semantic idea feels abstract, there is a good chance you have already met it at building scale, because BIM (Building Information Modelling) is exactly this principle applied to a single building. A BIM model is not a 3D drawing; it is a semantic model in which walls are walls, doors are doors, beams are beams - objects carrying rich information (material, fire rating, cost, manufacturer, thermal properties) and relationships (this door is hosted in this wall, which bounds this space). BIM is, in effect, the building-scale sibling of CityGML's city-scale semantics, and the open standard that lets BIM data move between tools without lock-in is IFC (Industry Foundation Classes), an openly published schema maintained by the buildingSMART community - the BIM world's equivalent of what CityGML is for cities.

The relationship between them is the connective tissue of a city twin, and it runs in both directions. Downward, a city model provides the context a building sits in; upward, detailed BIM/IFC building models can be generalised into the coarser semantic objects a city model needs - a construction-grade IFC building becoming an LOD2 or LOD3 CityGML building for the city twin. This is how the nested idea from Lesson 0.1 (a building twin inside a district twin inside a city twin) is actually realised: shared semantics at each scale, with defined mappings between them. It is also where a great deal of the hard, unglamorous engineering of real twins lives - the conversion is lossy, the object definitions do not map one-to-one, and classifications differ between the standards.

For a designer this link is practical and immediate. The BIM model you produce is, increasingly, not just a deliverable for construction but a potential contribution to a wider city model - which raises the quality of your semantic data (are your objects correctly classified? your attributes filled?) to a matter of civic consequence, not just internal convenience. And it is the clearest proof that 'semantic versus geometric' is not a niche city-modelling debate but the same fault line that runs through the whole of digital design: a model made of meaningful, attributed, related objects can be reasoned about, exchanged and built upon; a model that is only shape cannot. The integration and interoperability work that makes these standards actually talk to each other is substantial, and we return to it in Module 3 - where the honest truth is that 'it is all open standards' hides a lot of difficult plumbing.

Semantics is powerful, but an honest account has to name its price and its limits, or it becomes just another kind of hype. The first cost is effort: a semantic model is far more demanding to create and maintain than a mesh. Someone, or some algorithm, has to decide what each object is, classify it correctly, fill in its attributes and establish its relationships - and that work must be redone as the city changes. A mesh can be captured almost automatically by photogrammetry; a richly attributed semantic model cannot, at least not reliably, and automation here remains partial (Lesson 2.4). Much semantic data is entered by people, which means it can be incomplete, inconsistent or simply wrong.

The second, subtler point is that semantics does not equal truth. An object confidently labelled 'hospital' with a height of '14 metres' is only as correct as whoever or whatever set those values. A semantic model can be richly structured and systematically wrong - misclassified uses, stale attributes, missing relationships, buildings that were demolished still standing in the data. Worse, the very structure that makes a semantic model queryable lends its answers an air of authority: a crisp query result feels like fact, even when it rests on dubious attributes. The queryability that is semantics' great strength can thus amplify false confidence, which is why the cautions from Module 0 apply with full force - a twin is decision-support, never an oracle, and a structured wrong answer is still wrong.

There is also an equity edge to semantics. What gets modelled as a first-class object, with rich attributes, reflects whose concerns the model was built to serve. Formal buildings, registered roads and planned infrastructure tend to be well represented as proper objects; informal settlements, unregistered structures and the street-level economy are often absent, lumped into coarse geometry, or simply missing - so the semantic model can encode and harden the same blind spots as the data behind it, the India-relevant concern this course keeps returning to. The takeaway is balanced and firm: semantics is what makes a twin possible and is worth its considerable cost, but a semantic model must be read as a human-made, maintained, value-laden artefact that can be wrong and can exclude - and binding decisions about what a building really is, where a boundary really lies, and how its data may lawfully be used stay with the accountable professionals, custodians and the law, never with a confident-looking attribute in a file.