A downtown Toronto infrastructure client had BIM models with the consultants who built them, condition data in a maintenance system with its own asset IDs, and a GIS that knew where things were but not what state they were in. Here's how reconciling those three into one asset register turned reactive maintenance into condition-driven maintenance.
We wrote recently about which GIS data actually earns a place in a digital twin, and why BIM and digital twins solve different problems. Both posts skip past the step that usually determines whether a twin works at all: getting your existing data to agree on what it's even talking about.
Here's a project where that was the whole job.
The Setup
In 2023 we built a digital twin for infrastructure asset management for a private client in downtown Toronto — a live, data-rich model of their physical assets, bringing BIM geometry and geospatial context together in one place, intended to give the asset owner a continuously updated view for condition monitoring, maintenance planning, and long-term investment decisions.
The Problem Wasn't Missing Data — It Was Disagreeing Data
The client had plenty of data. That wasn't the issue. The issue was that it lived in three places that had never been asked to agree with each other:
- Design models sat with the consultants who'd produced them
- Condition records lived in a maintenance database, keyed on asset IDs that didn't match the models
- Location lived in a GIS that knew exactly where every asset was, and nothing about what state it was in
Answering a question that crossed those three systems — which assets in this corridor are approaching end of life — meant someone manually reconciling three separate exports by hand. That's slow enough that it mostly didn't happen, which meant maintenance was reactive: triggered by failure or by a fixed inspection cycle, because condition simply wasn't visible early enough to act on.
Identity First, Everything Else After
The unglamorous part came first, and it's where most of the effort actually went: building a single asset register that the BIM models, the GIS layers, and the maintenance history could all resolve against. Every subsequent step depends on that register existing.
With identity settled, we could assemble the actual twin:
- BIM geometry, georeferenced into its real-world position — so a single asset can be found either by clicking it in the 3D model or by navigating to it on the map, with both views pointing at the same underlying record
- IoT and sensor feeds attached to the assets they measure, so condition data arrives against the asset itself, not as a standalone time series someone has to correlate back to a location later
- Open formats throughout, so the twin isn't locked to one vendor's platform, and the client's own team can extend it without needing us for every change
What Actually Got Delivered
The finished handover was the integrated digital twin sitting on top of the asset register, the BIM-to-GIS pipeline that keeps geometry and location in sync going forward, live sensor integration wired to the correct assets, and a condition dashboard the asset team works from day to day. We also handed over the documentation and training the client needed to run and extend the system in-house, rather than staying dependent on us for every future change.
What Changed
Maintenance planning moved from cycle-driven to condition-driven — decisions triggered by actual asset state instead of a fixed calendar or a failure. And the question that used to take a day of manual reconciliation across three systems became a single query against one model.
Neither of those outcomes came from the sensors or the 3D geometry. They came from the asset register underneath both — the part of a digital twin that's least visible in a demo and most responsible for whether the thing is still useful a year after handover.
Have infrastructure data spread across BIM, GIS, and maintenance systems that don't talk to each other? Get in touch and we can help you figure out what reconciling them would actually take.
