What is the difference between a 3D city model and a digital twin?

A 3D city model, in CityGML, 3D Tiles or a mesh, describes geometry and attributes as they were captured. A digital twin adds a link to the current state of the place, refreshed at a known rate, and does something with it: shows it, raises alerts, keeps a history.

Do you need a platform or a server to build an urban digital twin?

Not always. When the data providers allow requests from a browser (CORS), a twin can run entirely in the visitor's browser from open data, as the three examples here do. Private data behind keys, heavy simulation or anything that controls equipment needs a server.

What data does a city digital twin use?

Usually an elevation model for the ground, a base map with buildings and streets for context, detailed models (often IFC) of the assets that matter, and live feeds: mobility, energy, environment or IoT sensors. Each layer comes from a different source and updates at its own pace.

Back to the BIM & IFC blog

Digital twins · 2026-10-10 · 8 min

What Is an Urban Digital Twin? Three Live Examples You Can Open

Q: What is an urban digital twin?

A 3D model of part of a city — terrain, buildings, streets and the assets in them — connected to data about its current state, so the model shows what is happening there now and can be checked against rules, queried and recorded. A 3D city model on its own describes a moment; the connection is what makes it a twin.

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.

Three live urban digital twins side by side in IFC Viewer Online: Plaça de Catalunya in Barcelona, the Elielinaukio bus terminal in Helsinki and a station entrance in Tokyo, each coloured by its city's open data

An urban digital twin is a 3D model of part of a city that stays connected to what is happening there. The model says what is where: the ground, the buildings, the streets, the assets in them. The connection says what state they are in now — a bike dock empty, a bus at its bay, a train delayed.

The Digital Twin Consortium defines a digital twin as a "virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity"^[dtc]. The frequency is the part most 3D city models lack. This guide shows what the rest looks like, with three twins you can open right now, each built from its city's open data and running in the browser.

Key takeaways

A digital twin is a model plus a live link to the place it models. A 3D city model without that link is a good map, not a twin.
A city twin stacks five layers: ground, city context, detailed asset models, bindings and live state. Each comes from a different source and refreshes at its own pace.
When publishers allow browser requests, the whole stack can run in the visitor's browser from open data — no platform, no server of ours.
Barcelona, Helsinki and Tokyo below are live: bike docks, bus bays and a station entrance coloured by their cities' feeds.

What makes a model a twin

Three things, and the third is the one people skip:

A model of a real place: geometry, identity and data for the things in it, placed where they really are.
A connection to the place's current state, refreshed at a known rate: every second for a bus, every minute for a bike dock, every hour for air quality.
Something done with that state: shown on the model, checked against rules that raise alerts, kept as history you can replay.

Without the second, you have a 3D city model, which is still useful: Japan publishes open models of its cities through PLATEAU^[plateau], Helsinki publishes its own^[helsinki3d], mostly in the open CityGML standard^[citygml]. How such a model differs from a twin, step by step, is in BIM vs digital twin.

The five layers of a city twin

Diagram of an urban digital twin as five stacked layers — ground, city context, IFC models, bindings and live state — for Plaça de Catalunya in Barcelona, with the source and refresh rate of each — The five layers of the Barcelona twin, from the terrain up to the live readings. Every number comes from its scene file.

Ground An elevation model the rest stands on. In Barcelona it is the ICGC's 5 m terrain model, so the models sit on the street instead of floating above it or sinking into it.
City context Buildings and streets around the assets, here from OpenStreetMap, drawn in the same projection as the models so that a kerb lines up with the kerb in the IFC.
Asset models The things you want to know about, modelled in detail: here eight IFC 4.3 files — fountains, a Bicing station with its dock posts, a metro entrance, an EV charger — each placed by its own georeference.
Bindings What ties a feed to elements: which source, which device in it, which IFC elements, which colour for which value. Without them, live data is a list of numbers next to a model.
Live state The readings themselves, each at its own pace: Bicing every 60 s, the EV charger every 5 minutes, air quality every 15. A reading older than its source allows turns grey instead of passing for fresh.

Most of the work, and most of the failures, sit between layers: a model a few metres off its street, a binding that finds no elements because the docks are parts of an assembly, a feed whose timestamps are not what they seem. The case studies below each describe one of those.

Three live examples

Each runs from one scene file with its city's open data. Open it, click any asset to see its data, and use Explore to jump between the live points.

Barcelona: bike docks and an EV charger

Plaça de Catalunya, live

Eight IFC models on the 3D map of Barcelona. The Bicing docks and the Endolla charger bays take their colour from the city's feeds.

Live digital twin of Plaça de Catalunya in Barcelona: IFC models of the Bicing station and the fountains on the 3D map, with the bikes available floating above the docks

Open the interactive IFC viewer

Eight georeferenced IFC models around the square, with Bicing station 65 and an on-street charger bound to their live feeds, and traffic and air quality as map layers. The whole build, from feed to coloured dock post: a live digital twin of Plaça de Catalunya.

Helsinki: buses at their bays

Live digital twin of the Elielinaukio bus terminal in Helsinki: IFC model of the bays next to the Central Station, each bay coloured by the bus at it — Elielinaukio, next to Helsinki Central Station: each bay changes colour as its bus pulls in, waits and opens its doors.

Three IFC models — the station, the Cathedral and the terminal — and nine bays bound to HSL's real-time vehicle positions, which arrive over MQTT about once a second per bus. Why MQTT and not GTFS-Realtime, and how a stop id becomes a bay: a live bus terminal twin over MQTT.

Tokyo: a station entrance and a tram stop

Live digital twin of exit A4 of Tochōmae station in Tokyo: IFC model of the entrance with its Toei signs and bus stop, coloured by ODPT open data — Tochōmae exit A4: the Toei marks show the Ōedo line's status, the station sign a train at the platform, the stop pole a recent bus.

Two stations bound to ODPT open data: train positions, line status and the Toei bus GTFS-Realtime feed, decoded in the page. The details, and what ODPT can and cannot tell you: Tokyo station twins from ODPT open data.

How the data gets to the model

Diagram of how a browser-only digital twin reads open data: Bicing GBFS over HTTPS, HSL vehicle positions over MQTT and Toei GTFS-Realtime, each lighting up IFC elements, and a feed blocked by missing CORS headers — Three transports, one rule: the browser can read a feed only if its publisher sends CORS headers.

Every request goes from the visitor's browser to the publisher. That is possible only when the publisher answers with CORS headers, which allow a page on another site to read the response. Barcelona's bike and charging feeds, HSL's MQTT stream and ODPT's public endpoint all do; HSL's GTFS-Realtime feed does not, so the Helsinki twin uses the MQTT stream instead.

Where a browser twin stops

Private or keyed data. It needs a server between the browser and the source.
Heavy simulation. Flood, energy or crowd models over a whole district need more computing than a page should take.
Control. A twin that switches equipment needs authentication, an audit trail and a reliable connection, not a public link.
Phones. The full scenes have been tested on desktop browsers; on phones they have not been measured yet.

Build one from your own models

Place your IFC on the map Open it on the 3D map and check that it lands where it should: how to view an IFC on a 3D map.
Fix the georeference if it does not Most misplaced models have a missing or wrong IfcMapConversion: IFC coordinates and georeferencing.
Add a feed and a binding Point a device source at a feed that sends CORS headers, and bind it to elements by IFC class and name, or by GlobalId.
Share it Save it as a scene file or pack it into a link, and embed it where people already work: how to embed an IFC viewer.

References

Digital Twin Consortium defines digital twin — Digital Twin Consortium. The definition quoted here. The consortium revised its wording in 2024.
Project PLATEAU — Ministry of Land, Infrastructure, Transport and Tourism, Japan. Open 3D city models of Japanese cities.
Helsinki 3D — City of Helsinki. The city's open 3D city models.
OGC City Geography Markup Language (CityGML) 3.0 Conceptual Model — Open Geospatial Consortium. The open standard for 3D city models, and its levels of detail.

What Is an Urban Digital Twin? Three Live Examples You Can Open