All 26 guides on this topic
A city digital twin is a 3D model of a place that stays connected to what is happening there. What that means in practice: the five layers it is built from, where each comes from, and three live examples — Barcelona, Helsinki and Tokyo — that run in your browser from open data.
Most tools handle one kind of data well and make you export the rest. This scene takes models, scans, sheets and sensors together, in the same coordinates.
Most twin projects begin with a diagram of boxes that nobody can place on the asset. Draw the idea in space instead: which gauge, which span, how far the water reaches. Turn the live bridge and city, and add to them.
Descriptive, informative, predictive, comprehensive, autonomous: the five levels most maturity models use. Each one shown on a real, open example, and where an example does not reach a level, it says so. Plus how to tell which level a project actually needs.
Three formats keep coming up when a digital twin reaches city scale, and they are often compared as if they competed. They do different jobs: CityGML describes the city as objects, IFC describes one asset element by element, and 3D Tiles delivers either to a browser in pieces.
A digital twin that runs in the browser can only use data a web page is allowed to read. We requested 28 public feeds in 20 cities exactly as a browser would and recorded which ones answer. 25 do. Here is the list, what blocks the other three, and the data to download.
"Real-time" says nothing about how old the data is when it reaches you. We logged six public feeds that live digital twins read, for 24 hours, and measured the age of every vehicle and station in them. The answer ranges from under a second to a minute and a half, and the feed's own timestamp can hide it.
BIM and digital twins get talked about as if they were the same thing. They are not, and the difference is easiest to see on one set of models: as BIM files, placed in their city, and connected to live data. What each step adds, what a twin needs from BIM, and when you do not need a twin at all.
Ask for "LOD 2" and you may get a block with a pitched roof or a generic wall, depending on who reads it. CityGML's levels of detail and BIM's levels of development share an acronym and little else. What each scale means, how they line up, and how to write a requirement nobody can misread.
Eight IFC models of Plaça de Catalunya on the real terrain, with Bicing docks, an EV charger, street traffic and air quality updating from Barcelona's open data. It all runs in the visitor's browser: no IoT platform, no GIS server, no backend of ours.
At the Elielinaukio terminal next to Helsinki Central Station, each bay of an IFC model lights up when a real bus stands at it, with the line number above. The data comes from HSL's public MQTT feed, received directly by the browser.
An exit of Tochōmae station and the Waseda tram stop, as IFC models that react to Tokyo's public transit data: the Ōedo line's status, the train at the platform, the buses passing, the tram at the stop. It runs in the browser from ODPT's open APIs, and the GTFS-Realtime protobuf is decoded on the page.
Cities were built over streams. The streams were piped, filled in or diverted; the valleys they cut were not. When a storm overwhelms the drains, water goes back to where the stream ran. OpenStreetMap often still records those courses. How to find them, and see what the rain does over them.
From the Oriental Pearl to the Yuyuan gardens: how we built a 3D context that keeps streets, entrances and open spaces, and where its limits lie for a BIM project.
An elevated ring can look perfect from above and fail at street level. This is how we review decks, widenings, stairs and lifts in Lujiazui.
Hongqiao and Shanghai South show why a station needs more than an extruded footprint: clear space, consistent elevations and trains that follow the track.
Trees inside plazas, water over islands and covered courtyards: three mistakes that make a map worse however detailed it is. How we tackled them in Shanghai.
Every point in a LAS or LAZ file can carry a class: ground, building, vegetation, water, noise. Those numbers decide what you can do with a scan — terrain models, scan-vs-BIM, clearance checks. Here is the full ASPRS table, what each code is for, and how to use them without desktop software.
Most of what a site team needs from a scan is not a 3D view. It is a plan of what was built, a flatness check before the screed, a terrain with contours, and a clearance that can be quoted. All of them are filters on the same cloud — slices, bands and classes — and none needs desktop software.
See a forklift and an autonomous cart move through a dense warehouse point cloud while the IFC stays available as the designed spatial reference.
Scrub through structural phases, follow a lifted panel and reveal a deliberately shifted column return cluster against the IFC reference.
Move an inspection trolley through dense services, visualize its scan fan and localize a changing wall-condition cluster in the IFC corridor.
Open a real IFC4 pavilion in its Barcelona map context, inspect the live 3D demo, and learn how IfcProjectedCRS and IfcMapConversion place BIM correctly.
See a real CRAS TLS-to-IFC alignment, inspect sections and launch an interactive IFC + LAS browser demo with no model upload.
Run the actual web replay interface and learn the bounded buffers, binary frames and telemetry behind an honestly labelled simulated IFC + LiDAR stream.
See the actual viewer place video beside IFC as a screen, terrain overlay or billboard, then try metric position and opacity in the browser demo.