← Digital Twin
Digital Twin · Data

Data flow & storage

End-to-end architecture of the BEAM Digital Twin — from physical sensors on campus to interactive visualisation in the browser. Backend hosted on Amazon Web Services (AWS); frontend built with React and deck.gl.

01 — Backend
Sensor data pipeline

Weather station data follows a 7-step path from physical sensor to on-screen visualisation, processed and served entirely through AWS.

BEAM Digital Twin data flow diagram

Sensor data flows hourly from dataloggers to AWS S3 via FTP, processed by Lambda functions, and served to the DT frontend via API Gateway. · Ref: BEAM Phase 1 Report §4.2.1

Backend — Amazon Web Services
AWS infrastructure

All data storage, processing, and serving runs on AWS. An EC2 instance hosts the FTP server that receives hourly uploads from sensor dataloggers. Two separate S3 buckets handle raw and processed data independently — keeping the archive clean and the API responses fast.

Lambda functions run on a scheduled trigger, compiling and formatting incoming data without the need for a persistent server. API Gateway sits in front of Lambda, providing clean REST endpoints that the frontend calls whenever a user opens a sensor popup or time-series chart.

Frontend — React + deck.gl
Browser interface

The DT platform is a single-page web application built with React and Node.js. All map rendering is handled by deck.gl — a GPU-accelerated visualisation library that supports terrain, 3D models, heatmaps, GeoJSON, and image overlays as independently toggled layers.

Charts and time-series displays inside sensor popups use plotly.js, providing interactive line charts, bar charts, and heatmaps. deck.gl was selected over CesiumJS for its stronger support for fine-grained, campus-scale data visualisation. · ASim 2024, Paper ID 1244

02 — Storage
Static spatial data

3D models, GIS layers, terrain tiles, imagery, and simulation outputs are stored in S3 and loaded directly by deck.gl layers on demand — no database required for spatial assets.

Data typeFormatSourceSize / notesdeck.gl layer
3D buildings (detailed).STLVirtual Campus 2019–2020431 MB · LOD 3.2ScenegraphLayer
3D buildings (recent).OBJGPS Lands LiDAR scan 2023~5 MB · LOD 2.1ScenegraphLayer
Tree points (big + small)GeoJSON / PointGreenery databaseCampus-wide inventoryScatterplotLayer
Tree canopyGeoJSON / PolygonGreenery databaseSpecies + canopy spreadGeoJsonLayer
Shrubs, turf, forestGeoJSON / PolygonGreenery database + 2019–2020LiDAR + DEM derivedGeoJsonLayer
Roads, pavements, fieldsGeoJSON / PolygonVirtual Campus 2019–2020GeoJsonLayer
Admin zones + boundaryGeoJSON / PolygonVirtual Campus 2019–2020Zones 1, 2, 3, 4, 7GeoJsonLayer
TerrainRaster tileSatellite DEM (Maxar 0.5 m)Full campus + surroundsTerrainLayer
360° street view imagery.jpg / equirectangularOn-site capturePer weather station locationBitmapLayer
Simulation rasters (CFD, ENVI-met)GeoJSON / RasterResearch outputsUpdated per studyHeatmapLayer

Ref: BEAM Phase 1 Report §4.3, Table 5 · Lu et al. (2025) Journal of Digital Landscape Architecture

03 — Machine learning
Prediction pipeline

An ML model trained on campus morphology and weather station data delivers hourly air temperature predictions at 50 m grid resolution — deployed live via AWS Lambda and served back to the DT as an interactive heatmap.

ClimaTwin — air temperature prediction
XGBoost · Phase 1
Input 01
Meteorological data
40 weather stations · 1-min intervals · clear-day conditions
Input 02
Urban morphology
Building height, SVF, greenery %, impervious cover, emissivity, albedo — from LiDAR + GIS
Model
XGBoost (XGB)
Trained per hour · RMSE <0.3°C night · <0.6°C day · deployed via Docker on AWS Lambda
Output
50 m grid prediction
JSON grid IDs + predicted temperatures → deck.gl HeatmapLayer on DT interface
Phase 2 — ClimaTwin upgrade: LSTM and transformer-based time-series architectures are planned to replace the current XGBoost prototype, requiring more than 1 year of continuous sensor data for training. Deployment will remain on AWS Lambda + API. · Ref: BEAM Phase 2 proposal; Xu et al. (2025) CISBAT
04 — Frontend
Technology stack

Six core technologies power the BEAM DT interface — from map rendering to chart display to the application framework.

Map engine
deck.gl

GPU-accelerated WebGL visualisation. Each data source is a separate, independently toggled layer. Selected over CesiumJS for campus-scale fine-grained data density.

Charts & time-series
plotly.js

Interactive line charts, bar charts, and heatmaps inside sensor popups. Supports range selection, hover tooltips, and downloadable outputs.

Application framework
React

Single-page web application. Component-based — sensor popups, layer controls, and the 3D viewport update independently without full page reloads.

Server runtime
Node.js

JavaScript runtime powering the DT backend logic, API calls, and data formatting before delivery to the React frontend.

Cloud infrastructure
AWS

EC2 (FTP), S3 (storage), Lambda (serverless processing), API Gateway (REST endpoints). All sensor data and spatial assets served from AWS.

ML deployment
Docker + Lambda

XGBoost models packaged in Docker containers, deployed as AWS Lambda functions. API endpoint interfaces directly with the DT for on-demand predictions.