Editing received files

Open a Revit export of a house and look for a WC. It is there, on the right storey and in the right place, carrying the manufacturer’s product name. It is also an IfcBuildingElementProxy, which is IFC’s way of saying something, unspecified. So are the washing machine, the tumble dryer, the cooker hood and the hob.

IFC is an open standard, shared by every program that writes it, and it has a class for WCs. The exporter didn’t use it. In software that treats IFC as something produced at the end, for other people, that is where the matter rests: the file is output, and the only place to fix it is back in the program that wrote it. In Bonsai the file is the document whichever program wrote it, so you select the WC, tell Bonsai it is a sanitary terminal, and save.

What you didn’t touch comes back as it was

The WC keeps its identity through the change. It has the same GlobalId, the permanent identifier every IFC object carries, and the same shape, the same properties and the same storey. Only what it is has changed. Its type has changed with it, and so has every other WC of that type, because an object and its type have to agree about what they are.

The rest of the file is untouched. Bonsai works on the file it opened rather than on a translation of it, so the objects you never selected go back out as they came in, with the same identities and the same values. Two things will differ if you compare the files line by line. The header records Bonsai as the program that last wrote the file, and some numbers are written differently - 1.0000000E+000 comes back as 1. - without their value changing.

The geometry is left alone as well, and it is whatever the exporter wrote. A wall that arrived as a mesh of triangles stays one, and a door from another program has a shape and no parameters behind it. Both can be moved, reshaped or replaced like any other geometry, but they don’t answer to the parametric tools the way something made in Bonsai does.

Adding what the exporter never had

Most of the work on a file like this isn’t correction but addition. A client wants classification codes on every element, a specification asks for fire ratings that nobody entered, the people who will run the building want the manufacturer on every fitting. Checking the model against a written requirement tells you what is missing, and the gaps are filled in here, in the same file.

You rarely do that one object at a time. Select by what things are - every door, every door on the ground floor, everything of one type - with the same queries you would use to find them, and a classification, a type or a corrected class applies to the whole selection at once. A property value set on one object can be copied to everything selected with it. An element the exporter left outside the spatial tree is dealt with the same way: select the strays and assign them to the storey they belong on.

Exporters have habits

Some faults turn up so regularly that there are standard fixes for them, called recipes, which Bonsai runs against the file you have open.

The commonest fault is duplicated types. The house’s Revit export holds one door type, Single-Flush 800 x 2100, four times over, and one curtain-wall mullion type sixty-three times; a schedule of door types built from it would list four where there is one. A recipe merges the duplicates, and that file goes from 215 types to 111.

Shared property sets catch you while you are editing. Some exporters attach a single set of properties to several objects at once - an older Revit export does it with three floor slabs - so that changing a value on one slab changes it on the other two. That is legal IFC and a reasonable way to save space, but it means an edit lands somewhere you didn’t intend. Another recipe gives each object its own copy before you start.

Whose file is it?

Being able to edit a file doesn’t make it yours to edit. A consultant’s model carries their name and their professional liability, and the boundary between models is about who is answerable, not about what the software allows. If the structural engineer’s beams are wrongly classified, the usual answer is an issue sent to the engineer, not a quiet correction.

Editing is plainly right where the responsibility is already yours. That covers your own office’s export, from software you haven’t moved off yet, so Bonsai is useful before you have authored anything in it. It covers a model handed over to you, as the client or as the people who will run the building. And it covers a working copy kept for your own purposes, which goes no further than you.

The next export

A fix made by hand lasts until the file is exported again. If the same model is going to arrive every fortnight, the correction has to be repeatable, and a recipe is exactly that: the same fix, run from a script over every delivery. Several of the recipes Bonsai ships began that way, as one person’s fix for one vendor’s export, shared with whoever met it next.

Before you change anything, open the file, save it, and commit that to version control. The first save is where the number notation changes, and getting it over with keeps it out of the record of your edits; the saves after it are stable. From then on the history shows exactly what you did - reclassifying every WC in the exported house changes seven lines in a file of more than a hundred thousand - and it goes on answering the question of what was done to somebody’s file for as long as anybody asks.

Last updated 8 October 2026.