bimtex
The format

Entity types

One object per line, joined by ids. The whole grammar fits in a paragraph.

A bimtex file is a flat list. Every line is one JSON object, and the object's t says what it is. There is no nesting, no document tree, no opening and closing of anything.

{"t":"level","id":"g","name":"Ground","elev":0,"height":3}
{"t":"room","id":"kitchen","label":"Kitchen","level":"g","x":0.3,"y":0.3,"w":4,"d":3}

Structure comes from ids. The room says "level":"g" and that is the entire mechanism — the same one that puts an opening in a wall, a roof on a storey and a canopy on a parapet. References are always ids and never array positions, so reordering the file changes nothing.

What you have to know before the table

Three conventions, and then the reference below answers everything else.

Units are metres, always. "w":4 is four metres. There is no unit field on an entity; project.unit records what the drawing is dimensioned in, not what the numbers mean.

Axes are x east, y south, z up. So a bigger y is further down the plan, which matches how you read a drawing and surprises people who expect graph paper.

Ids are yours and they are permanent handles. Name them the way you would name a room on a real drawing — kitchen, w-south, roof-main — because every diagnostic you ever read will quote them back at you.

EntityRequired fieldsReferencesControlled values
projectid—unit · displayUnits · frontSide
footprintid——
gradeid · elev——
levelid · elev · heightbuildingkind
roomid · level · w · dlevelceiling
moduleid · entities——
instanceid · module——
wallid · levellevelside · type · top
curtain-wallid · level · side—side
openingid · on · kind · widthonkind · arch · operation · hinge
slabid · level · x · y · w · dlevel—
voidid · level · x · y · w · dlevel—
columnid · level · x · y · sizelevel—
platformid · level · x · y · w · dlevel—
stairid · from · to · x · y · width · run · dirfrom · todir
liftid · from · to · x · yfrom · todir
rampid · level · from · to · width · riselevel—
roofid · typelevelridgeAxis
dormerid · on · widthon—
formdefid · for · op · profile—op
vaultid · axis · spring · riselevelaxis
furnitureid · type · level · x · ylevel—
assetid · class—side
treeid · x · y · canopy——
parcelid—frontage · shape
setbackid——
buildingidfootprintshape
pavingid · use—use · shape
roadid · use · width · from——
parkingid · along · count——
landscapeid—shape
fenceid · from · to · height · kind—kind
curbid · from · to——
streetid · name · from · width · lanes——
signid · kind—kind
utilityid · kind · from · to——
poolid · x · y · w · d · depth——
scheduleid · name · rows——
gridid · axis · at · label—axis
parapetid · on——
copingid · on——
fasciaid · on——
sillid · on——
canopyid · on——
plinthid · on——
louvreid · on——
downpipeid · on——
symboldefid · draw——
materialdefid · of · value—of · value
texturedefid · image · period——
lookid · for · use——
lookdefid · for · body——

This table is build output, generated from ENTITY_DEFS in the same file the compiler and validator read. Adding a type changes this page on the next build, so the reference cannot drift away from what the code accepts. If a field is here, it works.

Where to go next