Befehlsübersicht

Draws a circular arc: through three points (start, any point on it, end), or counter-clockwise round a center from a start point to the direction of an end point, or round a center with a radius between two angles (degrees from +X, counter-clockwise). Door swings, rounded corners, curved walls, rows of seats. Snaps to its ends, middle and center; trim, extend and offset work on it.

JSON-Form: arc {"points": [[x, y, z], [x, y, z], [x, y, z]]} (start, a point on the arc, end) or {"center": [x, y, z], "start": [x, y, z], "end": [x, y, z]} (counter-clockwise) or {"center": [x, y, z], "radius": r, "startAngle": deg, "endAngle": deg}; with a center also "normal": [x, y, z] (default [0, 0, 1]: level)

Draws a closed polyline round the area around each point, found among the lines, arcs, polylines, circles and ellipses that close it, even where they cross or run past each other; with islands, also round what stands inside. Turns rooms or site zones drawn with single lines into outlines to offset, extrude into walls or slabs, hatch, or measure. Selects what it made.

JSON-Form: boundary {"points": [[x, y, z], ...] (inside the areas), "islands": bool (default true: outlines of what stands inside too)}

Draws a circle. By default it lies flat (normal +Z). Extrude turns it into a cylinder.

JSON-Form: circle {"center": [x, y, z], "radius": r, "normal": [x, y, z] (default [0, 0, 1])}

Places filled rings or dots, as AutoCAD's DONUT: a closed polyline of two half circles with a width, so it stays a polyline (width and size change like any). Inside diameter 0 gives a filled dot: plugs, cable passages, survey or anchor points.

JSON-Form: donut {"inside": 0.5 (diameter, 0 for a filled dot), "outside": 1.0, "centers": [[x, y, z], ...]}

Draws an ellipse lying flat at the center's height, or an elliptical arc: oval tables, stage platforms, planters, the curve of a stand. Give the half-lengths of its axes ("radii", the first along "rotation") or the end of one axis and the other's half-length. Start and end angles turn counter-clockwise from the first axis, as seen from the center. Extrude turns a whole one into a solid.

JSON-Form: ellipse {"center": [x, y, z], "radii": [rx, ry], "rotation": degrees (direction of rx, default 0) | "axisEnd": [x, y], "otherRadius": r; "startAngle", "endAngle": degrees from the first axis (for an elliptical arc)}

Fills areas with a pattern or solid color, lying flat: walls in section, paving, lawns, zones of a site. Give points inside areas: the smallest area around each point that the shown lines, arcs, polylines, circles and ellipses close (they may cross or run past each other's ends; whatever stands inside stays free as an island), the ids of closed outlines, or the corners of loops directly. Lines that don't quite meet leave the area open. Patterns: solid, lines (diagonal), cross, grid, horizontal, brick, dots; spacing is the distance between lines. Returns the area. Put hatches on their own layer.

JSON-Form: hatch {"points": [[x, y, z], ...] (inside the areas) or "ids": [id, ...] (closed outlines) or "loops": [[[x, y, z], ...], ...] (corners), "pattern": "lines" (solid, lines, cross, grid, horizontal, brick, dots), "spacing": s (default: suits the area), "angle": degrees}

Changes hatches: another pattern (solid, lines, cross, grid, horizontal, brick, dots), the spacing between their lines, or how far the pattern is turned (as the hatch command takes it: lines at 0 run at 45 degrees). Without a new pattern, the one they have (also a pattern from a DWG) gets closer or wider and turns; a new pattern keeps spacing and turn.

JSON-Form: hatchedit {"ids": [id, ...] (default: the selection), "pattern": "brick", "spacing": s, "angle": degrees}

Draws connected straight line segments through the points. Use it for 2D drafting, outlines and guide lines.

JSON-Form: line {"points": [[x, y] or [x, y, z], ...] (at least 2), "close": bool (optional)}

Draws one polyline through the points, with straight or arc segments. A closed polyline is an outline that extrude turns into a solid, e.g. the floor plan of a wall or an L-shaped slab. A bulge bends the segment after its point into an arc: the tangent of a quarter of the angle the arc turns through; positive turns left (counter-clockwise), so the arc bulges out to the right of the straight way; 1 is a half circle, 0 straight.

JSON-Form: pline {"points": [[x, y] or [x, y, z], ...] (at least 2), "close": bool (optional), "bulges": [b, ...] (optional, one per point), "width": w (optional: a filled band that wide)}

Draws a regular polygon as a closed polyline lying flat: triangles, hexagons, octagonal tents and kiosks. With inscribed (default) the corners lie on the circle of the radius; otherwise its sides touch it. Extrude turns it into a prism.

JSON-Form: polygon {"center": [x, y, z], "sides": n (3-1024), "radius": r, "inscribed": bool (default true: corners on the circle; false: sides touch it), "angle": degrees (to the first corner, or the first side's middle; default: bottom side horizontal), "xAxis", "yAxis": [x, y, z] (the plane, default the world's)}

Rays: construction lines from a point on, endless the other way, as AutoCAD's RAY.

JSON-Form: ray {"start": [x, y, z], "through": [x, y, z] or [[x, y, z], ...] | "angle": degrees | "direction": [x, y, z]}

Draws a rectangle as a closed polyline in the horizontal plane at the corner's height, or with xAxis and yAxis in the plane they span through the corner (on a wall: the wall's horizontal and up), its sides along them. Extrude turns it into a box-shaped solid; presspull pushes it into the solid it lies on.

JSON-Form: rectangle {"corner": [x, y, z], "opposite": [x, y], "xAxis": [x, y, z], "yAxis": [x, y, z]} (a closed polyline at the corner's height; the axes, both or neither, lay it in another plane, default the world's)

Turns closed outlines into regions, as AutoCAD's REGION: areas lying flat, drawn as their outline, with an area (area, list) and to combine: union joins regions, subtract cuts some out of the first (holes stay holes), intersect keeps what they share. The outlines are replaced.

JSON-Form: region {"ids": [id, ...] (closed polylines, rectangles, circles, ellipses; default: the selection)}

Draws a revision cloud: a closed polyline of arcs bulging outwards round a rectangle, an outline given by its corners, or a closed polyline, circle or ellipse (which becomes the cloud). Marks what changed in a plan. "arc" is the length of each arc; the corners of the outline are kept.

JSON-Form: revcloud {"corner": [x, y, z], "opposite": [x, y]} or {"points": [[x, y, z], ...]} or {"id": closed object}; "arc": length (default: 40 arcs round)

Freehand lines: each stroke (the points of a hand-drawn path, in order) becomes one polyline, or a smooth spline, keeping only the points that matter to its shape. In the app, click to put the pen down, move, click to lift it; Enter keeps the strokes.

JSON-Form: sketch {"strokes": [[[x, y, z], ...], ...], "type": "polyline" | "spline" (default polyline), "tolerance": d (optional)

Draws a smooth curve through the points, in their order (a closed one back to the first): paths, planted beds, ponds, the organic outline of a site. It becomes a smooth polyline; to change its shape, draw it again.

JSON-Form: spline {"points": [[x, y, z], ...] (at least 2), "close": bool (default false)}

Covers an area with the background, so what lies under it in the draw order disappears: a quiet field for a legend or note on top of a busy plan, a stamp of free space. Give the corners, points inside areas (each covers the outline around it, islands included) or closed outlines ("erase" takes them away). Each area becomes one wipeout on the current layer, drawn over everything there is; what is drawn later lies on top of it. "frames" shows their outlines on screen and paper (on), on screen only (display), or not at all (off).

JSON-Form: wipeout {"loops": [[[x, y, z], ...], ...] (corners) or "points": [[x, y, z], ...] (inside areas) or "ids": [id, ...] (closed outlines), "erase": false (the outlines given as ids); or "frames": "on"|"off"|"display" alone}

Construction lines, endless both ways, as AutoCAD's XLINE: through a point and another (several at once with a list), at an angle, level or upright, halving the angle at a vertex, or a distance beside a line or construction line. They draw across the view, snap like lines and stay out of the drawing's extents.

JSON-Form: xline {"point": [x, y, z], "through": [x, y, z] or [[x, y, z], ...] | "angle": degrees | "direction": [x, y, z] | "horizontal": true | "vertical": true} | {"bisect": {"vertex": [x, y, z], "first": [x, y, z], "second": [x, y, z]}} | {"offset": d, "from": line, "side": [x, y, z]}

Moves objects so that a point of theirs lands on a destination point, and with a second pair turns them (in plan, about the first point) so that the line through their second point runs through the second destination point; scale true also scales them to it. For fitting a scanned plan or a PDF underlay onto known points, or a part onto its place.

JSON-Form: align {"ids": [id, ...] (default: the selection), "from": [[x, y, z], ...] (1 or 2 points of the objects), "to": [[x, y, z], ...] (where they go), "scale": bool (default false)}

Repeats objects evenly along a line, polyline, circle or arc: posts along a railing, lamps along a road, piers along a bridge. The base point of the objects goes to each point; the originals are the item at the base. align true turns the copies with the path.

JSON-Form: arraypath {"ids": [id, ...] (default: the selection), "path": id, "count": n, "base": [x, y, z] (default: the path's start), "align": bool (default false)}

Repeats objects around a vertical axis through the center: chairs around a table, bolts on a flange, columns in a circle. count includes the original; angle is the angle to fill (360: evenly all round). rotate false keeps the copies upright.

JSON-Form: arraypolar {"ids": [id, ...] (default: the selection), "center": [x, y, z], "count": n, "angle": degrees (default 360), "rotate": bool (default true)}

Repeats objects in columns along X, rows along Y and levels along Z, the originals being the first item: grids of columns, windows on a facade, floors of a building. Block references stay references.

JSON-Form: arrayrect {"ids": [id, ...] (default: the selection), "columns": n, "rows": n, "levels": n (default 1), "spacing": [dx, dy, dz]}

Cuts a gap into a line, polyline, circle or arc between two points on it (a door opening in a wall line), or cuts it in two at one point. A circle loses the part counter-clockwise from the first point to the second, a closed polyline the part from first to second the way it runs.

JSON-Form: break {"id": id, "first": [x, y, z], "second": [x, y, z] (default: the first, which cuts it in two)}

Makes copies of objects, moved by an offset. The copies get new ids; the originals stay.

JSON-Form: copy {"ids": [id, ...] (default: the selection), "by": [dx, dy, dz]}

Puts points, or a block, along a line, polyline, circle, arc or ellipse so that it is cut into equal parts: on an open path between the parts (count - 1 of them), on a closed one count of them, the first at its start. ends true puts one at both ends of an open path as well, like fence posts. align turns blocks with the path. The object itself stays whole.

JSON-Form: divide {"id": path, "count": parts, "block": "name" (default: points), "align": bool (default true), "ends": bool (default false)}

Changes which objects cover which: a solid fill, hatch or image covers what lies under it in the draw order. "front" and "back" put the objects over or under all others, "above" and "under" just over the topmost or under the lowest of the reference objects. The objects keep their order among themselves. New fills and images go under the lines already drawn; use this to lay a fill over them, or a legend box over the plan.

JSON-Form: draworder {"ids": [id, ...] (default: the selection), "to": "back" (front, back, above, under), "reference": [id, ...] (for above and under)}

Deletes objects.

JSON-Form: erase {"ids": [id, ...]} (default: the selection)

Lengthens a line, open polyline or arc at the end nearest to the point (straight on, or round the arc's circle) until it meets the next object. Works in plan (XY).

JSON-Form: extend {"id": id, "point": [x, y, z] (near the end to extend)}

Takes one grip of an object to a point: a line's "start" or "end" (stretch) or "mid" (move); a polyline's "vertex-N" or "mid-N" (a straight segment moves, an arc bends through the point); a circle's "center" or "quadrant-N" (radius); an arc's "start", "end", "mid", "center"; a solid's "base" (move) and, for a box, cylinder, cone, sphere or torus, the measure it changes ("height", "radius", "length", "width", "topRadius", "tubeRadius"), read off the point; a dimension's "start", "end", "position"; a block's "insertion"; a text's or point's "position". A wrong grip name lists the object's grips.

JSON-Form: grip {"id": object, "grip": "end", "to": [x, y, z]}

Sends every hatch and solid fill to the back, under all lines and texts; images at the very bottom stay under them. Objects on locked layers stay where they are.

Joins lines, arcs and open polylines that meet end to end into one polyline (closed when they go all round), or into one line when they are lines on one straight: an outline drawn in pieces becomes one that can be offset, hatched or extruded. It takes the look of its first object.

JSON-Form: join {"ids": [id, ...] (default: the selection)}

Makes a line, arc or open polyline longer or shorter at the end nearest to the point: by a difference (negative shortens) or to a total length. Arcs change round their circle.

JSON-Form: lengthen {"id": id, "point": [x, y, z] (near the end to move), "delta": d or "total": length}

Gives objects the look of another: its layer and own color, and between objects of the same kind a text's height, a dimension's text height and decimals, an image's fade.

JSON-Form: matchprop {"source": id, "ids": [id, ...] (default: the selection)}

Puts points, or a block, along a line, polyline, circle, arc or ellipse every length, starting from the end nearest "from": lamps every 25 m along a path, a post every 2.5 m along a fence. What is left over stays at the far end. ends true puts one at both ends of an open path as well. align turns blocks with the path.

JSON-Form: measure {"id": path, "length": distance, "from": [x, y, z] (start at the end nearest it; default: the start), "block": "name" (default: points), "align": bool (default true), "ends": bool (default false)}

Mirrors objects in a plane given by a point and its normal. With keep (the default) the mirrored objects are new and the originals stay; otherwise the originals are replaced.

JSON-Form: mirror {"ids": [id, ...] (default: the selection), "point": [x, y, z], "normal": [x, y, z], "keep": bool (default true)}

Moves objects by an offset. Ids stay the same.

JSON-Form: move {"ids": [id, ...] (default: the selection), "by": [dx, dy, dz]}

Makes a parallel copy of lines, polylines, circles and arcs at a distance, on the side of the given point: wall thicknesses, kerbs, rings. Polyline corners stay sharp. Works in plan (XY).

JSON-Form: offset {"ids": [id, ...] (default: the selection), "distance": d, "side": [x, y, z]}

Removes objects that lie twice: copies of another object with the same look (layer, color, linetype), and lines lying on one line that overlap, which become one line (with endToEnd also lines that only meet end to end). Cleans up imported plans that print darker and count double. Solids are left alone.

JSON-Form: overkill {"ids": [id, ...] (default: the selection, or the whole drawing when nothing is selected), "tolerance": d (default 0.000001), "endToEnd": bool (default false)}

Rotates objects about an axis through a center point, counter-clockwise by the angle in degrees (seen from the axis tip). The default axis is vertical (Z).

JSON-Form: rotate {"ids": [id, ...] (default: the selection), "center": [x, y, z], "angle": degrees, "axis": [x, y, z] (default [0, 0, 1]), "copy": bool (turn a copy, keep the objects)}

Scales objects uniformly about a center point; a factor of 2 doubles every size. By reference: a length as it is now and the length it should have, e.g. to bring a scanned plan to its true size from one known dimension.

JSON-Form: scale {"ids": [id, ...] (default: the selection), "center": [x, y, z], "factor": f or "reference": length now and "length": length wanted, "copy": bool (scale a copy, keep the objects)}

Moves the points of objects that lie inside a crossing window, so what crosses its edge stretches: a wall made longer, a room made wider. Lines and polylines move the ends and corners inside (arcs keep their angle); circles, texts, blocks, images and points move when their point is inside; dimensions follow their points; solids move only when wholly inside.

JSON-Form: stretch {"corner": [x, y], "opposite": [x, y] (the crossing window in plan), "by": [dx, dy, dz], "ids": [...] (optional: only these)}

Brings every text, every dimension and leader, or both to the front, so no fill or image covers them. Objects on locked layers stay where they are.

JSON-Form: texttofront {"what": "all" (text, dimensions, all)}

Cuts away the part of a line, polyline, circle or arc nearest to the point, up to the nearest crossing objects on either side (or an open end). Every other object cuts, as in AutoCAD's quick mode. Works in plan (XY). The first remaining piece keeps the id.

JSON-Form: trim {"id": id, "point": [x, y, z] (on the part to cut away)}

Adds a corner to a polyline, in the segment nearest to the point (an arc stays an arc, now through it), or takes away the corner nearest to the point (the segments either side become one straight one). For bending a fence line or simplifying an outline without drawing it again.

JSON-Form: vertex {"id": polyline, "add": [x, y, z] (a new corner, in the segment nearest to it)} or {"id": polyline, "remove": [x, y, z] (near the corner to take away)}

Creates a rectangular solid from its minimum corner and its size along X, Y and Z. Use it for walls, slabs, blocks and the cutting tools for openings.

JSON-Form: box {"corner": [x, y, z], "size": [width, depth, height]} (negative sizes extend the other way)

Two lines: bevels their corner with a straight line, `distance` from the corner along each (or `distances`, one per line); each keeps the part on the side of its point (default: its middle); 0 just closes the corner. Polylines: bevels every corner between straight segments, the first distance back along the segment coming in. Solids: bevels every edge by the distance; they keep their ids.

JSON-Form: chamfer {"ids": [id, ...] (default: the selection), "distance": d} for solids or polylines; {"ids": [line, line], "distance": d or "distances": [d1, d2] (default 0), "points": [[x, y, z], [x, y, z]]} for a corner

Bevels only the chosen edges of a solid by a distance, as AutoCAD's CHAMFEREDGE. Each point picks the edge nearest it.

JSON-Form: chamferedge {"id": solid, "edges": [[x, y, z], ...] (a point on or by each edge), "distance": d}

Creates an upright cone or truncated cone from the center of its base, the base radius and the height; top_radius > 0 cuts the tip off. Use it for roofs of towers, funnels, spikes.

JSON-Form: cone {"center": [x, y, z] (center of the base), "radius": r, "height": h, "top_radius": r (default 0)}

Creates an upright cylinder from the center of its base circle, its radius, and its height along +Z (negative goes down). Use it for columns, holes (with subtract), pipes and round parts.

JSON-Form: cylinder {"center": [x, y, z] (center of the base), "radius": r, "height": h}

Draws the solids as seen from far away in one direction, flat and exact (AutoCAD's FLATSHOT), the lines other solids hide left out, or dashed with "hidden": the elevations (Ansichten) of a building beside its plans, to dimension and put on sheets. "front" looks north (from the south), "left" east, "right" west, "back" south; its lower left corner lands on "place". Grouped, so one click picks it. With "sheet" instead of "place", it goes on that sheet (made if there is none) as a viewport drawn anew from the model whenever the sheet is, so it follows every change, windows and doors with their frames, the levels marked at its side, the materials of the walls and roofs it faces named at its left ("notes", default true: each material's description, "Kalkzementputz, weiß", as building applications ask); "crop" shows only what stands in a rectangle of the plan (Revit's crop region), the view as wide as it. For plans to hand out prefer "sheet": a copy at "place" stays as it was when the model changes. "room": a room's walls seen from inside, a view each (its interior elevations, Raumabwicklung: tiles, damage, installations), as sections cut just inside the room and cropped to it and its storey, going round from the north wall, on one sheet ("sheet", default "Raumabwicklung" and the room; "scale" default 1:50), in one step; their cuts are not marked on the floor plans, and the materials are named only with "notes": true.

JSON-Form: elevation {"direction": "front"|"back"|"left"|"right"|"top" or [x, y, z] (the way one looks; front looks north), "place": [x, y, z] (its lower left corner), "hidden": false (hidden lines dashed), "ids": [...] (default: all solids) | "sheet": "Ansichten" instead of "place" (on that sheet, following the model), "nextSheet": true (a full sheet hands it on), "scale": 100, "levels": true, "notes": true, "crop": [[x, y], [x, y]] (only what stands in this rectangle of the plan; [[x, y, z], [x, y, z]] a box) | {"room": id, "sheet": name, "scale": 50} (the room's walls from inside, a view each)}

Turns closed outlines (closed polylines, rectangles, circles, ellipses) into solids by pulling them up by the height (negative goes down). The solids keep the outlines' ids. Use it for walls from a floor plan, slabs of any shape, cylinders and oval platforms.

JSON-Form: extrude {"ids": [id, ...] (default: the selection), "height": h}

Two lines: makes them meet at their corner, trimmed or extended, each keeping the part on the side of its point (default: its middle); a radius adds a tangent arc, 0 just closes the corner (clean wall corners this way). A line and an arc or circle, or two of those: the arc touching both, arcs trimmed or extended like lines, circles staying whole. Polylines: rounds every corner between straight segments, replacing earlier roundings (radius 0 makes the corners sharp again); corners whose segments are too short stay. Solids: rounds every edge with the radius; they keep their ids and fail when the radius is too large for their smallest faces.

JSON-Form: fillet {"ids": [id, ...] (default: the selection), "radius": r} for solids or polylines; {"ids": [line, line], "radius": r (default 0), "points": [[x, y, z], [x, y, z]] (where each line was picked)} for a corner

Rounds only the chosen edges of a solid, as AutoCAD's FILLETEDGE: the top edges of a counter, the outer corners of a stage. Each point picks the edge nearest it (a corner's midpoint, or where a click on a face next to the edge lands).

JSON-Form: filletedge {"id": solid, "edges": [[x, y, z], ...] (a point on or by each edge), "radius": r}

Keeps only the volume the solids share, as one new solid (new id), or the area regions share; the inputs disappear.

JSON-Form: intersect {"ids": [id, ...] (at least 2 solids or regions; default: the selection)}

Makes one solid through two or more closed outlines in the given order, e.g. a square footing that turns into a round pier, a lamp shade, a tapering tower. ruled true joins them with straight faces. The first outline becomes the solid; the others are used up.

JSON-Form: loft {"ids": [id, ...] (two or more, in order; default: the selection), "ruled": bool (default false)}

Pulls closed areas of the plan up into solids: click inside an area bounded by any lines (as hatch finds it) and give a height. Islands in it stay open. For quick 3D from a 2D plan: booths, stages, walls drawn as outlines. Curves become fine straight pieces. On a solid, pulls one of its flat faces out along its outward side or pushes it in (a negative distance): a wall made longer, a niche or an opening pushed through, a step up on a platform.

JSON-Form: presspull {"inside": [[x, y, z], ...] (points inside closed areas), "height": h (negative goes down)} or {"id": solid, "point": [x, y, z] (on a flat face), "distance": d (negative pushes in)}

Changes the measures of a box, cylinder, cone, sphere, torus or wall, as long as it still knows them (a boolean, fillet or the like makes it a plain solid): a box's length, width and height from its corner, a cylinder's or cone's radius and height from its base, a cone's top radius, a sphere's radius, a torus's radius and tube radius, a wall's thickness, height and how it lies about its path, a floor's thickness and fall ("fall" in percent, "direction" the way down; 0 makes it level), a terrain's depth below its lowest point and its contour lines' spacing. Where it stands and how it is turned stay.

JSON-Form: primitive {"id": solid, "radius": r, "height": h, "topRadius": r (cone), "tubeRadius": r (torus), "length": x, "width": y (box), "thickness": t, "align": "center"|"left"|"right" (wall), "fall": 2 (slab, percent), "direction": [x, y] (slab: the way down), "depth": d, "contours": 0.5 (terrain)}

Creates a pyramid on a regular polygon: a tent's roof, a spire, a hopper. radius reaches from the center to the base's corners (a square of side s has radius s/√2); topRadius > 0 cuts the tip off flat. By default a square base lies with its sides along X and Y.

JSON-Form: pyramid {"center": [x, y, z] (of the base), "radius": r (to the base's corners), "height": h, "sides": 4 (3-64), "topRadius": r (default 0: a point), "rotation": degrees}

Turns closed outlines about an axis into solids: columns and balusters from their half profile, vases, domes, wheels. Draw the profile in a plane through the axis (e.g. a closed polyline in XZ for a vertical axis) and keep it on one side of the axis. The outlines become the solids.

JSON-Form: revolve {"ids": [id, ...] (default: the selection), "axis": [[x, y, z], [x, y, z]], "angle": degrees (default 360)}

A room's walls seen from inside, a view each (its interior elevations, Raumabwicklung: tiles, damage, installations), as elevation {"room": id} makes them: sections cut just inside the room and cropped to it and its storey, going round from the north wall, on one sheet at 1:50, following the model, in one step. Without "room" the selected room.

JSON-Form: roomelevations {"room": id (default the selected room), "sheet": name (default "Raumabwicklung <room>"), "scale": 50, "notes": false}

Cuts the solids with a plane and draws the cut as a flat 2D section at "place", the cut faces hatched, each in the layer and color of the solid it cuts, grouped so one click picks it all. Walls, floors and roofs of a type show their layers: thin lines between them, each layer hatched as its material says (see material: concrete crossed, masonry diagonal, insulation zigzag...); stairs of a type and framing members as their material; other solids with diagonal lines. For building and stage sections, to check heights and clearances and to dimension them. The section's x runs along the cut (to the right, looking along the normal) and its y upwards (for a cut lying flat, the plan's y); the point on the plane lands on "place". A vertical cut along the X axis looking north: normal [0, 1, 0]. An upright cut also draws what one sees beyond it, hidden lines left out, as building sections show it ("beyond": false only the cut). With "sheet" instead of "place", the section goes on that sheet (made if there is none) as a viewport that is cut anew from the model whenever the sheet is drawn, so it follows every change, the levels marked at its side (Höhenkoten, ±0 also above the sea where the drawing has a height), and noted as a building application needs it ("notes", default true): each storey's clear height, each stair's risers, rise and going, the wall height H at the outer walls (from the ground to where the wall meets the roof's skin, else its top) and the roof's pitch. Its normal is then level. "crop" (Revit's crop region) shows only what stands in a rectangle of the plan, the view as wide as it and cut at its sides: the house without the neighbourhood, its ground only round it; with heights ([[x, y, z], [x, y, z]]) only what lies in that box, cut at its top and bottom too: a detail at 1:20 (the eaves, a sill) from the same model. For plans to hand out prefer "sheet": a copy at "place" stays as it was when the model changes.

JSON-Form: section {"point": [x, y, z] (on the cutting plane), "normal": [x, y, z] (square to it), "place": [x, y, z] (where the flat section goes), "hatch": "lines" (one pattern for all, or "none"; default: each cut's material's), "beyond": true (also what one sees beyond the cut), "ids": [id, ...] (default: all solids) | "sheet": "Schnitte" instead of "place" (on that sheet, following the model), "nextSheet": true (a full sheet hands it on to "Schnitte 2", ...), "scale": 100, "levels": true, "notes": true, "crop": [[x, y], [x, y]] (only what stands in this rectangle of the plan; [[x, y, z], [x, y, z]] a box, for a detail)}

Cuts the 3D view open, as Revit's section box: what lies outside a box round objects, round a storey (from half a meter below its floor up to "cut" above it) or between two corners is hidden; or single planes hide what lies on the side their normal points to (a section through the building). Only the view changes, not the drawing: nothing to undo; {"off": true} shows everything again. Issues keep the cut in their viewpoints (BCF clipping planes).

JSON-Form: sectionbox {} (what cuts the view) | {"ids": [...] (default: the selection), "margin": 0.3} | {"level": "EG", "cut": 1.5} (a storey, cut that high above it) | {"min": [x, y, z], "max": [x, y, z]} | {"planes": [{"point": [x, y, z], "normal": [x, y, z] (towards what is hidden)}, ...]} (up to 6) | {"off": true}

Hollows a solid to walls of a thickness, inwards, as SOLIDEDIT Shell does: with faces taken away it becomes a tray, a tube, a basin or a room's shell; without, a closed hollow body. Give a point inside each face to take away, not on an edge (the middle of a box's top is ((minX+maxX)/2, (minY+maxY)/2, maxZ) from get_drawing's min and max), or click on the face.

JSON-Form: shell {"id": solid, "thickness": t, "open": [[x, y, z], ...] (a point on each face to take away)}

Cuts solids with a plane, as AutoCAD's SLICE: both pieces stay as solids of their own (or only the one the normal points to, front, or the other, back). To open up a model, split a slab where it changes, or take the top off. Solids the plane misses stay as they are.

JSON-Form: slice {"ids": [id, ...] (default: the selection), "point": [x, y, z] (on the plane), "normal": [x, y, z] (square to it), "keep": "both"|"front"|"back"}

Creates a sphere from its center and radius.

JSON-Form: sphere {"center": [x, y, z], "radius": r}

Cuts the 'ids' solids away from the 'from' solid, or regions from a region. The result is one new solid or region (new id); all inputs disappear. Use it for openings: windows, doors, holes.

JSON-Form: subtract {"from": id, "ids": [id, ...]} (default: the first selected solid minus the others)

Carries closed outlines along a path (line, polyline, circle or arc) into solids: handrails, pipes, mouldings, curved beams. Draw the profile flat anywhere, e.g. a circle at the origin; it is moved to the path's start and turned square to it. The outlines become the solids; the path stays.

JSON-Form: sweep {"ids": [id, ...] (default: the selection), "path": id}

Creates a ring lying flat around its center: radius to the middle of the tube, and the tube's own radius (smaller).

JSON-Form: torus {"center": [x, y, z], "radius": r (to the middle of the tube), "tube_radius": t}

Sets the work plane, as AutoCAD's UCS: clicks land on it and typed coordinates are its own (x,y along its axes from its origin), so outlines can be drawn on a wall, a roof or the side of a stage and then extruded or pushed. "face" lays it on a flat face of a solid (X along the horizontal), three points or axes set it freely, "rotate" turns it about one of its axes, "world" goes back. Named planes come back with one word ("save", "restore", "delete", "list"), as AutoCAD's named UCS. Saved with the drawing. Commands in their JSON form keep taking world coordinates; rectangle, polygon and circle take the plane's axes or normal to lie in it.

JSON-Form: ucs {} (says which it is) | {"world": true} | {"origin": [x, y, z]} (moves it) | {"origin", "xPoint", "yPoint"} (three points) | {"origin", "xAxis": [x, y, z], "yAxis": [x, y, z]} | {"origin", "normal": [x, y, z]} | {"face": {"id": solid, "point": [x, y, z]}} | {"rotate": {"axis": "x"|"y"|"z", "angle": degrees}} | {"save": "Wall north"} (with a plane given, that one) | {"restore": "Wall north"} | {"delete": "Wall north"} | {"list": true}

Joins two or more solids into one new solid (new id), or regions into one region; the inputs disappear.

JSON-Form: union {"ids": [id, ...] (at least 2 solids or regions; default: the selection)}

Creates a wedge: full height at the corner, sloping down to nothing at the end of its length along X, as wide as given along Y. For ramps, stage stairs and sloping ground. Negative sizes go the other way; rotate it for another direction.

JSON-Form: wedge {"corner": [x, y, z], "size": [length, width, height]}

Sets the scale the model shows texts and dimensions at that keep a size on paper (a paperHeight, given with text, mtext, dimensions, their styles or change): at 1:50 a text of 2.5 mm is 0.125 m high in a drawing in meters. Sheets show them at each viewport's own scale, so one text is 2.5 mm on a plan at 1:50 and on one at 1:100 - unlike AutoCAD there are no several sizes to manage. Exports to DWG take the size at this scale.

JSON-Form: annoscale {"scale": 50} (1:50; {} says which it is)

Works out an expression: numbers (a point for decimals), + - * / ^ and brackets, pi and e, and sqrt, abs, sin, cos, tan (degrees), asin, acos, atan, atan2, ln, log, exp, round, floor, ceil, min, max and hypot. At any prompt, "=" and an expression (without spaces) stands for its value: =2.75+0.2 as a height.

JSON-Form: cal x({: })x

Draws the axis between two lines, as AutoCAD's CENTERLINE: midway between parallel lines, on the bisector of lines at an angle, from their one ends to their other ends and a little past, in the Center linetype. It holds on to the two lines and follows them. For the axis of a road, a corridor, a tent, a truss. Straight segments of polylines work too: give a point on each.

JSON-Form: centerline {"ids": [first, second] (lines or polylines), "points": [[x, y], [x, y]] (on each, to pick a polyline's segment), "linetype": "Center" (default) or another, textHeight, dimstyle}

Marks the centers of circles and arcs, as AutoCAD's CENTERMARK: a cross on the center and lines across to a little past the circle, in the Center linetype. A mark holds on to its circle and follows it when it moves or changes size. For round tents, columns, trees, holes. How far the lines reach past the circle comes from the dimension style (extension beyond).

JSON-Form: centermark {"ids": [id, ...] (circles and arcs; default: the selection), "linetype": "Center" (default) or another, textHeight, dimstyle}

Dimensions the true distance between two points, parallel to them: slanted walls, diagonals.

JSON-Form: dimaligned {"start": [x, y, z], "end": [x, y, z], "position": [x, y, z], "textHeight": h, "decimals": 2, "separator": "." or ",", "text": "<> m"}

Dimensions an angle in degrees: between two lines (extended to meet if need be), of an arc, or from a vertex to a point on each leg. The arc goes through position and measures the angle on its side, so the same two lines give the angle or its supplement depending on where position lies.

JSON-Form: dimangular {"ids": [line, line], "position": [x, y, z]} or {"id": arc, "position"} or {"vertex": [x, y, z], "start": [x, y, z], "end": [x, y, z], "position"}; decimals (default 0), textHeight, separator, text

Dimensions the length along an arc, as AutoCAD's DIMARC: a dimension arc beside it, the value after an arc sign. Curved stands, round stages, bent paths. It follows the arc when that changes.

JSON-Form: dimarc {"id": arc or polyline, "point": [x, y, z] (near the arc of a polyline), "position": [x, y, z] (where the dimension arc goes; default just outside), textHeight, decimals, separator, dimstyle}

Dimensions measured from the same first point, each on a line a step further out: distances from one reference edge, e.g. stands along a festival area measured from its entrance.

JSON-Form: dimbaseline {"from": id (default: the newest linear dimension), "points": [[x, y, z], ...]}

A chain of dimensions on one line: each starts where the one before ends, like the openings along a wall. Each takes the look of the dimension it goes on from.

JSON-Form: dimcontinue {"from": id (default: the newest linear dimension), "points": [[x, y, z], ...]}

Dimensions the diameter of a circle or arc, shown as Ø and the value: columns, pipes, round tents. The line runs through the center towards the position.

JSON-Form: dimdiameter {"id": circle or arc, "position": [x, y, z]} or {"center": [x, y, z], "radius": r, "position": [x, y, z]}; "point", textHeight, decimals, separator, text as for dimradius

A jogged radius, as AutoCAD's DIMJOGGED: for a large radius whose center lies off the sheet (a long curved wall, a site boundary), the dimension line starts at a center shown nearer, jogs, and runs along the radius to the arc, the value R and the real radius. A radius dimension with "shownCenter" and "jog"; it goes to DWG as AutoCAD's jogged radius.

JSON-Form: dimjogged {"id": circle or arc, "position": [x, y, z] (where the line points), "shownCenter": [x, y, z], "jog": [x, y, z]} or {"center", "radius", ...}; textHeight, decimals, separator, text as for dimlinear

Dimensions the horizontal or vertical distance between two points: wall lengths, room widths, openings. The dimension line passes through position; the value is measured and stays right when the points move.

JSON-Form: dimlinear {"start": [x, y, z], "end": [x, y, z], "position": [x, y, z], "direction": "horizontal"|"vertical" (default: from the position), "textHeight": h, "decimals": 2, "separator": "." or ",", "text": "<> m"}

Writes a point's X or Y coordinate at the end of a leader, as AutoCAD's DIMORDINATE: a leader running up or down shows X, one running sideways Y, measured from the drawing's origin. For setting out posts, survey points and corners on a site. The value follows the point when its object moves.

JSON-Form: dimordinate {"point": [x, y, z] (the point measured), "leader": [x, y, z] (where the value goes: above or below shows X, beside it Y), "textHeight": h, "decimals": 2, "separator": "." or ",", "dimstyle": "Plan"}

Dimensions the radius of a circle or arc (or a polyline's arc), shown as R and the value: curved walls, round tables, stage edges. The line runs from the center towards the position; a position outside the circle puts the value outside.

JSON-Form: dimradius {"id": circle or arc, "position": [x, y, z]} or {"center": [x, y, z], "radius": r, "position": [x, y, z]}; "point": near the arc of a polyline; textHeight, decimals, separator, text as for dimlinear

Spaces parallel linear dimensions evenly from a base dimension, as AutoCAD's DIMSPACE: rows of dimension chains on a plan an equal step apart ("auto": twice the text height), or with 0 all on the base's line. The measured points stay.

JSON-Form: dimspace {"base": dimension, "ids": [dimension, ...], "spacing": d or "auto" (default: twice the text height; 0 lines them up)}

Dimension styles, as in AutoCAD: under a name, how dimension lines end (architectural ticks, filled arrows, dots or nothing), the sizes of those ends, the gap between a measured point and its extension line, how far extension lines reach past the dimension line and the gap to the value (all in text heights, so a style suits every scale), the text style of the value, an optional fixed text height, decimals and separator, a length factor (the value is what is measured times it, as DIMLFAC: 100 shows a detail drawn in meters in centimeters), whether the value sits above the line or in a gap of it (DIMTAD 0, usual in Italy and much of Europe) and whether it reads level whatever the line's direction, and lengths in feet and inches (DIMLUNIT: architectural 5'-6 1/2", in a drawing in meters with the factor to inches set for it), or as German building plans write them (din1356: below 1 m in centimeters, from 1 m in meters with two decimals, the millimeters raised: 88⁵, 1,76⁵, 2,01; what is measured times the length factor counts as meters). New dimensions take the current style; changing a style changes every dimension of it in one step. Standard: ticks, the built-in font, the value above the line.

JSON-Form: dimstyle {"name": "Plan", "ends": "tick"|"arrow"|"dot"|"none", "endSize": 1, "extensionOffset": 0.35, "extensionBeyond": 0.7, "textGap": 0.5 (sizes in text heights), "textStyle": "Beschriftung", "textHeight": 0 (0 = suits the drawing), "decimals": 2, "separator": "." or ",", "lengthFactor": 1, "lengthFormat": "decimal"|"architectural"|"engineering"|"fractional", "textPlacement": "above"|"inline", "textLevel": false, "extensionLines": "both"|"first"|"second"|"none", "din1356": true (88⁵, 1,76⁵), "current": true} (makes or changes it; its dimensions follow) | {"delete": name} | {} (lists)

An arrow pointing at something with a note beside it, as AutoCAD's MLEADER: materials, fixtures, notes on a plan. The line runs from the arrow through the bends to the last point, where the note sits beside a short level landing on the side away from the arrow. "arms" add more arrows to the same note (one note for several windows); "frame" puts the note in a circle (a balloon with a position number), a box or a hexagon. mleaderedit adds or takes away arms, mleaderalign lines notes up.

JSON-Form: leader {"points": [[x, y, z] (arrow), [x, y, z] (bends, any), [x, y, z] (note)], "text": "Fire exit" (\n for more lines), "arms": [[[x, y, z] (another arrow), ...bends], ...], "frame": "none"|"circle"|"box"|"hexagon", "textHeight": h}

Draws the plan's legend: a table with a small picture of each symbol (block), its name and how often it is placed, as one group. The pictures are copies, so quantities don't count them. "fields" adds a column for each field with the value the placements share (a lighting plan's key: mode, channels, weight, power); "totals" a row adding up the count and the numbers of all placements (the rig's weight and power); "having" keeps to the symbols with that field (ADDRESS: the fixtures).

JSON-Form: legend {"position": [x, y] (top left), "blocks": ["Bauzaun 3.5 m", ...] (default: every block placed), "having": "ADDRESS" (only symbols with this field: the fixtures), "fields": ["MODE", "CHANNELS", "WEIGHT", "POWER"] (columns of their values), "totals": true (a row adding them up), "height": text height, "language": "en"|"de"}

Lines the notes of leaders up, as AutoCAD's MLEADERALIGN: one above the other on the topmost one's landing (vertical), or side by side (horizontal); with a spacing, also that far apart. The arrows stay where they point.

JSON-Form: mleaderalign {"ids": [leader, ...] (default: the selection), "along": "vertical"|"horizontal" (default vertical), "spacing": d (optional)}

Adds arms to a leader, takes one away or frames its note, as AutoCAD's MLEADEREDIT: one note for several things ("Fenster F1" with an arrow to each window). Typed: click the leader, then the arrow of each new arm.

JSON-Form: mleaderedit {"id": leader, "add": [[[x, y, z] (arrow), ...bends], ...], "remove": n (an arm's number from 1; 0 the main line), "frame": "none"|"circle"|"box"|"hexagon"}

Places a block of text as one object: notes, legends, title blocks, descriptions. "\n" starts a new line; with a width, long lines wrap between words. The position is where the text hangs from: by default its top left corner (attach and align choose another), as AutoCAD's MTEXT. Height is the height of capitals. Formatted text, as MTEXT's: "runs" are pieces each with its own bold, italic, font, height (a factor on the text's), color, underline, overline, strike-through or a stacked fraction ("1/2"); or "codes" gives AutoCAD's MTEXT format codes (\P \H \C \f \L \S {}).

JSON-Form: mtext {"position": [x, y, z], "text": "Line 1\nLine 2" or "runs": [{"text": "Kitchen", "bold": true, "height": 1.4, "color": "#C00000", "underline": true}, {"text": " 12 m²"}] or "codes": "{\fArial|b1;Kitchen}\P12 m²" (AutoCAD's MTEXT codes), "width": w (0: no wrapping), "height": h, "rotation": degrees, "align": "left"|"center"|"right", "attach": "top"|"middle"|"bottom"|"baseline", "lineSpacing": 1, "style": "Beschriftung" (default: the current text style), "normal": [x, y, z] (default level)}

A north arrow at "position": a ring with the arrow and an N, pointing to true north where the drawing lies on the earth (its georeference, the meridian's convergence taken into account), else up the drawing, or where "north" says. Site plans must show it (Bavaria's Bauvorlagenverordnung § 7), floor plans do. In the model it is 15 mm across on paper, at the drawing's scale (annoscale) and on each sheet at its viewport's scale (unless given a "size"); on a sheet's paper (space) 15 mm, turned as the sheet shows the model (its viewport's twist). A block (Nordpfeil) on the current layer.

JSON-Form: northarrow {"position": [x, y, z], "size": across (default 15 mm on paper), "north": degrees counter-clockwise from up (default: true north from the georeference, else up)}

Dimensions objects in one go, as AutoCAD's QDIM: a chain over all their ends, corners and centers along X or Y, on a line through position (continuous), or every one from the first, stacked outwards (baseline). A row of booths, the posts of a fence, the axes of a hall. The dimensions hold on to the objects' points and follow them.

JSON-Form: qdim {"ids": [id, ...] (default: the selection), "position": [x, y, z] (where the dimension line goes), "direction": "horizontal"|"vertical" (default: from the position), "style": "continuous"|"baseline", textHeight, decimals, separator, dimstyle as for dimlinear}

Marks heights where they are, as plans write them: a floor's level in a floor plan (a triangle standing on the point, its height as +2,95 / ±0,00 / −0,20 from the project's zero), the ground's height on a site plan (a cross, with "terrain" the terrain's height under the point, above the datum when the drawing is georeferenced: 342,50; where the ground is graded, "existing" or "planned" says which, true takes the planned). Each mark is a block placed at its height whose value is a field ({=height}, {=height:abs}, with an offset {=height:-0.15}): moved up or down it shows its new height; attedit can type words over it. "floor": true marks the slab under the point with its finished floor's level (its top, OKFF) over its raw floor's (OKRF: less the finishes of its type, the layers above the first of concrete, masonry, timber or steel). On a sheet a mark in a section or elevation shows the height there, worked out from the view. 2.5 mm high on paper: in the model at the drawing's scale (annoscale), on each sheet at its viewport's scale, so one mark serves plans at 1:100 and 1:50.

JSON-Form: spotheight {"at": [x, y, z] | "points": [[x, y, z], ...] (each marked at its height), "terrain": true | "existing" | "planned" | id (the ground's height under each point instead; true the planned ground where there is one), "kind": "level"|"ground" (a triangle for floors, a cross for the ground; default ground on a terrain), "absolute": bool (above the georeference's datum, 342,50; default for the ground when the drawing has one), "floor": true (a slab's finished and raw floor levels, OKFF over OKRF)} (on a sheet: in a section or elevation, the height there)

Makes a table, as AutoCAD's TABLE: rows of cells in a ruled grid, one object. A title (optional) is its first row, one cell across; the next row heads the columns under a heavier line; columns are as wide as their longest text unless given, numbers line up on the right. Cells hold text, fields that stay current ({=area:ID} of a room or outline, {=length:ID}, {=count:Block}, {=date}) and formulas over other cells, as in a spreadsheet: =sum(C3:C9), =B3*C3, average, count, min, max, round, with cells named by column letter and row number from A1 at the top left (the title row is row 1). Change cells and rows with tableedit. For room lists, schedules, legends and quantities on a plan.

JSON-Form: table x({: [x, y, z] (top left corner), : [[, , ], [, , ], [, , ]], : , : bool (default true), : h, : [w or 0, ...], : [, , ], : deg, : })x

Changes a table (by "id", or the one selected), as AutoCAD's TABLEDIT and the table's row and column tools: cells by name (B3; text, a field or a formula =sum(C3:C9)); a range (D3:D9) fills each of its cells, formulas moved along as when copied ($C$3 stays); rows and columns inserted (they become row or column "at") or deleted, rows appended, column widths (0: as wide as the texts), alignment, text height, title and header row on or off. Rows and columns change first, then the cells, named as in the table that results. Formulas follow inserted and deleted rows as in a spreadsheet; a reference to a deleted cell shows ####. Gives what the changed cells show.

JSON-Form: tableedit x({: 12, : {: , : , : }, : {: 4, : 1, : [[...]]}, : {: 4, : 1}, : {: , : 1}, : {: }, : [[...]], : {: 30} or [w, ...], : {: }, : h, : bool, : bool, :  or [, ...], :  or })x

Writes a table to a CSV file for Excel, as AutoCAD's TABLEEXPORT: each cell as it shows, fields filled in and formulas worked out; with the separator ; numbers get a decimal comma, as Excel reads them there. table {"file": ...} makes a table from such a file.

JSON-Form: tableexport {"id": table (default: the one selected), "path": "Räume.csv", "separator": ";"|","|"\t" (default: as Excel expects in the language)}

Places one line of text lying flat in plan: room names, notes, titles. The position is on the baseline, at the start, middle or end as align says. Height is the height of capitals in drawing units (0.2 to 0.3 suits a house drawn in meters).

JSON-Form: text {"position": [x, y, z], "text": "Living 24.5 m²", "height": h (default: suits the drawing), "rotation": degrees, "align": "left"|"center"|"right", "style": "Beschriftung" (default: the current text style), "normal": [x, y, z] (default [0, 0, 1]: level; another stands it in that plane, reading along its horizontal at rotation 0)}

Text styles, as in AutoCAD: under a name, a font installed on the computer (Arial, Helvetica, ...) or the built-in single-stroke font, bold or italic, letters stretched (widthFactor 0.8: narrow) or slanted (oblique, degrees), and an optional fixed height. New texts take the current style; changing a style changes every text of it, also in blocks and their fields, in one step. Standard is the built-in font. "fonts" lists the installed fonts.

JSON-Form: textstyle {"name": "Beschriftung", "font": "Arial" ("" = built-in), "bold": false, "italic": false, "widthFactor": 1, "oblique": 0, "height": 0 (0 = each text its own), "paperHeight": 2.5 (mm on every sheet), "current": true} (makes or changes it; its texts follow) | {"delete": name} | {"fonts": true} (installed fonts) | {} (lists)

Adds a field (attribute) to a block, or changes the one with that tag, or removes one: every placement shows its own value as text, set with insert or attedit. The position is in block coordinates, from the block's base point. Existing placements get the default.

JSON-Form: attdef {"block": "Booth", "tag": "NUMBER", "prompt": "Booth number", "default": "", "position": [x, y, z] (block coordinates: the base point is 0,0,0), "height": h, "rotation": degrees, "align": "left"|"center"|"right", "invisible": bool} or {"block": "Booth", "remove": "NUMBER"}

Sets the values of block fields (attributes) on block references: a booth's number, an operator. Several references at once get the same values.

JSON-Form: attedit {"ids": [id, ...] (default: the selection), "values": {"TAG": "value", ...}}

Sets where other drawings that reference this one (xref) place it from, as AutoCAD's BASE: a bar drawn somewhere in its file lands with this point on the insertion point. Nothing in the drawing moves. DWG and DXF files bring theirs ($INSBASE); new drawings have the origin.

JSON-Form: base {"point": [x, y, z]} | {} (says where it is)

Finishes editing a block in place (see bedit): its objects, also those drawn meanwhile, become the block again and every placement changes; with save false the block stays as it was.

JSON-Form: bclose {"save": bool (default true; false drops the changes)}

Changes a block in place: its placement is taken apart into the block's objects, where it stands. Change, add or erase objects as usual, then bclose saves the block, and every placement changes with it; bclose {"save": false} drops the changes. Fields (attributes) stay as they are.

JSON-Form: bedit {"id": block reference (default: the selected one)}

Turns objects into a block: a named definition placed by references. The objects are replaced by one reference at the base point. Use it for anything that repeats (windows, doors, columns, posts): insert the block instead of copying. Reusing an existing name redefines that block, and every reference to it changes with it (keeping its fields unless "attributes" is given). "attributes" are fields each placement fills in, shown as text: booth numbers, operators; insert and attedit set their values. "parameters" and "states" make it a dynamic block (see bparameter): lengths that stretch it, a flip, and visibility states listing which of the objects show in each (the first is the default; objects in none show in all).

JSON-Form: block {"name": "Window", "ids": [id, ...] (default: the selection), "base": [x, y, z] (default: lower left corner), "attributes": [{"tag": "NUMBER", "prompt": "Booth number", "default": "", "position": [x, y, z], "height": h}, ...], "parameters": [see bparameter], "states": [{"name": "Open", "ids": [...]}, {"name": "Closed", "ids": [...]}], "visibility": "Look"}

Sets a dynamic block's parameters on placements, as AutoCAD's grips and Properties palette: a length or an angle in degrees (one of the offered values, or within its range), flipped or not, a visibility state. Each placement shows its block so; the others stay.

JSON-Form: blockparams {"ids": [id, ...] (default: the selection), "values": {"Width": 1.01, "Flip": true, "Look": "Closed"}}

Makes a block dynamic, as AutoCAD's BPARAMETER in the block editor: a length that stretches it (the points of its objects inside "frame" move along "direction" by the length minus the "standard" one, as STRETCH moves them; "values" offers a list, as a door's widths; "repeat" objects get copies every "spacing" as it grows, as AutoCAD's array action), a flip (mirrored across the axis through "base" along "direction": a door's swing), a rotation (the objects inside "frame" or listed in "rotate" turn about "base" by the angle minus the "standard" one: a window's sash, a swivel chair, a barrier arm) and visibility states ("states" says which objects, by number in the block from 0, show in which state; the others show in all). Points are in the drawing coordinates of the placement given as "id" (or of the block, by name). Every placement keeps its values; set them with blockparams or its grips.

JSON-Form: bparameter {"id": placement or "block": "Door", "parameters": [{"name": "Width", "kind": "length", "base": [x, y, z], "direction": [1, 0, 0], "standard": 0.885, "values": [0.76, 0.885, 1.01], "frame": [[x, y], ...]}, {"name": "Flip", "kind": "flip", "base": [x, y, z], "direction": [0, 1, 0]}, {"name": "Open", "kind": "rotation", "base": [x, y, z], "values": [0, 45, 90], "frame": [[x, y], ...]}, {"name": "Look", "kind": "visibility", "states": ["Open", "Closed"]}], "states": {"Open": [0, 1], "Closed": [0, 2]}, "remove": "Width"}

Places a parametric component (see componentdef): its type's values, or its defaults, with "values" changing any of them. The same values place the same block again; others build a block of their own. With "ids", changes those placements' values or type (blocks no placement uses any more go), or without values tells what they are. Typed: the name, then points; T for a type, R for the rotation.

JSON-Form: component {"name": "Shelf", "type": "Shelf 80", "values": {"shelves": 5}, "position": [x, y, z], "rotation": deg} | {"ids": [id, ...], "values": {...}, "type": "..."} (change placements) | {"ids": [id, ...]} (their values) | {} (list)

Defines a parametric component, as Revit's families and Archicad's objects: parameters (length, number, integer, angle, boolean, choice, text; with defaults, limits, and formulas worked out from the others), types (named sets of values) and a recipe: the drawing's own commands that build it, in drawing units with the base point at the origin. In a step's params "=formula" is a value worked out from the parameters (+ - * / ^, min, max, round, if(c, a, b), comparisons; a choice's or text's name alone gives its text), "@name" the ids an earlier step with "as": "name" made ("@name.1" the first). "repeat" runs a step several times, i counting from 0; "if" leaves it out; "color" colors what it made. Recipes may draw and model (line, pline, box, cylinder, extrude, revolve, union, subtract, move, copy, rotate, arrayrect, filletedge, text, hatch, change, ...), nothing else. The definition is built with its defaults and as each type before it is kept; redefining builds every placed block anew from the values it had. Category (generic, furniture, sanitary, heater, lighting, equipment, column, beam, member, railing, covering, window, door) says what schedules and IFC call it. A window or door fills a wall's opening (window or door with "component"): it needs length parameters "width" and "height", which the opening sets, and may have "wall", set to the wall's thickness; it is built from 0 to its width along x, from 0 up (the sill), centred on y = 0 across the wall, and follows the opening and the wall as they change. {"name"} alone gives the definition to read and change; {} lists them.

JSON-Form: componentdef {"name": "Washbasin", "category": "sanitary", "from": [ids] (objects become its body) | {"name": "Shelf", "category": "furniture", "description": "...", "parameters": [{"name": "width", "label": "Breite", "kind": "length", "default": 0.8, "minimum": 0.4, "maximum": 2.4}, {"name": "shelves", "kind": "integer", "default": 4}, {"name": "inner", "formula": "width - 2*0.019"}], "types": [{"name": "Shelf 80", "values": {"width": 0.8}}], "recipe": [{"command": "box", "params": {"corner": [0, 0, 0], "size": [0.019, "=depth", "=height"]}}, {"command": "box", "params": {"corner": [0.019, 0, "=i*height/shelves"], "size": ["=inner", "=depth", 0.019]}, "repeat": "=shelves + 1"}]} | {"name": "Shelf"} (the definition) | {"name": "Shelf", "delete": true} | {} (list)

Takes objects apart to edit their pieces: block references into copies of their objects, one level deep (to change every reference instead, explode one, edit it and create the block again under the same name); polylines into lines and arcs; dimensions into lines and a text.

JSON-Form: explode {"ids": [id, ...]} (default: the selection)

Places a picture (PNG, JPEG, TIFF, GIF, BMP, WebP) in the drawing to trace over, such as a scanned plan. The pixels stay in the file, which the drawing refers to like AutoCAD's attached images; scale it to its real size with two known points.

JSON-Form: image {"path": "scan.png", "corner": [x, y, z] (default [0, 0, 0]), "width": w (default: 1 per 100 pixels; the height follows the picture), "rotation": degrees, "fade": 0-90}

Places references to a block: the block is stored once, however often it is placed. Rotation turns about the Z axis, counter-clockwise. "attributes" fills the block's fields (the others get their defaults); "parameters" sets a dynamic block's lengths, flip and visibility state. An external reference's block drawn in other units is scaled by their ratio too, as when it was attached.

JSON-Form: insert {"block": "Window", "position": [x, y, z] or "positions": [[x, y, z], ...], "rotation": degrees (default 0), "scale": factor (default 1), "attributes": {"TAG": "value", ...}, "parameters": {"Width": 1.01, "Flip": true}}

Places single points, such as survey points or stakes, to snap to (Node snap). They show as small marks of the same size at any zoom: crosses, dots (as most drawings from AutoCAD have them) or not at all, set with "display" on its own.

JSON-Form: point {"points": [[x, y, z], ...]} | {"display": "cross"|"dot"|"none"} (how all points show)

Removes block definitions that nothing in the drawing uses.

Clips block references and external references, as AutoCAD's XCLIP: only what lies inside the boundary shows, in the view, on sheets, in snapping and in exports; lines and curves are cut at its edge, texts, hatches and other objects show where their insertion point or middle lies inside. The boundary belongs to the reference and moves and turns with it; nothing of the block is lost, "remove" shows all of it again. For a site plan or a neighbour's drawing referenced in, cut to the part that matters.

JSON-Form: xclip {"ids": [block references] (default: the selection), "corner": [x, y], "opposite": [x, y] (a rectangle) | "points": [[x, y], ...] (a polygon) | "remove": true (all of the block again)}

Removes an external reference: all its placements, its definition and its layers.

JSON-Form: xdetach {"name": "Sofa"}

Places another drawing file as an external reference: a block whose objects come from that file, so a team can draw parts (a sofa, a window, a site plan) in their own files and assemble them in one plan. An IFC file brings another discipline's model (the structural engineer's, the services'): its elements as solids, on layers by presentation layer or class, in this drawing's units, to look at and check against (interference), not to edit. A file drawn in other units comes in scaled by their ratio (a part in millimeters at a thousandth in a plan in meters), as AutoCAD attaches it. Its layers come along as "Name|Layer"; references it places itself (a bar's cups) come along as references of this drawing under their own name, read once however many place them. Attaching the same file again adds references to it; xreload brings in its latest version, and the app reloads a reference by itself when its file changes (unless it is held, see xrefs).

JSON-Form: xref {"path": "Sofa.frame", "plan.dwg", "plan.dxf" or "Tragwerk.ifc", "name": "Sofa" (default: the file name), "position": [x, y, z] (default origin) or "positions": [...], "rotation": degrees, "scale": factor}

Lists the external references and whether the drawing shows their file's latest: up to date, loaded anew since opening (its file had changed), older than their file (held, or not loaded yet) or without file (the drawing shows the copy it saved, with the date of that version). "hold": true keeps references at the copies shown, for a plan that was approved or invoiced: opening and reloading leave them, whatever happens to their files; a reference is held with those placed inside it (a bar with its cups; shared ones for all that place them). "hold": false lets them follow their files again and loads what changed meanwhile, in the same step. "path" points the reference "name" at another file (moved, renamed, or converted), "extension" each reference whose file has one of that kind beside it (a library's DWGs saved as .frame; with "name", it and those inside it); they are loaded from there in the same step, keeping their placements, layers and name. A held reference keeps its copy until it is let go.

JSON-Form: xrefs {} (lists them with their state) | {"name": "Bar"} (just that one) | {"hold": true} (all held) | {"name": "Bar", "hold": true} (it and the references inside it) | "hold": false (follow their files again) | {"name": "Bar", "path": "Bar.frame"} (points it at another file) | {"extension": ".frame"} (each at the file of that kind beside its own)

Loads the files of external references again, so the drawing shows what others changed in them. Opening a drawing does this by itself.

JSON-Form: xreload {"name": "Sofa"} (default: all external references)

Changes properties of objects: moves them to another layer and/or gives them their own color, linetype or lineweight ("ByLayer" makes them take their layer's again; prefer layers over own properties) or a linetype scale of their own (times the drawing's ltscale). For texts and dimensions also the text height, the text (for a dimension: what it shows instead of the value, "" for the value again), a size on paper (paperHeight, mm, the same on every sheet), a text's style (its font and look, see textstyle), and a dimension's decimals and decimal separator; for images how far they fade into the background. Other objects in the selection keep those. Geometry as in AutoCAD's Properties palette: a line's start and end, the center and radius of circles and arcs (and an arc's angles), where texts, points and blocks sit, how texts and blocks are turned, a block's scale, whether a polyline is closed; a point whole or only some axes ({"x": 5} keeps y and z). Dimensions on the objects follow.

JSON-Form: change {"ids": [id, ...] (default: the selection), "layer": "Walls", "color": "#FF0000" or "ByLayer", "linetype": "Dashed" or "ByLayer", "lineweight": 0.35 (mm) or "ByLayer", "linetypeScale": 2, "height": h, "text": "...", "decimals": 2, "separator": "." or ",", "fade": 0-90, "width": w (texts: wrapping; polylines: band), "mask": true (texts: background mask), "style": "Beschriftung" (texts: a text style), "dimstyle": "Plan" (dimensions: a dimension style); geometry: "start", "end" (lines), "center" (circles, arcs, ellipses), "position" (texts, points, blocks) as [x, y, z] or {"x": 5}, "radius", "startAngle", "endAngle" (arcs), "rotation" (texts, blocks), "scale" (blocks), "closed" (polylines), "material": "KVH C24" (framing members)}

Deletes an empty layer. Layers that still hold objects, layer 0 and the current layer stay.

JSON-Form: deletelayer {"name": "Old layer"} (only empty layers; never layer 0 or the current one)

Finds text in texts, paragraphs, leader notes, dimension texts and block field values and selects the objects; with "replace" also replaces every occurrence (one undo step). Ignores case unless matchCase; wholeWords finds "WC" but not "WCs". Text inside blocks is counted but not changed.

JSON-Form: find {"text": "WC", "replace": "Toilets" (optional), "matchCase": bool (default false), "wholeWords": bool (default false), "ids": [id, ...] (default: the whole drawing)}

Groups objects under a name so that clicking one picks all of them, e.g. a stand of tent, counter and sign; unlike a block they stay single objects that can be changed one by one.

JSON-Form: group {"ids": [id, ...] (default: the selection), "name": "Stand 12"}

Hides these objects for a while (not drawn, picked or snapped to; plots, exports and takeoffs keep them) until unisolateobjects: to get at what lies behind them. Not a change to the drawing: not saved, not undone.

JSON-Form: hideobjects {"ids": [id, ...] (default: the selection)}

Shows only these objects for a while: all others are hidden (not drawn, picked or snapped to; plots, exports and takeoffs keep them) until unisolateobjects. A way of looking at a dense plan, not a change to it: not saved, not undone.

JSON-Form: isolateobjects {"ids": [id, ...] (default: the selection)}

Deletes layers with everything on them, as AutoCAD's LAYDEL: their objects in the drawing, on sheets and inside blocks go, then the layers (never layer 0; the current one hands over to 0). One undo step brings it all back.

JSON-Form: laydel {"layers": ["Hilfslinien", ...] (or one name)}

Creates a layer or changes one: color, linetype (see linetype), lineweight in millimeters (walls cut in plan 0.5, outlines 0.35, furniture 0.18), visible, off (hidden as AutoCAD's off: block references on it still show their parts on other layers; visible: false hides them whole, as freezing does), locked, transparency in percent (glass about 60), newName to rename. scales: the layer shows only at those scales, [from, to] as the N of 1:N - on a sheet at its viewport's scale, in the model at the drawing's (annoscale) - so one model carries dimensions for 1:50 on one layer ([1, 50]) and for 1:100 on another ([51, 1000]), each plan showing its own. current: true makes it the current layer: every new object goes on the current layer and shows in its color. Organise a model by layers such as Walls, Doors, Windows, Glass, Furniture, each with its own color, and make the right one current before drawing. A new layer without a color gets an unused one.

JSON-Form: layer {"name": "Walls", "color": "#B0B0B0" or "red" or 1-255, "linetype": "Dashed", "lineweight": 0.5 (mm) or "Default", "visible": bool, "off": bool, "locked": bool, "transparency": 0-90, "scales": [1, 50] (shown at 1:1 to 1:50 only; null: every scale), "current": bool, "newName": "..."} (creates the layer if it is new; only the given properties change)

Saves which layers show and which are locked under a name, and restores it at once: one drawing, several plans (escape routes, power, set-up). Give a sheet a layer state (layout with "layerState") and it plots with it, whatever shows at the moment. Layers made later stay as they are on restore.

JSON-Form: layerstate {"save": "Power", "layers": ["Power", "Site", ...] (optional: only these show)} | {"restore": "Power"} | {"delete": "Power"} | {} (list them)

Hides every layer except those the given objects lie on, to work in a full plan on one trade; layuniso shows the hidden ones again.

JSON-Form: layiso {"ids": [id, ...] (default: the selection)}

Locks the layers the given objects lie on: they stay visible but can't be changed or selected.

JSON-Form: laylck {"ids": [id, ...]}

Moves objects onto the layer another object lies on (or a layer by name).

JSON-Form: laymch {"ids": [id, ...] (default: the selection), "like": object on the layer to move to} or "layer": name

Makes the layer the object lies on the current one, so what is drawn next goes there too.

JSON-Form: laymcur {"id": object}

Merges layers into one, as AutoCAD's LAYMRG: every object on them, in the drawing, on sheets and inside blocks, moves to the target layer, and the merged layers go (layer 0 stays). For tidying plans from others whose layers name the same thing differently.

JSON-Form: laymrg {"layers": ["A-WAND", "Wände alt"] (or one name), "into": "Wände" (made if new)}

Hides the layers the given objects lie on: click what is in the way, and its whole layer goes.

JSON-Form: layoff {"ids": [id, ...]}

Shows every hidden layer.

Unlocks the layers the given objects lie on.

JSON-Form: layulk {"ids": [id, ...]}

Shows the layers the last layiso hid again.

Lists the linetypes the drawing knows (Continuous, Dashed, Hidden, Center, Phantom, DashDot, Dot and its own), or defines one: dashes as lengths in drawing units, positive for a dash, negative for a gap, 0 for a dot, repeated along lines. Layers and objects take a linetype with layer and change; ltscale makes all dashes longer or shorter.

JSON-Form: linetype {} lists the linetypes; {"name": "Fence", "dashes": [0.5, -0.2, 0, -0.2], "description": "..."} defines one

Scales the dashes and gaps of every linetype in the drawing: 2 makes them twice as long. The standard linetypes suit drawings in meters at 1; a drawing in millimeters needs about 1000.

JSON-Form: ltscale {"scale": 0.5}

Gives objects a name, such as "Towel radiator" or "Stage left". Every command that takes ids then takes the name instead, for all objects that carry it: name the parts of one thing alike and move, copy or erase them by name. A group's name works the same way. Names are labels, not unique; an empty name takes it away.

JSON-Form: name {"ids": [id, ...] (default: the selection), "name": "Towel radiator" ("" takes it away)}

Shows the model's building parts alone for a while, its solids (walls, slabs, roofs, stairs, terrain, pipes): the lines, texts, tables, hatches and dimensions in the model are hidden (not drawn, picked or snapped to), also those inside blocks, as Revit's 3D views leave annotations out. Sheets show everything, and plots, exports and takeoffs keep it all. A way of looking, not a change to the drawing: not saved, not undone.

JSON-Form: partsonly {"on": true | false} ({} switches it)

Selects objects, so they are highlighted for the user and Move, Erase and the booleans act on them. Select what you created or changed when it helps the user find it. "all" selects everything that can be selected; "similar" everything of the same kind on the same layer as an object (for blocks: references to the same block), as AutoCAD's SELECTSIMILAR. "layers", "types" and "blocks" select everything on those layers, of those types, placing those blocks (each given narrows it), as AutoCAD's QSELECT: all toilets, everything on Fences.

JSON-Form: select {"ids": [id, ...]} (an empty list clears the selection), {"all": true}, {"similar": id} or {"layers": [name, ...], "types": [type, ...], "blocks": [name, ...]}; "add": true adds to the selection

An office's drawing templates, as AutoCAD's .dwt files: layers with their colors, linetypes and line weights, text, dimension and plot styles, wall, floor and roof types, materials, sheets with the title block. new {"template"} starts a drawing from one; "apply" brings a template's layers and styles into this drawing (a layer standard: layers it has take the template's color, linetype, lineweight and transparency, the others come; what shows or is locked stays); "save" keeps this drawing as a template. Templates come from one's own folder and from packs (a Templates or Vorlagen folder in a linked library folder); any drawing serves, also a DWG.

JSON-Form: template {} (lists them) | {"apply": "Büro" (a template's name or file), "only": ["layers", "linetypes", "textstyles", "dimstyles", "plotstyles", "types", "materials"]} (its layers and styles into this drawing) | {"save": "Büro A3", "replace": false} (keeps this drawing as a template)

Takes groups apart: the one named, or those the objects belong to. The objects stay.

JSON-Form: ungroup {"name": "Stand 12"} or {"ids": [id, ...]} (default: the selection's groups)

Shows again every object that isolateobjects or hideobjects hid.

Views saved by name in the drawing, as AutoCAD's VIEW: save how the view looks now ("Stage", "Entrance"), and come back to it later in one step. restore turns the user's view there; it changes nothing in the drawing. Without anything, lists the views. A view saved by numbers looks from yaw (degrees counter-clockwise from +X, the direction it looks from) and pitch (above the horizon, 90 straight down) at the target from distance.

JSON-Form: view {"save": "Stage"} (as the view is now, or with "target": [x, y, z], "yaw", "pitch" in degrees and "distance") or {"restore": "Stage"} or {"delete": "Stage"}; {} lists them

Which of the app's workspaces this drawing opens in, as AutoCAD's WSCURRENT: "building" adds the building tab (walls, floors, roofs, stairs, rooms, levels, conversions, plans to models, terrain), "civil" the earthworks tab (survey points, terrain, building pits, trenches, earthwork and demolition quantities, setting out), "services" the building services' tab (distribution boards, circuits, cables), "drafting" keeps to drawing, modelling and annotating. A workspace only decides which tabs the app shows; every command works in all of them and the drawing stays as it is. The drawing remembers it ("none" forgets it: the app then shows the one it used last). Without parameters: which one, and the workspaces there are.

JSON-Form: workspace {"name": "building"|"civil"|"services"|"drafting"|"none"} | {} (which one)

Measures the area and perimeter of an outline given by its corners, of closed outlines, or of the areas around points inside them, bounded by whatever lines, arcs and outlines close them (islands left out). Several are added up. For floor areas, plots, and the capacity of a field (area times people per square meter). Changes nothing.

JSON-Form: area {"points": [[x, y, z], ...] (corners of an outline)} or {"ids": [id, ...] (closed polylines, rectangles, polygons, circles, ellipses; added up)} or {"inside": [[x, y, z], ...] (points inside areas bounded by any lines; added up)}

Writes the size of areas into the drawing, in square meters, where it is clicked: an area bounded by any lines (as hatch finds it). What stands inside it (a stage, a bar, blocks) is left out: the net area, with the gross beside it. With density (persons per square meter, 2 for a standing audience) also how many people fit on the net area. For rooms, fields, audience areas; German writes 1.535,00 m².

JSON-Form: arealabel {"points": [[x, y, z], ...] (inside the areas; the labels go there), "density": persons per m² (optional), "text": "Audience" (optional first line), "height": h, "language": "en"|"de"}

Measures the distance between two points, with its X, Y and Z parts and the angle in plan. Changes nothing.

JSON-Form: dist {"from": [x, y, z], "to": [x, y, z]}

How far an area (an audience area, a field) lies from its emergency exits, as the crow flies: the farthest point and its distance to the nearest exit, and with a limit the share of the area beyond it. With "walls" the way is walked: round the walls, columns and other solids standing across a height over the floor (1 m: doors open, windows not), through their doors, on a grid of 10 cm, as a building's escape routes are measured (35 m to a stair or out, a storey's floor as the area); parts no way leads out of (shafts) are named. A help for planning escape routes, not a building-code check.

JSON-Form: escapedistance {"area": id (closed polyline, circle or hatch), "exits": [id, ...] (blocks, points, lines: gates) and/or "points": [[x, y], ...], "limit": 30 (meters, optional), "walls": true | {"height": 1.0, "cell": 0.1} (walk round walls and through doors), "mark": bool (draw the longest way)}

How long an area takes to empty and to fill: each exit takes the people nearest to it (as the crow flies); they are out when the farthest has walked there or, where the exit is the narrower part, when all have passed it at the rate a crowd goes through a meter of width, whichever is longer, after "delay" minutes. Rates as the UK Green Guide's (82 persons per meter and minute on the level, 66 on steps), 8 minutes as the time aimed at, walking 1 m/s; each can be given. "entry" gives the lanes checking people in and how many each takes an hour (300 if not given, a rule of thumb): how long all take to come in, and how many lanes bring them in within "window" minutes. A help for planning, not the authority's check.

JSON-Form: evacuation {"area": id, "exits": [ids] (gates as lines: their length is the clear width; signs or points with a field BREITE), "persons": 2400 | "density": 2 | "block": "Stuhl", "each": 1, "width": 2.4 (m, for signs without one), "rate": 82 (persons per m of width and minute), "stairs": [exit ids on steps], "stairRate": 66, "speed": 1.0 (m/s walking), "delay": 0 (minutes before moving), "target": 8 (minutes), "entry": {"lanes": 12, "perHour": 300, "window": 60}, "mark": true (each exit's persons and minutes, green, amber or red), "select": true (the exits too slow), "language": "en"|"de"}

Checks whether the exits of an area are wide enough for its people, as the building codes size escape routes (MVStättV § 7 (4)): 1.20 m per 200 persons, outdoors and in stadiums per 600, in steps of 0.60 m, at least 1.20 m (0.90 m for up to 200 places indoors); any value can be given where a Land says otherwise. The persons are given, come from a density on the area's net area (holes left out) or are the seats placed in it. Each point of the area goes to its nearest exit as the crow flies, which gives each exit its share and the width that share needs. A help for planning, not the authority's check.

JSON-Form: exitwidth {"area": id (closed polyline, circle or hatch), "exits": [ids] (gates as lines: their length is the clear width; signs or points with a field BREITE), "persons": 2400 | "density": 2 (persons per m²) | "block": "Stuhl", "each": 1 (the seats in the area), "outdoors": false, "width": 2.4 (m, for signs without a width), "rules": {"perWidth": 200, "outdoorPerWidth": 600, "step": 0.6, "minimum": 1.2, "smallMinimum": 0.9, "smallLimit": 200}, "mark": true (each exit's persons, width needed and width beside it, green, amber or red), "select": true (the exits too narrow), "language": "en"|"de"}

Fills an area with a block in rows: beer tent sets in a tent, chairs in front of a stage, tables for a banquet, booths on a field. Only places that fit wholly inside (and the margin from the edge) get one; aisles after every n. With "center" the rows are curved, circles round it (a stage's middle), each place turned with its y to the center, the first row where the area begins or at "radius", "angle" where the places start. One step; the count is in the answer.

JSON-Form: fillarea {"area": id, "block": "Bierzeltgarnitur", "spacing": [along a row, between rows] (default: the block's size), "angle": degrees of the rows, "margin": distance from the edge, "aisle": width, "every": n (an aisle after every n in a row), "center": [x, y] (curved rows round it), "radius": the first curved row's}

Measures the shortest distance between two objects or sets of objects (a name stands for all its parts), solids exactly: the gap between a radiator and a door leaf, a stage and a fence, a pipe and a wall. Returns the distance and the two closest points; touching or overlapping gives 0, a solid inside another says so. Use it to check clearances instead of estimating them from coordinates.

JSON-Form: gap {"from": [id or name, ...], "to": [id or name, ...]}

Measures straight up and down from a point to the nearest faces of solids: the clear height from floor to ceiling there, under a sloping roof, a beam or a stage roof. Returns the distance above, the distance below, which objects they reach, and their sum as the clear height. Give a point in the open, such as a little above the floor.

JSON-Form: headroom {"at": [x, y, z]} (a point in the open, e.g. just above a floor)

Shows the coordinates of a point; clicked with object snap, the exact coordinates of a corner, a center or an intersection.

JSON-Form: id {"point": [x, y, z]}

Finds solids that overlap, including those inside block references: furniture standing in a wall, a beam through a window, parts placed twice. Faces that only touch don't count, nor the terrain (buildings stand in it). Returns each overlapping pair with the overlap's volume and extents, and selects them. Use it to check a model after building or moving things.

JSON-Form: interference {"ids": [id, ...] (default: all solids; given ids are checked against everything)

Lists what the objects are: type, layer, name, color, the points and sizes that fix them, and the length and enclosed area where they have one.

JSON-Form: list {"ids": [id, ...] (default: the selection)}

A quantity takeoff: how many placements of each block (also inside other blocks: a row of five toilets counts five toilets), and per layer how many objects, the total length of lines, polylines, arcs and circles (meters of fence, cable, kerb), the hatched area and the volume of solids. With place, writes the list into the drawing as text. Use it to count and price a plan instead of counting by eye.

JSON-Form: quantities {"ids": [id, ...] (default: everything shown), "layers": ["Fence", ...] (only these), "by": "OPERATOR" (count blocks apart by this field's value), "place": [x, y, z] (write the list into the drawing there), "perLayer": bool (default true: the list has the layer totals too), "as": "text"|"table", "language": "en"|"de" (of the list)}

Turns a door leaf (or a window sash, a gate, a cabinet door) about its hinge degree by degree and reports whether it swings freely through the angle, or which objects it hits and how far it opens before. Give the leaf's solids (ids or its name), a point on the hinge axis and the opening angle, positive counter-clockwise seen from above. Objects the closed door already stands in, such as its frame, are left out. Selects what it hits.

JSON-Form: swing {"ids": [door leaf, ...] (ids or a name; default: the selection), "hinge": [x, y, z], "angle": degrees (counter-clockwise seen from above), "axis": [x, y, z] (default [0, 0, 1])}

Plan sheets along an alignment (Blattschnitt): the alignment cut into pieces as long as a sheet holds at the scale (shorter in curves, so it stays inside), each on a sheet of its own with the drawing turned so its piece runs along the paper, the pieces overlapping by "overlap"; match lines across the axis in the drawing, each side naming the sheet it goes on to. With "longsection" (the ids the longsection command gave for this alignment, drawn at the same scale) each sheet shows the long section for the same stations under the plan: the Lage- und Höhenplan. Title blocks with the stations and sheet numbers. Run again, it replaces its sheets and lines. One undo step.

JSON-Form: alignmentsheets {"ids": [an alignment] (default the selection), "paper": "A1" (A0 to A4), "orientation": "landscape"|"portrait", "scale": 500, "from": 0, "to": 800 (stations, m), "overlap": 10 (m the sheets overlap), "longsection": [the ids of the alignment's long section] (shown under the plan for the same stations: Lage- und Höhenplan), "longScale": 500 (the scale it was drawn at; default the plan's), "name": "Lageplan Achse 1" (the sheets' names, numbered), "project": "...", "drawnBy": "...", "date": "...", "lines": true (match lines in the drawing), "layerState": "Lageplan" (the plan's layers), "renovation": "final" (its stage of a conversion), "language": "de"}

Reads field values from a table (CSV from Excel, as attout writes it) into the block references named in its Id column, as one step to undo. Cells with <> and fields a block hasn't are left alone.

JSON-Form: attin {"path": "booths.csv"} (a table as attout writes it: a column "Id", a column per field)

Writes the fields of block references as a table for Excel: a row per reference with its id, block, layer and position, a column per field. Change the values there and read them back with attin.

JSON-Form: attout {"path": "booths.csv", "ids": [id, ...] (default: every block with fields), "separator": ";" | "," | "\t" (default: as Excel in the language of the interface)}

Copies objects, with the blocks they place and their layers, to paste them into this or another drawing.

JSON-Form: copyclip {"ids": [id, ...] (default: the selection)}

Copies objects to paste them elsewhere, and erases them here.

JSON-Form: cutclip {"ids": [id, ...] (default: the selection)}

Deletes a sheet; the drawing stays as it is.

JSON-Form: deletelayout {"name": "Site plan"}

JSON-Form: export {"path": "plan.dwg", "plan.dxf", "plan.svg", "plan.pdf", "model.step", "model.ifc", "model.glb", "model.gltf", "rig.mvr", "abbund.btlx", "gelaende.xml", "netz.geojson", "netz.gpkg", "netz.shp", "abgabe" with "format": "gisnb" (a folder; "phase": 1|2|3|4, "company": who builds, for the address layer after the award) or "issues.bcf", "format": "isybau" (an .xml as ISYBAU, with "version": "2017"|"2024", "status": "built"|"planned"), "crs": "map" (GeoJSON in the drawing's own system instead of WGS 84), "profile": {...} or "erfurt.json" (DWG/DXF as an operator's GIS asks it, see below)} (DWG/DXF in AutoCAD 2018 format, IFC4 for BIM programs (networks too: pipes and cables as segments with their ports joined, systems, circuits), glTF for renderers (Twinmotion, Enscape, D5, Blender), MVR 1.6 for lighting programs (Vectorworks Spotlight, grandMA3, Capture): fixtures with their GDTF types and DMX addresses, the rest as 3D scene objects, BTLx for joinery machines: the framing members with their cuts, notches, tenons and mortises; LandXML 1.2 the terrains as triangle networks (TIN) and the points, in map coordinates, for civil programs and machine control; ISYBAU XML the network's manholes, connection points and pipes as master data for public owners (valid against the schema); GeoJSON the networks' connections (system, type, length, from, to) and the objects they hang on, and points, in WGS 84 for GIS; GeoPackage the same in the drawing's own system, a layer per drawing layer (QGIS, ArcGIS); a shapefile the connections, the points beside it as name_points.shp, with .dbf, .prj and .cpg (UTF-8); with "format": "gisnb" the network plan the gigabit funding asks for (GIS-NB 5.1): devices with the field art, end customers with endkunde, the platform's addresses (see addresses) as the address layer 3.1.1 (phase 1) or 3.1.2, connections by their fields (netfields) or system (Trasse, Leerrohr, Kabel), a zip per layer in ETRS89 longitude and latitude, and a check report of what the phase requires; a profile (an operator's or a town's rules for its GIS, kept as a small JSON file) changes a DWG/DXF as it asks: {"name", "layers": {"Glasfaser": "TK_LWL", "Leerrohr*": "TK_ROHR"} (or [[pattern, layer], ...] in order), "only": true (nothing else), "arcs": 3 (arcs, circles and ellipses as segments of at most 3 degrees), "close": true (polylines whose ends meet closed), "continuous": true (no dashes), "masks": false (no wipeouts), "texts": {"plot": "text_plot", "gis": "text_gis"} (texts as drawn on one layer, each symbol's and connection's name at the object on the other), "textHeight"}; BCF 2.1 the drawing's issues; the drawing keeps its own file)

Writes quantities for a bill of quantities as GAEB DA XML 3.3, exchange phase 31 (Mengenermittlung, .x31), as the AVA (tendering and billing software: ORCA, California, iTWO, ...) reads them into its bill: each item by its number (OZ) with its quantity. The quantities come from roadquantities, earthwork, sewertrench or a schedule; the item each belongs to is the bill's. Written after the schema gaeb.de publishes; the quantity per item, counted as REB 23.003 (2009) has it, without takeoff rows.

JSON-Form: gaebx31 {"path": "massen.x31", "items": [{"oz": "01.02.0010", "quantity": 660.0}, ...] (the bill's item numbers and their quantities in its units; the same item twice adds up), "breakdown": [2, 2, 4] (each part's length; default the longest found), "project": "Erschließung Süd", "boq": "LV Straßenbau" (the bill's name in the AVA), "description": "Mengen aus dem Straßenkörper"}

JSON-Form: import {"path": "plan.dxf", "plan.dwg", "rig.mvr", "plan.pdf", "parts.step", "model.ifc", "gelaende.xml" (LandXML), "kanal.xml" (ISYBAU), "dgm.xml" (OKSTRA), "netz.geojson", "leitungen.shp" (beside it its .dbf and .prj), "netz.gpkg" (GeoPackage, with "tables": ["Leitungen"] for some of its layers) or "issues.bcf", with GeoJSON, shapefiles and GeoPackages "as": "network" (lines as connections; with IFC the building services: pipes, ducts and cables as connections hanging on the ports of their fittings and devices, with system and size), "layerBy": "art" (a layer per value), "system"/"type": the properties naming them} (adds to the drawing; one undo step; a GeoJSON file's points, lines and areas come onto the drawing's map (WGS 84 projected into its UTM zone, or the file's named system); a LandXML file's surfaces become terrains (with their breaklines and outer boundary), its points points; an ISYBAU file's sewer network a network: manholes from cover to invert, connection points, structures, and its pipes as connections joined to them, with system and type; an OKSTRA file's ground models terrains, ending where their triangles do; an IFC model's plain walls and floors come editable, with their windows and doors; a BCF file's issues are added, those there already by guid updated)

Creates or changes a sheet to plot: paper (default A3 landscape) with a frame, a title block with title, project, drawn by, date, scale and sheet number, and a viewport onto the drawing from above at a scale, by default the largest standard scale that shows all of it ("fit"). Only the given fields change. plot writes the sheets as PDF. For floor plans of a building give "cut": the sheet then shows the model cut at that height (walls filled), what lies below down to the bottom, nothing above; with a layer state per sheet and room labels at each floor's height one model gives every floor's plan, and the plans follow every change of the model. Never copy or section the model beside itself for a plan. Notes, an office's title block or a north arrow go on the sheet's paper: space {"sheet": name}, then draw in millimeters ("frame": false leaves out the sheet's own frame and title block).

JSON-Form: layout {"name": "Site plan", "paper": "A0".."A4" or [w, h] mm, "orientation": "landscape"|"portrait", "scale": 500 (1:500) or "fit", "center": [x, y], "title": "...", "project": "...", "drawnBy": "...", "date": "...", "sheet": "...", "revision": "b" (the plan's index), "language": "en"|"de" (title block labels), "layerState": "Power" (plots with that layer state; "" for the layers as they are), "plotStyle": "Office" (see plotstyle; "" as on screen), "frame": bool (its own frame and title block), "renovation": "existing"|"demolition"|"changes"|"final"|"all"|"" (a conversion's stage), "cut": {"height": h, "bottom": b, "labels": true, "marks": false} (a floor plan, its openings labelled, without the sections' cut marks) or null}

Symbols from the installed libraries: drawings whose blocks are ready-made symbols, such as fences, toilets and stages for event sites, or an office's own blocks from its DWG files. Without blocks it lists the libraries and their symbols; with blocks it brings those into the drawing as block definitions (one step), to place with insert, at the drawing's unit. A name in several libraries comes from the first unless library names one. Symbols the drawing has already stay as they are. A library can also be a pack of ways of building (a country's or an office's): its wall, floor, roof and stair types are listed too, and "types" brings them in, in the drawing's units; types the drawing has under a name stay its own unless "replace" is true. Parametric components (see componentdef) come with "components", with the blocks they are made of; they keep the library's unit and are scaled where placed (component).

JSON-Form: library {"blocks": ["Bauzaun 3.5 m", ...], "library": "Festival und Event" (optional)} (brings them in as blocks to insert) | {"types": ["AW 36,5", ...] or "all", "library": name (optional), "replace": false} (brings wall, floor, roof and stair types) | {"components": ["Regal", ...] or "all", "library": name (optional), "replace": false} (brings parametric components) | {"library": name} or {} (lists the symbols, types and components)

JSON-Form: open {"path": "drawing.frame", "plan.dxf", "plan.dwg", "rig.mvr" or "model.ifc"} (replaces the drawing; not undoable; an MVR lighting rig comes with its trusses and fixtures as blocks, their fixture id, DMX address and GDTF type as attributes)

Pastes what copyclip or cutclip copied, with its blocks and layers (layers of the same name and blocks the drawing has already are used as they are), at a point or where it was. Selects it.

JSON-Form: pasteclip {"at": [x, y, z] (where the lower left corner of what was copied goes; default: where it was), "data": "..." (default: what was copied last)}

Places a page of a vector PDF, such as a plan printed from AutoCAD, as lines and fills to trace: one block on a layer of its own, at the plan's scale. Text drawn with fonts is left out.

JSON-Form: pdfimport {"path": "plan.pdf", "page": 1, "scale": 100 (the plan's 1:100), "position": [x, y]}

Writes the sheets as a PDF, one page each, true to scale with lineweights; without sheets the whole drawing on A3. "pdfa" writes it as PDF/A (ISO 19005, 2b or 1b), as building permit portals and archives ask: colours named by sRGB, the metadata saying the standard; CMYK photos are then left out.

JSON-Form: plot {"path": "plans.pdf", "layouts": ["Site plan", ...] (default: all sheets), "monochrome": false, "pdfa": true | "2b" | "1b" (PDF/A for permit portals and archives; true: PDF/A-2b)}

Plot styles say what each color prints as on a sheet, as AutoCAD's color-dependent plot styles (CTB) do: a pen per color index (1 to 255) with a color of its own (null: the object's), a lineweight in millimeters (null: the object's or its layer's) and a screen in percent; "monochrome" prints every color black. Without one a sheet prints as on screen with the lineweights of objects and layers, which is what new drawings should use. "import" reads an office's .ctb file (named after the file); give it to a sheet with "sheet" or layout {"plotStyle": ...}. Pens given change only the fields given.

JSON-Form: plotstyle {} (list them) | {"name": "Office", "monochrome": bool, "pens": [{"index": 1, "color": "#000000" or null, "lineweight": 0.5 or null, "screen": 100}, ...]} | {"import": "/path/office.ctb", "name": "Office" (optional)} | {"name": "Office", "delete": true}; "sheet": "Plan" also gives it to that sheet

Opens a recovery copy (written while the app ran, before it ended without saving) or an earlier version a save replaced, as a drawing that is not saved yet: Save asks where and suggests the file it came from, which stays as it is until then.

JSON-Form: recover {"path": "the copy.frame", "original": "the file it came from" (Save as suggests it; its references are found from there), "name": "drawing name"} (replaces the drawing, unsaved; not undoable)

Cuts a route plan into sheets along the route (Blattschnitt), as construction files and execution plans of utility routes are: one sheet after the other at the scale on the paper (landscape), each turned so the route runs across it and centered on its piece, overlapping by so many meters, with the title block filled (title, project, sheet 3/12); the sheets' frames and numbers drawn on a layer of their own in the model, and an overview sheet with the whole route at the largest standard scale that fits. One undo step; sheetlist lists them.

JSON-Form: routesheets {"ids": [the route: a line, polyline or alignment] (default the selection), "scale": 500, "paper": "A3" (landscape), "overlap": 10 (m), "name": "Blatt", "title": "Trassenplan", "project": "...", "frames": true, "overview": true, "language": "en"|"de"}

Saves the drawing as a .frame file. Drawings over 4 MB are packed (Zstandard, lossless: a site plan with its references' copies takes 5.9 MB instead of 81); smaller ones stay readable text. "packed": false writes text whatever the size, to read or compare it; true packs a small one too. In the app each save keeps the version it replaces (the last three); "backup": false keeps none, for saves every few seconds (a shared drawing's), which would leave only seconds-old versions.

JSON-Form: save {"path": "drawing.frame"} (optional once the drawing has a file), "packed": true|false (default: drawings over 4 MB packed), "backup": true|false (default true)

The column grid of circuit diagram sheets (Strompfade): the paper's width in equal columns, numbered in a band along the top of the drawing area, as cross references count them ("/S2.3": sheet S2, column 3; crossref with the same "columns"). On each sheet on a layer of its own; run again, the grid of before goes; "remove" takes it off.

JSON-Form: sheetgrid {"sheets": ["S1", ...] (default all), "columns": 10, "remove": true, "language": "en"|"de"}

Lists the drawing's sheets as a plan list (Planliste) has them, in their order: each sheet's number, title, the scales of its views, its paper, its index (the state of its changes, see layout "revision") and date, from their title blocks. With "place" it is drawn as a table there, as a set of plans hands it out; run it again after a change of index for the list as it is then.

JSON-Form: sheetlist {"place": [x, y, z] (draw it as a table there, on the sheet or model shown), "language": "en"|"de"}

Switches between the model and the paper of a sheet, like AutoCAD's model and layout tabs. On a sheet's paper, coordinates are millimeters from its lower left corner, and every command works there: text, mtext, line, insert (a title block with fields, a north arrow, a logo), move, erase, change. What lies on the paper plots over the sheet's viewports; texts with a paperHeight are that many millimeters. Use the model for the building itself and the paper for what belongs to the sheet only. The selection is cleared.

JSON-Form: space {"sheet": "Plan 1"} (work on its paper) | {"model": true} (work in the model) | {} (say where)

The office's own title block on the sheets instead of the built-in one: a block of the drawing (from the office's template or library), drawn in millimeters as on paper with its base point at its lower right corner, placed at the frame's lower right on each sheet, the frame round the paper drawn as ISO 5457 has it. Its fields are filled by their tags from the sheet: TITEL/TITLE, PROJEKT/PROJECT, DATUM/DATE, GEZEICHNET/DRAWN, BLATT/SHEET, INDEX/REVISION, MASSSTAB/SCALE (the first viewport's), BLATTNAME/NAME, and from "fields". Run again after changes; "remove" gives the sheets their built-in title block back.

JSON-Form: titleblock {"block": "Plankopf Büro" (its base at its lower right), "sheets": ["A1", ...] (default all), "fields": {"BUERO": "Planung Muster GmbH"}} | {"remove": true, "sheets": [...]}

Says what one drawing unit is, so sheets plot at true scale: a floor plan drawn in meters plots at 1:100 the way it should. Nothing moves or changes size. New drawings are in meters; DWG and DXF files bring theirs. "format" shows coordinates and lengths in feet and inches (AutoCAD's LUNITS): architectural 5'-6 1/2", engineering 5'-6.50", fractional 66 1/2"; "precision" is the decimals, or for fractions 1/2^n of an inch (4: sixteenths). Feet and inches can always be typed (5'6-1/2", 6'), in any units.

JSON-Form: units {"units": "mm"|"cm"|"m"|"in"|"ft"|"none", "format": "decimal"|"architectural"|"engineering"|"fractional", "precision": 0..8} ({} says which they are)

Adds a further viewport to a sheet, for a detail at a larger scale beside the overview: its corners on the paper in millimeters from the lower left, the drawing's point to show in its middle and the scale (default: fits the drawing in). With index, changes that viewport (1 is the main one, which fills the frame; make it smaller with corner and opposite to make room) or deletes it. New viewports get a thin frame. A viewport can show the drawing in a layer state of its own (an overview of the site beside a detail of the power plan), like AutoCAD's layers frozen per viewport. With "view" it shows an elevation (Ansicht) or, with "section", a section (Schnitt) cut through "center", worked out anew from the model whenever the sheet is drawn, the levels marked at its side. "twist" turns the drawing on the paper (AutoCAD's view twist), for a site plan whose north is not up.

JSON-Form: viewport {"sheet": "A3", "corner": [x, y], "opposite": [x, y] (on the paper, mm), "scale": 20, "center": [x, y, z] (the drawing's point in its middle); "index": n to change one, with "delete": true to remove it; "frame": bool; "cut": {"height": h, "bottom": b, "labels": true, "marks": false} (a floor plan, its openings labelled, without the sections' cut marks) or null; "view": {"direction": "front"|"back"|"left"|"right"|[x, y], "section": false, "levels": true} (an elevation or section) or null; "layerState": "Power" (its own layers; "" for the sheet's), "renovation": "changes" (a conversion's stage; "" for the sheet's), "twist": 30 (the drawing turned on the paper)}

Walls reach up to a roof, as Revit's walls attached at the top: gable walls fill the gable's triangle, walls under a slope end at its underside, wherever that is above or below their own height. Give the walls and the roof, or select both. When the roof changes its measures, its walls follow; "detach" gives them back their own height. roof "on" a wall attaches that wall at once.

JSON-Form: attachwalls {"ids": [walls], "roof": id} (their tops follow the roof's underside) | {"ids": [walls and one roof]} | {"ids": [walls], "detach": true}

A beam, as Revit's structural framing and Archicad's beam tool: a section hanging below the line from start to end (its top's middle on it, as a beam under a floor is placed), level or sloping, of a "material", named after its section (24/40, or "name" such as IPE 300: width 0.15, depth 0.3, web 0.0071, flange 0.0107). Schedules list beams with their lengths, IFC files carry them as IfcBeam. First 24/40 cm.

JSON-Form: beam {"start": [x, y, z], "end": [x, y, z] (its top's middle at both ends), "size": [0.24, 0.4] | "diameter": d | "profile": {"shape": "rectangle"|"round"|"I", "width", "depth", "diameter", "web", "flange"}, "name": "IPE 300", "material": "Stahl S235"}

Columns, as Revit's structural columns and Archicad's column tool: a section (a rectangle, round, or an I section given by its measures: a steel HEB 200 is width 0.2, depth 0.2, web 0.009, flange 0.015) standing on its foot up to the next storey's floor (or "height"), turned by "rotation", of a "material", named after its section (30/30, Ø30, or "name"). Floor plans cut them filled, schedules list them, IFC files carry them as IfcColumn. First 30/30 cm, then the last size used.

JSON-Form: column {"at": [x, y, z] or "points": [[x, y, z], ...] (each foot's middle), "size": [0.3, 0.3] | "diameter": 0.3 | "profile": {"shape": "rectangle"|"round"|"I", "width", "depth", "diameter", "web", "flange"}, "name": "HEB 200", "height": h (default up to the next storey), "base": z, "rotation": degrees, "material": "Stahlbeton C25/30"}

Quantities by DIN 276 cost group, as a cost estimate (Kostenschätzung) and the tender after it start: outside walls (331 load-bearing, 335 and 336 their claddings outside and inside, 334 their windows and doors, 337 curtain walls), inner walls (341 load-bearing - masonry or concrete 17.5 cm and more -, 342 the others, 345 their claddings, 344 their doors), floors (351 the structure and stairs and beams, 353 finishes above, 354 claddings below; the lowest is the ground slab: 322, 324, 325), roofs (361, 363 coverings above the rafters, 364 claddings below, 362 roof windows), columns (333 outside, 343 inside). Layers of types count by their material, in m² of the part's face; walls are outside walls where a side of them lies beyond their storey's floor slabs. With "rates" (the office's own prices per unit, by group or by group and part) each row is priced and the groups and the building totalled. "place" draws the estimate as a table, "path" writes it as a spreadsheet. The IFC export carries the same groups as a DIN 276 classification of each part.

JSON-Form: costs {"rates": {"331": 180, "335 Kalkzementputz": 28} (per unit, by group or group and part), "ids": [...] (default all), "place": [x, y, z] (draw the table there), "path": "costs.csv", "separator": ";"|","|"\t", "language": "en"|"de"}

Gives walls a curtain wall's grid (Pfosten-Riegel-Fassade), or changes it: mullions at most "spacing" apart, evenly on each straight piece, transoms at the "transoms" heights above the foot, "mullion" wide, glass "glass" thick in the middle, rows listed in "panels" (1 the lowest) closed by opaque panels "panel" thick (spandrels, Brüstungsfelder); what isn't given stays (or is the last grid used). The wall keeps its path, height and joins; its type and layers go, it has no windows. "remove": true makes them plain walls again.

JSON-Form: curtain {"ids": [walls] (default: the selection), "spacing": 1.5, "transoms": [0.9, 2.1], "mullion": 0.06, "glass": 0.03, "panels": [1] (rows closed by panels, 1 the lowest), "panel": 0.06, "thickness": 0.15 (the mullions' depth) | "remove": true}

A curtain wall (Pfosten-Riegel-Fassade), as Revit's: a wall along clicked corners whose frame is mullions standing evenly at most "spacing" apart on each straight piece (a post at each corner, as wide as the mitre), transoms across at the "transoms" heights and along its foot and top, and a pane of glass in each field. It is a wall: it joins, is dimensioned and stands on its level like one; floor plans cut its mullions and draw its glass, elevations show the grid, IFC carries it as IfcCurtainWall. curtain changes the grid or turns walls into curtain walls.

JSON-Form: curtainwall as wall, with "curtain": {"spacing": 1.5, "transoms": [h, ...], "mullion": 0.06, "glass": 0.03} (default the last grid used); "thickness" is the mullions' depth (15 cm first)

What a demolition takes away (Abbruchmassen), for the offer and the containers: by material, the walls, floors, roofs and stairs of a type layer by layer (cut by their windows), other solids by their material or else their layer's name, in m³ as they stand and in tonnes where the material has a density (material {"density"}: the tip charges by weight). "swell" is the factor rubble grows by broken (Auflockerungsfaktor, about 1.5 for masonry and concrete), "load" what a container or truck takes, giving the loads. By default everything marked to demolish (renovation {"status": "demolish"}) and what new windows and doors take out of walls that stay (Durchbrüche: their face times the wall, layer by layer) and new openings out of floors that stay (a stair hole: its area times the floor, layer by layer; "breaches": false leaves them out); "place" draws the list as a table, "path" writes it as a spreadsheet.

JSON-Form: demolition {"ids": [...] (default: everything marked demolish), "swell": 1.5 (rubble's loosening), "load": 10 (m³ a container takes), "breaches": true (new openings in walls and floors that stay), "place": [x, y, z] (as a table there), "path": "abbruch.csv", "separator": ";"|","|"\t", "language": "en"|"de"}

A dimension chain through the rooms along a line, as plans for building have them and Archicad's interior dimensioning makes them: a stop at every wall face the line crosses, so the chain gives the rooms' clear widths and the walls' thicknesses in turn. Only the walls standing at the line's height count (one storey). A chain level or upright in plan holds on to the walls' own corners and jambs, so it follows when the walls move; the dimension line runs through the walls, without extension lines. The values are 2.5 mm high on every sheet, each at its own scale (paperHeight; a textHeight fixes them in the model instead).

JSON-Form: dimthrough {"from": [x, y, z], "to": [x, y, z] (the line the chain lies on, at the storey's height), "ids": [walls] (default all walls shown standing at that height), paperHeight (default 2.5) or textHeight, decimals, separator, dimstyle as for dimlinear}

Dimension chains round the outside of the walls, as plans for building have them and Archicad's automatic exterior dimensioning makes them: on each side, nearest the walls the openings (piers and shell openings of the windows and doors), then the walls (corners, recesses and projections), outermost the whole length; a chain that would tell no more than the next is left out; what lies behind a part further out (the inside of a U) isn't on that side's chains. Each storey and each building of it gets its own chains, at its walls' foot. Each chain is a row of linear dimensions holding on to the walls' corners, so they follow when the walls move. The building's own directions count: one turned on the site gets its chains along its sides. Distances follow the drawing's scale (10 and 7 mm on paper); the values are 2.5 mm high on every sheet, each at its own scale (paperHeight; a textHeight fixes them in the model instead). "to": "core" measures the walls' structure instead of their finished faces (Rohbaumaße, as working drawings give them; Revit's dimensions to the core): the masonry, concrete, timber or steel layers of each wall's type, plaster and insulation left out, the openings' shell sizes as they are.

JSON-Form: dimwalls {"ids": [walls] (default: the selection, else all walls shown; each storey on its own), "chains": ["openings", "walls", "overall"], "sides": ["south", "east", "north", "west"], "distance": 1.0 (first chain from the outside; default 10 mm on paper), "spacing": 0.7 (between chains; default 7 mm on paper), "to": "finish"|"core" (the walls' faces, or their structure: Rohbaumaße), paperHeight (default 2.5) or textHeight, decimals, separator, dimstyle as for dimlinear}

Puts a door opening into a wall, like window but standing on the wall's foot: first 0.885 by 2.01 m (German shell size), then the last measures used. Floor plans cut through it draw the leaf standing open and its swing: "hinge" says at which end of the opening it hangs, "swing" to which side of the wall's path it opens (by default the side of the point given). A door "type" (openingtype) gives its size, its leaves (one or two) and how open views show it.

JSON-Form: door {"wall": id, "at": [x, y, z] (at the wall: its middle) or "distance": d (along the path), "width": 0.885, "height": 2.01, "sill": 0, "hinge": "start"|"end", "swing": "left"|"right", "type": "Tür 2-flg" | "component": "...", "componentType": "...", "values": {...}}

Builds a dormer on a roof's face: a front wall standing on the roof "height" high up to its own roof, cheeks at its sides down to the roof, and its roof sloping at "slope" up from its front until it meets the roof ("shed", a Schleppgaube) or from both sides to a ridge ("gable", a Satteldachgaube), "wall" thick; the roof is opened under it, the window in its front is "window" [width, height] (else four fifths of the front). "at" a point on the roof puts its front's middle there; or "side", "along" and "up" (its front in from the eave line, in plan). It stays on its face, apart from other dormers and windows; its roof must be flatter than the roof's. Framing trims the rafters round its opening; the dormer's own timbers aren't framed.

JSON-Form: dormer {"roof": id, "at": [x, y, z] (on the roof: its front's middle) or "side": n, "along": a, "up": d (its front in from the eave line, in plan), "width": 2.0, "height": 1.2 (its front, above the roof), "shape": "shed"|"gable", "slope": 15, "wall": 0.15, "window": [w, h]} | {"roof": id} (lists) | {"roof": id, "remove": n}

Checks the outer components a conversion renews against the highest U-values the GModG (formerly the GEG) allows when an existing building is changed (§ 36, Anlage 7): outer walls 0.24, windows 1.3, roof windows 1.4, outer doors 1.8, roofs and ceilings under an unheated attic 0.24, walls and floors to the ground or an unheated room 0.30, floors over the outside air 0.24 W/(m²K) ("zone": "cool" for zones of 12 to 19 °C). Where each lies comes from the model as the heat load sees it: the walls along each heated room's outline and what lies behind them, their windows and doors, the floor and what is below, the ceiling or roof over it. Renewed is what is marked new (renovation; "all" checks every outer component). Changes to no more than 10 % of a component group's area (Anlage 7's four: outer walls; windows, roof windows and outer doors; roofs and what borders an attic; to the ground, unheated rooms and below) are exempt. U-values from the types' layers (EN ISO 6946) or as given. Selects what exceeds or has no U-value; a table with "place". A first check for the energy consultant: measures that renew only a layer (rendering, floor build-up, waterproofing) and special glazing are not told apart; French doors count as windows when drawn as windows, as doors (1.8) when drawn as doors; roof windows follow their roof's stage, a dormer's window with the windows (2a) and its front, cheeks and roof with the roof (5a; "u": {"dormer": U}, else the roof's); walls of heated basements count as outer walls; a roof's and a floor's area is the room's below it.

JSON-Form: envelopecheck {"unheated": ["0.01", "Keller"] (rooms by number or name), "u": {"AW neu": 0.22, "window": 0.95, "door": 1.3, "roofwindow": 1.1, "dormer": 0.2, "floor": 0.28} (W/(m²K) by type name or kind), "overOutside": ["slab type"] (floors over the outside air), "zone": "warm"|"cool", "all": false, "select": true, "place": [x, y, z], "language": "en"|"de"}

Writes the drawing's wall, floor and roof types as a table of build-ups for Excel, a layer a row: component (Wand, Decke, Dach), type, layer and thickness in the drawing's unit. importtypes reads such a table back, also one an office keeps itself.

JSON-Form: exporttypes {"file": "Aufbauten.csv", "separator": ";" | "," | "\t" (default: as Excel in the language of the interface)}

The timber members of a roof, wall or floor of a type as solids of their own: a roof's rafters up each sloping face from its eave, cut at the ridge, with hip and valley rafters, and if asked collar ties between opposite rafters ("collar": the height of their tops above the eaves), a ridge purlin and middle purlins ("purlins": heights of their flat tops) under them, the rafters notched on them (Kerve, "notch" deep square to the rafter, at most a quarter of its depth); a wall's studs along its path (at its ends and corners, two beside each window and door, either side of where another wall butts against it) between a bottom and a top plate, nailed or with "tenons" (Zapfen) in mortises, which follow its foot and top (under a roof too) and run as sill and header round its windows; a floor's joists across its shorter span (or "direction") with rim joists at their ends, trimmers beside each opening and headers at its ends. They stand in the type's layer of timber ("layer" names another; a type without timber is refused), as deep as it, "width" wide (default 8 cm rafters, 6 cm studs, 10 cm joists) and at most "spacing" apart (80 cm rafters, else 62.5 cm), evenly; grouped, in the component's layer and color. The layer stays (rafters and insulation); IFC files take them as IfcMember and IfcBeam. Each member knows its section, length and "material" (schedule of timber lists them). The component keeps these settings: changed (moved, stretched, a window added, its type changed), it is framed again in the same step, and erased, its members go too. Framing it again replaces its members and changes only the settings given; "remove": true takes them away.

JSON-Form: framing {"id": roof or wall of a type, "layer": "Sparren und Dämmung" (the type's layer they stand in; default: its timber one), "width": 0.08, "spacing": 0.8 (center to center, at most), "plates": true (walls: bottom and top plates, sills and headers), "doubled": true (walls: two studs beside each window and door), "tenons": false (walls: studs tenoned into the plates), "rim": true (floors: rim joists), "collar": 2.2 (roofs: collar ties, their tops so high above the eaves), "collarSize": [0.06, 0.16], "ridgePurlin": true, "purlins": [1.4] (roofs: middle purlins, their tops so high above the eaves), "purlinSize": [0.12, 0.2], "notch": 0.03 (roofs: rafters notched so deep on the purlins), "direction": [x, y] (floors: the way the joists run; default across the shorter span), "material": "KVH C24" (what the members are made of; default the layer's material if it is timber), "remove": true (takes the members away)}

Takes wall, floor, roof and stair types from a file into the drawing, as Revit's Transfer Project Standards: from an IFC file (IFC2X3, IFC4) the material layer sets of walls, slabs and roofs (or their IFC types) become types with their layers, named after the IFC type or the layer set, and stairs bring their material; from another drawing (.frame, an office's standard build-ups) its types; from a table of build-ups (CSV from Excel, a layer a row: Bauteil (wall, slab or roof; with one of kinds it may be left out), Typ, Schicht, Dicke with its unit in the header, as exporttypes writes it). All in the drawing's units. A type the drawing has under that name stays its own unless "replace" is true; then its walls, floors, roofs or stairs follow. One step to undo.

JSON-Form: importtypes {"file": "Hersteller.ifc", "Bauweisen.frame" or "Aufbauten.csv", "kinds": ["wall", "slab", "roof", "stair", "opening"] (default all; window and door types from drawings), "replace": false (default: the drawing's own types of a name stay)}

The storeys' levels, as Revit's: a name and the height of the floor. What stands on a level belongs to it up to the next one (a wall by its foot, a slab by its top, other objects by their bottom), so moving a level up or down takes its walls, slabs, stairs and furniture along; "above": true moves the levels above with it, as when a storey gets higher. "current" puts the work plane on the level's floor, so clicks land there. "alone" shows only what stands on the level, in 3D and in plan, until {"alone": false}: a way of looking, as isolateobjects, that leaves the layers alone and follows what is drawn or moved meanwhile. "storeys" makes several at once (EG, 1. OG, 2. OG, ... unless named). levelplans makes a floor plan sheet for each.

JSON-Form: level {} (lists them) | {"name": "OG", "elevation": 2.95} (makes one, or moves it with what stands on it; "above": true moves the levels above too) | {"name": "OG", "rename": "1. OG"} | {"name": "OG", "current": true} (draw on it) | {"name": "OG", "alone": true} (only this storey shown; {"alone": false} all) | {"name": "OG", "delete": true} | {"storeys": 3, "height": 2.95, "from": 0, "names": ["EG", "OG", "DG"]}

A floor plan sheet for each level, named after it: the plan cuts "cut" above the level's floor (1 m unless given) and shows down to the floor. Sheets made before are kept and only follow the levels' heights, so run it again after moving a level.

JSON-Form: levelplans {"cut": 1.0 (above each floor), "scale": 100, "paper": "A3", "levels": ["EG", "OG"] (default: all), "labels": true (windows and doors with their sizes)}

A building of an early design as one block (a mass, Baukörper): its outline standing so many storeys of a height (the lowest ones perhaps higher: "heights"), drawn with its storeys' floors round it. A roof on top ("roof": gable, hip or shed, "slope" in degrees, "gables" the sides standing upright, "kneeWall" how high its eaves stand above the top storey) holds an attic. "on" stands a mass on another's top, its outline "inset" from all or each side (a storey set back, Staffelgeschoss). massing works out the key figures a zoning plan asks for from the masses (GRZ, GFZ with the full storeys, BMZ, gross floor area and volume). Try variants by moving, copying and changing masses; with "id" its storeys, heights or roof change.

JSON-Form: mass {"points": [[x, y, z], ...] (its outline, at its foot) | "ids": [closed polylines or circles] | "on": mass (on its top, its outline), "inset": 1.5 or [per side] (set back), "bulges": [...], "storeys": 4, "height": 3.0 (a storey's), "heights": [4.5] (the lowest storeys' own), "roof": "flat"|"gable"|"hip"|"shed", "slope": 35, "gables": [sides], "kneeWall": 1.0} | {"id": mass, ...} (changes one)

Turns masses into a building to go on with, as early design ends: a level at each storey's floor (KG, EG, 1. OG …, DG, or those there are at that height), a floor slab on each and one on top, outside walls round the outline inside it, from each floor to the next one's underside. Under a mass's roof the attic's walls reach up to the roof (the gables into the gable), and the roof rests on them where the mass's was, reaching "overhang" beyond. Then levelplans makes the plans, and walls, openings and rooms are drawn in as usual. One step; the mass goes unless "keep".

JSON-Form: massbuild {"ids": [masses] (default: the selection), "thickness": 0.3 or "wallType": "AW 36,5", "slab": 0.2 or "slabType": "Geschossdecke", "roofThickness": 0.3 or "roofType": "Sparrendach", "overhang": 0.5, "keep": false (the mass stays)

The key figures of the masses (mass) against the plot, as a zoning plan (Bebauungsplan, BauNVO) asks for them: the area built over (the masses' outlines together) and GRZ, the floor area of all storeys (BGF) and of the full ones (GF) and GFZ, the gross volume (BRI) and BMZ, the storeys and the tallest building's height, each storey with its area and whether it is a full storey; an estimate of the living area (a share of the floor area) and of the costs (per m² of floor area, from a rate the user gives, as from BKI's figures). The plot, the plan's limits and the assumptions are kept in the drawing, so the app shows the figures as the masses change; figures above a limit are named. GFZ counts the full storeys (Vollgeschosse, BauNVO §20) as most Länder define them: more than 1,40 m out of the ground, 2,30 m high over two thirds of the floor; an attic under a roof or a storey set back over two thirds of the storey below. BMZ counts the full storeys' volume (Baumasse, BauNVO §21). Attics count where one can stand in them, their living area by WoFlV. Areas in m², whatever the drawing's unit.

JSON-Form: massing {} (the figures) | {"plot": id (a closed polyline round the plot), "grz": 0.4, "gfz": 1.2, "bmz": 0 (the zoning plan's limits; 0: none), "rate": 2900 (cost per m² gross floor area), "livingShare": 0.75} (kept in the drawing)

What layers of wall, floor and roof types and stairs are made of, as Revit's materials. A layer is of the material of its name, a stair type of its "material". "kind" (guessed from the name when not given) says how sections hatch it: concrete crossed, masonry diagonal, timber along the layer, insulation zigzag, plaster and screed dotted, steel solid; "hatch" sets another pattern. The values are what engineers work with: "density" kg/m³, thermal "conductivity" λ W/(m·K), "heatCapacity" J/(kg·K), modulus of "elasticity" and characteristic "strength" N/mm². With densities and λ for all its layers a type tells what a square meter weighs and its U-value (walltype, slabtype, rooftype, get_drawing). "description" says how it looks ("Kalkzementputz, weiß", "Tondachziegel, rotbraun"), as Revit's material description: elevations name the materials of the faces they show with it, as building applications ask. Materials go into IFC files with their values.

JSON-Form: material {} (lists them) | {"name": "Kalksandstein", "kind": "masonry", "density": 1800, "conductivity": 0.99, "heatCapacity": 1000, "elasticity": 5000, "strength": 12, "description": "Kalksandstein, weiß geschlämmt"} (makes or changes one; values in SI units, 0 for not known) | {"name": "..."} (shows it) | {"name": "...", "delete": true}

Lists the windows and doors of a wall with their numbers, changes one (measures or place along the wall), or closes it up again. Grips drag them along the wall too. In a conversion (see renovation) an opening may be at another stage than its wall: "renovation": "new" is a door broken through a wall that stays (yellow where the wall comes out, the door red), "demolish" a window bricked up (red infill, the old window yellow); deleting it would forget it was ever there.

JSON-Form: opening {"wall": id} (lists its windows and doors) | {"wall": id, "index": n, "width": w, "height": h, "sill": s, "distance": d or "at": [x, y, z], "hinge": "start"|"end", "swing": "left"|"right", "type": "..." or "", "component": "..." or "", "componentType": "...", "values": {...}, "inside": "left"|"right", "renovation": "new"|"demolish"|"existing"|"", "mark": "F 0.01"} (changes one) | {"wall": id, "index": n, "delete": true} (closes it up)

Kinds of window and door under a name, as Revit's window and door types. A type gives new windows and doors their size (window and door with "type"); its frame is "frame" wide in view and "depth" deep through the wall; "sashes" side by side (a door's leaves: 1 or 2) with mullions between them, each opening as "opening" says (fixed, turn, tilt or tiltturn; one for all or one each; a sash that opens has a frame of its own); "bars" [across, up] glazing bars in each pane; "transom": a top light that high above a transom bar; "sillInside" and "sillOutside": sills reaching so far beyond the wall's faces (which side is inside: opening with "inside"); a door's "swing" shows its leaves open by that many degrees in views (plans draw them open as always). Views and plans draw them as the type says, schedules count them by type. Changing a type's width or height changes its windows and doors (their sills stay); deleting it leaves them with a plain frame.

JSON-Form: openingtype {} (lists them) | {"name": "Fenster 2-flg", "kind": "window", "width": 1.51, "height": 1.385, "sill": 0.9, "frame": 0.07, "depth": 0.08, "sashes": 2, "opening": ["turn", "tiltturn"], "bars": [0, 1], "transom": 0.3, "sillInside": 0.03, "sillOutside": 0.04} | {"name": "Tür 2-flg", "kind": "door", "width": 1.51, "height": 2.135, "sashes": 2, "swing": 90} (makes or changes one) | {"name": "..."} (shows it) | {"name": "...", "delete": true}

Marks where a photo was taken and which way it looks, as surveys of an existing building and damage reports do: a circle with the photo's number and a cone toward what it shows. The mark is a block whose fields carry the photo's file, a note ("crack over the window") and the date; numbers count on (F1, F2 ...) unless given. "list": true lists the photo points of the plan with their view (N, NE ...), file, note and date; with "place" it draws them as a table, the photo log. 2.5 mm letters on paper: in the model at the drawing's scale (annoscale).

JSON-Form: photopoint {"at": [x, y, z], "toward": [x, y, z] | "direction": degrees (0 along +x, counter-clockwise), "number": text (default the next free, F1, F2 ...), "file": the photo's path, "note": what it shows, "date": text} | {"list": true, "place": [x, y, z] (draws the table; without it only lists)}

Puts the doors and windows a drawn floor plan shows into the walls standing on it (made with planwalls or by hand): each gap in a wall's lines with a door's swing or symbol, or a label as high as a door, is a door, hinged and opening as its swing shows; one with lines in it (frame and glass) or a window symbol is a window. As wide as the gap; as high as its label says ("0.90/2.10", or the height written under the width), else the last ones used (first 2.01 m for doors, 1.26 m on a 0.9 m sill for windows). Openings already there stay. "missed" lists those that found no wall.

JSON-Form: planopenings {"ids" | "within" | "layers" | "gapsAsDoors" (the plan, as for planwalls), "level": "OG" | "base": z (its storey, as for planwalls), "walls": [ids] (default all), "preview": true}

Makes the rooms a drawn floor plan's stamps name, between the walls standing on it (made with planwalls): each name inside walls becomes a room of that name, with the number written beside it (else the next one) and checked against the area the stamp states ("12,34 m²"): rooms whose area differs are counted, each with its "difference" in the list. Several names in one room: the biggest is its name; a stamp with only an area makes a room named Raum; heights and window ratios ("R.A. 1/8") are no names. Rooms there already keep theirs.

JSON-Form: planrooms {"ids" | "within" (the plan, as for planwalls), "level": "EG" | "base": z, "fill": false, "preview": true}

Puts one storey's plan onto the others: moved (and with two points turned) so that its points "from" (a corner of the stair, an axis crossing, an outer corner) lie on "to", the same points in the plan it goes over, and lifted to its level's height (made at "elevation" when new). Plans of several storeys drawn side by side on one sheet become a stack, ready for planwalls on each level.

JSON-Form: planstack {"ids" | "within" (the storey's plan; default the selection), "from": [x, y] or [[x, y], [x, y]] (points of it), "to": the same (where they go: the same points in the plan below), "level": "OG", "elevation": z (makes the level if new)}

Builds the walls a drawn floor plan shows (lines from a DWG, a DXF or a PDF), as someone tracing it would: two or more parallel lines a wall's thickness apart are a wall, its axis in their middle, as thick as they are apart (lines between them, insulation or plaster, belong to it); evenly spaced lines (stair treads, patterns) are none. Pieces of one wall in line are one wall across a wall running into the gap, a door (its swing, a door symbol, a label as high as a door) or a window (lines in the gap, a window symbol, a label); corners meet and T's butt. Walls of a wall type's thickness become that type. Gaps nothing explains are listed in "unclear": ask about them. Gaps the user says are doors: "gapsAsDoors" with their points (or true), then the walls run on through them. "layers" lists the layers the walls were found on: when furniture or railings show as walls, give the layers of the cut walls (doors, windows and labels are still read from all); "lineweights" likewise how heavy their lines were: a PDF's cut walls are told apart by "lineweight". Several plans on one sheet: one at a time with "within", each on its storey's "level". Walls stand on the level (or "base") up to the next level (or "height"). Run it with "preview" first, look at what it found (thicknesses, counts), then without; planopenings then puts the doors and windows in, planrooms makes the rooms.

JSON-Form: planwalls {"ids": [...] | "within": {"min": [x, y], "max": [x, y]} (the plan; default the selection, else all), "layers": ["Walls"] (the layers its walls' lines are on; default all), "thickness": [min, max] (drawing units; default 5 to 80 cm), "lineweight": 0.35 (mm, walls' lines at least), "gapsAsDoors": [[x, y], ...] or true (unclear gaps that are doors), "maxOpening": w, "level": "EG" | "base": z, "height": h, "types": true (wall types of the same thickness), "renovation": "existing" (a plan of what stands, for a conversion), "preview": true}

Numbers the windows and doors as working drawings and their schedules call them (Revit's Mark): storey by storey, round the storey's middle clockwise from the north-west (the north side from west to east first; the drawing's true north where it lies on the earth), windows and doors each on their own: "F 0.01" the first window of the ground floor, "T 1.03" the third door of the floor above, "F -1.02" in the basement (storeys as room numbers count them; without levels "F 01"). Those with a position keep it and new ones go on from the highest, unless "renumber": true. Floor plans with labels show them over the shell sizes; schedule {"of": "openings", "per": "piece"} lists them one by one. opening sets one by hand ("mark").

JSON-Form: positions {"ids": [walls] (default all shown), "renumber": false (true numbers all anew), "windows": "F", "doors": "T"}

Conversions, as Revit's phases and Archicad's renovation status: marks objects as existing, to be demolished or new ("status"; "none": no stage, as notes and dimensions have), and sets what the model shows ("show"): "existing" the building as it stands (new work hidden), "demolition" what comes down in yellow, "changes" what stands as drawn with demolition yellow and new work red (DIN 1356-1, as permits want it; Italy's tavola comparativa), "final" the building when done, "all" everything as drawn. Sheets and viewports show a stage of their own (layout and viewport with "renovation"), so one drawing gives the existing, demolition and new plans. Windows and doors may differ from their wall: a door broken through a wall that stays, a window bricked up (opening with "renovation"). Once a stage is given, new objects are new work ("draw" says otherwise; notes, dimensions, tables and rooms get none). Schedules count each stage apart, IFC files carry it (Pset …Common Status). Without parameters: how many objects are at each stage.

JSON-Form: renovation {"ids": [id, ...] (default: the selection), "status": "existing"|"demolish"|"new"|"none"} (marks objects) | {"show": "all"|"existing"|"demolition"|"changes"|"final"} | {"draw": "new"|"existing"|"demolish"|"none"} | {"colors": {"demolished": "#F7B500", "new": "#E2001A", "existing": "#808080" or ""}} | {} (counts)

Builds a roof over an outline: every side slopes up inwards at "slope" degrees from its eave (a hip roof), except the gables, which stand upright ("shape": "gable" makes the two short ends of a four-cornered outline gables, "gables" names edges by number, edge 1 running from the first corner to the second). It is "thickness" thick square to its faces, its underside meeting the outline at the eaves' height (on walls it rests on their outer top edges), reaching "overhang" beyond the outline all round. "on" a closed wall takes its outer face as the outline and its top as the eaves; otherwise the eaves lie at the outline's height or "base". The roof keeps its measures: primitive changes slope, overhang and thickness, grips drag its corners. Over L-, T- and U-shaped houses the wings' roofs meet in valleys and hips; over outlines with corners aslant, and where sides have slopes of their own ("slopes", one per side or by side number), the faces are those of the outline's straight skeleton, as Revit and ArchiCAD build them. Without measures, the last ones used, first 35°, 0.5 m overhang, 0.3 m thick.

JSON-Form: roof {"points": [[x, y, z], ...] (the eaves' outline) | "ids": [a closed polyline] | "on": wall (a closed wall round a house), "slope": 35 (degrees), "overhang": 0.5, "thickness": 0.3 or "type": "Sparrendach" (a roof type), "shape": "hip"|"gable", "gables": [2, 4] (edge numbers from 1), "slopes": [35, 45, 35, 45] (each side's) or {"2": 45}, "base": z (eave height)}

Kinds of roof under a name, as Revit's roof types: their layers from the outside in (tiles, battens, rafters with insulation, or a concrete slab, lining); a roof of the type (roof with "type", or primitive with "type") is as thick as its layers together, square to its faces. Changing a type changes all its roofs at once, and the walls attached to them follow; IFC exports the layers as materials. Deleting a type leaves its roofs as they are.

JSON-Form: rooftype {} (lists them) | {"name": "Sparrendach", "layers": [{"name": "Tiles and battens", "thickness": 0.06}, {"name": "Rafters and insulation", "thickness": 0.2}, {"name": "Plasterboard", "thickness": 0.0125}]} (makes or changes one) | {"name": "..."} (shows it) | {"name": "...", "delete": true}

Sets a window into a roof's face, as Velux and Roto windows sit: a hole square to the face, frame and glass in it; "at" a point on the roof puts its middle there, or "side" (the eave it rises from, from 1), "along" that eave from the side's first corner and "up" the face from the eave to its lower edge. It stays on its face (not over a hip, valley, ridge or the eaves) apart from other windows and dormers. Framing trims the rafters round it with headers. Without measures, the last ones used, first 78 by 140 cm.

JSON-Form: roofwindow {"roof": id, "at": [x, y, z] (on the roof: the window's middle) or "side": n, "along": a, "up": u (its lower edge up the face from the eave), "width": 0.78, "height": 1.4 (up the slope)} | {"roof": id} (lists its windows and dormers) | {"roof": id, "remove": n}

Rooms, as Revit's: the floor inside the walls round a point (doors and windows don't break it), named and numbered ("0.01" for the first on the storey at height 0, "1.01" one storey up), its stamp on the plan: number, name and area in m², in the drawing's text style, 2.5 mm high on paper, with the dimension style's decimal separator. Not filled unless "fill" (then in its layer's color). A room found between walls follows them when they move. Its "use" after DIN 277 (NUF 1 living, 2 office, 3 production and kitchens, 4 storing, 5 teaching, 6 care, 7 other: baths, store rooms, garages; TF technical, VF circulation), "outdoor" for a balcony, loggia or terrace, and "share" the share of its floor counted as living area: unless given, as its name tells (Flur VF, Heizung TF, Bad NUF 7, Balkon outdoor with a quarter, Keller and Garage none). schedule {"of": "rooms"} lists them with their living area after the German WoFlV: in full where the room is 2 m high or more, in half from 1 to 2 m (under a sloping roof), not below; a balcony or terrace a quarter (half at most); and the areas of each storey after DIN 277: NUF, TF, VF, NRF, BGF and KGF. Its "finishes" (floor, walls, ceiling, skirting, as written) make the room book: schedule {"of": "finishes"} lists each room's floor, wall and ceiling areas and skirting length, totalled by finish for the tender. In a conversion its "renovation" stage: a new room (the building when done) is found between the walls that stay and the new ones, an existing room (or one going) between the walls that stand now, and each follows those walls; schedule {"of": "rooms", "renovation": "before"|"after"} gives the areas before and after the conversion. {"update": true} fits all rooms to their walls again.

JSON-Form: room {"inside": [x, y, z] (a point between walls), "name": "Wohnen", "number": "0.01" (default: the next on its storey), "fill": false, "label": [x, y] (where its stamp goes), "use": "NUF 1"|...|"NUF 7"|"TF"|"VF", "outdoor": true, "share": 0.25, "finishes": {"floor": "Parkett Eiche", "walls": "Putz, Anstrich weiß", "ceiling": "Gipskarton", "skirting": "Holz"} | "points": [[x, y, z], ...] (its outline) | {"id": room or "ids": [...], "name", "number", "label", "fill", "use", "outdoor", "share"} (changes them; null: by the name again), "renovation": "existing"|"demolish"|"new" | {"update": true} (all rooms follow their walls)

The room book: each room's floor area, walls (all round up to the slab or roof over it, less its windows and doors), ceiling and skirting (less doors), clear height, and the finishes given by room {"finishes": {"floor", "walls", "ceiling", "skirting"}}, with what each finish comes to for the tender. "deductAbove": 2.5 measures openings up to 2.5 m² over, as VOB's plaster and paint rules do. The same as schedule {"of": "finishes"}.

JSON-Form: roombook {"ids": [...] (rooms; default all), "deductAbove": 2.5 (windows and doors up to this many m² measured over), "place": [x, y, z] (write tables there), "path": "raumbuch.csv", "separator": ";"|","|"\t", "language": "en"|"de"}

A room from a hand survey (Handaufmaß): its sides measured round it and diagonals between corners (counted from 1), for rooms that are nowhere square. Corner 1 lies at "at", the first side runs along "direction", the room to its left; each further corner where its two measures from known corners meet. It needs at least n − 3 diagonals that split the room into triangles (from one corner to all others will do); further measures check it, and the largest misfit is reported. Draws the outline as a closed polyline: walls follow with wall {"ids": [...]}, the room with room.

JSON-Form: roomsurvey {"sides": [4.02, 3.51, 4.05, 3.48] (m, round the room from corner 1), "diagonals": [[1, 3, 5.33], [2, 4, 5.30]] (corner, corner, m; at least n − 3 that split it into triangles, more check it), "at": [x, y, z] (corner 1), "direction": 0 (the first side's, degrees)}

Lists building parts, as Revit's schedules: the walls with their length (along the path), height, thickness, face area along the path without their windows and doors, and volume, summed by thickness; the windows and doors by kind and size, counted ("per": "piece" one row each as a working drawing's window and door schedule has them: position, storey, room, the way it faces outside, type, measures); the slabs with area and volume; the roofs with the area of their faces; the stairs with their shape, risers, going and width; the columns and beams by section, material and length, counted; the placements of parametric components by component, type and values, counted; the rooms with their floor and living area (WoFlV); "finishes" (only when asked) the room book: each room's floor, walls (up to the slab or roof over it, less windows and doors, those up to "deductAbove" m² measured over), ceiling and skirting (less doors) with the finishes given by room {"finishes"}, and what each finish comes to for the tender; "materials" (only when asked) a material takeoff: the volume of each material in the walls, floors, roofs and stairs of a type, layer by layer, and its weight where the material has a density; "timber" a timber list of the framing members (rafters, studs, plates) alike in section and length, counted; "connections" the joints where framing members meet (rafters on purlins, studs on plates, collar ties on rafters, jack rafters on hips, joists on rims and headers), counted, each with what usually joins it (an anchor, nails, a bolt, a joist hanger; a tenon where the studs are tenoned): a list to order by and to hand the structural engineer, not a design. Walls and slabs in blocks count at the size the block places them. "place" writes the lists as tables into the drawing (totals by thickness, openings by size), "path" a spreadsheet with one row per wall or per window and door (German Excel takes ';' and decimal commas, the default when the interface is German).

JSON-Form: schedule {"of": "walls"|"openings"|"slabs"|"roofs"|"stairs"|"rooms"|"finishes"|"columns"|"beams"|"components"|"materials"|"timber"|"connections"|"all" (default all; finishes, materials, timber and connections only when asked), "per": "size"|"piece" (windows and doors counted by size, or one row each by position), "deductAbove": 2.5 (room book: windows and doors up to this many m² measured over), "ids": [...] (default: everything in the model, also when the tables go on a sheet), "renovation": "existing"|"demolish"|"new" (one stage of a conversion; for rooms also "before"|"after"), "place": [x, y, z] (write tables there), "path": "walls.csv" (write a spreadsheet of one list, "of" not all), "separator": ";"|","|"\t", "language": "en"|"de"}

Draws the setback areas (Abstandsflächen) before the outside walls of the building as it will be (what a conversion demolishes left out) as the Musterbauordnung §6 measures them: each wall's height H from the ground before it (the terrain shown, the planned one first; without one ±0, or "ground") to where it meets the roof's skin or to its top, a gable rising with its wall, a parapet or a wall above standing within half a meter behind the face counting; a roof steeper than "third" degrees (45) adds a third of its height, one steeper than "full" (70) all of it; the area square to the wall, "factor" × H deep (0.4), at least "minimum" meters (3). The states differ: 0.2 H in commercial areas; "factor": 0 with "minimum": 3 where a state allows 3 m for small houses; "gables": "third" where gables count a third; "third": 0 where any roof under 70° adds a third. Walls built up to a boundary (row and semi-detached houses) go in "exclude". Each storey's walls count (a storey set back gets its own areas), a curved wall's chords one area, a courtyard (no floor or roof over it) as outside, a partition standing free in a room not. Hatched on a layer of their own with H and T written in, replacing those drawn before; checked against the plot ("plot") and walls facing each other (enclosing no more than 75°), whose areas must not overlap. Areas may reach onto "streets" (public traffic, green or water areas beside the plot) up to their middle. Projections, bays and balconies standing out of a straight wall, are left out as §6 (6) says when they stand out no more than 1.5 m, take no more than a third of their wall together and stay 2 m from the boundary before them ("projections": {"share", "depth", "boundary"} as the state's code says; false counts them): the wall's area runs on across them. To be checked against the state's code; dormers standing back from the face get areas of their own.

JSON-Form: setbacks {"factor": 0.4, "minimum": 3 (meters), "third": 45, "full": 70 (roof slopes adding a third or all of a roof's height), "gables": "full"|"third", "plot": id (a closed polyline round the plot), "streets": [ids] (closed polylines round streets, public green or water beside the plot: the areas may reach onto them up to their middle), "projections": false | {"share": 0.33, "depth": 1.5, "boundary": 2} (bays and balconies left out), "exclude": [walls built up to a boundary], "terrain": id | "ground": z (default the terrain shown, else ±0 or the walls' foot)}

A shading study (Verschattung): where the buildings' shadows fall on the level ground at times of a day, from the sun's position at the drawing's place (from its georeference, or latitude and longitude given), as hatches on a layer of their own with the time at each shadow's tip. For a building permit the spring equinox (21 March) and 17 January are usual days. Masses, walls, roofs and other solids cast shadows as far as they stand above the ground (the terrain's height under them, else ±0 where they reach below it, else their foot), taken level; finely meshed things (trees) cast their outline's hull. Times when the sun stands lower than 2° are reported without a shadow.

JSON-Form: shadows {"date": "2026-03-21" (default the spring equinox), "times": ["09:00", "12:00", "15:00"] or "time": "15:00" (clock time; CET/CEST unless "utcOffset"), "latitude": 48.14, "longitude": 11.58 (default from the georeference), "north": 0 (where north lies in the drawing, degrees counter-clockwise from up; default from the georeference), "ids": [solids] (default all shown), "ground": z (default the lowest solid's foot)

Builds floors and ceilings: a slab under an outline, its top at the outline's height (or "top"), "thickness" down from there, as Revit places floors at a level. The outline comes from corners given, from closed polylines ("ids"), or from the walls round a room ("inside": a point in it; the slab then fills the room up to the inner faces of the walls standing on that floor, leaving out what stands in it apart, such as a shaft). It keeps its outline and thickness: grips drag its corners, primitive changes its thickness, schedule counts its area and volume. Outlines may have arcs (a round balcony). Laid to falls ("fall" in percent, "direction" the way down), its top rises uphill from its lowest edge while its bottom stays level; of a type, its top layer takes the fall, as a screed laid to falls. slabopening cuts openings into it. Without a thickness, the last one used, first 20 cm.

JSON-Form: slab {"points": [[x, y, z], ...] (its outline), "bulges": [b, ...] (arcs, as a polyline's) | "ids": [closed polylines or circles] | "inside": [x, y, z] (a point in a room of walls), "thickness": 0.2 or "type": "Geschossdecke 22" (a floor type), "top": z (its top face; default the points' height), "fall": 2 (percent), "direction": [x, y] (the way down)}

Cuts openings into a floor (slab) by hand, as Revit's shaft or floor openings: from corners, from closed polylines (arcs too) or circles drawn on it ("ids"; they stay). An opening must lie inside the floor, apart from its other openings. "remove" closes opening n again; with the floor alone it lists them with their corners and areas. The floor's area, volume, layers and framing (trimmers and headers round it) follow. Stairs cut their own opening into the floor they reach. In a conversion an opening has a stage as a wall's openings do: cut into a standing floor it is broken through (new), its piece in the demolition; "demolish" closes an opening up ("hole": n sets the stage of opening n).

JSON-Form: slabopening {"slab": id, "points": [[x, y], ...] (the opening's corners), "bulges": [b, ...] (arcs, as a polyline's), "renovation": "new" (broken through)|"demolish" (closed up)|"existing"|"" (default: as new work drawn into another stage is, like a wall's openings)} | {"slab": id, "ids": [closed polylines or circles], "renovation"} | {"slab": id, "hole": n, "renovation": "demolish"} (its stage) | {"slab": id, "remove": n} | {"slab": id} (lists them)

Kinds of floor and ceiling under a name, as Revit's floor types: their layers from the top down (screed, impact sound insulation, concrete or timber, plaster); a floor of the type (slab with "type", or primitive with "type") is as thick as its layers together, its top staying where it is. Changing a type changes all its floors at once; IFC exports the layers as materials. Deleting a type leaves its floors as they are.

JSON-Form: slabtype {} (lists them) | {"name": "Geschossdecke 22", "layers": [{"name": "Screed", "thickness": 0.05}, {"name": "Insulation", "thickness": 0.03}, {"name": "Concrete", "thickness": 0.18}]} (makes or changes one) | {"name": "..."} (shows it) | {"name": "...", "delete": true}

Builds a stair from its bottom step up to the floor above. Without "risers" and "going" its steps follow DIN 18065: risers of about 17.5 cm and treads making a stride of 63 cm (two risers and a tread), the message saying when the rule is not kept. "shape" "quarter" turns it at a landing by a quarter (an L), "half" back beside itself (a U), to the "turn" side; "winding": "winders" turns those corners with winders instead of landings, the treads balanced along the inner side (Verziehen) over the steps before and after the corner so the narrow ends keep the 10 cm DIN 18065 asks for; "spiral" winds it round a "spindle" (diameter, first 20 cm), its treads "width" long out from it (first 80 cm), their "going" measured on the walking line in their middle; "railing" puts railings along its sides (left and right going up): a handrail "railingHeight" above the nosings, posts at most 1.2 m and balusters at most 12 cm apart; "flights" with "turns" give flights one by one (degrees, positive to the left). It is a concrete stair with a waist "thickness" under the flights. A slab whose top it reaches gets a hole for it, leaving 2 m headroom over its treads ("hole": false not). Plans draw its walking line with a circle at the bottom, an arrow at the top and the cut line.

JSON-Form: stair {"start": [x, y, z] (the middle of the bottom step), "toward": [x, y] or "angle": degrees (which way it runs up), "rise": 2.75 or "top": z (the floor it climbs to), "width": 1, "risers": n, "going": a, "thickness": 0.16 or "type": "Holztreppe Eiche" (a stair type), "shape": "straight"|"quarter"|"half"|"spiral", "turn": "left"|"right", "winding": "landings"|"winders", "spindle": 0.2 (a spiral's), "railing": "left"|"right"|"both"|"none", "railingHeight": 0.9, "landing": risers below the landing, "gap": between the flights of a half turn, "flights": [8, 8], "turns": [90] (instead of shape), "hole": true}

Kinds of stair under a name, as Revit's stair types: "solid" ones in one piece with a "waist" under their steps (concrete), or "stringers" ones of two stringers along their sides with treads between them, the risers open (timber, steel): "tread" thick treads, "stringer" thick stringers "stringerDepth" deep, inside the stair's width. "waist" is also the landings' depth; "material" names what it is made of (IFC takes it along). A stair of the type (stair with "type", or primitive with "type") is built so; changing a type changes its stairs, deleting it leaves them as they are.

JSON-Form: stairtype {} (lists them) | {"name": "Betontreppe", "build": "solid", "material": "Stahlbeton", "waist": 0.18} | {"name": "Holztreppe Eiche", "build": "stringers", "material": "Eiche", "tread": 0.04, "stringer": 0.06, "stringerDepth": 0.28, "waist": 0.2} (makes or changes one) | {"name": "..."} (shows it) | {"name": "...", "delete": true}

The sun a presentation shows the model in, kept with the drawing (as SketchUp's shadow settings): with "shown" the 3D view lights the model from where the sun stands at the drawing's place (its georeference) on the day and at the time of day, casting shadows, under the sky; the published view in the browser starts there. The time is the place's clock (Central European time with summer time in Europe's middle, else by the longitude) unless "utcOffset" gives the hours ahead of UTC. A drawing without a place on the earth is lit from the south-west of the drawing. Without parameters: the settings and where the sun stands (azimuth from north, elevation). For shadows drawn into the plan at several times, see shadows.

JSON-Form: sun {"shown"?: true, "date"?: "2026-06-21"|"today", "time"?: "15:00", "utcOffset"?: 2|null} | {} (where it stands)

The buildings around the drawing's place from OpenStreetMap, as bodies of their height on a layer of their own ("Umgebung (OpenStreetMap)"; those of unknown height, guessed from storeys, on another), and the trees mapped there (trunk and crown, conifers as cones, 10 m high unless known) on a third, parks, lawns, woods and water as flat areas (within the radius, the plot left out) on a fourth, and streets and paths as bands of their width (from "width", their lanes or their kind) on a fifth, for the site plan, shadows and the presentation. Needs a georeference in a UTM system (georef). Fetched from the Overpass API (the drawing's place goes there); run again, it replaces what it brought. Buildings standing on the plot (massing "plot") stay out: they are the user's to draw. The data is © OpenStreetMap contributors (ODbL): name it wherever it shows.

JSON-Form: surroundings {"radius": 150 (meters around), "center": [x, y] (default the plot's middle, else the model's), "levels": 2, "levelHeight": 3 (for buildings of unknown height), "trees": true, "areas": true, "streets": true, "file": "answer.json" (an Overpass API answer instead of fetching)

Builds walls: a solid along a path of straight pieces and arcs ("bulges", as a polyline's) with mitred corners, a thickness and a height, standing on the height of its points (or "base"). "align" says where the path lies: in the wall's middle, or on its left or right face looking along the path (draw along the outside of a house with the right setting). "close" goes round a room. With "ids" it builds a wall along each line, polyline, arc or circle already drawn, which stay. Walls keep their measures: change thickness, height and align with primitive, drag corners and the height with grips. Floor plans show them cut (layout with "cut"). An end that lies in a wall already there (an inner wall drawn to the outer wall's middle) stops at its face, so walls butt ("join": false keeps it). This replaces AutoCAD's multiline: the double line is the wall seen from above. Without measures, the last ones used, first 24 cm by 2.5 m.

JSON-Form: wall {"points": [[x, y] or [x, y, z], ...] (corners, at least 2), "bulges": [b, ...] (one per point: the piece after it bent into an arc, as a polyline's), "close": bool (round a room), "thickness": 0.24, "height": 2.5, "align": "center"|"left"|"right", "base": z, "join": bool (default true), "type": "AW 36,5" (instead of thickness), "flip": bool, "curtain": true | {"spacing", "transoms", "mullion", "glass"} (a curtain wall)} | {"ids": [lines, polylines, arcs and circles], ...the same measures} (walls along them)

Kinds of wall under a name, as Revit's wall types: their layers (plaster, masonry, insulation, ...) from the wall's left face to its right one, looking along the wall's path; a wall of the type is as thick as its layers together (wall with "type", or primitive with "type" for one that stands). Changing a type changes all its walls at once; floor plans draw the lines between the layers, and schedule sums the areas per layer. Deleting a type leaves its walls as they are.

JSON-Form: walltype {} (lists them) | {"name": "AW 36,5", "layers": [{"name": "Plaster", "thickness": 0.015}, {"name": "Masonry", "thickness": 0.24}, ...]} (makes or changes one) | {"name": "AW 36,5"} (shows it) | {"name": "AW 36,5", "delete": true}

Puts a window into a wall: a hole through it, its middle at the point given (moved onto the wall's path) or so far along the path, so wide and high, starting "sill" above the wall's foot. It belongs to the wall: moves with it, shows as a gap in floor plans cut through it, and is listed, changed and closed up with opening. It must lie within one straight piece of the wall. Without measures, the last ones used, first 1.01 by 1.26 m with a 0.9 m sill. A window "type" (openingtype) gives its size and how it is built (frame, sashes, glazing bars, sills; "inside" says which side the inner sill goes).

JSON-Form: window {"wall": id, "at": [x, y, z] (at the wall: its middle) or "distance": d (along the path), "width": 1.01, "height": 1.26, "sill": 0.9, "type": "Fenster 2-flg" (its size and build) | "component": "Rundfenster", "componentType": "...", "values": {...} (a window component fills it), "inside": "left"|"right"}

An alignment (Achse) of a road, a track or a sewer, as road design lays one out: straights, circular arcs and clothoids. Along a tangent polygon (its corners, or a selected polyline), each inner corner rounded by an arc of "radius", led in and out by clothoids of parameter "clothoid" (A, the transition from straight to curve; "curves" gives each corner its own radius and unequal clothoids in and out); refused where curves overlap on a leg. Or element by element ("elements"), as OKSTRA files and design programs list them. Its main points (where elements meet) are snap points; stationing, cross sections and long sections run along it. DWG and DXF get it as a polyline. Given an alignment's "ids" with "radius", "clothoid" or "curves" (null keeps a corner as it is), it is changed: its curves laid anew over its own tangent polygon, its name, first station and gradient kept.

JSON-Form: alignment {"points": [[x, y, z], ...] (the tangent polygon's corners) | "ids": [a polyline: the polygon] (default the selection), "radius": 50 (m, each inner corner), "clothoid": 30 (A, in and out; 0 none) | "curves": [{"radius": 50, "in": 30, "out": 20}, ...] (each inner corner its own) | "elements": [{"kind": "line", "length": 17.15}, {"kind": "clothoid", "length": 25, "startRadius": 0, "endRadius": 100}, {"kind": "arc", "length": 46.79, "radius": 100}, ...] with "from": [x, y, z], "direction": degrees (from the x axis, counter-clockwise); radii positive to the right, negative to the left; "start": 0 (its first station, m), "name": "A1"} | {"ids": [an alignment], "radius": 80 | "clothoid": 40 | "curves": [{"radius": 80, "in": 40, "out": 40}, null, ...]} (changes it)

Checks an alignment and its gradient as road design guidelines (RAL, RASt, RAA) have the designer check them (Trassierungsprüfung), against the limits given for the road's class and speed; the program holds no table of them. In plan: the least radius, each clothoid's A against the radius it leads to ("clothoidRange", A/R, as R/3 ≤ A ≤ R), neighbouring radii's ratio, straights between curves turning the same way and over-long ones. In height: grades, crest and sag radii, and the sight distance over each crest from the eye's and the object's heights. Lists each element and vertical curve with what it is, and each finding with its station. Changes nothing.

JSON-Form: alignmentcheck {"ids": [an alignment] (default the selection), "minRadius": 100, "clothoidRange": [0.333, 1] (A/R), "maxRadiusRatio": 1.5, "minStraight": 50 (m between curves the same way), "maxStraight": 1500, "maxGrade": 8, "minGrade": 0.5 (%), "minCrest": 2500, "minSag": 1000 (m), "sight": {"eye": 1.0, "object": 0.45, "least": 85} (m) — each only checked when given, the values the guidelines give for the road's class and speed}

The official cadastre (ALKIS) from a NAS file, as the surveying authorities give it (open data downloads, their NAS WFS): parcels (AX_Flurstueck) and buildings (AX_Gebaeude) as closed polylines with their arcs, on layers of their own, each parcel named by its number ("Flst. 210/3") with the number in its middle, 2 mm high on paper. In ETRS89/UTM or Gauss-Krueger; a drawing without a place takes the file's, one in another system is refused. Name the source as the data's terms ask.

JSON-Form: alkis {"path": "flurstuecke.xml" (NAS), "parcels": true, "buildings": true, "numbers": true, "language": "en"|"de"}

Checks measured points against the ground as planned (Aufmaß, Soll-Ist): each point's measured height beside the planned terrain's there, how far apart (+ above, - below), and whether within the tolerance (3 cm by default); the mean and the worst. The points come from a surveyor's file ("path", read as survey reads it, through the georeference; they are added on a layer of their own) or are points in the drawing. "mark" writes each deviation beside its point, green within the tolerance and red beyond; "place" draws the list as a table.

JSON-Form: asbuilt {"path": "aufmass.csv" (a surveyor's point file, as survey reads it) | "ids": [points] (default: the selection), "terrain": id (default the planned ground, else the only one), "tolerance": 0.03 (m), "mark": true (each deviation beside its point, green within, red beyond), "place": [x, y, z] (the table there), "language": "en"|"de"}

Fits the drawing onto points measured on site, as a GNSS rover's site calibration does: a plan in local site coordinates onto UTM, or a scanned plan onto the surveyor's points. The best turn, shift and scale over all passpoints (least squares, a 2D Helmert transformation), heights by one shift or a tilted plane. Lists what is left at every passpoint and names those beyond the tolerance (taken wrong, or moved); with two points nothing checks the fit. "apply": false only checks. The pairs' coordinates are in the drawing's units.

JSON-Form: calibrate {"pairs": [{"from": [x, y, z] (in the drawing), "to": [E, N, H] (where it lies), "name": "P1"}, ...] (2 or more), "scale": bool (default true), "heights": "shift" | "plane" | "none" (default shift), "tolerance": meters (default 0.02), "apply": bool (default true; false only checks), "ids": [id, ...] (default: the selection, or the whole model), "crs": "EPSG:25832" (records the system the drawing is in then)}

Writes the heights on a terrain's contour lines, as site and survey plans have them: on the index lines (every metre where the lines are closer, else every fifth line, or "every"), along the line and readable from below or the right, a label every "distance" along it (60 mm on paper by default) and at least one on each line long enough. They are texts on a layer of their own; run it again after the terrain changed: the labels of before on that layer are replaced.

JSON-Form: contourlabel {"id": terrain (default the planned one, else the only one), "every": 1 (m in height between labelled lines; default every metre, or every fifth line), "distance": 30 (m along a line between labels; default 60 mm on paper), "layer": "Höhenlinien Beschriftung"}

The road body along an alignment (Straßenkörper, a corridor): its typical sections (roadsection) built at stations with the cross slope band (crossslope), the lowered curbs (curbdrop) and the ground as it is, the slopes running down or up to it. Makes the feature lines (3D polylines, one per point of the section), a solid per layer of each part and the curb stones, and the planned ground: the formation (Planum) set into the ground as it is, which earthwork counts against; with "surfaces" also the finished surface, the formation and the top of each layer as terrains, for machine control (export LandXML). Where a structure carries the road ("structures", a bridge's stations), its layers are built but the ground under it stays as it is. Reports each layer's volume, counted along the curve. Running it again replaces what it made before for this alignment. One undo step.

JSON-Form: corridor {"ids": [an alignment with its gradient and typical sections] (default the selection), "from": 0, "to": 250 (stations, m; default all of it), "step": 5 (m between stations; closer in curves, and at every main point and band station), "terrain": id (the ground as it is; default the one there is), "lines": true (feature lines through the section's points), "solids": true (each layer of each part a solid, curb stones), "ground": true (the formation set into the ground as it is: the planned ground, the old one kept and marked to go), "surfaces": false (true: the finished surface, the formation and the top of each layer as terrains of their own, for machine control), "structures": [[38.0, 52.0], ...] (stations where a bridge carries the road: its layers built, the ground under it left as it is), "language": "de"}

Draws cross sections (Querprofile) across a way every so many meters: the ground as it is and, with a planned ground ("planned", or the drawing's terrain marked new, as earthwork takes it), as it will be, each section over its own datum with its station, and the areas to dig (cut, Abtrag) and to fill (Auftrag) in it. A table sums the volumes between neighbouring sections by the mean of their areas (average end areas, the principle of REB 21.003 without its correction for curved axes); earthwork counts the volume exactly from the terrains. The sections' lines across the way are drawn in the plan with their stations (0+020,00).

JSON-Form: crosssections {"ids": [one alignment, line or polyline: the way] (default: the selection), "existing": terrain (the ground as it is), "planned": terrain (as it will be: cut and fill); default the drawing's terrains, the one marked new as planned, "every": 20 (meters between sections), "stations": [0, 15.5, ...] (instead of "every"; an alignment's own stations), "width": 30 | [left, right] (meters across; default 15 each side), "scale": 200 (for its texts), "exaggeration": 1, "columns": 3, "place": [x, y, z] (the grid's top left; default beside the drawing), "language": "en"|"de"}

The cross slope band of a road (Querneigung, Schrägneigungsband): each side's fall at stations, changing linearly between them (Verwindung); the lanes of the alignment's typical section follow it. Reports each transition's ramp gradient Δs = Δq·a/L (a: the lanes' reach from the axis) and the flattest resulting fall √(s²+q²) with the gradient's grade; against limits the designer gives (maxRamp, minRamp where the fall turns over, minFall) it names where they are broken. Draws the band like a long section's ("draw"). One undo step.

JSON-Form: crossslope {"ids": [an alignment] (default the selection), "points": [[0, -2.5, -2.5], [40, -2.5, -2.5], [70, 4, -4]] (station m, left and right fall in %, rising outward: -2.5 falls away from the axis; [station, both] for one value; linear between them, the Verwindung), "maxRamp": 2.0, "minRamp": 0.4, "minFall": 0.5 (the designer's limits in %: ramp gradient Δs = Δq·a/L, and the resulting fall √(s²+q²) with the gradient), "draw": [x, y] (the band as a long section's), "scale": 500, "language": "de"} | {"ids": ..., "at": [12.5, 40]} (the falls there) | {"ids": ..., "remove": true}

A lowered curb (Bordabsenkung) at a driveway or a crossing: the first curb on that side of the alignment's typical section stands at the given reveal from one station to another, ramping down to it and up again over "ramp"; the footway behind it falls to it, its back edge staying where it was.

JSON-Form: curbdrop {"ids": [an alignment] (default the selection), "from": 32.5, "to": 38.5 (stations, m) and "side": "left"|"right"|"both" | "points": [[x, y], [x, y]] (the ends beside the road: stations and side from them), "height": 0.03 (its reveal there, m), "ramp": 1.0 (m to go down and up again)} | {"ids": ...} (lists them) | {"ids": ..., "clear": true}

A terrain from a digital terrain model as the surveying authorities publish it: DGM1 tiles (a height every meter, free in Bavaria, NRW and most other states) as GeoTIFF or as "x y z" grids. It takes the drawing's area with "margin" meters round it (or "area", or the whole file in an empty drawing), every "step" meters, coarser where more than 50000 heights would come. The drawing gets the file's reference system when it has none yet; a file in another one (Gauss-Krueger into UTM) comes converted. For an offer before the survey: the state's ground is good to a few decimeters, a surveyor's points replace it for the job.

JSON-Form: dtm {"path": "726_5297.tif" (a GeoTIFF or an "x y z" grid) | "paths": [tiles, ...], "margin": 20 (m round the drawing), "area": [[x, y], [x, y]] (opposite corners in the drawing, instead), "step": 1 (m between the heights taken; default the file's, coarser beyond 50000), "crs": "EPSG:25832" (when the file does not say), "datum": "DHHN2016" (the heights' datum, for a drawing not yet on the map), "contours": 0.5}

The earth to move between the ground as it is and as it will be (two terrains): cut (Abtrag, where the planned ground lies lower: a building pit, a levelled plot) and fill (Auftrag, where it lies higher), in m³, over the area both cover, and what is left to take away or bring. Exact for the two surfaces. Model a building pit as the planned terrain (its bottom and sloping sides). Without ids it takes the drawing's two terrains, the one marked new (renovation) as the planned one. For the offer and the trucks: "topsoil" the topsoil stripped first where the ground changes by 5 cm or more (its depth), "swell" the factor dug soil grows by on the truck (Auflockerungsfaktor, 1.25 for ordinary soil), "load" what a truck or container takes, giving the loads for the surplus; "place" draws the protocol (Massenermittlung: each figure, the terrains and the method) as a table, "path" writes it as a spreadsheet; "prisms" lists every prism of the overlay (where it lies, its area, cut and fill) as a spreadsheet to check the sums by, as REB 22.013 (volumes from prisms) has them. "soils" splits the cut by homogeneous zones (Homogenbereiche, DIN 18300) lying in layers under the ground as it is, each down to a depth the soil report gives; the protocol lists each.

JSON-Form: earthwork {"existing": terrain (the ground as it is), "planned": terrain (as it will be); default the drawing's two terrains, the one marked new as planned; "topsoil": 0.2 (stripped first, m), "swell": 1.25 (dug soil's loosening), "load": 10 (m³ a truck or container takes), "place": [x, y, z] (the protocol as a table there), "path": "massen.csv", "prisms": "prismen.csv" (each prism listed, REB 22.013), "soils": [{"name": "HB 1 Oberboden", "depth": 0.3}, {"name": "HB 2 Sand, Kies", "depth": 2.0}, {"name": "HB 3 Ton"}] (the cut per homogeneous zone, depths below the ground as it is), "separator": ";"|","|"\t", "language": "en"|"de"}

Where the drawing lies on the earth: a projected coordinate system by its EPSG code ("EPSG:25832" ETRS89 / UTM 32N, "EPSG:25833" UTM 33N, "EPSG:4647" UTM 32N with the zone in front of the eastings), the map coordinates of the drawing's origin or of a point of it (a survey point on the site plan), its height above the datum, and how far the drawing is turned from grid north. Written into IFC files as IfcMapConversion, with the site's latitude and longitude and true north, so IFC viewers and Revit place the building where it stands. A place can be given by its name or address ("place", found with OpenStreetMap's geocoder, so its name goes there) or by latitude and longitude: the drawing's origin (or "point") then lies there, in the UTM zone's system (ETRS89 in Europe, else WGS 84; northern half). Moving a drawing to another place this way, surroundings and sun follow when asked. "at" and "map" convert between drawing and map coordinates.

JSON-Form: georef {} (says where it lies) | {"place": "Kollwitzplatz, Berlin"} or {"latitude": 52.536, "longitude": 13.417} (the origin, or "point", lies there; "crs" chosen by the zone unless given) | {"crs": "EPSG:25832", "eastings": E, "northings": N, "height": H (the origin's, meters), "rotation": degrees (grid east to the drawing's X, counter-clockwise), "heightDatum": "DHHN2016"} | {"crs", "point": [x, y, z] (a drawing point), "eastings", "northings", "height" (where that point lies)} | {"at": [x, y, z]} (its map coordinates) | {"map": [E, N, H]} (its place in the drawing) | {"remove": true}

Grades the ground as it will be round a building (Revit's graded region and building pad): the area (its corners, or a closed polyline) set level at "height" (or "depth" below the ground along its edge: a pit dug 1.5 m in), its edges sloping out at "slope" degrees until they meet the ground, cut where the ground lies higher and filled where it lies lower. The first time the ground as it is stays as it was, marked to change (renovation demolish), and the graded ground is a new terrain marked new, so sections draw the ground as it was dashed, setbacks and wall heights take the planned one, and earthwork counts the difference; a further area grades the planned ground further. Cut and fill in m³ come at once.

JSON-Form: grade {"points": [[x, y], ...] (the area's corners) | "id": closed polyline, "height": z (default the ground's along its edge) | "depth": 1.5 (m below the ground along its edge: a pit), "slope": 33.7 (the edges' angle, degrees; 1 in 1.5), "terrain": id (default the planned ground, else the one there is)}

The gradient (Gradiente) of an alignment: its heights along it as road and sewer design gives them, a polygon of tangents through vertices at stations and heights, each inner vertex rounded by a vertical curve of radius H (Ausrundung, a quadratic parabola; tangent length T = H·Δs/2). Refused where curves overlap or the stations leave the alignment. The long section along the alignment draws it with its vertices, curves and grades; "at" tells height and grade at stations. One undo step; "remove" takes it off again.

JSON-Form: gradient {"ids": [an alignment] (default the selection), "points": [[0, 500.5], [40, 502, 250], [80, 498.5, 162.79], [159.48, 500]] (vertices: station, height, radius H of the vertical curve, in meters; heights on the map, NHN when the drawing lies on it) | "remove": true | "at": [12.5, 40] (stations: height and grade there, nothing changed)}

A house connection (Hausanschluss) of a sewer: a branch on the main pipe (across from the handover point, or at a station "at"), into it at its springline by default, and a pipe rising at "slope" percent to the handover point at the property's boundary, where an inspection opening stands. Both ends are ports, so the pipe follows when they move; it takes the main pipe's system. Tells the inverts at both ends and, over a terrain, how deep it lies at the boundary. "list" draws the house connection list (Hausanschlussliste): property, pipe and station of the branch, inverts, size, length, slope and depth. With "gully" the same for a road gully's connection (Straßenablaufleitung), ending at the gully, and listed apart from the houses. On a water main or a power cable (by its system, or "kind") a service instead: the main split by a tapping saddle (Anbohrschelle) or a branch joint (Abzweigmuffe) where it branches off, so the network stays one, and the service at its least cover ("cover") to its end, a point or a house connection box's or meter's port; ids made: the tee, the main's rest, the service. The list with "kind" lists them.

JSON-Form: houseconnection {"pipe": the main pipe (a connection; default the selection), "to": [x, y] (the handover point at the property's boundary; a water or power service's end, or {"id": a house connection box or meter, "port": "a"}), "at": 12.5 (station along the main pipe in m; default across from "to"), "type": "DN 150 PVC" (a water service "PE 100 SDR 11 d32", a power one "NAYY-J 4x35 SE"), "slope": 2 (percent, rising to the property), "entry": "springline"|"crown"|"invert", "kind": "sewer"|"water"|"power" (default by the main's system), "cover": 1.0 (m, a water or power service's least cover; default water 1.0, power 0.6), "name": "Flst. 112/4" (the property), "gully": true (a road gully's connection instead, "to" the gully), "existing"/"planned": terrains (for its depth) | "list": true with "place": [x, y, z] (the house connection list of them all; with "gully": true the gullies', with "kind" the water or power services), "language": "en"|"de"}

The level book (Deckenbuch) of a road, as setting out and the paver use it: at round stations (every "step", 10 m), the main points and every band station, the axis' height, each side's cross fall and every edge of the finished surface across (each point of the typical section: lanes, gutters, curbs front and back, footways, the slopes' feet) with its offset from the axis and its height, the cross slope band and lowered curbs built in. As a list, a table on the drawing ("place") or a spreadsheet ("path"). Heights as the map has them.

JSON-Form: levelbook {"ids": [an alignment with its gradient and typical sections] (default the selection), "from": 0, "to": 250 (stations, m), "step": 10 (m; and every main point and band station), "terrain": id (the ground, for the slopes' feet), "place": [x, y] (as a table there), "path": "deckenbuch.csv" (as a spreadsheet), "separator": ";", "language": "de"}

Draws the long section (Längsschnitt) along a sewer or a trench, as civil engineers draw it: the ground along the way and the planned ground, the pipe at its inverts with its crown by the nominal size ("DN 250" in its type), the manholes from invert to cover, and under it the bands: ground heights and stations every so many meters and at each manhole, cover and invert heights, manhole depths, each pipe's name, length between the manholes' middles, type and fall in per mille. From the pipes of a network it follows the longest run, upstream down (branches, as house connections, are left out); a line or polyline gives the way, and its heights the pipe where it has them. Lengths true at the section's scale, heights stretched. Drawn once, from the drawing as it is: again after changes.

JSON-Form: longsection {"ids": [the pipes of a run (connections), or one line or polyline] (default: the selection), "existing": terrain (the ground as it is), "planned": terrain (as it will be); default the drawing's terrains, the one marked new as planned, "place": [x, y, z] (its lower left; default under the drawing), "scale": 500 (the section's scale, 1:500, for its texts), "exaggeration": 10 (heights so many times their length), "datum": m (the reference height; default a whole meter under all), "every": 10 (ground heights and stations every so many meters), "language": "en"|"de"}

The building pit (Baugrube) as the ground will be dug: its sole under the lowest floor slab and its blinding, a working space round the building's outline, the sides sloping up at the angle the soil allows (DIN 4124: 45° loose soil, 60° stiff cohesive soil, 80° rock) until they meet the ground. It becomes a planned terrain (marked new; the ground as it is marked to be removed), so the changes view shows both and earthwork counts cut and fill; the cut is reported at once.

JSON-Form: pit {"terrain": id (default the drawing's terrain), "ids": [slabs or walls] (default all; the lowest floor slabs, else walls, count), "workspace": 0.5 (working space round the building, m), "blinding": 0.1 (under the slab), "slope": 60 (the sides' angle, degrees: DIN 4124 45 for loose soil, 60 for stiff cohesive, 80 for rock)}

Converts a drawing from one map system to another: an old plan in Gauß-Krüger (DHDN, EPSG:31466 to 31469) to ETRS89 / UTM (EPSG:25832, 25833; 4647 with the zone in front) and back, or between UTM zones. The datum change goes by the surveying authorities' grid BeTA2007, built in, sub-meter all over Germany; for centimeters give a state's NTv2 grid from the surveying office ("grid"), or fit the plan onto measured passpoints with calibrate. Points and lines are converted exactly, solids and blocks turn and scale with the plan round them; heights are kept. With a georeference the drawing keeps its own coordinates, and its georeference moves with it; "objects": false only moves the georeference (a model kept at true size). Sheets keep showing the same part of the plan.

JSON-Form: reproject {"to": "EPSG:25832" (default: ETRS89 / UTM where the drawing lies), "from": "EPSG:31468" (default: the drawing's georeference, else told by its numbers), "ids": [id, ...] (default: the selection, or the whole model), "method": "grid" | "helmert" (default grid), "grid": "path/to/state.gsb" (an NTv2 grid for DHDN to ETRS89; default the built-in BeTA2007), "objects": bool (default true; false only moves the drawing's georeference)}

The road body's bill of quantities (Schichtmassen) along an alignment, without building it: each layer of the build-ups in m² (in plan at its top) and m³, grouped by name, thickness and material; curbs in m with the lowered stretches (curbdrop) apart; gutters in m; slopes in cut and in fill and unpaved parts (verges, shoulders, ditches) in m² along their surface, for topsoil and seed. Measured at the typical section of each station, in curves at each band's centroid (Pappus). As a list, a table on the drawing ("place") or a spreadsheet ("path").

JSON-Form: roadquantities {"ids": [an alignment with its gradient and typical sections] (default the selection), "from": 0, "to": 250 (stations, m), "step": 5, "terrain": id (the ground as it is, for the slopes), "place": [x, y] (the list as a table there), "path": "mengen.csv" (as a spreadsheet), "separator": ";"|","|"\t", "language": "de"}

A road's typical section (Regelquerschnitt): parts laid outward from the axis on each side, each with its width, cross fall and build-up (Oberbau: layers from the top down, thicknesses as the designer takes them from RStO's tables; the program knows no norm values). Lanes follow the alignment's cross slope band (crossslope) where it has one, curbs lowered by curbdrop; curbs stand up by their reveal; ditches sink by their depth; slopes run 1:n to the existing ground. Kept in the drawing by name, given to alignments ("ids", from a station on for sections that change along the road), drawn as the section drawing with widths, falls and build-ups ("draw"); with "utilities" the pipes and cables at a station of an alignment as they lie under it (the networks' connections cut square to the axis), each with its depth under the surface, and over it the zone each system takes across (DIN 1998).

JSON-Form: roadsection {"name": "RQ 9", "both": [{"kind": "lane", "width": 3.0, "slope": -2.5, "pavement": "Fahrbahn"}, {"kind": "gutter", "width": 0.3, "slope": -2.5, "pavement": "Fahrbahn"}, {"kind": "curb", "width": 0.15, "height": 0.12}, {"kind": "footway", "width": 2.5, "slope": 2.0, "pavement": "Gehweg"}, {"kind": "slope", "cut": 1.5, "fill": 1.5}] (or "left" and "right", each from the axis outward; kinds: lane, gutter, curb, footway, cycleway, verge, shoulder, ditch ("depth", "bottom"), slope (1:"cut", 1:"fill" to the ground), link ("height": a step); widths and heights in m, "slope" the cross fall in % rising outward, a lane following the alignment's cross slopes unless "crossSlope": false; a curb's "height" its reveal, "face" its batter), "pavements": [{"name": "Fahrbahn", "layers": [{"name": "Asphaltdeckschicht", "thickness": 0.04}, {"name": "Asphalttragschicht", "thickness": 0.14}, {"name": "Frostschutzschicht", "thickness": 0.45}]}], "ids": [alignment] (give it to them), "from": 120 (from this station on; else all along), "draw": [x, y] (its drawing, the RQ-Plan), "scale": 50, "utilities": {"alignment": id, "station": 40, "width": 30} (the pipes and cables cut there, with their depths and zones), "language": "de"} | {"name": ..., "remove": true} | {} (lists them)

The simple hydraulics of a small sewer network (Fließzeitverfahren), as designers check it in the CAD before a hydrodynamic model: downstream the reduced catchment (area × runoff coefficient) adds up, the flow time grows with the time through the pipes above, the rain's intensity for it comes from the designer's table (the site's KOSTRA values), Q = r(t)·A_red plus constant inflows. Each pipe's capacity full by Prandtl-Colebrook (kb as given, at its fall), its filling h/d and velocity carrying Q, its load; against the limits given. As a protocol table ("place") or spreadsheet ("path"); changes nothing in the drawing but the table.

JSON-Form: sewerflow {"ids": [the sewer's pipes] (default the selection), "rain": [[5, 260], [10, 180], [15, 140], [30, 90]] (the site's intensities in l/(s·ha) by duration in min for the return period, KOSTRA) | 150 (one intensity), "roughness": 1.5 (operational kb, mm), "areas": [{"pipe": id, "area": 0.25 (ha), "runoff": 0.8}], "inflows": [{"pipe": id, "flow": 2.0 (l/s)}], "startTime": 5 (min at the heads), "temperature": 10 (°C), "maxLoad": 90 (%), "minVelocity": 0.5, "maxVelocity": 6 (m/s), "place": [x, y], "path": "hydraulik.csv", "separator": ";", "language": "de"}

A sewer's heights (Kanalhöhen) as the designer works them out: the manholes' covers from the road surface (alignments with their typical sections) or the planned ground; the inverts downstream from the top with each pipe's fall, as high as the least cover over the crown allows and never above what flows in; where the ground falls faster than the pipe, a drop (Absturz) at the manhole, drawn as the incoming pipe's upright last piece. Then the rules: least and greatest fall, least cover, drops higher than allowed, pipes running uphill. The manholes stretch from their cover to their bottom; the pipes' ends stay on their ports. With "check" only the rules. Heights in m as the map has them (NHN when the drawing lies on it). One undo step.

JSON-Form: sewerheights {"ids": [the sewer's pipes] (default the selection), "road": [alignments] (their road surface covers the sewer, else the terrain), "terrain": id (default the planned ground, or the only terrain), "cover": true (set the manholes' covers from that surface), "start": 98.40 (the invert at the top, m; default as high as the least cover allows), "fall": 5 (‰ for every pipe; default each keeps its own), "minCover": 1.2 (m over the crown), "wall": 0.05 (m, the pipe wall over its DN), "minFall": 3, "maxFall": 100 (‰), "maxDrop": 0.5 (m before a drop structure), "check": true (only check, change nothing)}

The trench a sewer is laid in, counted along its pipes (Leitungsgraben, Massen): each pipe's trench from the ground down to its bedding under the pipe's outside bottom, as wide as the pipe (DN from its type and "wall") and the working room ("space" each side, or the designer's "widths" by size after DIN EN 1610), its walls upright or at "sides" degrees. Gives the pipe laid by type (m), the excavation, the shoring of both walls where upright and deeper than "shoreFrom" (m², DIN 4124), the bedding, the pipe zone up to "cover" over the crown and the backfill (m³), and what leaves the site loosened and in loads; as a table ("place") or a spreadsheet ("path"). Drops in manholes are left out; manhole pits are not counted.

JSON-Form: sewertrench {"ids": [the sewer's pipes] (default the selection), "terrain": id (default the planned ground, else the only one), "wall": 0.025 (m, the pipe wall over its DN), "space": 0.2 (m working room each side) | "widths": [[0.225, 0.4], [0.35, 0.5], [0.7, 0.7]] (up to DN m: width added to the outside diameter, the designer's table after DIN EN 1610), "sides": 90 (degrees; 90 upright), "shoreFrom": 1.25 (m: upright walls deeper are shored, DIN 4124), "bedding": 0.1, "cover": 0.3 (pipe zone over the crown), "swell": 1.25, "load": 10, "place": [x, y], "path": "graben.csv", "separator": ";", "language": "de"}

Writes points to set out on site (Absteckung) as a point file a surveyor's instrument reads: the selected points, the corners of lines and polylines, where blocks are placed, each place once, numbered from "start" (with "prefix" in front), in map coordinates (eastings, northings, height above the datum) when the drawing has a georeference, else in meters as drawn; with "heights": "ground" each point's height is the terrain's there (the planned ground: a pit's outline drawn flat gives its corners at the pit's bottom). The code is the layer's name or the block's. Columns as "format" says (default PENZD: number, eastings, northings, height, code); with ';' the decimals have a comma, as German programs read them.

JSON-Form: stakeout {"ids": [points, lines, polylines, blocks] (default: the selection), "path": "absteckung.csv", "heights": "drawn"|"ground" (the terrain's at each point), "format": "PENZD"|"PNEZD"|..., "start": 1, "prefix": "A", "separator": ";"|","|"\t", "axis": alignment, line or polyline (each point's station and offset, right +, as two more columns), "axisStart": 0 (the axis's first station, m)}

Stations along a way (an axis, a trench, a kerb), as road and sewer plans show them: a tick across the way every "every" meters with its station beside it (0+020,00), longer every fifth and at both ends; "start" gives the way's first station. With "points" nothing is drawn: each point's station along the way and its offset beside it (right of the way positive, left negative), as setting out gives places. stakeout with "axis" writes them into the point file.

JSON-Form: stationing {"ids": [one alignment, line or polyline: the way] (default: the selection), "every": 20 (m between ticks), "start": 0 (the way's first station, m; an alignment's own by default), "scale": 1000 (the plan's, for its ticks and texts; default the drawing's), "points": [[x, y], ...] (instead of ticks: each one's station and offset, right +), "language": "en"|"de"}

A part of the ground with a surface of its own, as Revit's subregions: a lawn, a bed, a path, a paved court. A thin skin (2 cm) lying exactly on the terrain inside a closed outline, drawn on the current layer in its colour, its outline on the ground its only line. Each closed polyline makes one; arcs are followed. It keeps a copy of the terrain it lies on, so it is built without it and follows when the terrain command changes that terrain (one that would then reach off the ground stays as it was). With "id" it changes a subregion's outline, skin or terrain; "terrain" with "id" lays it on a terrain again.

JSON-Form: subregion {"ids": [closed polylines] (default: the selection) | "outline": [[x, y], ...], "terrain": id (default the drawing's ground: the planned one, else the one there is), "thickness": 0.02 (its skin, default 2 cm); "id": subregion with "outline", "thickness", "terrain" to change it}

Reads a surveyor's point file (Vermessung einlesen): a point a row with its number, eastings (Rechtswert), northings (Hochwert), height and code, split by ';', ',', tabs or blanks, decimals with a point or a comma. The columns' order comes from "format" (P number, E eastings, N northings, Z height, D code: PNEZD as Civil 3D writes, PENZD as German surveyors mostly do), else from a header row (Punkt, Rechtswert, Hochwert, Höhe, Code), else from the numbers themselves (UTM northings have seven digits, eastings six or eight with the zone in front). Each point goes on a layer of its code ("Vermessung BO"), its height written beside it. Map coordinates (ETRS89/UTM, Gauß-Krüger) come in through the drawing's georeference, so the drawing keeps small numbers and each point stays where the map has it; a drawing without one gets one at the points (EPSG:25832 for UTM zone 32, the zone written in front of the eastings taken off). Points in another system than the drawing's, as Gauß-Krüger into a UTM drawing, are converted to its (the datum by the surveying authorities' grid BeTA2007); "to" converts them anyway. Points of the codes in "lines" join, in the file's order, into 3D polylines (Bordstein, Böschungskante); "terrain" builds the ground from the points with those lines as breaklines. stakeout writes points out again.

JSON-Form: survey {"path": "points.csv" (CSV or text: number, eastings, northings, height, code), "format": "PENZD"|"PNEZD"|"ENZ"... (default: the header's names, else from the numbers), "crs": "EPSG:25832" (default from the numbers: UTM with the zone in front, else zone 32), "to": "EPSG:25832" (convert them; points in another system than the drawing's are converted to its), "datum": "DHHN2016", "layer": "Vermessung" (the layers' names start so, one a code), "labels": true (heights beside the points), "lines": ["BO", "BK"] | true (codes whose points, in the file's order, are lines: kerbs, slope edges), "terrain": true (build the ground from them, the lines as breaklines)}

The ground, as Revit's toposurface and Archicad's mesh: a solid whose top runs through survey points (triangulated between them, Delaunay), its sides upright round them, its bottom level "depth" below the lowest (2 m), with contour lines every "contours". The points come from the selected objects: points, polylines' corners, lines' ends, point blocks where they are placed, each at its height (a point block's height attribute, tagged H, HOEHE, Z ... or "tag", gives it); with "texts": true numbers written in the plan (123,45) are heights: each point takes the nearest one beside it, numbers left over are points themselves, points without one keep their own height (left out when that is 0, drawn flat); lines and polylines drawn flat count as spot heights' symbols when short (a cross, a triangle: a point at their middle) and are left out when long (a plan from a PDF or a 2D DWG), unless a number is written along them, on the line: a contour line, its corners at that height. Floor plans leave it out, site plans show its outline and contour lines, sections cut it, elevations show its line, IFC files carry it as the site's terrain (IfcGeographicElement). With "id" it changes a terrain or tells how high it is "at" a point. Breaklines (Bruchkanten: walls' tops and feet, kerbs, the edges of slopes and paths) are edges of its triangles, their corners survey points too: corners given without a height, or a drawn line with "drape", lie on the ground and follow it. "smooth" curves the ground between the points as surveyors smooth it (Clough-Tocher, as Civil 3D's smoothing): no kinks at the triangles' edges, never above or below the heights around (no bulges, level lawns stay level), bending only at breaklines; walls and steps need them, else they are rounded off. Holes (as Civil 3D's hide boundaries) leave the ground out where the building stands: their edges are breaklines at their corners' heights (the terraces' and walls' edges), so the ground meets the building without a gap; asked inside one it has no height. A boundary (as Civil 3D's outer boundary) ends it along a closed loop instead of round its outermost points: no ground outside, its edge a breakline; a building at the plot's edge is a notch in it. Drawn on the current layer; the conversion's stage (existing, new) as any object.

JSON-Form: terrain {"ids": [points, polylines, lines, point blocks, height texts] (default: the selection) | "points": [[x, y, z], ...], "texts": true (numbers written beside the points are their heights), "tag": "HOEHE" (point blocks' height attribute), "depth": 2 (its bottom below the lowest point), "contours": 0.5 (contour lines' spacing, 0 none; default a few dozen lines), "material": "Erdreich", "smooth": true (curved between the points, not flat triangles), "breaklines": [[[x, y, z] or [x, y] (on the ground), ...], ...] | "breaklineIds": [lines, polylines] ("drape": true: on the ground) (edges it keeps, bending only there: walls, kerbs, slope edges), "holes": [[[x, y, z], ...], ...] | "holeIds": [closed polylines] (no ground inside: where the building stands; their edges breaklines), "boundary": [[x, y, z], ...] | "boundaryId": closed polyline (where it ends; default round its points); "id": terrain with "points" (replace them, "add": true to add; breaklines and holes likewise), "depth", "contours", "material", "smooth" to change it, or "at": [x, y] to ask its height there}

Checks a terrain before quantities and machine data are built on it, as a ground model is checked: points on top of others (the triangles leave all but the first out) and points measured twice a few centimeters apart at other heights; heights that stand off the plane through their neighbours by more than "spike" and far more than the neighbours themselves (a mistyped height, a 0 for none; a slope's or a wall's step is no outlier; on the outline, where the neighbours lie on one side, only ten times as far off counts); and, without a boundary, long edges round its outline where the triangles bridge a bay. Each is marked with a pin over it on layer Terrain check; "fix" takes the outliers and doubles out of the terrain's points (its breaklines stay). One step undoes it.

JSON-Form: terraincheck {"ids": [terrains] (default: the selection, else all), "spike": 0.5 (m a height may stand off the plane through its neighbours), "near": 0.05 (m: points closer in plan at heights this far apart count as measured twice), "edge": m (edges round the outline longer than this are marked; default four times the usual edge), "fix": true (take the outliers and doubles out), "mark": false (no marks), "language": "en"|"de"}

A pipe laid in a trench (Leitungsgraben) over the ground: the pipe's bottom ("invert") falls evenly from start to end (or from a start by "fall" percent, or as the path's own heights are); the trench is dug from the terrain down to the bedding below the pipe, "width" wide at the bottom (default the pipe and 0.2 m working room each side), its sides upright (shored) or at "sides" degrees. It gives the earth along the path in steps of half a metre: excavation, bedding, the pipe zone round the pipe up to "cover" above it (less the pipe), backfill above, the pipe's length and how deep the trench runs; it warns where the pipe lies shallower than 0.8 m (frost) and where upright sides run deeper than 1.25 m (DIN 4124: shore them). It draws the pipe at its axis (a 3D polyline) and the trench's edges on the ground. With "swell" and "load" the surplus loosened and in truck loads; "place" and "path" give the quantities as a table or a spreadsheet. The working room and depths are defaults to check against DIN EN 1610 and the job's specification.

JSON-Form: trench {"id": polyline | "points": [[x, y], ...] (the pipe's path), "diameter": 0.2 (outside, m), "invert": [500.20, 499.80] (the pipe's bottom at start and end, m) | 500.2 with "fall": 0.5 (percent along the path) | the path's own heights, "width": 0.6 (the bottom, default the pipe and 0.2 m each side), "sides": 90 (degrees; 90 upright, shored), "bedding": 0.1, "cover": 0.3 (pipe zone above the pipe), "terrain": id (default the planned ground, else the only one), "swell": 1.25, "load": 10, "layer": "Leitung", "place": [x, y, z], "path": "graben.csv", "language": "en"|"de"}

A map from a web map service (WMS GetMap) placed under the drawing in its place: the cadastral map (ALKIS), aerial photos (DOP) or a topographic map of the surveying authorities, as route and site plans are drawn on them. Needs the drawing's place in a UTM system (georef); the map is asked for in that system and the area (two corners, default the drawing's extents), at most 4096 pixels on its longer side. The picture is kept beside the drawing ("<name> Karten") and placed as an image on its own layer, under everything; the same request again is not fetched again. The address and the layers come from the service (its GetCapabilities); the drawing's place goes there. Name the map's source as its terms ask.

JSON-Form: wms doc({: , :  (comma-separated), : , : |, : |, : [x, y], : [x, y] (the area in the drawing; default its extents), : 2048 (the longer side, up to 4096), : 30, : , :  (a picture fetched before, instead of fetching)})doc

Places an address list on the map: the project area the gigabit funding's platform hands out (GIS-NB layers 3.1.1 and 3.1.2, as GeoJSON, shapefile or CSV) or house coordinates of the land survey. Each address becomes a symbol (block Adresse) carrying all the list's fields as its own (uuid, stra_name, nr, plz, ortsname …), named street and number; the GIS-NB export gives them back as the address layer of the phase, and fiberconnection takes an address. Longitudes and latitudes go into the drawing's UTM zone (an undrawn drawing takes the one they lie in); an address whose uuid is in the drawing already is not placed twice.

JSON-Form: addresses {"path": "adressen.geojson" | ".shp" | ".csv" (columns lon and lat, x and y as the GIS-NB write them, or rechtswert and hochwert), "crs": "EPSG:25832" (a CSV's eastings and northings), "layer": "Adressen"}

How far a network's construction has come, for interim proofs and site meetings: per construction section (field bauabschnitt) and kind (route, duct, cable) the meters planned, being built, built and surveyed, by each connection's field baustand (geplant, im Bau, gebaut, eingemessen, or planned, building, built, surveyed; none is planned), set with netfields; the share done, and the house connections whose drop duct is built. Existing networks (renovation existing) are counted apart. As a table in the drawing and CSV.

JSON-Form: buildprogress {"place": [x, y, z] (the table there), "path": "baustand.csv", "language": "en"|"de"} (mark with netfields {"ids": [...], "fields": {"baustand": "gebaut", "bauabschnitt": "BA 2"}})

Makes connections the cores (Adern) of one cable: its name, its type for all of them, and each core's name. The cable list (netlist with "of": "cables") lists it core by core from–to with its length; the terminal plan names the cable and core on each terminal. "remove" makes them plain connections again.

JSON-Form: cable {"ids": [connections] (default the selection), "name": "-W1" (default the next free W number), "type": "NYM-J 5x1,5" (for all its cores), "cores": ["L1", "L2", "L3", "N", "PE"] (one per connection, in their order; default 1, 2, 3 ...) | "remove": true}

A connection of a network (a pipe, a cable, a signal line) as a polyline from a port of a placement (or a point) through "via" to another port (or point): its ends hang on the ports and follow when the placements move; moved by hand away from a port, an end is cut loose. A port named without its "port" is the placement's one nearest where the connection goes on. An end {"on": connection, "at": point} branches off that connection: it is split there and a tee goes in (block T-Stück for pipes, Abzweig for others, on a sheet a small Verbindungspunkt; ports a, b, c), the new one taking its system and type unless given; one undo step. "orthogonal" squares it to the sheet as circuit diagrams draw wires: right angles, leaving each port the way it points. "system" says what it carries, "type" what it is; netlist lists them from–to with their lengths, trace follows a network, netcheck finds open ends. By clicks: the first and last at ports (node snap), the ones between where it runs.

JSON-Form: connect {"from": {"id": placement, "port": "out"} | [x, y, z] | {"on": connection, "at": [x, y, z]} (branches off it), "to": {"id": placement, "port": "in"} | [x, y, z] | {"on": connection, "at": [x, y, z]}, "via": [[x, y, z], ...], "orthogonal": true (square to the sheet, leaving each port the way it points), "system": "Schmutzwasser", "type": "DN 150 PVC", "fall": 2 (percent, falling from its start: the points after it lower by the way in plan; an end on a port keeps its height), "height": 0.3 (m over the floor of its start's level: the run there, stepping up or down square at its ends), "offset": 0.05 (m: the run between the ends beside the points given, to the left; negative right), "laid": "open"|"wall"|"prewall"|"floor"|"ceiling"}

Lays connections in another (Containment): a cable in a micro duct, micro ducts in a bundle, a bundle in a trench; each in its slot (the tube's number or color), a slot holding one thing. The occupancy table (occupancy) lists what lies in each. Refuses what would lie in itself. "remove" takes them out.

JSON-Form: contain {"ids": [cables or ducts] (default the selection), "in": duct, bundle or trench, "slot": "3" (one) | "slots": ["1", "2", "rot"] (each its own) | "remove": true}

A fiber house connection (Glasfaser-Hausanschluss) in one step: a branch on the duct bundle in the street (across from the house or at a station), the house's own micro tube of the bundle (the first free one, by the bundle's fields lr_anzahl and anzahl), the drop duct from the branch to the house transfer point (HÜP, GIS-NB art 16, id_tech the NVt) with the address as its fields (as the occupancy table and the GIS-NB read them; "address" takes an address of the list with its place), and the end customer (endkunde, id_netze the HÜP). With "cable" the drop cable from the NVt through the tube to the HÜP, spliced there onto the fiber socket (Gf-TA) and with "feed" at the NVt onto the next free fibers of the cable feeding it: fibertrace then follows the house to the PoP. The symbols are plain until a package's HÜP replaces them (same block name).

JSON-Form: fiberconnection {"bundle": the duct bundle in the street (default the selection), "to": [x, y] (the HÜP, in the building), "at": 12.5 (station along the bundle in m; default across from "to"), "tube": "7" (default the first free), "type": "Mikrorohr 7x1,5" (the drop duct; default the bundle's field rohrtyp), "address": an address's symbol (addresses: its place, street, number and town), "street": "Hauptstraße", "number": "12", "place": "Neubeuern", "date": "2026-11-06", "name": "Hauptstraße 12" (default street and number), "nvt": the NVt (default the symbol at the bundle's start), "cable": "A-DQ 4E9/125" (a drop cable), "fibers": 4 (when its type says none), "feed": cable at the NVt (splices the drop cable onto its next free fibers), "customer": 1 (1 household … 6, false for none)}

Follows a fiber through the network (Faserverfolgung): along its cable, through the splices in each closure and through splitters (from the input to every output, from an output back to the input), to the ports it ends at: from the ODF at the PoP to the fiber socket in the house. Gives each way with its steps (closure, tray, cable, tube, fiber, color), length, splices and splitters; "select" selects its cables and closures. "all" lists every way from port to port once, the PoP's end first: the fiber assignment from PoP to house. As a table and CSV. With "budget" each way's calculated loss (the table of losses per fiber the funding asks besides the measurement): per km of fiber, per splice, per connector at its ports and per splitter by its ways; the plan's values, or common planning values (0.35 dB/km at 1310 nm, 0.1 per splice, 0.5 per connector, splitters 1:2 3.6 to 1:64 20.5 dB).

JSON-Form: fibertrace {"cable": id, "fiber": 5 | "at": closure, "port": "ODF A" | "splitter": "S1", "fiber": 3 | "all": true (every way from port to port: the fiber assignment), "select": true, "budget": true or {"perKm": 0.35, "splice": 0.1, "connector": 0.5, "splitters": {"32": 17.1}} (dB), "place": [x, y, z], "path": "faserweg.csv", "language": "en"|"de"}

Checks the plan against the funding's uniform material concept (Einheitliches Materialkonzept), as the proof of use asks: at each house transfer point (art 16) 4 fibers per dwelling and 2 for the building (the dwellings from its field we, else one per end customer hanging on it by id_netze, else one; the fibers of the cables ending there, by their fields or their type in the catalog); each duct bundle whose tubes are known (lr_anzahl times anzahl, or its type in the catalog) keeps 15 % of them free; at a PoP or collocation point (art 12 or kollokatio 1) the bundles arriving keep 3 more free. What does not hold is listed with what it needs and has, as CSV on wish, and selected with "select".

JSON-Form: materialcheck {"reserve": 15 (percent of tubes kept free), "select": true, "path": "materialkonzept.csv", "language": "en"|"de"}

Checks the networks: connections with an end that hangs on nothing (open), ends whose object or port is gone (broken), and how many ports nothing hangs on. Selects the faulty connections ("select": false only tells).

JSON-Form: netcheck {"select": true}

Checks the clear distances between the lines of different networks (gas, water, district heating, power, telecom: their systems) and from trees, against the rules the plan follows: per pair of systems (patterns with *) a distance when they run side by side and one where they cross, and a distance from the trees on a layer (GW 125 asks one for trees). The rules come from the operator or the standard, given here or as a JSON file an office keeps; the program knows none. Measured in 3D between the lines' outer walls (the outer diameter from the catalog, pipetype; the axis where unknown), a tree from its trunk in plan. Lines joined at a node, lying in one another or in one duct are not measured against each other. Each place too close once per pair, the closest first, as CSV on wish, and selected.

JSON-Form: netclearance {"rules": [{"a": "Gas", "b": "Wasser*", "parallel": 0.4, "crossing": 0.2}, ...] or "regeln.json", "trees": {"layer": "Bäume", "distance": 2.5, "systems": "*"}, "select": true, "path": "abstaende.csv", "language": "en"|"de"}

Draws the schematic of a network from its source (Strangschema, Netzschema): the main to the right, each branch dropping off where it leaves a tee, each piece labelled with its type and length, each end with what it feeds (its name, or its block's). Only the system given is followed, so a tank's cold and hot sides stay apart. Not to scale. With "layout": "storeys" the heights are true, as a building's riser diagram: the drawing's levels the network passes as lines with name and height, each riser upright, the branches on each floor along it at their height, widths still schematic. Works for pipes and cables alike; drawn once on its own layer, again after changes.

JSON-Form: netdiagram {"from": the object the network starts at (default the selection), "system": "Trinkwasser kalt" (default the source's first connection's), "layout": "tree"|"storeys" (heights true, across the drawing's levels), "place": [x, y, z] (its top left; across storeys the lowest level's left end; default beside the drawing), "language": "en"|"de"}

A connection's own fields, as a symbol's attributes are: the codes the GIS-NB of the gigabit funding ask of a duct or a cable (lr_art, anzahl, verb_art, anzahl_f_a …), an owner, a date. Set or changed; null takes one away; without "fields" it lists them. The GIS-NB export takes them by name.

JSON-Form: netfields {"ids": [connections] (default the selection), "fields": {"lr_art": 12, "anzahl": 2, "eigentuemer": "Stadtwerke", "alt": null (takes it away)}} | without "fields" (lists them)

Draws an isometric of a network (Isometrie), as plumbing plans show drinking water and waste water runs: each connection in the 30° projection (x to the lower right, y to the upper right, height straight up, so risers stand upright), the objects they hang on as rings with their names (fittings as dots), each run labelled with its type. On its own layer, beside the plan; drawn once from the network as it is, again after changes.

JSON-Form: netiso {"system": "Trinkwasser kalt" (default all networks), "ids": [connections], "place": [x, y, z] (its lower left; default right of the drawing), "scale": 1, "language": "en"|"de"}

Labels the connections of networks as installation plans do: each pipe or cable gets its type ("DN 20 Cu", "NYM-J 3x1,5"), and on wish its length, fall (%), height (m, where the label sits), system and any of its fields ("field:volumenstrom", as balance writes it, or a heating circuit's "field:heizkreis", a route's "field:tiefe"), its name, and for a duct or bundle its occupancy ("3/12 belegt": what lies in it, see contain, of its tubes), along the middle of its longest piece, readable from below or the right, on a layer of its own. Run again after changes: the labels of before at those places are replaced.

JSON-Form: netlabel {"ids": [connections] (default all), "system": "Trinkwasser kalt", "show": ["type", "length", "fall", "height", "system", "name", "occupancy", "field:volumenstrom"] (default ["type"]), "size": 2 (mm on paper), "layer": "Leitungsbeschriftung", "language": "en"|"de"}

Lists the connections from–to (Von-bis-Liste, cable list, pipe list): where each starts and ends (the object's name or block, its id and port, or open), what it carries, what it is and how long, and the lengths summed by type for ordering; where they run at heights (pipes laid to falls) the ends' heights and the fall in percent, a sewer's pipe list (Haltungsliste). With "of": "objects" what they join instead, each once: where it lies (map coordinates), how high, its lowest port with a connection and how deep that is under it (a manhole list, Schachtliste), its ports taken and free; with "systems" each system's connections, objects, length and types (a circuit list: Stromkreisliste). Only some networks with "ids", one system with "system"; "place" draws it as a table, "path" writes it as a spreadsheet.

JSON-Form: netlist {"ids": [connections or objects: their networks] (default all), "system": "Schmutzwasser", "of": "connections"|"objects"|"systems"|"paths"|"cables"|"quantities"|"pulls"|"labels", "allowance": 5 (% on cable meters), "heights": true (the ends' heights and the fall; default where they run at heights), "place": [x, y, z], "path": "verbindungen.csv", "separator": ";"|","|"\t", "language": "en"|"de"}

A quality report of the network's data, as operators and the funding check them: end customers without their house transfer point (id_netze) or pointing at nothing, transfer points (art 16) without their NVt (id_tech) or with nothing connected, designations (bezeichner, else the name) given twice among nodes of one kind, splices of cables that no longer end at their closure, connections lying in a duct that is gone, two in one tube, and fiber cables whose fiber count nobody knows. Each finding with its object, as CSV on wish, and selected with "select". Open and broken ends are netcheck's; what the GIS-NB phase asks, the export's check report.

JSON-Form: netquality {"select": true, "path": "qualitaet.csv", "language": "en"|"de"}

The systems of the drawing's networks (Trinkwasser kalt/warm, Zirkulation, Heizung Vor-/Rücklauf, Schmutzwasser, Zuluft): the name connections carry, what it is for IFC (kind, IfcDistributionSystemEnum) and the layer its connections go on, whose color, linetype and lineweight show it. Defining one moves its connections onto its layer; connect puts new ones there. "newName" renames it in every connection. "legend" draws a sample of each system's line with its name. The program sets no colors: they are the office's or its norm's.

JSON-Form: netsystem {"name": "PWH", "description": "Trinkwasser warm", "kind": "domestichotwater", "color": "#E2001A", "linetype": "Dashed", "lineweight": 0.35, "layer": "SHK PWH" (default its name), "newName": "TWW"} | {"name": ..., "remove": true} | {"legend": [x, y], "size": 2.5 (mm on paper)} | {} (lists them)

Names a network's objects and connections one after another as they follow from where it starts, downstream (from each object first the connections leaving it, then those arriving): manholes S01, S02 ... and pipes H01 ... as a sewer's plans number them, circuits' devices and cables likewise. The names stand in netlist's lists and stand for the objects in commands. "block" and "type" number only a block's placements and a type's connections (the manholes apart from the houses' chambers), walking through the rest.

JSON-Form: number {"id": object or connection to start at (default the selection's first), "prefix": "S" (objects: S01, S02 ...), "connectionPrefix": "H" (connections: H01 ...), "start": 1, "digits": 2, "of": "both"|"objects"|"connections", "block": "Schacht" (only its placements), "type": "DN 250" (only connections of this type)}

The occupancy table (Rohrbelegung): each container (a duct bundle, a protective pipe, a trench) with its slots (its field lr_anzahl times anzahl), what lies in each slot and what is free (the reserve the GIS-NB counts); where fewer are free than its field lr_reserv asks, it says so. As a table and as CSV. "detail" gives a row per tube with the columns of the funding's material concept: bundle, its sheath color (field mantelfarbe), tube, tube type (rohrtyp), what lies in it, and the cable's fields strasse, hausnr, anschlusspunkt, datum, gesetzt; free tubes by number.

JSON-Form: occupancy {"place": [x, y, z], "path": "rohrbelegung.csv", "detail": true (a row per tube), "language": "en"|"de"}

The drawing's pipe and duct catalog: types by the name the connections' types write, with material, nominal size, outer and inner diameter or a duct's width and height, roughness and weight per meter, as the maker states them; one by one or from a CSV of a catalog (columns named in English or German). The bill of materials sums their weights; insulation and provisions take their measures instead of reading them from the name. For fiber networks a type also says what lies inside: a duct bundle's micro tubes (the occupancy table and fiberconnection count them where the bundle has no field lr_anzahl), a cable's fibers, fibers per loose tube and the colors of tubes and fibers in order (splice, spliceplan and fibertrace take them where the cable has no fields of its own). The colors are the maker's or the operator's code, typed in or brought by a pack ("library"): the program ships none.

JSON-Form: pipetype {"name": "Cu 22x1", "material": "Kupfer", "nominal": 20 (DN), "outer": 22, "inner": 20 (mm), "width": 400, "height": 200 (a duct's, mm), "roughness": 0.0015 (mm), "weight": 0.59 (kg/m), "tubes": 12 (a bundle's micro tubes, a cable's loose tubes), "fibers": 48, "fibersPerTube": 12, "tubeColors": "rt, gn, bl, …", "fiberColors": "rt, gn, bl, …"} | {"name": ..., "remove": true} | {"path": "katalog.csv"} (a header row: name, material, dn, da, di, breite, höhe, rauigkeit, gewicht, röhrchen, fasern, fasern_je_bündel, bündelfarben, faserfarben) | {"library": "Glasfaser FTTH", "types": [...] or "all"} (a pack's catalog) | {} (lists them)

A plan extract for a utility information request (Leitungsauskunft, after DVGW GW 118 and VDE-AR-N 4203): a sheet with the area asked about at a scale in a framed viewport, and beside it the information office's contact (required), the operator, date and time of issue, the scale with the map reference (system and the area's middle), the networks in the area as a legend with their colors, and the notes: on protecting the lines, the extract's limits (area and day, position without guarantee), dimensions from locating, lines not shown, a briefing on site. The notes are the operator's: "notes" replaces the defaults. The title block says plan information, operator and date. Plot it for the PDF to send.

JSON-Form: planinfo {"from": [x, y], "to": [x, y] (the area asked about) | "center": [x, y], "radius": 50 (m), "contact": "Netzauskunft, Tel. ..., auskunft@..." (required), "operator": "Stadtwerke ...", "scale": 500 (default the largest standard one that shows the area), "paper": "A3" (landscape), "issued": "2026-11-07 09:30" (default now), "notes": ["...", ...] (instead of the default notes), "language": "en"|"de"}

A block's ports (Anschlusspunkte): named points where a pipe, a cable or a signal line of a network joins what the block draws (a manhole, a socket, a radiator, a lamp, a device), in block coordinates, facing out along "direction", with what joins ("kind") and how large ("size": a nominal diameter, a cross-section). The block is defined anew with them and every placement shows them: they snap (node), and connect hangs connections on them, which follow when the placement moves. A port that leads "through" to another inside (a patch panel's front to its rear) lets trace follow the way on.

JSON-Form: port {"block": "Schacht", "ports": [{"name": "out", "position": [x, y, z] (in the block), "direction": [x, y, z], "kind": "pipe"|"cable"|"signal"|"hang", "size": 150 (DN, mm²), "through": "R1" (the port it leads to inside, a panel's rear)}, ...] (sets them all) | "add": {port} | "remove": "out" | nothing (lists them)}

Splices fibers in a closure (Muffe, NVt, PoP, a house's transfer point): the fibers of a cable that ends there onto those of another, onto a splitter's input or outputs, or onto positions on a port of the device itself (an ODF at the PoP, the fiber socket in the house). Each fiber end is spliced once. Fibers given as ranges; without "onto" the next free ones of the other side. A cable's fiber count comes from its field fasern or its type (4x12E9/125, 96E9/125), its tubes from fasern_je_buendel, colors from its fields faserfarben and buendelfarben (comma lists, as the maker's or operator's code). Adds splitters (1:ways) and takes splices out. spliceplan lists it, fibertrace follows a fiber.

JSON-Form: splice {"at": closure (Muffe, NVt, PoP: the symbol the cables end at), "from": cable | {"splitter": "S1"} | {"port": "ODF A"}, "fibers": "1-12, 15" (default all not yet spliced; a splitter's 0 is its input), "to": cable | {"splitter": "S1"} | {"port": "Gf-TA"}, "onto": "13-24" (default the next free; a splitter's input for one fiber), "tray": "3" | "traySize": 12 (fills trays 1, 2 … with so many each), "splitter": {"name": "S1", "ways": 32, "tray": "5"} (adds one; or a list), "remove": "all" | cable | {"cable": id, "fibers": "1-4"} | {"splitter": "S1"}}

The splice plan (Spleißplan) of each closure, as splicers and operators work by it: tray by tray, each splice from a cable's fiber (its tube and colors) to another's, to a splitter or to a port, and where the way leads on both sides (the ODF at the PoP, the house). Its splitters in the title. With "all" the fibers nothing is spliced to as free. As tables in the drawing (for the PDF) and as CSV (for Excel).

JSON-Form: spliceplan {"ids": [closures] (default the selection, else all with splices), "all": true (also the fibers nothing is spliced to), "place": [x, y, z], "path": "spleissplan.csv", "language": "en"|"de"}

The terminal plan (Klemmenplan) of a strip: each terminal, what its inside and its outside are wired to and by what (the wire's name, or the cable and its core), and the bridges between its terminals; as a table in the drawing and as CSV.

JSON-Form: terminalplan {"strip": "-X1" | id (default the selected or only strip), "place": [x, y, z], "path": "klemmen.csv", "separator": ";"|","|"\t", "language": "en"|"de"}

Draws a terminal strip (Klemmleiste): its terminals side by side, each with a point inside at its top ("3.1") and outside at its bottom ("3.2") that lead through to each other. connect wires them; trace follows a way through; terminalplan lists what each terminal is wired to.

JSON-Form: terminalstrip {"place": [x, y, z], "name": "-X1" (default the next free X number), "count": 10, "labels": ["1", "2", "PE", ...] (default 1 to count), "levels": 2 (Etagenklemmen: each terminal's levels 3/1, 3/2), "pitch": 6 (a terminal's width, mm), "rotation": 0}

Tie dimensions (Einmaße) as utility plans and surveying rules ask: each bend of a route (or only its ends), each symbol (manhole, closure, house transfer point) and each point is tied to the nearest corners of the fixed objects (buildings, fences: the layers "to" names) by its distances, two by default, whose directions cross at 30 to 150 degrees so the point can be found again by two tapes. Each tie is an aligned dimension from the corner to the point on a layer of its own ("Einmaße"), 2 mm high on paper at the drawing's scale. Points with fewer corners near enough are named in the message and the data ("loose").

JSON-Form: tiedims {"ids": [routes, connections, symbols, points] (default the selection), "to": ["Gebäude", "ALKIS*"] (the fixed objects' layers, or their ids), "count": 2 (fixed points per point, 1 to 3), "reach": 30 (m), "angle": 30 (the ties of a point cross at least so many degrees), "points": "vertices"|"ends", "layer": "Einmaße", "textHeight": 0.5, "decimals": 2, "language": "en"|"de"}

Follows a network from one of its objects or connections: every connection hanging on it and every object they join, on and on (a circuit, a sewer line, a cable run). Selects them ("select": false only tells), with their number and the connections' length. With "port": only the way from that port of the object, cable by cable, on through a port where two cables hang or from a panel's front to its rear (a port's "through"), to where it ends (where does socket 2.14 go?).

JSON-Form: trace {"id": object or connection (default the selection's first), "port": "A" (one way from that port), "select": true}

Makes an object (the symbol of a distribution board, Verteiler) a board of the electrical installation, or changes it: its name (unique in the drawing), the circuit of another board that feeds it (none: the meter), its surge protection (SPD, Überspannungsschutz: near the supply, before the RCDs), its residual current devices (FI). Circuits come with circuit. Given only the id, tells its structure: SPDs, RCDs and circuits. "remove" makes it a plain symbol again; its devices lose their circuits. Renaming the board relabels its devices (UV1.F3 becomes UV2.F3).

JSON-Form: board {"id": the board's symbol (default the selection), "name": "UV1" (default the next free UV number), "supply": {"board": "HV", "circuit": "F12"} | null (from the meter), "spds": [{"name": "F0", "type": "1"|"2"|"1+2"|"3", "poles": 4, "level": 1.5 (Up, kV)}, ...] (sets them all), "rcds": [{"name": "Q1", "rating": 40 (A), "residual": 30 (mA), "poles": 4, "type": "A"}, ...] (sets them all) | "remove": true | nothing else: its structure}

Draws a distribution board's layout (Aufbauzeichnung, Verteilerbelegung) from its structure: rows of modules (TE, 17.5 mm), each residual current device (2 or 4 modules) followed by the breakers of its circuits (a module per pole), then the combined breakers (RCBO, 2 modules) and the circuits without an RCD; each device with its name and rating. Rows are added until the reserve asked for (20 %) stays free; the free modules and their share are told. As DIN 18015-1 asks it with the documentation; again after changes.

JSON-Form: boardlayout {"board": "UV1" | id (default the selected or only board), "modules": 12 (TE per row), "reserve": 20 (% of modules left free; rows added until it is), "place": [x, y, z] (its top left), "language": "en"|"de"}

Draws the single-line diagram of a distribution board (Verteilerplan, einpoliger Übersichtsschaltplan) from its structure: the supply onto the busbar, each RCD with its rating and residual current and the circuits under it, circuits under none straight from the busbar, each circuit's breaker, and under it the column of its number, breaker, cable, phase, name and devices. Drawn once on the layer "Verteilerplan"; again after changes.

JSON-Form: boardplan {"board": "UV1" | id (default the selected or only board), "place": [x, y, z] (its top left; default beside the drawing), "scale": 50 (the scale its paper sizes are for, 1:50; default the drawing's), "language": "en"|"de"}

The cables as the store packs them: each connection's length with slack for sag and routing and a reserve at its ends, in the next stock length the store has (several pieces where none is long enough), counted by type and length; the looms (connections cables are laid in with contain) with what runs in them. As a table or CSV.

JSON-Form: cablelist {"ids": [connections] (default the selection, else all), "lengths": [1, 2, 3, 5, 10, 15, 20, 25, 30, 50] (the store's, m), "slack": 0.1 (share added for sag and routing), "reserve": 1 (m added at the ends), "place": [x, y, z] (as a table), "path": "kabel.csv", "language": "en"|"de"}

Finds where cables (connections) cross walkways, roads and escape routes drawn as closed outlines or hatches, as the crew lays cable ramps (Kabelbrücken) there: each crossing's length along the cable and the ramp modules that cover it. With "block" the modules are placed along the cable, centered on the crossing.

JSON-Form: cableramps {"areas": [ids] (walkways, roads, escape routes: closed outlines or hatches), "ids": [cables] (default all), "module": 0.9 (m of one ramp module along the cable), "block": "Kabelbrücke" (places the modules)}

A circuit (Stromkreis) of a distribution board: its number, name, breaker ("B16"), poles, the RCD it hangs under (by default the first with room: six circuits under a four-pole RCD, two under a two-pole one), cable type, phase (by default the least loaded) and installed power; and the devices it feeds, the selection by default, wired or not. Devices whose block has a field STROMKREIS show "UV1.F3" there, moving with them and going into DWG. An existing number changes that circuit; "renumber" relabels its devices, "remove" takes it out, "unassign" takes devices off their circuits. "list" gives the circuit list per board (devices, rooms, power, cable length from the cables on its devices or its board port) with the load per phase, as a table ("place") or CSV ("path").

JSON-Form: circuit {"board": "UV1" | id (default the selected or only board), "number": "F3" (an existing one changes it; default the next free F number), "name": "Steckdosen Küche", "protection": "B16", "poles": 1|3, "rcd": "Q1" | "rcbo" | "none" (default the first RCD with room), "cable": "NYM-J 3x1,5", "phase": "L1"|"L2"|"L3" (default the least loaded), "power": 2000 (W), "devices": [ids] (default the selection), "renumber": "F5" | "remove": true | "unassign": [ids] | "list": true with "place": [x, y, z] and/or "path": "stromkreise.csv", "language": "en"|"de"}

Checks the electrical installation as plans are checked: devices with a field STROMKREIS on no circuit, a board fed from the meter without a type 1 or 2 SPD (DIN 18015-1, DIN VDE 0100-443), circuits feeding nothing, more circuits under an RCD than DIN 18015-1 allows (six under a four-pole, two under a two-pole one), sockets on circuits without an RCD (DIN VDE 0100-410: 30 mA), more installed power than the breaker carries (P / 230 V; three-phase P / (√3 · 400 V)). Tells the findings and selects what they concern; changes nothing.

JSON-Form: circuitcheck {"select": true (selects the devices and boards concerned)}

The circuit list (Stromkreisliste) of the distribution boards: each circuit with its breaker, RCD, cable, phase, devices by kind, the rooms they stand in, installed power and the length of its cables (those hanging on its devices or on the board's port of its number; with "route", the height their runs take, they count in plan plus the drop at each end to the device's height, its field HÖHE or the height given by block, and "allowance" adds a share); the installed power per board and phase. As a table ("place"), a CSV file ("path") or only the data. The same as circuit {"list": true}.

JSON-Form: circuitlist {"board": "UV1" | id (default all), "route": 2.3 (m: cables run at this height, dropping to each end), "allowance": 10 (% for bends and boxes), "heights": {"Steckdose": 0.3, "Schalter": 1.05} (m, by block, where devices carry no field HÖHE), "place": [x, y, z] (draws it), "path": "stromkreise.csv", "separator": ";", "language": "en"|"de"}

The cross references of a circuit diagram: symbols sharing a name ("-K1") are one device; its coil (the main function) gets its contact mirror beneath it, each contact with its terminals and where it lies, each contact where its coil is, each interruption point where the others of its name are. Addresses are the sheet and column (the sheet's width in equal columns; in the model by "columnWidth"). What a symbol is comes from its field FUNKTION or its block's name (Spule, Schließer, Öffner, Wechsler, Unterbrechung); its terminals are its ports. Run again, the references are written anew on their own layer; contacts without a coil and lone interruptions are named.

JSON-Form: crossref {"columns": 10 (a sheet's width in columns), "columnWidth": 42 (in the model, drawing units), "place": [x, y, z] (the device list), "language": "en"|"de"}

Reference designations as IEC 81346 structures them (BMK): what a device does (function "=A1"), where it is (location "+S1") and what it is (product "-K3"), written as its name "=A1+S1-K3", which cross references, lists and labels read. With "ids" it sets them on placements, a product's letter code with the next free number under its function and location; "renumber" numbers each letter code anew in reading order (sheet, left to right, top to bottom), a coil and its contacts keeping one name; without either it lists the structure tree ("place" draws it). Letter codes are the office's or its standard's.

JSON-Form: devicetag {"ids": [devices] (default the selection), "function": "=A1", "location": "+S1", "product": "-K" (the next free number) or "-K3"} | {"renumber": true} | {} (the structure tree), "place": [x, y, z], "language": "en"|"de"}

Puts together the documentation of the electrical installation as DIN 18015-1 asks it to be handed over (the boards' sheets on the smallest paper up to "paper" their drawings fit at the drawing's scale): a sheet with the installation plan (boards, devices and cables, at 1:50 or the next scale it fits; when they stand on more than one of the drawing's levels, a plan for each storey, cut a metre above its floor, all on the same window, shown in "layerState" if given: the building and the electrical layers, not the other trades), and for each distribution board a sheet with its single-line diagram, one with its circuit list and one with its layout of modules (boardlayout), at the drawing's scale (or the next one they fit). The diagrams and lists are drawn beside the plan on a layer of their own; run again after changes, it draws them anew and updates the sheets by name. One undo step. The test reports come from the measuring instrument.

JSON-Form: elecdoc {"paper": "A3" (landscape), "scale": 50 (the installation plans'; larger when they do not fit), "layerState": "Elektro" (what the installation plans show), "language": "en"|"de"}

The potentials of circuit diagrams: wires that touch are one, at a port they share, through a terminal (a port leading through), at a branch, where free ends meet, and across sheets at interruption points of the same name; a device's other ports (a contact's, a coil's) are another. A potential is named by its interruption points ("L1", "24V") or a wire's field potential, the others numbered. "number" writes each wire's number into its field draht (and its potential into potential): its potential's name or number, or with "by": "place" its sheet, column and a running number ("S1.3.2"); netlabel "field:draht" writes them along the wires.

JSON-Form: potentials {"ids": [wires] (default all), "number": true (each wire's number into its field draht), "by": "potential"|"place", "prefix": "" (before the numbers of unnamed potentials), "start": 1, "columns": 10 (a sheet's width in columns, for "place"), "place": [x, y, z] (the list), "path": "potentiale.csv", "language": "en"|"de"}

Makes an object of the plan (a rack's symbol) a 19-inch rack with its height units (HE, 44.45 mm), or changes its name or units. Devices go in with rackmount; rackview draws it with them. "remove" makes it a plain symbol again and takes its devices out.

JSON-Form: rack {"id": the rack's symbol (default the selection), "name": "R1" (default the next free R number), "units": 42 (HE) | "remove": true}

Mounts devices (patch panels, switches, servers, amplifiers) in a rack: at the unit given, several stacked upward in their order, or each at the highest free place, as racks are filled from the top; each as high as its field HE says unless "height" is given; front or back. Refuses what does not fit or would overlap another device. "remove" takes them out.

JSON-Form: rackmount {"ids": [devices] (default the selection), "rack": "R1" | id (default the selected or only rack), "unit": 12 (the lowest unit; several stack upward; default the highest free place), "height": 2 (units each; default the device's field HE, else 1), "side": "front"|"back" | "remove": true}

Draws racks to scale as their views (Rackansicht): the units counted from the bottom, each device where it is mounted with its name, front and, where devices sit at the back, back beside it; under each how many units are used and what its devices weigh and draw, from their fields GEWICHT (kg) and LEISTUNG (W). "path" writes the device list per rack as CSV (rack, unit, height, side, device, weight, power).

JSON-Form: rackview {"rack": "R1" | id (default all racks), "place": [x, y, z] (its top left; default beside the drawing), "path": "geraete.csv" (the device list; with only it nothing is drawn), "language": "en"|"de"}

Changes a terminal strip already wired (Klemmleisten-Editor): terminals inserted, removed, renamed or put in another order, levels added or taken away (Etagenklemmen, each level its own points "3/2.1" inside and "3/2.2" outside). The strip is drawn anew and its wires follow their terminals by name, onto level 1 when levels come or go; a wire whose terminal is gone comes loose there (netcheck shows it open). One undo step.

JSON-Form: terminaledit {"strip": "-X1" | id (default the selection), "insert": {"labels": ["3a"], "after": "3" | "before": "3"}, "remove": ["5"], "rename": {"3": "N"}, "order": ["1", "2", "N", ...], "levels": 2 (Etagenklemmen)}

The hydraulic balance of a two-pipe heating (hydraulischer Abgleich): each radiator's share of its room's heat load ("loads", split by output) or its output at the temperatures, the water it needs at the spread, the pipes' pressure loss on its way from the source and back (Darcy-Weisbach, Colebrook-White, inner diameter and roughness from the catalog or the type's name, water at the mean temperature, a surcharge for fittings; a way drawn only one way is taken twice), so the pressure each valve must take for all to get their water, its kv and, with the maker's table ("presets"), its setting; the pump's flow and head. "write" keeps each pipe's water, speed and friction gradient in its fields (volumenstrom, geschwindigkeit, druckgefaelle) for netlabel. "zeta" takes the single resistances instead of the surcharge: each bend of a pipe, each tee (through or into its branch) and each object passed by its block's name or field FUNKTION, by the coefficients the maker or the office gives. "protocol" puts the calculation and a confirmation to sign on sheets of their own (the installation as given, the basis, the result by radiator; plot them to PDF). Radiators end a way; tees, valves and manifolds pass it on. A design aid for planning, no proof; the heat loads are the planner's.

JSON-Form: balance {"from": the heat source (default the selection), "flow": 55, "return": 45 (°C), "inside": 20, "loads": {"0.01": 1200} (W by room number), "outputs": {"Typ 22 600/1000": 1650} (nominal W by type), "exponent": 1.3, "systems": ["Heizung Vorlauf", "Heizung Rücklauf"] (default all hanging on the source), "fittings": 30 (% on the pipes' loss), "valve": 5 (kPa the least favoured radiator's valve keeps), "source": 0 (kPa through the boiler), "roughness": 0.0015 (mm where the catalog has none), "presets": {"1": 0.05, "2": 0.09, ...} (the valves' kv by setting, m³/h), "speed": 1 (m/s named above), "zeta": {"bend": 0.5, "tee through": 0.5, "tee branch": 1.5, "Kugelhahn": 0.2} (single resistances; then no surcharge unless "fittings" is given), "write": true (each pipe's water, speed and gradient into its fields), "place": [x, y, z], "path": "abgleich.csv", "protocol": true | {"sheet": "Abgleich", "paper": "A4", "project", "address", "client", "company", "by", "date", "building", "units", "boiler", "vessel", "pump", ...} (a protocol and confirmation on sheets of its own, to plot), "language": "en"|"de"}

The hot water circulation: each hot water pipe's heat loss through its insulation and outer surface (from its type's size), the circulating water that makes it up within the drop, shared at each branch by the loss behind it (as DVGW W 553 reckons), the return pipes back to the heater, each loop's pressure loss, the pump's flow and head, each loop's regulating valve (kv) and the water's temperature where it turns back, against the least (W 551: 55 °C). Loops are where return pipes end on hot water pipes. Table and protocol.

JSON-Form: circulation {"from": the water heater (default the selection), "flow": "PWH", "return": "PWH-C" (the systems), "hot": 60, "drop": 5 (K round a loop), "least": 55 (°C where a loop turns back), "ambient": 20, "surface": 10 (W/(m²K)), "valve": 5 (kPa the least favoured loop's valve keeps), "source": 0 (kPa through the heater), "roughness": 0.0015, "place": [x, y, z], "protocol": true | {...}, "language": "en"|"de"}

The climate a building is designed for at its place: the design outside temperature (Norm-Außentemperatur) and the annual mean outside temperature, which heatload reckons with (the ground under the building at the mean). Set as numbers, or looked up by postcode or place in the office's table (a CSV with columns named plz, ort, te, tme or in English); the program ships no such table.

JSON-Form: climate {"outside": -14, "mean": 8.6 (°C), "place": "Bad Feilnbach"} | {"path": "klima.csv" (a header row: plz, ort, te, tme), "place": "83075" or a name} | {"remove": true} | {} (shows it)

Sizes the waste water pipes (DIN EN 12056-2 and DIN 1986-100 in their way of reckoning): each pipe's sum of the fixtures' connection values (DU) draining through it (water runs to the lower end), the flow Q = K·√ΣDU, never less than the largest fixture's, and against it a falling pipe's capacity partly filled (Prandtl-Colebrook with its fall, inner diameter and roughness) or a stack's capacity given for its size (a stack falls more than it runs and a metre or more; a fixture's short drop into the floor is its connection pipe); stacks whose top does not go on upwards (no main vent) are named. The connection values, K and the stacks' capacities are the planner's (the standards' tables).

JSON-Form: drainage {"du": {"WC": 2.0, "Waschtisch": 0.5} (connection values by block name; or field DU), "k": 0.5 (frequency factor), "filling": 0.5 (h/d of falling pipes), "stacks": {"DN 100": 4.0} (capacity by type or DN, l/s), "roughness": 1.0 (mm), "systems": ["SW"], "place": [x, y, z], "path": "entwaesserung.csv", "language": "en"|"de"}

Sizes the drinking water pipes as DIN 1988-300 sets it out: from the meter along the pipes to each outlet, each pipe's sum of design flows behind it, the peak flow by the simultaneity curve (V_S = a·(ΣV_R)^b − c, its constants given), speed, friction (Darcy-Weisbach, Colebrook-White, the catalog's inner diameter and roughness) and single resistances; each flow path's need (pipes, height, apparatus, the outlet's least flow pressure) against the supply. Pipes faster than allowed get the smallest catalog type of their material that keeps the speed. Design flows, least pressures and the curve are the planner's: the program ships no table. Table, CSV, protocol.

JSON-Form: drinkingwater {"from": the water meter (default the selection), "systems": ["PWC"], "flows": {"Waschtisch": 0.07, "WC": 0.13} (design flows by block name, l/s; or field VR), "peak": {"a": .., "b": .., "c": ..} (V_S = a·(ΣV_R)^b − c), "pressures": {"Dusche": 100} (least flow pressure by block name, kPa; or field PMIN), "outlet": 100 (kPa where none), "supply": 400 (kPa at the meter), "apparatus": 65 (kPa through meter, filter, softener), "temperature": 10, "speed": 2 (m/s, the most), "fittings": 0 (% on friction), "zeta": {"bend": 0.5, ...}, "roughness": 0.0015, "place": [x, y, z], "path": "trinkwasser.csv", "protocol": true | {...}, "language": "en"|"de"}

The pipes' fittings as objects of their own (Formteile): a bend at each corner of a rigid pipe, named with its angle (15, 30, 45, 60, 90°, else its own) and the pipe's type ("Bogen 90° Cu 22x1"), placed at the pipe's size; each tee named with the sizes it joins, reduced where the branch is smaller. In plans, lists by name (quantities) and to pick. Flexible pipes (PE-X, multilayer) bend without fittings. On a layer of their own; run again, the bends of before go.

JSON-Form: fittings {"systems": ["PWC"] (default all), "remove": true, "language": "en"|"de"}

Designs the floor heating circuits floorheating laid (DIN EN 1264 in its way of reckoning): each room's heat load shared by its circuits as their pipe lies in it, the output per square meter, the floor's surface temperature (q = 8.92·(θF − θi)^1.1) against its limit, the heating medium's excess the maker's curve asks for at the circuit's spacing (q = K_H·ΔθH), the flow temperature for the room that needs the most at the spread asked, each circuit's spread, water and pressure loss over its length, and the manifold's valve settings (kv) with the pump's head. The makers' K_H and the limits are the planner's.

JSON-Form: floorcheck {"loads": {"0.01": 1200} (W by room number), "kh": {"0.10": 6.4, "0.15": 5.5} (the maker's K_H by spacing, W/(m²K)) or 5.5, "inside": 20, "temperatures": {"0.03": 24}, "spread": 5 (K), "surface": 29 (°C, the floor's limit), "surfaces": {"0.03": 33}, "down": 0 (% more for downward loss), "valve": 5 (kPa), "roughness": 0.007 (mm), "place": [x, y, z], "language": "en"|"de"}

Lays the heating circuits of a floor heating in a room (Fußbodenheizung), as laying plans show them: a double meander at the spacing (Verlegeabstand), flow and return side by side so they never cross and both ends lie at the entry, the margin from the walls, from the manifold's next free pair of ports (VL1/RL1 …) and back. A room whose circuit would be longer than "max" gets several, in strips. Each circuit is a connection (system Fußbodenheizung), named after the room; pipelist counts its metres. Tells each circuit's length and the area. Heat output and pressure loss (DIN EN 1264) are not worked out.

JSON-Form: floorheating {"room": a room (default the selection) | "outline": [[x, y, z], ...], "spacing": 0.15 (m between pipes), "margin": 0.1 (m from the walls), "max": 100 (m, the longest circuit), "manifold": its placement (ports VL1/RL1, VL2/RL2 ...; the next free pairs are taken), "entry": [x, y, z] (where the pipes come in; default at the manifold), "type": "PE-X 16x2"}

The design heat load of each room from the building model, as EN 12831-1 sets it out: transmission through each element (area × U × temperature difference) and ventilation (air change × volume). The walls along the room's outline and what lies behind them (another room at its temperature, else the outside), their windows and doors, the room below or the ground (a slab on ground by EN ISO 13370: B' from the ground floor's area and outline, the walls' thickness, the soil; with f_g1 and G_w against the annual mean), the room above or the slab or roof over it, and heating up after a setback. U-values from the types' layers (EN ISO 6946) or as given by type name or kind (window, door, wall, floor, ceiling, roof). The design outside temperature, the rooms' temperatures and air changes are the planner's (the national annex's tables are not part of the program); defaults are named in the result. Gives each room's load by number ("loads", for balance and radiatorcheck), a table, a CSV and a protocol with every element on sheets of its own.

JSON-Form: heatload {"outside": -12 (°C; default the climate's), "inside": 20, "temperatures": {"0.03": 24} (by room number or name), "ground": 9 (°C; default the climate's annual mean), "air": 0.5 (1/h), "airs": {"0.03": 1.5}, "u": {"Außenwand 36,5": 0.24, "window": 1.1, "door": 1.6, "F1": 0.9, "floor": 0.3} (W/(m²K) by type name or kind), "bridges": 0.05 (ΔU, W/(m²K)), "reheat": 0 (W/m² for heating up), "soil": 2.0 (W/(mK)), "fg1": 1.45, "groundwater": false, "groundLevel": -0.3 (the ground's height at the building: outer walls below it lie against the earth), "height": 2.5 (m where nothing is over a room), "place": [x, y, z], "path": "heizlast.csv", "protocol": true | {"sheet", "paper", "project", "address", "by", "date", ...}, "language": "en"|"de"}

Checks the drinking water hygiene a plan can show (DVGW W 551 in its way of reckoning): the water standing in the hot water pipes between each outlet and where the water circulates (the heater without circulation) against 3 liters, from the pipes' inner diameters and lengths; and the pipes that lead to no outlet (dead legs).

JSON-Form: hygienecheck {"from": the water heater (default the selection), "flow": "PWH", "return": "PWH-C", "limit": 3 (l)}

Insulates pipes (Dämmung): a thickness in mm on the connections, of a material and its thermal conductivity (default 0.035 W/(m·K)), or what the GEG asks (Anlage 8; since 2026 the GModG): by the pipe's inner diameter from its type ("Cu 22x1", "PE-X 16x2" outer by wall; "DN 20" the inner), 20 mm up to 22 mm, 30 mm up to 35 mm, the inner diameter up to 100 mm, then 100 mm, for heating, hot water and circulation pipes ("heating"); half in wall and ceiling openings or between users ("half"), 6 mm in the floor build-up ("floor"), double towards outside air ("outside"), 9 or 19 mm on cooling pipes ("cooling"). geg true takes the case from each pipe's system and leaves out cold drinking water and floor heating circuits. Another conductivity converts the thickness so the layer insulates as well, rounded up to whole mm. The pipe list counts insulation, the IFC export writes it as coverings; split pipes keep it. One undo step.

JSON-Form: insulate {"ids": [pipes] (default the selection), "system": "Heizung Vorlauf" (all of it, or only those of it among the ids), "thickness": 20 (mm) | "geg": true (each pipe as the GEG asks by its system) | "geg": "heating"|"half"|"floor"|"outside"|"cooling" | "remove": true, "material": "Mineralwolle", "conductivity": 0.035 (W/(m·K))}

Checks the insulation of pipes against the GEG (Anlage 8; since 2026 the GModG): heating, hot water and circulation pipes by their system ("Heizung Vorlauf", "Trinkwasser warm", "Zirkulation") and cooling ones, each against the thickness its inner diameter needs, converted to its insulation's conductivity; or every pipe given against one case ("geg"). Tells the pipes not insulated or too thinly, and selects them; changes nothing. Cold drinking water (a norm, not the GEG) and floor heating circuits are not checked.

JSON-Form: insulationcheck {"ids": [pipes] (default the selection, else all), "system": "Trinkwasser warm", "geg": "heating"|"half"|"floor"|"outside"|"cooling" (default by each pipe's system), "select": true}

The bill of materials of pipe networks (Materialauszug): the length of pipe by system and type (along the runs, risers included), and the fittings they need, counted from the drawing: a bend at each corner of a run (15, 30, 45, 60 or 90°, else its own angle), a tee where a branch leaves (block T-Stück or Abzweig, as connect puts them in; reducing when the sizes differ), a cross where four meet, a reducer where two sizes meet at a fitting; flexible pipes (PE-X, PE-RT, multilayer composite) are bent, not joined, at corners. Pipes are connections whose type names a nominal size ("DN 20 Cu"), or with "system" all of that system ("PE-X 16x2" of a floor heating). Insulated pipes (insulate) add their insulation in meters by thickness and material. Ducts, whose type starts with their size ("400x200", "ø160"), count in meters and sheet metal area (perimeter by length). As a table ("place"), CSV ("path") or only the data.

JSON-Form: pipelist {"system": "Trinkwasser kalt" (only these; default all), "ids": [pipes] (default every connection with a DN in its type), "place": [x, y, z] (draws it), "path": "material.csv", "separator": ";", "language": "en"|"de"}

The plan of the pipes as fitters' drawings show them, made from the network: each pipe two-lined at its outer size with its insulation (its system's color where netsystem defines it), dashed where it runs in a wall or under the floor, and each riser as its symbol: a circle at its size, an arrow up or down the way it runs, its system and type. On a layer of its own (Rohrplan); run again, the plan of before goes. The pipes stay one line each.

JSON-Form: pipeplan {"systems": ["PWC", "PWH"] (default all), "riser": 0.5 (m: how high a vertical piece must be to be a riser), "remove": true, "language": "en"|"de"}

Where pipes and ducts go through walls and floors, the voids to provide for them (Schlitz- und Durchbruchsplanung): a box through the wall, or for a round pipe through a floor a core hole, as large as the pipe or duct (from its type: "Cu 22x1", "DN 100", "400x200", "ø160") with its insulation and the clearance all round, rounded up; numbered D01 ..., on their own layer, listed with the part, its stage (existing: a breach, new: a recess), the size and the height of its bottom. They go to IFC as provisions for voids for the structure's planner. The structure's planner approves or rejects each ("approve", "reject"); run again, the suggestions are made anew, the approved and rejected stay, and where one stands no new one is suggested. Walls coming down and holes there already are left out.

JSON-Form: provisions {"ids": [connections] (default all), "clearance": 0.025 (m all round), "round": 0.05 (sizes rounded up to, m), "place": [x, y, z] (the list), "path": "durchbrueche.csv", "language": "en"|"de"} | {"approve": ["D03", ...]} | {"reject": [...]} | {"suggest": [...]} (the structure's planner's answer)

What the radiators give at the system's flow and return temperatures, room by room: each one's nominal output at 75/65/20 °C (its value "output", field NORMLEISTUNG, or by type in "outputs") times (ΔT / 49.83 K) to the power of its exponent, ΔT the logarithmic mean excess over the room. Against the rooms' heat loads (given, by room number) it gives each room's cover and, where short, the nominal output it would need (to swap the radiator or lower the flow temperature less). A check for planning, no proof; the heat load itself (DIN EN 12831) is not reckoned here.

JSON-Form: radiatorcheck {"flow": 55, "return": 45 (°C), "inside": 20 (°C, default 20), "temperatures": {"0.03": 24} (by room number), "loads": {"0.01": 1200} (each room's heat load, W), "outputs": {"Typ 22 600/1000": 1650} (nominal outputs at 75/65/20 by type, W, where the radiators lack them), "exponent": 1.3 (where they lack theirs), "place": [x, y, z], "path": "heizkoerper.csv", "protocol": true | {"sheet", "paper": "A4", "project", ...} (a protocol on sheets of its own), "language": "en"|"de"}

The ventilation concept of a dwelling (DIN 1946-6 in its way of reckoning): whether the air through the envelope (infiltration, given or from n50, the volume and the standard's factor) covers moisture protection, else a ventilation measure is needed; and each room's air for one: kitchens, baths and WCs exhausting at the flows given, scaled up together to the nominal ventilation, the other rooms supplied by their area, halls letting it pass. Rooms and volumes from the model; the standard's values are the planner's. Table and form (protocol).

JSON-Form: ventconcept {"ids": [rooms] (default all), "moisture": 55 (m³/h for moisture protection), "nominal": 120 (m³/h nominal ventilation), "infiltration": 40 (m³/h) | "n50": 1.5, "factor": 0.08, "exhaust": {"Küche": 45, "Bad": 45, "WC": 25} (m³/h by room), "height": 2.5, "place": [x, y, z], "protocol": true | {...}, "language": "en"|"de"}

A two-leg bridle as arenas want it shown: each leg's length, its angle from the vertical, the angle between the legs and the force in each leg (kg and kN) and pulling sideways at its anchor, from the load at the apex. The apex must lie under the line between the anchors, else the load swings; past 120° between the legs each carries more than the load. "draw" draws the legs with their values. A first design, no proof.

JSON-Form: bridle {"anchors": [[x, y, z], [x, y, z]] (the roof points the legs hang from), "apex": [x, y, z] (where the hoist hangs), "load": 500 (kg, the hoist with it), "draw": true (the legs with their length, angle and force), "language": "en"|"de"}

Follows the DMX lines as they are cabled (connect between ports of kind DMX or XLR): from each desk or node output (a device without a DMX input; its output's name gives the universe, "U2" or "B") along each device's thru, a splitter (an input and two or more outputs) starting a new line on each output. Checks each line: no more devices than "loads" (32, RS-485's unit loads), no longer than "length" (300 m), each fixture patched (field ADDRESS) in the line's universe; names the device at its end, where the terminator goes, cables joining two inputs or two outputs, inputs fed twice, outputs split without a splitter, loops and fixtures no line reaches. "place" writes the lines as a table.

JSON-Form: dmxflow {"loads": 32 (devices a line takes), "length": 300 (m a line may run), "place": [x, y, z] (the lines as a table), "select": true (what is wrong), "language": "en"|"de"}

Adds up fields of the placements, grouped by the value of another field: the weight and power of the fixtures per position or truss (field POSITION, which hang fills in), per distributor, per room. Numbers are read as fields hold them ("7,5", "180 W"); a field without a number is counted as missing, not as zero, and shown. "having" keeps only placements with a field (ADDRESS: the fixtures). As a table ("place") or CSV ("path"), with a total.

JSON-Form: fieldsum {"by": "POSITION" (the field to group by), "sum": ["WEIGHT", "POWER"] (fields to add up), "having": "ADDRESS" (only placements with this field), "ids": [placements] (default all), "place": [x, y, z] (as a table), "path": "totals.csv", "language": "en"|"de"}

Checks the fire brigade's access along its centre line, as the fire service does first (Muster-Richtlinie über Flächen für die Feuerwehr): the clear width between the obstacles on both sides at every station, at least 3.00 m straight and in a curve by its outer radius (10.5–12 m: 5.0 m, to 15 m: 4.5, to 20 m: 4.0, to 40 m: 3.5, to 70 m: 3.2, beyond: 3.0; under 10.5 m it fails), corners without a curve, slopes over 10 %, and that each movement area holds 7 × 12 m and is free. Obstacles are what lies on the layers given (default: all but the road's own, texts, hatches and points left out); what hangs higher than the clear height passes. Narrow stretches are drawn red and what narrows them selected. A check for planning; the fire service decides.

JSON-Form: fireaccess {"road": id (the access road's centre line, a polyline with its curves as arcs), "areas": [ids] (movement areas, closed outlines), "obstacles": ["Zaun", "Bühne"] (layers; default all but the road's), "ignore": ["Wege"] (layers left out), "width": 3.0 (m straight), "height": 3.5 (m clear height: what hangs higher passes), "slope": 10 (% at most), "step": 1.0 (m between stations), "mark": true, "select": true, "language": "en"|"de"}

Labels the lighting plan's fixtures as label legends do: each one's fields shown round it, by default its fixture id (the desk's channel) above, its DMX address below and its colour (field COLOR) to the right; several on one side stack. The labels are the fixture's own fields: they move, turn and hang with it and show its values as they change (patch, attedit). They read level and upright in the plan however the fixture is turned, "height" millimeters high on paper. "hide" hides them again.

JSON-Form: fixturelabel {"ids": [fixtures] (default the selection, else all), "fields": {"FIXTUREID": "above", "ADDRESS": "below", "COLOR": "right"} (the default; "left", "center" too), "height": 2.5 (mm on paper) | "hide": true

Takes a lighting fixture type from its maker's GDTF file (DIN SPEC 15800, as GDTF Share offers them) instead of drawing it: a symbol of the type with its 3D parts at rest, hanging as GDTF draws them, and the fields lighting programs go by (name, fixture id, unit, DMX address, type, mode, class, position) plus what the type says: WEIGHT (kg, rigload weighs it), POWER (W), CHANNELS (the mode's DMX footprint, patch takes it) and BEAM (the beam angle, lightbeam draws the light with it). The file stays in the drawing, so an MVR export carries it. "position" places one; insert places more. "search" finds GDTF files by words of their names in a folder (the libraries' folders if none is given); {} lists the types the drawing holds with their modes and channels.

JSON-Form: gdtf {"path": "Robe_Lighting@Robin_T1_Profile.gdtf", "mode": "Mode 1" (default the first), "name": "Robin T1" (the symbol; default maker and type), "position": [x, y, z] (places one) | "search": "robin t1", "folder": "~/GDTF" (default the libraries' folders) | {} (the types in the drawing)

Hangs devices (lighting fixtures, speakers: symbols in the model) on a truss, as lighting plans hang them on a hanging position: each goes onto the truss's line by its hanging point (its block's port of kind "hang", else its base point), at the truss's height, or "offset" meters from the line (half the truss's height puts it under the bottom chord); "way" turns it about the truss: hanging under it, standing over it or clamped at the side. Its field POSITION names the truss. From then on it moves with the truss: moved, turned, raised or stretched by any command, the truss takes its devices along (a stretched one keeps them by the end that stayed), and rigload counts them on that truss. Dragged alone onto another truss a device hangs there, off its truss it is loose. Without "truss" each hangs on the truss it lies on in plan. "remove" takes them off; {} with nothing selected lists what hangs where.

JSON-Form: hang {"ids": [devices] (default the selection), "truss": "T1" | id (default the truss each lies on in plan), "way": "under"|"over"|"side", "offset": 0.145 (meters from the truss's line: below it, above it or beside it), "snap": true (onto the truss; false: where it is), "reach": 0.3 (meters) | "remove": true | {} with nothing selected (lists what hangs where)

Makes points or symbols hoists or hanging points (Kettenzüge, Anschlagpunkte): what they may carry (WLL), what they weigh themselves (the roof carries it too) and their type; a symbol's fields WLL and EIGENGEWICHT are taken where it has them. A truss hangs from the hoists that lie on it (rigload). "remove" makes them plain again.

JSON-Form: hoist {"ids": [points, symbols or circles] (default the selection), "name": "M1" (one hoist; default the next free M number), "capacity": 500 (WLL, kg; default its field WLL), "weight": 50 (its own weight with the chain, kg), "type": "D8+ 500 kg" | "remove": true}

An LED wall of panels, straight or curved ("curve": degrees each column turns from the last): its size, resolution and pixel pitch, its weight in all and each column's (for the flybar or the ground stack), its power at most and the current a phase on three, the data ports it takes (the panels snaked up and down the columns, as many to a port as its pixels allow, 655,360 a 1 Gbit port if not given) and the circuits (16 A at 230 V if not given). The panel's values are the maker's: from its block's fields WIDTH, HEIGHT, PIXELS, WEIGHT and POWER (a pack's panel) or given as "panel". Drawn in one step: the panels, the data chains in front of them and the wall's values.

JSON-Form: ledwall {"block": "panel's block" (fields WIDTH, HEIGHT in m, PIXELS "128x128", WEIGHT kg, POWER W) | "panel": {"width": 0.5, "height": 0.5, "pixels": [128, 128], "weight": 7.5, "power": 180}, "columns": 8, "rows": 5, "at": [x, y, z] (bottom left, seen from the front), "angle": 0 (degrees in plan), "curve": 0 (degrees each column turns), "port": 655360 (pixels a data port carries), "circuit": 3680 (W a circuit carries), "depth": 0.08 (m, a panel drawn from values), "draw": true, "language": "en"|"de"}

Each fixture's light as a cone, to see where it falls: from the fixture to the point it aims at (straight down if none is given), with its beam angle from the field BEAM (gdtf fills it in from the maker's file) or "angle". Reports the throw, the beam's diameter there and the spot on the floor (the cone's section with the floor, an ellipse; none once its far edge reaches past the horizon), and draws the spot, four lines of the cone, the beam's circle at a focus above the floor and the values, in one step. A picture for planning, no photometry.

JSON-Form: lightbeam {"ids": [fixtures] (default the selection), "focus": [x, y, z] (where they aim; default straight down), "angle": 25 (degrees; default each fixture's field BEAM), "floor": 0 (the floor's height), "draw": true, "cones": false (each beam also as a cone body, for the 3D picture), "language": "en"|"de"}

A line array of loudspeakers as it hangs: its elements one under the other from the bumper, each turned down from the one above by its splay angle (hinged at the front), the top one at "tilt". Reports each element's angle, the array's height and weight with the bumper, its centre of gravity and, with two pick-up points on the bumper, the load on the front and the rear one (or that it tips, a point having to push), with one point where the centre lies from it. The element's values are the maker's, from its block's fields WEIGHT, HEIGHT, DEPTH (a pack's) or given. Drawn in side view standing in the vertical plane it faces along. A first design, no proof: the maker's rigging software has the last word.

JSON-Form: linearray {"block": "element's block" (fields WEIGHT kg, HEIGHT and DEPTH m) | "element": {"weight": 60, "height": 0.35, "depth": 0.5}, "count": 12, "splay": 2 | [0, 1, 2, ...] (degrees between elements), "tilt": -2 (the top element's, down negative), "bumper": 40 (kg), "bumperDepth": 0.6 (m), "pickups": [0.05, 0.55] (m back from the bumper's front; one or two), "at": [x, y, z] (the bumper's front edge), "angle": 0 (where it faces in plan), "draw": true, "language": "en"|"de"}

The lighting plan's DMX patch. Every fixture (a symbol with the field ADDRESS, as gdtf and MVR make them) takes from its address ("2.001" or absolute "513") as many channels as its mode has: its field CHANNELS, else its GDTF type's mode. Checks and selects what costs a load-in: fixtures sharing channels (with the same start, footprint and fixture id that is a multi-patch, named but meant), a fixture running past the end of its universe (512), an address that is none, one fixture id on fixtures patched apart. "auto" patches fixtures one after another from "universe"/"address", each where it fits whole around what others hold, a universe further where it no longer does; "number" numbers their fixture ids in the same order. "place" draws the patch list, "path" writes it as CSV.

JSON-Form: patch {} (checks the patch) | "auto": true (patches the selected fixtures, or those without an address), "universe": 1, "address": 1 (where to start), "order": "fixtureid"|"x"|"y"|"selection", "number": 101 (numbers their fixture ids from it) | "clear": true (their addresses away) | "place": [x, y, z] (the patch list as a table), "path": "patch.csv", "language": "en"|"de", "select": true (the fixtures at fault)

Checks an event's power distribution: from each feed (a generator, a supply: a device without an input) through the distributors to the consumers, the load on every outlet (the consumers' field POWER or LEISTUNG below it, times "factor") as current against what its connector and the input it feeds carry, each three-phase input's phases L1 to L3 (single-phase outlets on the phase their name says, the rest shared out), the voltage drop along the cables (their length, the copper section their type names, "5G6", "3G2,5") summed from the feed against "drop" percent, plugs that don't match, cables joining two outlets, loops, devices nothing feeds. Connectors are the ports' kinds: "CEE 16/3" (230 V), "CEE 16/5", "CEE 32/5", "CEE 63/5", "CEE 125/5" (400 V), "Schuko", "Powerlock" (400 A); a port's size is its current where the maker says otherwise. Inputs are the ports named in… or Ein…; a device of one power port is a consumer and that port its input, unless it is named out… or Aus… (a feed of one outlet). Connections from connect join them. A first design at cos φ 1: breakers and cables are the electrician's.

JSON-Form: powerplan {"factor": 1 (the share running at once), "drop": 5 (% voltage drop allowed from the feed), "place": [x, y, z] (the load list as a table), "path": "last.csv", "select": true (what is overloaded or wrong), "language": "en"|"de"}

The rental and packing list of what the drawing places: each symbol counted under its article number, the trusses in stock pieces with their corners and connector sets (as trusslist makes them up). The article numbers are the company's: a field of the symbol (ARTIKEL, ARTICLE or CADCODE), or "map", a table of names (symbols, "F34 3,00 m", "F34 Ecke 90°") and numbers. As CSV ("path") Rentman reads it into a project's equipment, matching the column CAD-code; easyjob and others take it as a table. Lines without a number keep their name and are counted in the answer.

JSON-Form: rentallist {"ids": [objects] (default the selection, else the whole model), "map": "artikel.csv" (name; article number; its name) | {"Scheinwerfer": "10234"}, "field": "ARTIKEL" (default ARTIKEL, ARTICLE or CADCODE), "trusses": true (in stock pieces; "lengths", "corner", "chords" as trusslist), "path": "mietliste.csv", "place": [x, y, z] (as a table), "language": "en"|"de"}

The load on each hoist from the trusses hanging from it and the devices on them (their field GEWICHT): each straight piece of a truss as a continuous beam on the hoists along it, its own weight spread along it, the devices where they hang; times the dynamic factor, against what each hoist may carry (WLL), with the hoist's own weight for the roof, and the chain down to the truss where they have heights. Overloaded hoists and those the trusses would lift are named. A first design (Vorbemessung), no verifiable proof: the venue's rigger or a structural engineer checks it.

JSON-Form: rigload {"factor": 1.2 (the dynamic factor; default 1), "reach": 0.3 (meters off a truss a hoist or device still counts as on it), "place": [x, y, z] (the table, and each hoist's load beside it), "path": "lasten.csv", "language": "en"|"de"}

The venue's load plan checked: each hoist under the roof point nearest to it in plan (within "reach"), the point carrying what rigload gives each hoist for the roof (load times the dynamic factor, plus the hoist's own weight), added up, against what the point may carry: a field of its symbol (WLL, LAST, ZUL, MAX, SWL, LOAD) or the label nearest to it that states a load ("500 kg", "1.000 kg", "1,5 t"), as imported plans write it. Overloaded points, points without an allowed load and hoists under none are named and selected. A hoist on a bridle counts on the point nearest to it: give the bridle's legs their own points. A first design, no verifiable proof.

JSON-Form: roofload {"layer": "Dachpunkte" (all points, circles and symbols on it) | "points": [ids] (the venue's roof points), "field": "WLL" (what a point may carry; default the fields WLL, LAST, ZUL, MAX, SWL, LOAD, else the nearest label stating "500 kg" or "1,5 t"), "reach": 0.5 (m in plan from a hoist to its point), "factor": 1.2 (dynamic, as rigload), "place": [x, y, z] (the table, and each point's load beside it), "path": "dachlasten.csv", "select": true, "language": "en"|"de"}

The rule profile the drawing's assembly site is checked by: which Land's ordinance or which case (a room, the open air) holds. The program knows the model code's values (MVStättV); a profile sets others for exitwidth (outdoors, perWidth, outdoorPerWidth, step, minimum, smallMinimum, smallLimit), seatcheck (outdoors, seatWidth, passage, aisle, rowsPerBlock, oneSide, twoSides, wheelchairShare, wheelchairMin, tableSpacing, tableReach), escapedistance (limit), evacuation (rate, stairRate, speed, delay, target) and visitors (density). They take its values where a call gives none and name the profile in what they report. Profiles are content: a pack's block "Regelprofil …" with fields as EXITWIDTH.OUTDOORPERWIDTH = 600, NAME and SOURCE; "use" takes one in, "set" changes values, "clear" goes back to the model code. One step.

JSON-Form: rules {} (show the profile in use and those within reach) | "use": "Bayern, im Freien" (the block "Regelprofil Bayern, im Freien" from the drawing or an installed pack) | "set": {"exitwidth": {"outdoors": true, "outdoorPerWidth": 600}, "seatcheck": {"oneSide": 20}, "visitors": {"density": 2}} (null: back to the model code's) | "clear": true, "name": "Bayern, im Freien", "source": "BayVStättV § 7, § 10"

Checks seats in rows against the rules for assembly venues (§ 10 of the model ordinance; Bavaria's values unless "rules" says otherwise): seat width, clear passage between rows, rows per block, seats beside one aisle and between two (doubled outdoors), aisle widths, wheelchair places (1 %, at least two). Rows are found along the seats' direction, broken where an aisle runs through, blocks parted by cross aisles. With "tables": 1.50 m between the tables (measured between the blocks, benches included) and no place more than 10 m from an aisle. Selects the seats at fault. A check for planning, not the authority's approval.

JSON-Form: seatcheck {"block": "Stuhl" (the seats: its placements) | "ids": [seats] (default the selection), "outdoors": false, "tables": false (the placements are tables or table sets), "persons": 10 (at each placement), "ends": "aisle"|"wall" (the rows' outer ends), "wheelchair": "Rollstuhlplatz" (its block), "depth": 0.45 (a seat's depth, m; default its block's), "rules": {"seatWidth": 0.5, "passage": 0.4, "rowsPerBlock": 30, "oneSide": 10, "twoSides": 20, "aisle": 1.2, "wheelchairShare": 0.01, "wheelchairMin": 2, "tableSpacing": 1.5, "tableReach": 10}, "select": true}

Numbers a seating block as tickets name its seats: the selected seats fall into rows (straight ones by their distance from "front", a point at the stage; curved ones by their radius round "center"), rows counted from the front (numbers or letters), seats along each row from the left as seen from the seats towards the stage (or the right). Writes each seat's fields BLOCK, ROW and SEAT in one step, optionally labels, and with "path" the list for the ticketing system (CSV: Block;Reihe;Platz;X;Y in meters).

JSON-Form: seatnumbers {"ids": [seats] (default the selection), "name": "Parkett links" (the block on the tickets), "front": [x, y] (a point at the stage, straight rows) | "center": [x, y] (curved rows round it), "from": "left"|"right" (seen towards the stage), "rows": "numbers"|"letters", "firstRow": 1, "start": 1 (the first seat's number), "tolerance": 0.3 (m a seat may lie off its row), "label": false (the number in each seat, the row at its ends), "path": "tickets.csv" (Block;Reihe;Platz;X;Y for the ticketing system)}

Hands the rig to the structural engineer as a member model, in one CSV of sections: nodes (m), members (each truss's straight pieces cut at its hoists and devices, with their system as the section and their own weight in kN/m), supports (a node under each hoist, held vertically, with its WLL) and nodal loads (each device's weight times the dynamic factor, in kN). Pieces meeting at a corner share a node. RSTAB, RFEM or SCIA take the tables in; the engineer sets the sections and restraints. A handover, no calculation.

JSON-Form: structuralmodel {"path": "stabwerk.csv", "ids": [trusses] (default all), "factor": 1.2 (dynamic, on the devices' loads), "reach": 0.3 (m off a truss a hoist or device still counts), "language": "en"|"de"}

The swept path (Schleppkurve) of a vehicle along a road: the middle of its front axle follows the line, the rear axle trails it at the wheelbase (a tractrix, cutting inside in curves), the body with its overhangs sweeps the area its four corners trace. Draws the corners' traces and the rear wheels' (blue), tests the body against the obstacles at every step and draws it red where it strikes; reports the widest sweep. The vehicle's measurements are content: a pack's block with its fields, or "vehicle". For planning; the maker's turning data decide.

JSON-Form: sweptpath {"road": id (the line, polyline with its curves as arcs, or alignment the front axle's middle follows; "id" the same) | "points": [[x, y], ...], "reverse": false (along it backwards), "vehicle": {"wheelbase": 4.6, "width": 2.55, "front": 1.5, "rear": 2.7, "track": 2.5} (m) | "block": "HLF 20" (a pack's vehicle: fields RADSTAND, BREITE, UEBERHANG_VORN, UEBERHANG_HINTEN or WHEELBASE, WIDTH, FRONT, REAR), "obstacles": ["Zaun"] (layers; default all but the road's), "ignore": ["Wege"], "height": 3.5 (m: what hangs higher passes), "step": 0.25 (m), "outlines": 5 (the vehicle drawn every so many m; 0 none), "draw": true, "select": true, "language": "en"|"de"}

Makes lines or polylines trusses (Traversen, pipes, beams that hang): what they weigh per meter and what system they are. rigload then finds the hoists they hang from and the devices on them along them. "remove" makes them plain lines again.

JSON-Form: truss {"ids": [lines or polylines] (default the selection), "name": "T1" (one truss; default the next free T number), "weight": 7.2 (kg per meter), "system": "F34" | "remove": true}

The trusses' parts list, by system: each straight run between corners and ends made up of stock lengths, the fewest pieces that give its length to the centimeter (else the shortest that cover it, the overrun named), the corners by the angle between their legs, the connector sets (one per chord at every joint) and the weight from each truss's weight per meter. Stock lengths and a corner's leg are the maker's data; without them common metric lengths and corners that take no length.

JSON-Form: trusslist {"ids": [trusses] (default the selection, else all), "lengths": [4, 3, 2.5, 2, 1.5, 1, 0.5] (stock lengths, m: the maker's), "corner": 0.5 (m: how far a corner reaches into each side, its leg), "chords": 4 (connector sets per joint), "place": [x, y, z] (as a table), "path": "traversen.csv", "language": "en"|"de"}

How far each span of a truss is used, against the maker's loading table: each span between two hoists as the single span the tables are made for, its devices (field WEIGHT) times the dynamic factor, its largest moment and shear against what the table's column for as many loads allows (one: CPL, two: TPL, three: QPL, four: FPL, more or "spread": UDL), read at the next longer span. The table is content: a block named as the truss's system (truss "system") with the fields SPAN, UDL, CPL, TPL, QPL, FPL from a pack, or "tables". Cantilevers, continuous beams and spans longer than the table are named: they need a calculation of their own. Overloaded trusses are selected. A first design (Vorbemessung), no verifiable proof.

JSON-Form: trussload {"tables": {"Prolyte H30V": {"span": [2, 4, 6], "udl": [kg/m], "cpl": [kg], "tpl": [kg], "qpl": [kg], "fpl": [kg]}} (default: a block named as each truss's system, its fields SPAN, UDL, CPL, TPL, QPL, FPL as "2;4;6"), "factor": 1.2 (dynamic; default 1), "spread": 5 (kg/m along every truss, as cables), "reach": 0.3 (m), "place": [x, y, z] (the table, each span's use at its middle), "path": "traversen.csv", "select": true, "language": "en"|"de"}

The visitor numbers a seating or site plan states for the authority: seated places (the seats' blocks, a table's persons with "each"), wheelchair places, standing places (the areas' size times "density", 2 per m² by the codes) and the highest number of visitors. "place" puts them as a table, with the approval box of 105 × 58 mm under it; the table counts the seats on as they are placed and erased. Fields named SITZPLAETZE, STEHPLAETZE, ROLLSTUHLPLAETZE, BESUCHER (or SEATS, STANDING, WHEELCHAIRS, VISITORS) of the title block are filled in. Without "place" the tables made before are brought up to date where they are. A seating variant (each on its own layer, its sheet showing it by a layer state) gets its own count with "layer": only the seats on it, a table of its own.

JSON-Form: visitors {"seats": "Stuhl" | ["Stuhl", {"block": "Tisch", "each": 10}], "wheelchair": "Rollstuhlplatz", "standing": [ids] (closed outlines or hatches; a hatch leaves out what stands in it), "density": 2 (persons per m² standing), "place": [x, y, z] (the table's top left; on a sheet in mm), "approval": true (the 105 × 58 mm approval box under it), "layer": "Bestuhlung A" (a seating variant: only what lies on it), "language": "en"|"de"}

After work made while away came into a drawing shared live: the objects changed here that someone else changed meanwhile (or reserved). The session kept theirs. Without "keep" it lists them (id, theirs and yours as type and layer, who holds a reserved one); "keep": "theirs" settles them as they are, "keep": "mine" brings back your version in one step everyone gets (undo takes it back). "ids" settles only those; default: all.

JSON-Form: conflicts {"keep": "mine", "ids": [12]}

Remarks and tasks about the model, as BCF topics travel between Revit, Archicad, Solibri and BIMcollab: a title, a type and status (Open, In Progress, Resolved, Closed: as you write them), priority, who it is assigned to, labels, a due date, comments, and the views it was seen in (camera, picture, the objects it is about, named by the IFC GlobalIds the IFC export gives them). "show" goes to its own (first) view and chooses its objects. export and import with a .bcf file take them out and in (BCF 2.1; 2.0 and 3.0 are read), so a coordinator's clashes from Solibri come in and our remarks go out.

JSON-Form: issue {} (lists them) | {"title": "Stütze kollidiert mit Fenster", "description": "...", "type": "Issue"|"Clash"|"Request"|"Remark", "status": "Open", "priority": "High", "assignedTo": "Statik", "labels": [...], "due": "2026-11-15", "ids": [objects it is about], "view": true (the view on screen, default), "snapshot": "shot.png"} (a new one) | {"issue": guid, number from 1 or title, ...the same fields} (changes it) | {"issue", "comment": "text", "view": true, "ids": [...]} (a comment, with a view of its own if asked) | {"issue", "show": true} (its view and objects) | {"issue", "delete": true}

Who works on the drawing now, and on what: the user of this app (their selection and running command), the others in a live session with what they run and have selected, how they look at the drawing ("view": camera target, distance, yaw and pitch in degrees, sheet, storey shown alone, the planes cutting it open as sectionbox takes them), whether they present (everyone's view follows theirs) and the agents at work in their apps (with the objects of their last steps), the comments people left on the session's published link in the browser meanwhile (who, what, where: to answer or act on), and the objects someone else changed in the last minute, and what is reserved by whom ("reserved": only who holds it changes it). An agent asks this before it changes something and leaves alone what others are on: what someone else changed in the last 20 seconds it may not change ("leaveAlone").

Releases reserved objects in a drawing shared live, the given ids or else the selection; "all": every one you hold. Someone else's only with "others": true, which the drawing's owner may (on a server without accounts anyone working in it). presence lists who holds what.

JSON-Form: release {"ids": [12], "all": false, "others": false}

Reserves objects in a drawing shared live (as Archicad's Teamwork does), the given ids or else the selection: until they are released only you change them; the others' apps and the server refuse to. The server answers everyone; presence lists who holds what. Only while connected to the live session.

JSON-Form: reserve {"ids": [12, 13]}

Makes the drawing that of a kept version of a shared drawing again (as the server gives it out: snapshot and changes), in one step: undo takes it back, and everyone in the live session gets it. Objects made since go, those erased since come back.

JSON-Form: restoreversion {"version": {"snapshot": "…", "changes": […]}, "name": "Stand für den Statiker"}

Skills are ways of working written down in plain words: how this office or project draws plans for a building permit, how a survey becomes a model. Each has a name, a line on when to use it, its steps, the commands it may use and the checks to run at the end. They come from the project (a Skills folder beside the drawing), the person's own folder and packs (linked library folders). Without parameters it lists them; with "name" it gives one to follow; "save" writes one down (from what the user explained), "delete" removes one of one's own.

JSON-Form: skill {} (lists them) | {"name": "Bauantrag-Grundrisse"} (its steps, the commands it uses, its checks) | {"save": "name", "description": "when to use it", "text": "the steps", "commands": [...], "checks": [...], "where": "own"|"project"} (writes one down) | {"delete": "name"}

Named states of a drawing (Stände), as Archicad and the BIM 2.0 programs keep versions: "save" keeps the drawing as it is now under a name, with who and when, as a drawing of its own in a folder beside its file (Haus.versions), which can be opened as any drawing. "compare" lists the objects added, removed and changed since a state (by their ids, which never change; their order on top of one another doesn't count) and marks them in the app. "take" brings objects back as they were in a state, "restore" all of them: one step, which undo takes back. Objects that came back get new ids. A state is named by its number or its name. "variant" keeps the drawing as the state a variant branches at and writes a copy beside it (Haus (B).frame) to work on; "merge" brings a variant's changes since then back (or the drawing's into the variant), object by object: what only the other changed comes over, what only this drawing changed stays, objects changed on both sides are listed and stay as here unless "prefer": "other".

JSON-Form: version {} (lists the drawing's states) | {"save": "Entwurf A", "note": "..."} (keeps the drawing as it is now) | {"compare": 3 | "Entwurf A"} (what was added, removed and changed since) | {"take": state, "ids": [...]} (those objects as they were) | {"restore": state} (all of them) | {"variant": "B"} (branches a copy off, "Haus (B).frame") | {"merge": "Haus (B).frame", "prefer": "drawing"|"other"} (its changes since the branch, object by object) | {"clear": true} (no comparison shown)