An asset register without a building attached is a cemetery for spreadsheets. You know the names of the things, you know how many of each there are, you might even know who installed them — but you don't know where, and on a real project that is the only question that ever matters when something goes wrong at four in the afternoon on a Friday.
The Oestler Spatial Hub is the part of the platform that closes that gap. It is the home for every 3D model, georeferenced site, and BIM artefact that belongs to a project, with all of them treated as first-class data alongside the asset register itself. It is also the surface where the rest of the platform — assets, attributes, validation rules, comments, the audit trail — meets the geometry of the real world.
One Project, Many Models
The hub itself is intentionally simple. It opens to a single screen: every model in the current project, listed by name, status, file size, element count, and time of last upload. A search bar narrows the list. A toggle switches between grid and table views. A button uploads a new IFC file.
What you don't see is the work happening behind it. When an IFC arrives, the platform streams it through an in-browser processor that strips the geometry, indexes the property sets, and writes a derived bundle to cloud storage. The model document in the hub watches that pipeline and updates its status in real time — pending, processing, ready, failed — so the rest of the team can see, at a glance, what is and isn't currently usable.
This matters in practice. Most BIM workflows still involve emailing a file to one person who opens it on one machine, exports a thumbnail, and circulates a screenshot. The hub turns that into a project resource: every team member sees the same registry, with the same status, the same metadata, and the same one-click route into the viewer.
Assets Linked to Geometry, Not Filenames
The most consequential thing the hub does is also the simplest to describe. It lets you click a piece of geometry inside the model — a pump, a valve, a duct, a structural column — and bind it to the corresponding record in the project's asset register.
Once linked, the binding is permanent and bidirectional. The asset record knows which model element represents it; the model element knows which asset it is. Both directions are queried constantly, by every other feature in the platform that needs the connection.
The model stops being a picture of the building and starts being an index into the project's data.
Hover an element and you see its asset ID. Click it and you can open the asset's full register entry in a side panel — its attributes, its history, its photos, its validation status. Conversely, open an asset elsewhere in the platform and the spatial hub will show you, in every model that contains it, exactly where it lives.
There is no IFC mapping spreadsheet. There is no naming convention to maintain. The link is the data.
Attribute Heatmaps: A Status Report You Can Walk Through
Once assets are linked to elements, the second feature falls out for free. Choose any enumerated attribute on the project — commissioning status, inspection result, fire rating, design responsibility — and the hub will colour every linked element in the model by its current value.
This is what we call an attribute heatmap, and it has quietly become the feature most users open first when they walk into a meeting. A floor of pumps shaded green for commissioned, amber for in progress, red for not started, with a small set of grey ones for unset and a striped overlay for mixed when several linked assets disagree, tells you in three seconds what a status report would take a quarter hour to read.
The legend on the side of the viewer shows the count for each bucket. Click any bucket and the model isolates only the elements in that state, which means you can stand in the meeting and say, "show me everything still unfinished," and have the answer rendered before the next sentence. The bridge between the asset register and the visual world is cheap to build, but the cognitive bandwidth it returns is enormous.
Comments Anchored to Reality
Site issues do not live on PDF page numbers; they live at coordinates. The hub treats comments accordingly. Every comment is anchored to one or more elements, optionally to a saved viewpoint (camera position and target), and is shown both inline next to the element and as a list along the side of the viewer.
A comment can collect replies. It records its author, its timestamp, and the project it belongs to. It survives version updates of the model — the link is by element identity, not by screen position. When somebody opens the model a month later, the conversation is still there, exactly where it was logged, attached to the same valve.
This is a small change with a large operational consequence. Issue tracking against a model has historically meant a separate BCF file, a separate viewer, a separate workflow that lived outside the main project tools. We don't think it should. The comment thread on a piece of geometry should sit on the same record as the asset's history, the same project as the validation log, with the same access controls and the same notification fan-out as anything else the team writes.
Georeferenced From the Inside Out
If an IFC carries an IfcSite with a real-world location, the hub reads it automatically. If it doesn't — and most don't, or carry one that's wrong — a project administrator can set the location manually using a built-in geocoder. The result is the same: the model knows where on Earth it is.
That single piece of information unlocks a category of functionality that has historically required a separate GIS team. The model can be placed on a map at the correct coordinates. Multiple buildings on a campus can be displayed in their actual relative positions. Mobile users walking the site can be located inside the model. The ground plane shown beneath the geometry can be rendered with real terrain, real elevation, real context.
Manual georeferencing is stored on the model document as an override, separately from any value extracted from the IFC. This is a deliberate separation of concerns: the original file remains untouched, the corrected coordinates are the ones the platform uses, and a future re-extract will not overwrite the team's hard-won corrections.
The Spatial Graph
For projects where the relationships between elements matter as much as the elements themselves, the hub includes a graph overlay: a force-directed visualisation of the model's elements connected by storey, by class, or by their shared linked asset. Click a node and you fly to the element. Click an asset and you open its register entry. It is the model viewed not as geometry but as a network — useful exactly when the geometry is too dense to navigate by eye.
This is where the spatial hub starts to overlap with the wider thesis of the platform. Buildings are graphs. Asset registers are graphs. Project teams are graphs. The platform's job is to keep those graphs aligned, queryable, and visible at the level of detail that matches the question being asked.
What the Hub Is Not
It is worth being explicit about what the spatial hub is not. It is not a clash detection engine. It is not a structural analysis tool. It is not a replacement for design-authoring software. It is a read-and-link surface — the place where the geometry produced upstream gets bound to the operational data the rest of the platform manages.
This focus is deliberate. Construction technology is full of monolithic suites that try to be every tool at once and end up being mediocre at all of them. We would rather do one thing extremely well: take the model the design team already produces, make it queryable as data, and bind it to the asset register so that the rest of the project's life can be managed against it.
Where It Sits in the Platform
The Spatial Hub is one of the main sections of an Oestler project, alongside the Asset Register, the Document Register, the Validation Register, the Annexures, the Knowledge Search, and the user's personal Notebook. It is the section a project lead opens during weekly progress reviews. It is the section a commissioning engineer opens when something fails on site and the rest of the team needs to see what's around it. It is the section that makes the rest of the platform's data feel real, because it ties every record back to a place a person can stand in.
If your project has an IFC, you can upload it now. If it doesn't, you can generate a small test model from the hub itself to feel out the workflow. Either way, the moment you bind your first asset to a piece of geometry, the rest of the platform changes shape around it.
The Spatial Hub is available in every Oestler project today.