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
projectidunit · frontSide
footprintid
gradeid · elev
levelid · elev · heightbuildingkind
roomid · level · w · dlevelceiling
moduleid · entities
instanceid · module
wallid · levellevelside · type · top
curtain-wallid · level · sideside
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 · profileop
vaultid · axis · spring · riselevelaxis
furnitureid · type · level · x · ylevel
assetid · classside
treeid · x · y · canopy
parcelidfrontage · shape
setbackid
buildingidfootprintshape
pavingid · useuse · shape
roadid · use · width · from
parkingid · along · count
landscapeidshape
fenceid · from · to · height · kindkind
curbid · from · to
streetid · name · from · width · lanes
signid · kindkind
utilityid · kind · from · to
poolid · x · y · w · d · depth
scheduleid · name · rows
viewid · modelevelaxis
gridid · axis · at · labelaxis
parapetid · on
copingid · on
fasciaid · on
sillid · on
canopyid · on
plinthid · on
louvreid · on
downpipeid · on
symboldefid · draw
materialdefid · of · valueof · 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