Decisions to settle when you start a project

Three things are defined by the project as a whole rather than by any object in it: the units it is measured in, where in the world it sits, and which version of the IFC schema it is written to. Units and schema are settled when Bonsai creates the file, and are awkward to change afterwards, so they are worth five minutes before you draw anything. Georeferencing can wait, but it constrains the schema, so it is a concern at the beginning anyway.

These three are kept either in the header or the IfcProject at the root of the spatial tree. They aren’t settings that Bonsai remembers for you but are written into the file, and because IFC is an open standard, everybody who opens the file will read them the same way.

Units

Units are chosen when the project is created - Bonsai offers metric and imperial starting points - and the choice applies to the whole file. Even in a metric country, you may need to use millimetres or metres depending on the project.

IFC stores lengths in the project’s units, so this isn’t a display preference you can flip when a consultant complains: the numbers in the file use the units specified.

Georeferencing

Georeferencing is the question of where in the world the model sits. The minimum is a projected coordinate reference system, named by its code in the public EPSG registry. What counts is narrower than people assume: a model whose coordinates are large real-world numbers isn’t thereby georeferenced, because without a declared reference system they are just big numbers, and nobody receiving the file can tell what they are measured from.

You can set it up at any point in the project; it doesn’t need to be done on day one. But IFC2X3 has no proper place for it. The schema has no words for a reference system, only a workaround that keeps the same numbers in property sets, and Bonsai will show you georeferencing stored that way but won’t let you add or edit it. So if you already know the project will need to sit properly on a site, choose IFC4 or later from the start.

The georeferencing guide covers the detail, including true north, which is a separate matter from grid north and catches people out.

Which version of the schema

The schema is the published vocabulary of object types and relationships that an IFC file is written in, and it comes in versions. A file declares which version it speaks in its header. Bonsai can write all commonly used versions, i.e. IFC2X3, IFC4 and IFC4X3, and ships a starter template for each.

These aren’t software version numbers and they don’t date anything. They are real standards, all in current use, differing in what they can express. So a consultant who asks you for IFC2X3 is asking for something substantive rather than being difficult.

It is a decision rather than a preference because the versions don’t travel equally well in both directions. Upgrading is generally supported - IFC2X3 to IFC4, IFC4 to IFC4X3 - because each later schema is broadly a superset of the one before. Going back down is lossy by definition: the later schema has words the earlier one doesn’t, and important information can be dropped. Georeferencing is the clearest example: IFC4 supports it properly and IFC2X3 doesn’t.

Why these three, and not the rest

Almost nothing else in a model has this character: a wall’s type can be changed, a property set added, a storey renamed, an object moved to a different floor, and none of these are very hard.

Units and schema are different because the rest of the file is expressed in their terms. Every length is a number in the project’s units, and every entity in the file is a word from its schema. Changing either afterwards isn’t editing the model; it is rewriting all of it in a different language. Georeferencing is different again: it can be added at any point, because it only says how the model’s own coordinates relate to the world, but it can only be added to a schema that can hold it (i.e. IFC4 or IFC4X3).

Converting later is possible: ifcpatch has a recipe for converting a file’s units and another for migrating it between schemas, and both run over a folder full of files as readily as over one file. But they are conversions or exports, and exports break the chain of revisions that is such a useful feature of Native IFC.

What you are given

Everything else in a new project is already there: Bonsai builds the spatial tree as it makes the file, and sets up the contexts that geometry is filed under - the 3D body, the plan symbol, the axis and more.

Last updated 6 October 2026.