P
  • Open Local Digital Twin
    1.0
  • City Services
    2.0
  • Product Architecture
    3.0
  • Integration Surface
    4.0
  • EU LDT Compatibility
    5.0
  • Product Resources
    6.0
  • Start a City Pilot
    7.0
  • Product / Open Local Digital Twin
    1.0
Self-hosted city runtime / v0.2.0 technical release candidate
Open Local
Digital Twin
Apache 2.0DockerPostGISPublic source
A city-controlled runtime for building a governed urban record, querying physical and contextual city subjects, connecting specialist models, publishing interoperable services and inspecting results through 2D, 3D and Civic XR surfaces.
Source code and installation
1
Canonical city
runtime
3
Viewer surfaces
2D / 3D / XR
12
EU LDT tools
evaluated
City-controlled core STORE

Evidence / entities / observations / workflows

sourcecanonicalmodelauthority
  • City Services
    2.0
Tallinn / operational path01
Planning caseGIS constraintsBIM / IFC evidenceReview artifact
Target: selected checks move from weeks toward days
Tallinn / planning / BIM / GISTurn planning evidence into an inspectable municipal review service.

Planning cases, parcels, building envelopes, constraints, BIM/IFC references and GIS layers can be compared through one traceable workflow. The measurable opportunity discussed was moving selected checks from workflows measured in weeks toward workflows measured in days, while strengthening rather than replacing existing city systems.

Gaziantep + Kharkiv / city control02
Hazard evidenceBuilt environmentAccess + sheltersPreparedness service
Result: traceable readiness and reconstruction evidence
Gaziantep + Kharkiv / resilienceConnect preparedness, reconstruction and the built environment.

Gaziantep brought traffic, lighting, earthquake preparedness, heat and municipal data platforms into the discussion. Kharkiv sharpened the requirements around ownership, local hosting, sensitive data, digitisation, staffing and post-project continuity. Together they showed that resilience is as much a governance problem as a modelling problem.

Cross-sector / analytical path03
Networks + sensorsModels + simulationIndicatorsOperations + scenarios
Rule: every result keeps method, version and validation state
Cross-sector / operational + analyticalReuse one evidence base across movement, climate and public assets.

Transport networks, origin-destination patterns, synthetic populations, environmental grids, satellite observations, infrastructure, heritage scans and public-space evidence can support live operations, scenario analysis or both. Derived results must preserve method, version, uncertainty, privacy and validation status.

Readiness / delivery path04
Workflow ownerData authorityHosting + securityFunding + continuity
Gate: qualify the city route before claiming project readiness
Readiness / governance / deliveryQualify the delivery path before deployment.

Municipal routes in Istanbul, Atasehir, Funchal, Leiedal, Helmond, Sivas, Bornova, Catanzaro and Meath showed why a Local Digital Twin must identify the workflow owner, data authority, technical team, hosting, procurement, financing and continuity route before implementation.

  • Product Architecture
    3.0
product
system
A self-hosted Node.js, Next.js and Express runtime built around a PostgreSQL/PostGIS canonical city store. Source evidence, consolidated entities, inferred semantics, provider results, model outputs and city-authoritative decisions remain distinct and traceable.
Architecture and user manual
One city runtime for governed evidence, spatial intelligence, external models and interoperable delivery.
01

Canonical city store

PostgreSQL / PostGIS
Physical entities, contextual subjects, observations, relations, cohorts, administrative areas and scenario worlds share a governed city record with stable identity and provenance.
02

Governed intake

Open + city + provider
Public, municipal and provider data enter through bounded ingestion, consolidation and semantic-promotion workflows without silently becoming city-authoritative truth.
03

Query and evidence

TwinQL / CQL2 / SQL
Spatial and contextual queries produce reusable selections, query passports and export manifests while preserving the source, method, scope and returned result.
04

Models and scenarios

Provider-neutral contracts
Indicators, external models and scenario worlds return governed outputs with inputs, units, versions, confidence, warnings, provenance and validation state attached.
05

Standards and APIs

Exchange and reuse
DCAT, NGSI-LD, OGC API Features, GeoJSON, CityJSON and model-output paths connect the city runtime to external platforms without surrendering the canonical record.
06

Operator surfaces

Cockpit / 2D / 3D / XR
Technical workspaces, MapLibre 2D, Cesium 3D and Civic XR expose the same governed evidence to operators, analysts, specialists and guided civic scenarios.
  • Integration Surface
    4.0
connect
systems
OLDT connects city systems, provider modules and analytical services through explicit contracts. Each integration identifies the inputs it consumes, the output it returns, the method and version used, and the boundary where it operates.
Bring specialist technology into the city runtime without confusing a model result with a city fact.
01 / DATA AND FEDERATION
City evidence in, governed services out
Connect municipal APIs, GIS/BIM, OGC services, catalogues, sensors, satellite products and NGSI-LD context services to one city runtime. OLDT preserves source traceability, authority status and standards projections while allowing each deployment to select local, remote, offline, cloud or HPC processing boundaries.
Inspect the architecture
02 / MODELS AND SIMULATION
Population, movement and environment
Synthetic populations, crowd and evacuation models, wind/CFD, heat, pollution, flood, solar and building-energy scenarios were examined as specialist services. Their return path can be a traceable grid, vector layer, trajectory, indicator or scenario with units, time, version, confidence and validation attached.
Explore current experiments
03 / OBSERVATION AND CITY ASSETS
From RTSP and sensors to LiDAR and heritage
Video modules can return events, alerts, counts and heatmaps rather than raw surveillance feeds. Earth observation can return validated indicators. LiDAR, point clouds, CityJSON, IFC/BIM and heritage scans can remain linked evidence and viewer artefacts. Privacy, retention, licence and authority boundaries stay explicit.
See public city fragments
04 / INTERFACES AND ADOPTION
A service must be used, not merely installed
The product surface includes 2D/3D/XR interfaces, participatory scenarios, policy indicators, training, onboarding, adoption and continuity. Conductor mode demonstrates how the same spatial evidence can become a guided expert or civic explanation without changing its provenance.
Open the Guanajuato conductor
  • EU LDT Compatibility
    5.0
EU LDT
fit
The complete 12-tool EU LDT Toolbox bundle was installed in a local compatibility laboratory and exercised through bounded scenarios. Nine tools have an accepted OLDT scenario path; Integrated Environment was evaluated as a launcher, while Participate and Federated Learning remain future direct integrations.
Official EU repository
OLDT is the city-side runtime: local evidence and authority stay governed while EU services remain composable.
DI

Data + identity

Data Platform / OIDC
Bidirectional NGSI-LD publish/readback uses selectable profiles. Identity supports OIDC discovery, signed-token validation, role and city mapping, callback and logout.
PV

Play and Visualise

2D / 3D layers
OLDT query selections can be registered as governed visual layers and consumed through the EU visualisation route while the city record and query passport remain local.
MD

Modeller + data space

Schema / EDC exchange
Governed schemas and generated fixtures support a result-import cycle; data-space packages carry catalogue, policy, provenance and consumer-transfer evidence.
CI

City planning

KPI and initiative reuse
City Innovation Planner paths connect KPI measurements and initiatives to OLDT queries, indicator catalogues and U4SSC-oriented acceptance evidence.
AI

Scenarios + AI

UCS / AI Notebook
Baseline and intervention worlds can persist as governed scenarios; named KServe inference can return through an accepted Use Cases and Scenarios workflow.
NX

Next integrations

Participation / learning
Participate and Federated Learning remain explicit future direct integrations. Current laboratory evidence demonstrates compatibility paths, not EU certification.
  • Product Resources
    6.0
Open Local Digital Twin / v0.2.0 RC
Public Apache 2.0 source for a self-hosted PostGIS city runtime, including Docker installation, governed workflows, query services, standards paths and viewer surfaces.
(01)
PUBLIC PRODUCT / 01OPEN LOCAL
DIGITAL TWIN
SOURCE / INSTALL / RUNGITHUB ->
Public product brief / July 2026
A compact account of the city needs, capability families, Open Local Digital Twin architecture, EU LDT relationship and partnership routes behind the product.
(02)
PRODUCT BRIEF / 02PRODUCT +
ECOSYSTEM
PDF / ENGLISH / JULY 2026OPEN ->
User and architecture documentation
Product routes, city workspaces, data and governance model, APIs, query engines, provider intake, viewer surfaces, deployment profiles and operator workflows.
(03)
DOCUMENTATION / 03USER +
ARCHITECTURE
MANUAL / API / DATA MODEL / OPERATIONSREAD ->
Provider and EU LDT contracts
Integration boundaries identify inputs, returned outputs, method, version, runtime, authority, provenance, validation state and the route back into the canonical city record.
(04)
INTEGRATION / 04CONTRACTS +
EU LDT
PROFILES / PROVENANCE / ACCEPTANCEINSPECT ->
Public laboratory and future projects
The earlier public twin, City Fragments and experimental work provide distinct demonstration surfaces. The next route may be a European or national call, research collaboration, international financing mechanism, direct municipal pilot or open-source replication.
(05)
PUBLIC ROUTE / 05LAB + FUTURE
PROJECTS
DEMONSTRATE / QUALIFY / FUND / REPLICATEEXPLORE ->
  • Start a City Pilot
    7.0
start a
city pilot
Start with a real city workflow. Deploy OLDT, connect the evidence, then validate the service and its delivery route.
What the first conversation should resolve
  1. Workflow: what should become faster, safer or better informed?
  2. Owner: which municipal team uses and validates the result?
  3. Evidence: what data and systems exist, and who controls them?
  4. Module: what must be ingested, computed and returned?
  5. Boundary: local hosting, privacy, authority and publication rules.
  6. Delivery: resources, procurement, funding, adoption and continuity.

The output is a focused fit brief: use case, data gaps, architecture, roles, validation plan and realistic project route.