3D City Models: LiDAR, CityGML & the BIM Bridge

LiDAR (light detection and ranging) fires laser pulses and times their return, producing a dense point cloud - millions of points, each with an x, y and z, that together describe every roof, tree and kerb the beam touched. Flown from an aircraft or drone, it is the fastest way to capture a real city surface at building resolution, far finer than a 30 m satellite DEM.

From the cloud you derive two surfaces you met last lesson: the DSM (digital surface model - the top of everything, buildings and trees included) and, by classifying and removing the non-ground returns, the bare-earth DTM. Subtract the DTM from the DSM and what stands up is the built and vegetated world - the raw material for building heights and 3D massing. Free high-resolution LiDAR and derived DEMs for many areas are distributed through OpenTopography; in India, drone survey under programmes like SVAMITVA is expanding fine-grained coverage.

A point cloud is geometry without meaning; a semantic 3D city model adds the meaning. CityGML, an OGC open standard (current version 3.0), stores a city as objects that know what they are - buildings, walls, roofs, windows, ground, vegetation - each with attributes, not just triangles. That semantic layer is what lets you ask a 3D model real questions: total roof area suitable for solar, which facades face a noisy road, how many dwellings sit above a flood level.

CityGML famously defines levels of detail (LoD): LoD0 a flat footprint, LoD1 a simple extruded block, LoD2 with generalised roof shapes, LoD3 with detailed facades and openings (and interiors beyond). The lesson of the LoD ladder is economy: more detail costs far more data and effort, so you choose the level your question needs - LoD1 blocks are plenty for a city-wide shadow or skyline study, while a heritage sightline may want LoD2 or 3. Related OGC standards carry these models on the web: 3D Tiles streams massive 3D scenes, and CityGML itself is an application of GML (ISO 19136).

GIS and BIM (Building Information Modelling) look at the built world from opposite ends. GIS is outside-in: the whole city, terrain, plots, neighbours, at modest per-building detail, geo-referenced to the Earth. BIM is inside-out: one building in exhaustive detail - structure, services, materials - usually in its own local coordinate space. Neither replaces the other, and the interesting work of this decade is the bridge between them, often called GeoBIM.

The bridge runs both ways. Context in: pull the surrounding CityGML city, terrain and plot into your BIM environment so the design is modelled among its real neighbours. Design back out: place the finished BIM building (commonly exchanged as IFC) accurately into the city model to test its city-scale effects. The persistent friction is that the two speak different languages - CityGML and IFC organise the world differently, and georeferencing an IFC model correctly is a real, non-trivial step. But done well, the bridge means your shadow, sightline and skyline studies use the actual city, and the city's model gains an accurate new building.

With even an LoD1 city model plus terrain, the studies that a 2D plan cannot do become routine. Cast the sun across the whole neighbourhood and you get true overshadowing - how your proposal shades the streets, parks and windows around it through the seasons (with the low winter sun, again, the hard case). Set the eye at a viewpoint and you can test sightlines and protected views. Drop your massing into the block and you can read the skyline and how the new wall of the street sits against its neighbours.

You can do a great deal of this without paid tools. In QGIS, the qgis2threejs plugin exports your terrain, buildings and proposal to an interactive 3D web scene you can share and orbit. On the paid side, ArcGIS Pro has full 3D scenes and shadow tools, and Esri CityEngine builds procedural 3D cities and urban-design scenarios from rules. The honest closing note: a 3D city model is only as good as its LoD, its currency and its georeferencing - so match the model to the question, and never let a beautiful render outrun the accuracy of the data beneath it.