Digital twins with GIS: from a 3D scene to a live model you can act on

Most “digital twin” demos are a photoreal city you can fly through. They look great and answer nothing, because nothing in them changes when the real city does. A twin earns the name when it stays in step with the place it represents: the pump that tripped five seconds ago is red, the floor plan matches last month's refit, and the flood model runs against today's river level. GIS is what makes that possible. It puts every building, asset, sensor reading and simulation result in one coordinate system with one set of IDs. This post covers the layers, formats and feeds of a GIS-based twin, and the order we build them in.

A twin is not a 3D model

The Digital Twin Consortium's definition is the one we work to: a virtual representation of real-world entities and processes, synchronized at a specified frequency and fidelity. Each part of that sentence rules something out.

• Entities and processes. A twin models things with identity (this valve, this air handler, this bridge bearing) and how they behave, not only surfaces. A mesh with no IDs is a picture.
• Synchronized. Data flows from the real asset to the model, on a schedule or continuously. A model that was accurate on handover day and never updated is documentation.
• At a specified frequency and fidelity. Somebody decided how often each entity updates and how precise it needs to be. A pump needs seconds, a road surface condition needs months. A campus twin rarely needs millimetre geometry, while a tunnel clearance check does.

Why a twin needs GIS

You can build a twin of a single machine without a map. You can't build one of a campus, a utility, a port or a city without one, because the questions are spatial: which buildings are downstream of this main, which assets sit in the flood extent, which sensor belongs to which zone, what a crew can see from the gate. GIS supplies four things a game engine or BIM tool doesn't supply alone.

The coordinate problem is worth spelling out, because it's where most GIS–BIM projects stall. BIM models are usually authored in a local project coordinate system: a survey point, a project base point and a true-north rotation. Photogrammetry and LiDAR come in a projected CRS, often with ellipsoidal heights from GNSS. Your city GIS uses a national grid with orthometric heights above a geoid. The differences run to tens of metres vertically in many regions. Pick one horizontal CRS and one vertical datum for the twin on day one, record the transformation for every source, and check it with surveyed control points, not by eye.

Interactive: the six layers of a GIS twin

We build twins as a stack of layers over the same ground. Each layer answers a different question, arrives in different formats and refreshes at a different rate. Hover to pause, or click a layer.

Two things are easy to miss. First, the asset layer is the spine. Reality capture and BIM make the twin look right, but the feature layer with stable IDs and topology is what live data and analysis attach to. Second, the stack isn't built bottom-up in one go. A useful first release often has a coarse 3D base, a good asset layer and a single live feed. The photoreal capture can come later.

Formats and standards that matter

Twins outlive the software they start on, so the formats matter more than the viewer. The good news is that the 3D streaming problem is largely standardised now. The two formats that matter both have OGC status and are both supported by the major engines.

Two stacks: ArcGIS and open standards

We build twins on both. The choice usually follows what the organisation already runs, not the 3D feature list, since both render large scenes well. Many real projects mix them, which the open formats above make possible.

Whichever stack you pick, the live layer comes down to one join: feature ID to latest reading. In CesiumJS it looks like this. Buildings stream as 3D Tiles with an asset_id per feature, readings arrive over a WebSocket, and features are recoloured as tiles come into view.

1import * as Cesium from "cesium";
2
3const viewer = new Cesium.Viewer("twin");
4
5// Buildings from IFC / CityGML, tiled to 3D Tiles 1.1 with asset_id metadata
6const tiles = await Cesium.Cesium3DTileset.fromUrl(
7  "https://tiles.example.com/campus/tileset.json",
8);
9viewer.scene.primitives.add(tiles);
10
11// Latest reading per asset, pushed by the stream service
12type Reading = { asset_id: string; tempC: number; alarm: boolean };
13const live = new Map<string, Reading>();
14const ws = new WebSocket("wss://twin.example.com/stream/bms");
15ws.onmessage = (e) => {
16  const r: Reading = JSON.parse(e.data);
17  live.set(r.asset_id, r);
18};
19
20const ok = Cesium.Color.fromCssColorString("#38c2ff");
21const hot = Cesium.Color.fromCssColorString("#ff6b5e");
22
23// The join is asset_id, not geometry
24tiles.tileVisible.addEventListener((tile) => {
25  const content = tile.content;
26  for (let i = 0; i < content.featuresLength; i++) {
27    const f = content.getFeature(i);
28    const r = live.get(f.getProperty("asset_id"));
29    f.color = !r ? Cesium.Color.WHITE : r.alarm ? hot : ok;
30  }
31});

Keeping it live: frequency, fidelity, IDs

Synchronisation is where twins quietly die. The fix is to write down, per entity type, where its truth lives, how often it changes, and how the change reaches the model. A single “refresh the twin” job won't work, because a pump and a floor plan change at very different rates.

One ID to join them all

Every row above ends in a join, so the twin needs an identity strategy before it needs a renderer. An asset has an IFC GlobalId in the design model, a GlobalID in the geodatabase, an equipment number in the CMMS and a tag name in SCADA. Pick one as the master (usually the GIS or CMMS ID), carry the others as attributes, and make every pipeline resolve to the master. Then check the joins with SQL. Twins that skip this end up matching sensors to buildings by nearest neighbour, which works in the demo and fails at the first multi-storey plant room.

If you're not on ArcGIS, the OGC SensorThings API makes the live layer queryable in a standard way. Things carry your master asset ID in their properties, and one request returns an asset's location and the latest value of each datastream:

1curl -G "https://sta.example.com/v1.1/Things" \
2  --data-urlencode "\$filter=properties/asset_id eq 'PMP-014'" \
3  --data-urlencode "\$expand=Locations,Datastreams(\$select=name,unitOfMeasurement;\$expand=Observations(\$top=1;\$orderby=phenomenonTime desc))"

Interactive: a what-if flood on the twin

Live state tells you what is happening. Simulation, run on the same model, shows what could happen next and what to do about it. Below is a small twin: a river valley, sixteen buildings, a substation (SUB-3), a clinic and a road network. Raise the water level, try a flood wall, and compare two ways of computing the extent.

Three points from the demo carry over to real projects:

• Connectivity matters. At 1.5 m the bathtub model floods the clinic, but the clinic sits in a pocket behind higher ground that the river can't reach until about 1.65 m. A bathtub model is fast and pessimistic. Real twins use hydraulic or hydrodynamic models that account for flow paths, drainage capacity and timing, then bring the results back into the scene as time-enabled layers.
• Impact is a join. “Buildings hit” and “road cells cut” are overlays of the flood extent with the asset layer. Swap in parcels, customers or critical facilities and you have an evacuation list or a crew-routing constraint.
• Prescriptive is a comparison. Adding the wall and re-running the scenario is the step from “what will happen” to “what should we do”. The wall protects SUB-3 up to about 2.1 m. Whether that's enough is a decision for engineers, now made on a shared model.

Build it in levels

Digital-twin maturity models vary in naming but agree on the progression. Each level depends on the one below. You can't predict what you can't describe, and nobody should let a model act on its own if it can't yet predict reliably.

Level 5 is rarer than vendor slides suggest, and deliberately so. Control of physical assets stays in SCADA and OT systems with their own safety certification. The twin recommends, and a person or a bounded control loop acts. Plan for levels 1–3, and design the data so that 4 is possible later.

Where GIS twins pay off

For the water case in depth, including isolation traces and SCADA on the network model, see ArcGIS Utility Network for water distribution. For the ops-room case, a twin is often the backdrop of a TAK-connected common operating picture. Our own Earth Explorer app shows a smaller version of the same idea: OGC sensor observations on a 3D globe, on a phone.

Pitfalls we see

A rollout that ships

1. 01

   Pick the decision and the user

   “Plan valve isolations in minutes”, “cut space costs on campus”, “brief the council on flood options”. One decision sets which layers, fidelity and frequency you need.
2. 02

   Write the synchronisation register

   Entities, source systems, frequency, fidelity, the master ID and an owner per row. This page is the real specification of the twin.
3. 03

   Build the ground truth

   CRS and datum, 3D base, asset layer with IDs and topology. Bring in BIM for the buildings that matter to the decision. Capture reality only where it adds context.
4. 04

   Connect one live feed end to end

   From sensor to asset ID to the scene, with monitoring for staleness. One working feed shows more about the architecture than ten on a diagram.
5. 05

   Ship one app to one team

   A web scene for the ops room or a tablet app for crews. Put it in daily use, collect complaints, fix them.
6. 06

   Add what-if, then widen

   Scenario layers and simulation on the proven base, then the next decision, the next team and the next feed. The twin grows by use cases, not by layers.

Takeaways