P
+44 7887 147696
  • Open Local Digital Twin
    1.0
  • City Use Cases
    2.0
  • Open Integration Base
    3.0
  • Technology Capability Map
    4.0
  • EU LDT Toolbox
    5.0
  • Work Produced
    6.0
  • Future Collaboration
    7.0
  • Open Local Digital Twin
    1.0
Local Digital Twin ecosystem fieldwork / 2026
From ecosystem
to open twin
We reconciled public profiles, platform conversations, meeting records, city questions, technical demonstrations and call requirements. Recurring needs were translated into an open city runtime, provider contracts and a repeatable way to form credible Local Digital Twin projects.
Read the public concept note
202
Public profiles
screened
132
Platform conversations
indexed
32
Meeting records
reconciled
Field evidence 202 / 132 / 32

Profiles / conversations / meeting records

citiestechnologyresearch
Open city runtime OLDT

Evidence / contracts / standards / workflows

needdataserviceresult
  • City Use Cases
    2.0
city
signals
The conversations did not produce one universal use case. They exposed four recurring problem families and the conditions that make each one credible.
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 / deliveryA contact is not yet a city-ready project.

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

  • Open Integration Base
    3.0
open
base
The ecosystem work was converted into an installable architecture: a self-hosted PostGIS city runtime that separates source evidence, consolidated entities, provider results, scientific outputs and city-authoritative information.
Source code and documentation
Not another dashboard: a city-controlled evidence and orchestration layer built for integration, analysis and controlled publication.
01

City baseline

Postgres / PostGIS
City workspaces, catalogued datasets, source features, consolidated buildings, roads, facilities and places, with evidence and review state kept separately.
02

Governed intake

Open + city + provider
CSV, GeoJSON, Shapefile, GeoPackage, OGC services, STAC, CityJSON and BIM/IFC metadata enter through bounded ingestion and consolidation workflows.
03

Provider contracts

Models and specialist modules
Every external output can carry inputs, method, units, model and code version, confidence, warnings, licence, provenance, deployment boundary and validation state.
04

Science and scenarios

Operational + analytical
Indicators, networks, simulations, scenario inputs and outputs remain distinct from base facts so cities can inspect how a result was produced.
05

Standards and federation

Exchange and reuse
DCAT, OGC API Features, NGSI-LD, JSON-LD, OpenAPI, GeoJSON and CityJSON projections are generated from the city inventory, with a FIWARE/context-broker boundary.
06

Three visual surfaces

2D / 3D / Civic XR
MapLibre and vector tiles for familiar analysis, Cesium and 3D Tiles for city-scale spatial evidence, and Civic XR for guided expert or public scenarios.
  • Technology Capability Map
    4.0
capability
map
Provider demonstrations, technical notes and research discussions were translated into interface families. The assessment classified what a module consumes, returns and requires; it did not confuse a useful conversation with a finished integration or partnership.
01City fragments2D evidence 02Public twinEarlier runtime 03LaboratoryModels + scenarios 04Civic XRGuided evidence
Specialist technology becomes reusable when its inputs, outputs, method and operating boundary are explicit.
01 / DATA AND FEDERATION
City evidence in, governed services out
The mapped capabilities include NGSI-LD context hubs, temporal ingestion, municipal APIs, GIS/BIM, OGC services, catalogues, sensors and satellite/UAV products. The earlier public twin remains available as a demonstration surface; the Open Local Digital Twin advances that work into a durable city inventory with source traceability, authority status and standards projections.
View the earlier public twin
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 capability map also includes 2D/3D/XR interfaces, participatory scenarios, policy indicators, training, onboarding, exploitation and continuity. The 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 Toolbox
    5.0
EU LDT
Toolbox
We treated the EU LDT Toolbox as an ecosystem of real applications, models and infrastructure components, not as a finished city solution. Each component was read against city workflows, required inputs, return outputs and the operating boundary of the Open Local Digital Twin.
Official EU repository
The value is in the connection: city question, governed evidence, model contract, returned result and responsible user.
DP

Data Platform

Horizontal backbone
The EU Data Platform provides context-broker, scope, subscription and replication capabilities. OLDT remains the city runtime: inventory, evidence, workflows, standards, analysis and viewer surfaces.
AM

Applications and models

Use-case fit
EcoBuild, SUMO, Footprint, Renovation, Nevula, CHIMERE, SLIMFEELT and SPADE were screened as building, mobility, climate, planning or analytical components rather than treated as interchangeable tools.
CT

Contract testing

Integration evidence
Output-contract patterns for EcoBuild and building-SAP enrichment were exercised with model key, dataset version, provenance and generated/ingested timestamps. This validates plumbing, not the scientific model itself.
ID

Identity and access

City-controlled boundary
Restricted source data and operational rights remain local. Only approved datasets, indicators, model outputs, catalogues or service definitions cross the publication boundary.
VS

Visual and scenario tools

Shared evidence surfaces
Toolbox results can return as grids, vectors, indicators, scenarios or artefacts and be inspected through 2D, 3D or XR without confusing a simulation result with a city fact.
DS

Data-space readiness

Reuse with conditions
DCAT catalogues, NGSI-LD projections, OGC access, policy metadata, provider contracts and provenance define what can be found, exchanged and responsibly reused.
  • Work Produced
    6.0
work
produced
Download PDF / English
GitHub repositoryInstallation guideEarlier public twin
Public concept note / July 2026
A compact external account of the ecosystem map, city use-case families, technical capabilities, Open Local Digital Twin base, Toolbox connection and partnership routes.
(01)
PUBLIC OUTPUT / 01ECOSYSTEM
CONCEPT NOTEPDF / ENGLISH / JULY 2026OPEN ->
Open Local Digital Twin / release candidate
A self-hosted PostGIS city runtime with source evidence, consolidation, provider intake, science/scenario records, standards projections, workflows and 2D/3D/XR viewer surfaces.
(02)
PUBLIC OUTPUT / 02OPEN CITY
RUNTIMESOURCE / ARCHITECTURE / INSTALLATIONGITHUB ->
Project qualification method
A repeatable gate: name the city workflow and owner; inventory available data and authority; define the module contract; specify validation; then resolve deployment, financing, procurement, adoption and continuity.
(03)
WORKING METHOD / 03PROJECT
QUALIFICATIONNEED / OWNER / DATA / MODULE / DELIVERYREAD ->
Minimum provider exchange package
Each module should disclose identifiers and geometry, required inputs, returned outputs, units, method, model/code version, runtime, licence, privacy assumptions, uncertainty, provenance, validation state and the return path into the twin.
(04)
TECHNICAL METHOD / 04PROVIDER
EXCHANGECONTRACT / PROVENANCE / VALIDATIONINSPECT ->
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
PROJECTSDEMONSTRATE / QUALIFY / FUND / REPLICATEEXPLORE ->
  • Future Collaboration
    7.0
build the next
city service
contact@polisplexity.tech
Polisplexity / open infrastructure for city evidence, simulation and civic intelligence.
Bring a real city question. We will test the fit, evidence, interface, validation and delivery route before proposing a project.
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.